Get off your AMF and don’t REST on JSON

Dan Kuykendall

Fri, 8th August 2014

Speaker Bio 1:
Dan @dan_kuykendall is a founder of NT OBJECTives and has been with the company for more than 10 years. He is responsible for the strategic direction and development of products and services and works closely with technology partners to make sure integrations are both deep and valuable. As a result of Dan's dedication to security, technology innovation and software development, NTO application security scanning software is often recognized as the most accurate because of its sophisticated automation techniques.

Dan joined NT OBJECTives from Foundstone, where he was responsible for the portal interface to the company's flagship product, FoundScan. Prior to Foundstone, Dan was the founder of the Information Security team in the United States branches of Fortis. Dan is a regular blogger on web application security issues on and co-hosts an Information Security Place Podcast. His has presented on the topics of mobile and application security at many of the top security industry conferences such as ISSA (2011), B-Sides (2012-2013), OWASP AppSecUSA (2012), HouSecCon (2010-2012), ToorCon (2013) and THOTCON (2013). Dan has been involved with Web Application Security Consortium and is a regular contributor to many open source development projects including founding the RPM Builder, phpGroupWare and podPress projects.

Learning Objectives:

Dan will explain:

  • HTTP is being used to transport new request formats such as those from mobile apps, REST, JSON, AMF and GWTk, but few security teams have updated their testing procedures.
  • All of these new formats are potential new playgrounds for attackers and pen testers.
  • Demonstrate these new formats and where to attack them on various vulnerable applications. Attendees will learn to leverage their existing pen testing methods.

Questions and answers

Max, Concise Courses:
What’s the JSON learning curve like? I have limited JavaScript – should I learn JavaScript first?

Dan Kuykendall:
No, you don’t need JavaScript at all for JSON. JSON is its’ own format and is a text-based structured [language] so it’s is very easy to learn. JSON basically has ways to escape-out characters, and you don’t need to known JavaScript, it has its’ own format entirely. It was initially created for JavaScript to have an easy way to send and receive large amounts of data that it could process.

Max, Concise Courses:
What is your favorite app testing framework?

Dan Kuykendall:
I use Burp or Fiddler for manual testing and our tool for automated testing, but testing framework like MetaSploit are not as good with the Web Apps with these custom formats, that’s not really what they are good at.

Max, Concise Courses:
Can you share your favorite place for getting resources and learning – maybe OWASP?

Dan Kuykendall:
OWASP has some good stuff that they are doing there. I haven’t seen a lot of people doing this stuff, but I’d say my blog; I’ve been publishing a lot of this stuff and there are a few other people out there doing this but there isn’t very much published stuff. OWASP is great for web security so if you are talking about that OWASP absolutely is a great resource but for this particular topic there is not a lot. [With] AMF I am probably doing the most research that you are seeing out there.

Max, Concise Courses:
Our understanding is that most hacks are still mainly database issues – what is it going to take to make SQL more secure?

Dan Kuykendall:
This is something that I didn’t really get into but if you don’t mind I am going to jump back into my slides here [go to 19:29 in the video for a reference]. The same problems applies here; the name=pair value structures are still a problem. At some point it is taking that data from the application and shoving it into a sequel statement, so that is where sequel injection is still a problem. We see the same thing with AMF interfaces. The problem is that the developers, any time that they are dynamically creating a select statement or an update, they are generating a sequel statement on the fly and then they pass that to the SQL server and they are going to have problems. They are going to end up making the mistake of trusting the data coming from the client.

This was really how I got started down this path: I was attacking an AMF app for a customer on the fly because the scanner wasn’t able to do it and they needed help. They were trusting data that was coming from the AMF client because they didn’t really understand that that data could be manipulated. I always recommend developers to use stored procedures or parameter sequel; things like that that will allow you to let something else deal with the validation of that request and you are not sending a full complete sequel statement into the SQL server, that is always going to cause problems. At some point someone is going to make the mistake. Even if one developer is diligent in about avoiding those mistakes somebody else at some point is going to be working on that code and make that mistake. So, stored procedures and parameter sequel is the way to solve that.