DISQUS

Matasano Chargen: Fortify’s Announcement About Jeremiah’s Attack, Decoded

  • Jeremiah Blatz · 2 years ago
    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.
  • Matt · 2 years ago
    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?
  • Thomas Ptacek · 2 years ago
    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.
  • Phil Groce · 2 years ago
    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.
  • Thomas Ptacek · 2 years ago
    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.