Danger, Strings (Part 1)

[alexander]

If you have ever developed anything for the web, you would know how easy it is to find yourself in a different language, php, sql, javascript, css, html, maybe some asp for windows integration, some ruby for some back end pieces, little java for back end apis, mix in some bash, and you have a language soup that while it makes sense for a particular project, presents an issue that is not commonly looked and examined, and lies as one of the major causes of vulnerabilities in web apps. The problem ofcourse is interoperability, these languages were not designed to talk to each other, they are completely separate instances, they run on completely separate set of rules, engines, parsers, platforms, and programming practices. And they have no way to talk to each other, no way, that is, other then strings. Well what's so bad about strings? Well, for one, with strings, regardless of the language, we are creating type unsafety by smashing strings together and passing them along. Somewhere along the way we may hit a scripting language that allows for inline code execution or addition, and the injected code will run. Yeah, you may have a java back end, but if you smash String header="your \"good code\"" and String userInput = "my bad code", and output that to my browser, my browser doesn't know where your good code and my bad code starts, it will execute all of it. At the end of the day, it doesn't matter if you have type safe languages, evil strings are the arteries by which XSS and SQL Injection is ultimately possible.

 

But wait, you say, what about escapes? The simple matter is that they just DONT work, evolution has declared escape functions worthless by giving us unicode. Lets take the ever-so-dangerous "'", there are over a dozen characters in unicode that can represent this symbol, and if that is not enough, they do what is called best-fit matching, basically, if a character looks like another character in ascii for example, it will equate to that character when translation occurs. And the beauty is that this works differently on different platforms, different languages, basically unicode has smashed the definition of what it is to be a character, and so escapes simply do not work.

 

So what we need is data separation, our stuff needs to come in on a separate channel from the end user stuff, so that we can tell the end parser to execute our code, and to use the inputs as values. Wait, but we can do that already, can't we? Parameterized queries work just like that, just use those, bang, done, move on. Well problem is it is hard, it is hard to trace through the queries and know the parameters, it is a pain in the butt to write too, you end up with more code, and if you need to retrofit your code, its an awesome pain in the butt, and if you have any query complexity, it becomes a giant mess, Mike Samuel has a good example of it in his article:

 

print 'I met a ? in the ? who had a ? full of ?. He said'

' "Hello, ?, How are you today\?" "Fine," I replied'

' "but I can't seem to find my ?." "Hmm," he said.'

' "I Can\'t help you with that." "How about a ? to'

' make you feel ?\?"',

(profession, landmark, container, species_of_monkey,

proper_name, common_household_item,

'string that used to be tied to a red balloon',

state_of_mind);

 

(This is the end of part one, please insert the next CD labeled "2")

 

Sources:

http://google-caja.googlecode.com/svn/changes/mikesamuel/string-interpolation-29-Jan-2008/trunk/src/js/com/google/caja/interp/index.html