more web security

So it appears to me that when it's in the upper 70s and not too humid, Greenwich Village is one of the most wonderful places ever. This evening I had a nice walk across Washington Square park...beautiful. So wonderful. How many times am i going to post "OMG I love this city?" Probably a bunch more until the crush wears off. I really can't believe how lucky I am to get to be here.

I realized this afternoon that googling for "json xsrf" will pull up my December post on this topic in the first set of Google results. That's pretty scary, seeing as I totally waved my hands around on that post and said "be careful" and not much more. And, well, I'm a big webapp sec nerd, but I'm not a javascript expert and certainly not anything like one of the most knowledgeable people on webapp sec.

If you want to really learn something useful about how to secure your JSON from XSRF holes, go read these two blog posts instead:

* http://www.matasano.com/log/752/fortifys-announcement-about-jeremiahs-attack-decoded/
* http://jpsykes.com/47/practical-csrf-and-json-security

What really concerns me, though, is that there is a lot of FUD out there about "web 2.0" security. There are no web application vulnerabilities that apply ONLY to "web 2.0 websites" (whatever those really are). XSS is still an issue, but getXMLHTTPRequest does not, on its own, make that any bigger of an issue. Really, there are very few actual new web application vulnerabilities. (I'm still digesting the stuff about registered URL handlers- I think that might be a new one, although it's obviously also tightly coupled with xss and xsrf.)

If you want to shut down XSS entirely on your site, there's very little you have to do.

1. escape <, >, single quotes, double quotes, and backticks in EVERYTHING you EVER get from a user, even if it's a cookie value that you think you put on their computer, even if it's a text string you think you're just writing to a database and never looking at
2. Explicitly set your charsets on every single page
3. Rewrite any user uploaded images that you present back to other users
4. escape or strip out every \r\n
5. be mindful of your charsets and character encoding

There. I swear, that will get you 99% of the way there. Ok, yes, re-writing images is a holy pain in the neck. but necessary.

XSRF is a little harder. Not much, but it's not as dead simple as XSS is. There is one fix for it that will work incredibly well, but you had better not have a XSS hole on your site and you need to devote the computational power to fix it.

1. Generate secure one time tokens for all of your "account modification requests" (for lack of being able to think of a better phrase)
2. Now check it on every single request and never ever let user B's token work on user A's information

That will cure most xsrf problems... if you don't have an XSS hole on your site. If you do, go google "samy is my hero" to see why you're hosed. One of the interesting parts of security web applications is that all of these vulnerabilities play together. You can do a lot of dumb stuff with XSS like drawing new login boxes to go phishing with, but you can also leverage it to expose xsrf holes in an otherwise secure web application. It's all a big house of cards, because of the statelessness of the web (even so called 'stateful web 2.0 apps' are not really stateful. they fake it by and large) and the craptastic rendering engines we have out there.

Like I posted back in December, and as the two JSON/XSRF blog posts above discuss, you need to think a little more about what information you pass back in JSON, or use it in a way that will protect you from yourself (ie only return code that needs to be tweaked before you eval it). The way that <script src> breaks out of the javascript sandbox is confusing. Go read those blog posts above, they're clear and come with actual sample code.

I was talking with a web dev today about why he had a XSRF hole with some RPC calls that used cookie authentication and returned JSON. He inadvertently pretty much summed up why we have web application holes despite this stuff not being rocket science. He was saying "but we modify the RPC's response before we eval the code... oh wait, just because we modify it doesn't mean you have to. I see, I need think about what other people can do not what we do." That is pretty much what all this rambling sums up to.

I'll write something soon summarizing web services and feed vulnerabilites, but as I noted above about so called web 2.0 vulnerabilities... it's nothing new and it's nothing that only touches them. And of course none of this even touches on SQL injection, buffer overflows, or attacks on specific pieces of software such as exploits against the linux that a particular website might run over.