Why you should never trust client computers when building web apps

[giza]

This is a short and informative video that shows just how easy it is to take advantage of a web application where security was not given much thought:

Watch on YouTube

If you're writing web apps and not sanitizing your input, then this may have happened to you already. You're logging all accesses, right? Right?

Comments

[girtygrin.livejournal.com]

Wow... Speaking as someone who does network security that makes me cringe that a university didn't bother securing data like that.

[giza.livejournal.com]

And FFS, wrappers like ADODB (http://adodb.sourceforge.net/) will do this for you!

I see this all too often, where someone knows only what they were taught in class and can't (or doesn't want to) learn anything else on their own. It really is a case of when all you have is a hammer, everything else looks like a nail.

[sagejackal.livejournal.com]

"Oh, you can see. She was born in '74." XD

[tgeller.livejournal.com]

I'm amused by the nerd quotient of the presenter's voice. :)

[sidepocket-pro.livejournal.com]

This was a good find, I had no idea people did videos about this. Thanks! XD

I think the latest 2600 talked about something similar with bad web application security.

[ex-tjcoyote112.livejournal.com]

*sighs* And someone was *paid* to build that horror story.

Me, personally, I refused to start writing my personal furry website with PHP & MySQL until I knew how to secure it... :-P

[giza.livejournal.com]

It's not that hard. It all boils down to being careful what you do with input that comes from outside sources.

- Database stuff: Sanitize it. mysql_escape_string() is your friend. ADODB will do this if you make use of query parameters. Oracle has binding functions which are all sorts of awesome.

- File/directory names: whitelist them. Set up a regex so that any characters outside of those you choose to allow will be turned into an underscore. ("[^a-zA-z0-9]") would be a good start. This also protects against directory traversal attacks.

- Functions. Document them religiously with PHPDoc or a similar documenting scheme. Make it clear what the inputs and outputs are, and if there are any pre/post-conditions for the function.

The problem is that people either don't know, or are just plain lazy. Our industry is expanding fast enough that there is plenty of demand, and sometimes higherups just don't know how to evaluate what programmers do.

[andrew7782.livejournal.com]

Making sure magic quotes is on is good too, that slashes all the quotes coming in sources like GET and POST.

[giza.livejournal.com]

Uh, no.

The problem with Magic Quotes is that it does things half-assed. It escapes, but does not provide a mechanism for unescaping content. Ever see a site that has all quotes proceeded by backslashes? That's where Magic Quotes has run amuck.

Did I mention that it not being enabled in all PHP installations only complicates the problem? It's so bad that in Drupal, they wrot ethe fix_gpc_magic() function to specifically undo what Magic Quotes does.

[ex-tjcoyote112.livejournal.com]

Right now I'm not accepting user input, but I am passing values in pages (which of course has to be verified as if is was user input). Thus far I'm just doing regex whitelists on filenames and other values I'm passing around... $Pattern="/^[A-Za-z0-9_\\-\\.]*$/"; if you're curious. ;o)

I haven't looked into mysql_escape_string() yet... thanks for pointing it out! I'll certainly save a copy of your post!

P.S. I threw out my old PHP books 2-3 years ago... bought a new one last week. Hopefully it will cover the security holes the old ones left out.

[triggur.livejournal.com]

Another way to help stop attacks like that is to use prepared statements rather than concatenating values directly into the line of SQL. Prepared statement parameters aren't treated as sql that needs to be processed, they're treated as simple values to compare against/store.

[giza.livejournal.com]

Unfortunately, there's more overhead to that. However, ADODB's Execute() function actually lets you use a similar syntax for such statements and specify the values as separate parameters. And ADODB is platform independent. :-)

[triggur.livejournal.com]

My experience is that the opposite is true; the database server can cache prepared statements.

[giza.livejournal.com]

Hmm, I'll look into that then. With the volume we have here, any caching will help us!

[triggur.livejournal.com]

I'll caveat that I don't know to what degree PHP supports all that, but it's generally the gold standard everywhere I've worked in the java world.

[giza.livejournal.com]

For large scripts, I'll bet I can do a lot with a static variable inside a function serving as a prepared statement cache.

[triggur.livejournal.com]

the tricky bit is that a single cached db connection "owns" its prepared statements and that statement cannot be used on a different pooled connection. Further, you can't use the same connection in multiple concurrent threads.

[giza.livejournal.com]

Multi-threading in PHP? Haha, what's that? :-)

[darthgeek.livejournal.com]

Yeesh. All of our data validation and such is done on the server side. Including stuff to prevent SQL injection crap like that.

[toumal.livejournal.com]

I'm using a combination of prepared statements and a special XSS filter on ALL user input on yiffstar.com
I'm actually more concerned about XSS attacks because they're so hard to filter for on a site that allows HTML in user data...

[ionotter.livejournal.com]

You know, I've seen where that icon comes from, and every time I see you replying to someone with it, I just get all giggly. And in the context of this post, with the director showing how a university's website is getting "screwed", it only makes me laugh harder.

[giza.livejournal.com]

1) Just the script kiddies.

2) Since the author says it was a security audit that he was hired/authorized to conduct, I suspect that the issue was fixed before the video was published.