DISQUS

newsham · 3 years ago

A coworker wrote a paper about these attacks: http://www.isecpartners.com/files/XSRF_Paper_0.pdf. (Note: we use XSRF as an abbreviation). I don't agree that it's much harder to fix than XSS: You need to make the references (at least the ones that preform actions on behalf of a user) hard to forge. Crypto's got a lot to say about that kind of problem...

Thomas Ptacek · 3 years ago

That's harder than scrubbing metacharacters out of outputs. =)

Josh Daymont · 3 years ago

I had the pleasure of seeing Alex Stamos deliver his XSRF presentation last week and it was impressive.

The core difference in fixing XSRF versus XSS is that XSS is at its heart a server side issue while XSRF is at its core a client side problem. Both can be addressed on either side of the client server divide; but with XSRF fixing the issue at the server (using crypto/one time cookies etc) will be less of a direct approach than server side fixes for XSS.

So I agree w/ Tom that technically a server side fix will be slightly more complex (not a lot more), but do you want to fix hundreds of thousands of servers of a billion browsers? If you are a product company then have fun with browsers, service oriented firms on the other hand...

Thomas Ptacek · 3 years ago

A typical XSS fix doesn't really change application logic (in fact, often it doesn't change logic at all).

A typical "good" CSRF fix will.

lx · 3 years ago

Well, putting secret tokens in requests is probably a bit easier than implementing an effective input filtering and output escaping system. There are a number of complicating factors in effective XSS prevention - character set translations at various levels of the webapp, product specs that permit user-supplied include some, but not all HTML tags(a terrible idea, but still common), multiple web applications viewing the same potentially malicious data, etc. Multinationalization also makes whitelisting a pain.

Fixes for XSS can vary from application to application, while fixes for XSRF are relatively straightforward and only have to be implemented at one tier of a webapp. In a sensibly designed webapp, fixes for both problems should be quite easy. It's just that there aren't very many of those.

Alex · 3 years ago

Josh, thanks for the plug. Drop by the office for your twenty. :)

There is some irony that the recommendations the security community have given to web app developers for years (store information server side, don't use hidden fields or extra parameters, use cookies for state management) actually make apps more vulnerable.

Although "Web 1.0" apps have been vulnerable for years, this is a problem that is both better and worse with newer AJAX apps. The cross-domain script sourcing issue is the next big XSRF vuln, and a lot of AJAXish sites I've seen are vulnerable.

I agree that Jeremiah writes the best webapp security blog. Where does he get the time?

Thomas Ptacek · 3 years ago

In fairness, the security community's recommendations aren't bad, just incomplete. The token you want that asserts "this is an explicitly intentional action" is different from the one that says "I really am Alex Stamos".

Where's the iSec blog? I want to argue with Tim.

Alex · 3 years ago

Tim isn't allowed to argue. We keep him in a dank basement writing format string exploit code all day, and if he's good he's allowed to surf in the afternoon.

Also, arguing against a person with moderation rights is the blog version of bringing a knife to a gun fight.

The token you want to add to protect against XSRF really doesn't have a different function than a cookie. The real problem is that there is no such thing as a browser security model, only a cobbled together set of rules written by the developers that championed features inside of Netscape in 1997. The root issue isn't the assertion made by the cookie, it's that some idiot said "Let's make sure the browser automatically attaches cookies to cross-domain script tags and iFrame POSTs. That would be awesome!" I feel better knowing that whoever made these early decisions almost certainly lost their paper millions in the crash.

So we're back to hidden fields in forms and big blobs of crypto in GET parameters along with entropic and protected cookies (with SECURE and HTTPONLY). Adding this stuff isn't that difficult once developers understand the problem, although XSRF fixes can introduce tons of odd bugs in large web apps.

The really scary part is developers DO NOT understand this bug, and it is a flaw that applications are often vulnerable to BY DEFAULT. Very few apps have SQL injection bugs anymore because the default (and fastest) mechanisms of database access for big enterprises provide magic protection against most injections. In contrast, the easy way of writing the presentation layer is almost always vulnerable to XSRF.

And Thomas, blogs are soooooo 2002. We prefer to educate people on application security using a series of YouTube videos where we pretend to be emo teenagers with oppressive parents. Look for Tim as SurferBoy13.

space dude · 3 years ago

CSRF have been known for years!

Some guy · 3 years ago

If you want to punish him, make Tim find format strings in Microsoft or Cisco code. Something tells me they're pretty rare, but until my company allows me to publish my final report (!@#$ red tape), I can say no more.

CSRF? Yeah, we should be seeing a lot more public reports of that. But we don't. Which means it's there (the cynic's law). I know it was in my own code in the late 90's, which means nothing except that I kinda knew about secure coding and still didn't see it.

P.S. Dave - remind me that I posted this. Would you support anonymous guest posts?

P.P.S. If we don't get our stuff in gear and make protocols, languages, and frameworks more secure from the bottom up, we'll never make ourselves obsolete. Oh wait, I suddenly saw the design flaw in that argument.