Showing posts with label xss. Show all posts
Showing posts with label xss. Show all posts

Monday, July 16, 2007

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.

Friday, November 10, 2006

when I learned what XSS is

Here's another old Amazon history post. February, 2000- I'd had Declan for barely over a month, and I remember being outside with him, walking around our parking lot, on a rather sunny day. (It's never sunny in Seattle in February, that's why I particularly remember this.) I was the oncall frontend QA- basically, if we had to do an emergency content push to the onlines, I would be the one checkpoint. Small responsibility for a 22 year old. My pager went off, I went in, and logged into my computer, and read the problem. It linked to CERT Advisory On Malicious HTML Tags on slashdot. That was the birth of XSS.

I spent the next several hours testing pushes for every single page on the site that echoed back user input. On a site like amazon, you can imagine what that was like- I seem to recall that a lot of my time was frantically deleting pages from my pager because it kept running out of space for stored messages. Thankfully I worked with some great people, I remember farming out a lot of the testing to Jason, who was still really a newbie at that time. This is one of my starkest memories: we had the slashdot article on this open, and would reload over and over again reading the comments as more vulnerable sites were found, more exploits related to this came to light. The comments are still an interesting read today.

It took a few days for me to wrap my head around what this bug was, at the time I was just trying to test with the sample input we had, without totally following the complete theory of what we were doing. To be fair, I doubt anyone that understood that. I can talk a lot now about filtering vs escaping, why I love <plaintext>, and so on, but that day was more about survival mode. Lots of fun, though, and another insane amazon experience that I wouldn't trade for anything.