Paid Advertising
web application security lab

Top 10 Ajax Security Holes Post

AJAX and dynamic HTML in general is such a new technology that most people really don’t get it’s true security implications. It’s nice to see a few articles being written that address the web application security issues found with the various types of dynamic code out there. Today I ran across an article on Help Net Security talking about the “Top 10 Ajax Security Holes and driving factors”. Pretty impressive sounding, but the title is kinda misleading.

Of the actual holes there are only three mentioned, Phishing, XSS and CSRF. He actually misses one of the other major holes like the one Jeremiah found in Google for instance where you can steal any data inside JSON if you visit a malicious web-page (yes, you heard me right, don’t put sensitive information in JSON). But even still, what he does discuss, even if it’s not 10 holes, is 10 ways to create those three holes. Some of them are going to be fairly obvious or impossible to create without some other hole and others are a tad more creative, but still, it’s nice seeing people think about this.

However, I’d like to point out, as I have before that really users should not consider AJAX to be another security risk. It is the same old risk that we have always faced, except there is more client side code that can be circumvented now. The more logic you create on the browser for parsing and security the more you must insure that your backend also protects you at the same time, since all client side security can be circumvented in one way or another.

I’ve said it a number of times but this is tantamount to muddying the security waters. Instead of knowing your single choke point for security issues you now have two or more places that require security thought. Not that that makes you less secure, it simply increases the attack surface area. Anyway, it’s kind of an interesting read.

15 Responses to “Top 10 Ajax Security Holes Post”

  1. maluc Says:

    could you elaborate more on the JSON stealing..? i think i know what you’re referring to, but that would be an overly obvious CSRF hole - i’d be surprised if google did it.

  2. Sylvan von Stuppe Says:

    I may be dumb, here, but how is putting JSON on your site putting the sensitive data at risk? I mean, yes, if my JSON includes foo = {…}, then foo is in the scope of the page that called it, but if my JSON just returns {…}, (expecting the client to get it through XHR), then it’s anonymous and I can’t get at anything there, right? I can’t walk the DOM later and find the results of a src attribute on a script tag. The worst thing that could happen is if the very request for the JSON has some side effect.

    Yes - you’re absolutely right - never say “foo = {sensitive_info}”, but what’s the problem with returning “{sensitive_info}” anonymously?

  3. maluc Says:

    yeah, i don’t think you can.. it would be violating same origin. that is, unless there’s any XSS on the same domain. But sadly, more than half of the JSON implementations i’ve seen have a callback function, or a foo=

  4. Jeremiah Says:

    JavaScript feeds that contain sensitive information can be called into the current domain context bey using <script src=. CSRF really. Easy to steal the data. On the other hand, strictly formatted JSON feeds cannot be called directly with <script src=, the way the data is formatted causes an “invalid label” error. If someone finds a way around this, its REALLY bad news.

    Advanced Web Attack Techniques using GMail

  5. maluc Says:

    wow, i never knew overwriting the array constructor was possible. does that work in both firefox and ie7? also, is there a way to overwrite an object’s constructor? for example to access the info in:

    very interesting article.. although it was a bit confusing the first read through _-_

  6. Jeremiah Says:

    Glad you liked the write-up. I know its possible in Firefox/Mozilla to overwrite the array constructor, not sure about IE though. About the URL, I’ve not be able to overwrite what appears to the JavaScript interpreter as a code block, rather than an object/constructor. If someone can figure out a way, thats golden. I tried for days, no luck.

  7. maluc Says:

    my first guess is that it’s unpossible. Atleast i hope so.. would be a big find if it wasn’t.

    my second guess is that if it’s indeed possible, it’ll be related to the Object.prototype.constructor or prehaps superclass.prototype.constructor. I can’t claim to have ever messed with either, so i delve more into it when i get a chance.

    If it is possible, i think it would make all JSON a liability - nasty stuff.

  8. Jeremiah Says:

    Good luck! And if you want another little side research project, check out what happens in Firefox/Mozilla when you *script src=”" an XML file. You’ll notice no JavaScript console error message. There is something called E4X that the browser supports. I think whats happening is that an XML Object is being instantiated on the fly, but I can’t get access to it from JS space. I tried overwriting the XML constructor, I can, but the called in script source has no effect. Maybe you can do better.

  9. takuan Says:

    I read your post on “Advanced Web Attack Techniques using GMail”. Ive read it a couple times but dont quite understand it fully. Would it be possible to give the actual URL you used to get the contact list so that we can see what you are talking about? (I assume google has fixed the problem a long time ago (almost a year now?) so theres probably not too much harm for releasing it now. Itd help me and probably others out a bunch.

  10. maluc Says:

    Basically.. the contact list works by JSON.
    <script src=http;//></script>

    Loading that script would return:
    [[”ct”,”Your Name”,””], [”ct”,”Another Name”,””] ]

    That array is unreferenced though, so it gets initialized but there’s no way to call it, without the “contactArray = ” in front. If you’re on the same domain you can use XMLHttpRequest to read it .. so that’s why google assumed it was secure for their eyes only.

    What Jeremiah did was overwrite that constructor that initializes ALL arrays on the page. He replaced it with his own constructor that reads the current array being initialized, and outputs it as a table. Took me a second read-over to realize what was going on too ^^

  11. Jeremiah Says:

    Yah, should have been long enough by now. This is the URL that return the anonymous Array of your email contacts.

    One thing you’ll notice is a conspicuous while loop at the top of the array. This causes the browser to run into an infinite loop in the case of a CSRF attack. I’ve tried overwriting the while loop function, but no success. A hacky, but effective solution on their part.

  12. Chandler Says:

    Hi All Experts,
    I want to use AJAX (Asynchronous JAVA script with XML ). How can i Optimize the site SEO.
    as Java script and flash is not recommended by search engines. Any suggestion or help is welcomed. With Regards.

  13. RSnake Says:

    I think it depends on if you are attempting to get the site to index the content that you would otherwise have in the AJAX call or not.

  14. Guy Says:


    I would like to introduce you to a new concept which eliminates most of AJAX soft spots by simply returning back to server based computing but still having a dynamic AJAX based UI.


  15. Deneunsup Says:


    I requirement to buy Dedicated Server with harsh DDoS refuge in Europe.

    Anybody be aware is there any punctilious dedicated servers with ddos protection against HTTP and SYN inundation attacks?

    Our server has been stodgy attacked, and i am looking for reliable ddos protected hosting in Europe.

    For now I only got recommendation for