Matasano Chargen - Latest Comments in Fortify’s Announcement About Jeremiah’s Attack, Decoded

Re: Fortify’s Announcement About Jeremiah’s Attack, Decoded

Thomas Ptacek — Mon, 02 Apr 2007 17:25:06 -0000

It's definitely NOT JSON's fault. I personally don't even think it has anything to do with AJAX.

What's happening here is this:

There was a belief that XSRF attacks --- follow a link and, without requiring confirmation, cause an action in a target application --- only allowed you to "create", "update", or "delete", but not "read".

It turns out there's at least one major scenario in which that isn't true: when the data you want to read is embedded in Javascript, you can hijack prototypes to get at it.

However, if we never find a way to do something similar with XML, I'll be surprised.

XSRF-able UI actions shouldn't provide sensitive data. If you audit your application for XSRF flaws, you've defeated this attack. Moreover, the well-known preexisting exploits for XSRF are actually worse than this attack. I think it's much ado over not much, though I think Jeremiah's attack is very clever.

Re: Fortify’s Announcement About Jeremiah’s Attack, Decoded

Phil Groce — Mon, 02 Apr 2007 17:12:46 -0000

As I understand what you're saying, the vuln isn't JSON's fault, per se. If you're hooking into an AJAX app that uses XML to move data around, you can still proxy the XMLHTTPRequest and get that nice, sensitive data from a DOM tree.

That doesn't make the rest of what you say any less true, but it sounds like you're accusing JSON of being inherently insecure, when the problem is Javascript and how it's deployed in the browser. It's a very trusting (and trusted) language in a hostile environment.

As an aside, I hope web developers are at least being told never to just eval JSON data. Just because you can doesn't mean you should.

Re: Fortify’s Announcement About Jeremiah’s Attack, Decoded

Thomas Ptacek — Mon, 02 Apr 2007 17:02:51 -0000

Think of all the code written in C and PHP, and ask yourself whether people are going to pick a language because it is more or less secure.

The problem with Javascript isn't the language. It's the setting. The idea of executing code controlled by hostile content in any programming environment is sort of insane.

Re: Fortify’s Announcement About Jeremiah’s Attack, Decoded

Matt — Mon, 02 Apr 2007 16:33:22 -0000

Dynamic languages are awesome. They're also freakin' scary for us security folks -- I remember reading about Obj-C method swizzling for the first time, and thinking "Oh dear god...".

Maybe there's a middle ground in language design, somewhere with (most of) the benefits of dynamism, but without fear-inducing "features" like being able to redefine the guts of the runtime. Not that I've given this idea any deep thought, though; am I completely out in left field with that suggestion? Or, better yet, has somebody already designed a language like that?

Re: Fortify’s Announcement About Jeremiah’s Attack, Decoded

Jeremiah Blatz — Mon, 02 Apr 2007 15:03:22 -0000

Speaking of code injection, I learned today that one of the encoding types that flickr supports is php. As in, they give you a block of PHP code to execute and Good Things Happen(tm). JSON is bad enough, having a 3rd party (over plaintext http or non-certificate-verifying https, no less) hand you code to execute is madness.

Really, parsing isn't that hard.