Saturday, February 6, 2010

What So Many Web Programmers Don't Seem to Understand...

...is that all they are doing is playing with strings.

The browser sends you a string. Everything you do with that string is merely to create another string to send back to the client.

That's all we do.

Doubt me? Then you are an idiot. And if you think for a second that any user cares if you are using MVC, Ruby, PHP, .Net (C# or VB or any other flavor), C, D, F#, Haskell, whatever, then you are even more of an idiot.

Your job is to take a request string. Maybe your language splits it out into a nice neat object for you, maybe not. Learn what a request string looks like. Learn to split it up on your own. I did this in VB years ago. I learned a LOT.

Once you figure out that the only thing you know about any page run in your site is what gets sent to you, then you start to understand just how completely insecure your app is. There are some very easy ways that a script kiddie can let the browser generate a real request, stop that in its tracks before it actually gets sent, and alter any data in it that he wants.

What does this mean to you? It means that no matter how much touchy feely javascript/validator methods you have in the client, you can't trust anything you receive in a request object. You must ALWAYS verify data content, field lengths, formats yourself. You must ALWAYS determine if the cookie that tells you that userA is logged in is valid and makes sense. You must ALWAYS determine if userA has rights to edit the object that the request claims to want to edit.

Real world example. Orders on a site are numbered sequentially. It happens. userA has placed order5. userA is a hacker, and tries to edit the shipping address of a previously placed order, order3. You MUST check to see if userA has rights to edit order3.

No MVC, framework, library, whatever, will ever be able to do that work for you.

So, back to my original point, all you do is play with strings.

What does this mean to you? Get off your high horse about what language you are using. All that we should ever care about is what language is faster for us, and still gives us the flexibility to control, to a minute detail if needed, what string gets return back to the client.

No comments:

Post a Comment