Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Security Programming The Internet IT Technology

Experts Say Ajax Not Inherently Insecure 82

Posted by Zonk from the good-to-know dept.
An anonymous reader writes "Jeremiah Grossman (CTO of WhiteHat Security) has published Myth-Busting - an article dismissing the hyped-up claims that AJAX is insecure. He says: 'The hype surrounding AJAX and security risks is hard to miss. Supposedly, this hot new technology responsible for compelling web-based applications like Gmail and Google Maps harbors a dark secret that opens the door to malicious hackers. Not exactly true ... Word on the cyber-street is that AJAX is the harbinger of larger attack surfaces, increased complexity, fake requests, denial of service, deadly cross-site scripting (XSS) , reliance on client-side security, and more. In reality, these issues existed well before AJAX. And, the recommended security best practices remain unchanged.'"
This discussion has been archived. No new comments can be posted.

Experts Say Ajax Not Inherently Insecure More

Experts Say Ajax Not Inherently Insecure

Comments Filter:

  • Strawman (Score:3, Interesting)

    by markov_chain ( 202465 ) on Friday December 01, 2006 @01:33PM (#17069448)
    Way to make up an issue and then show off attacking it.

  • Vulnerability in practice is just as bad or worse (Score:5, Insightful)

    by ScentCone ( 795499 ) on Friday December 01, 2006 @01:34PM (#17069464)
    When something is this widely adopted and this tempting to rapidly trot out (because PHBs are desparate for that shiny stuff as they head to the next board meeting), the fact that you're suddenly introducing a wildly more complex set of GETs and POSTs and layered hoo-hah on an interactive page (never mind the purpose of the app) means that all of the stuff that always introduces vulnerabilities will be there, multiplied by the new complexity. And, of course, with a smaller crowd of talented, experienced people truly able to quickly size up the risks as something goes live.

    It's not the (non-existent?) inherent security problems in the bundle of techniques we're referring to, it's the weaknesses that show up in the practice of shoddy implementation, cheezy hosting platforms, etc. There's nothing wrong with AJAX, it's the AJAX-envy among less sophisticated operators that we have to worry about. We just have to quit saying it's 'easy' to implement, because none of the underlying bits and pieces are (in terms of being bullet-proof) are 'easy,' and a browser-agnostic soup of a couple dozen of those bits is that many times harder.
    • it's the weaknesses that show up in the practice of shoddy implementation

      Right, that's what I was about to say. The only vulnerability I've seen that I would say was AJAX-specific was that someone put security on the main page, but on none of the little ajax widgets. It just didn't occur to this person that securing the widgets was necessary - probably because what we're used to when programming on the web is a main page (that is secure) and libraries that can only be called on the server side.

      Someone who
    • The big risk with AJAX isn't that it introduces new vulnerabilities that Javascript doesn't have, or that good Javascript writers can't write good safe Javascript. The big risk is that evil Javascript writers can write harmful Javascript, and good AJAX web pages dangle something shiny in front of the user that makes them turn Javascript on at all, so when they also view the evildoers' web pages, they're running the harmful Javascript.

      It is of course possible for well-intentioned Javascript or AJAX writers

      • Yes, JavaScript is an evil, evil thing in the hands of the malcontent, but having scripting support deactivated in your browser isn't really going to stop much. Some of the most recent work being carried out by Jeremiah Grossman and others who like to dabble in the area has shown that it is possible to enumerate systems on internal LANs via the browser of a visitor to an external website that the attacker controls.

        Without Scripting enabled.

        While the developed technique is still quite noisy and fairly obvio
  • From TFA: "What can I do to protect myself as a user?"

    > One of the best ways to protect yourself is to turn off Javascript in your browser settings.

    The more things change, the more things stay the same.

    Best security practice has always been to turn off ActiveX, Javascript, Flash, and any other means by which untrusted executable content is automatically downloaded to one's machine and then automatically executed.

    • Re: (Score:3, Interesting)

      by nine-times ( 778537 )

      Is javascript really that horrible? I know it can be used in annoying ways, how difficult is it to do something outside of superficial changes to the browser?

      I'm really asking. It seems like you should be able to have a simple scripting language that can only really manipulate superficial aspects of web pages without any real increase to the security risk. I thought this was what javascript was. Am I wrong? If so, why doesn't someone replace javascript with something better.

      • Re: (Score:2)

        by Shados ( 741919 )
        No, its not. Or at least, its not supposed to be. Its just that most browser vulnerabilities come from errors in Javascript. Assuming a "perfect" browser, Javascript is safe. Of course, no browser is perfect, but the odds of getting owned while using, let say, Opera, are pretty god darn low.

        That being said, the NET without javascript is one damn boring beast. The only interaction you can then have with your page are links and submit buttons. Might as well read a book.
        • I like books. They don't come with flashing banner ads, pop-up windows, pop-under ads, and all the rest of the active content that pollutes a lot of the WWW nowadays. Of course, if you don't install Flash, disable animated images, Javascript, and so forth, the web becomes a lot less annoying and more legible.

          As for YouTube, or anything else that requires Flash or something to work, well, I live without.

      • Re: (Score:2, Insightful)

        by hotdiggitydawg ( 881316 )

        Is javascript really that horrible?

        Yes.

        I know it can be used in annoying ways, how difficult is it to do something outside of superficial changes to the browser?

        A computer is practically worthless to most people if you cannot use it to browse the internet nowadays. So, forget about things outside the browser, and start thinking about user-website interaction through the browser. You can rely on so many trivial vectors to build an effective attack to manipulate a user's browsing experience, and in the case of most sheeple they'll be none the wiser. And the proliferation of it with the latest AJAX fad simply means more people are likely to have it on globally b

        • But it's scope of manipulation is such that it can be effectively used to dupe gullible and/or less tech-savvy users into doing something foolish...

          What kind of "something foolish"? I'm just wondering, what are the limits to these sorts of things? Phishing?

          I always try to train people to distrust the internet, but you can't keep people from being stupid. Can javascript be used to open software firewall ports, or establish some kind of tunneling? Can it execute arbitrary code on the client machine? Ca

          • Re: (Score:2)

            by Phrogman ( 80473 )
            One example I just read about somewhere (possibly on /. not sure) is the use of Javascript and frames to capture username/password information for Phishers. So instead of making a false webpage and linking to it, they make a set of invisible frames that display the real website and say your bank account login page - then use JS to pull the values from those fields when you enter your data. I haven't looked into whether or not this is possible mind you, just read someone commenting that it was en vogue at th

            • I'm not sure about ActiveX. Do we need a replacement, or do we just need to get rid of it?

              But web applications and interactive/animated web pages are too useful and popular to expect they'll just go away. If the current mixture of PHP, HTML, CSS, Javascript, and XML is too inefficient and insecure, then by all means, I'd like to encourage people to come up with something better. I'd assume it's a bit harder than it sounds, though.

        • yes java script is that horrible. it's slow and prone to bugs. populate a 100x 100 grid of information in JS then do it in a native exe and see the difference, you'll be horrified at how shit JS is.

          • Re: (Score:1)

            by niteice ( 793961 )
            Perhaps you were testing on SpiderMonkey (Gecko's engine)? SM specifically is known to be a very slow JS engine.

        • Is javascript really that horrible?

          Yes.

          While I understand your objection to it -- which is essentially the most common objection to Javascript -- let me rephrase it, albeit in a deliberately provocative manner: "any tool to make the web-browsing experience more advanced than an IBM mainframe terminal can be exploited, and therefore should not be used."

          There obviously are dangers to client-side scripting, and our current solutions could arguably handle them better. But are we really going

    • Re:Best security practices (Score:5, Funny)

      by Ingolfke ( 515826 ) on Friday December 01, 2006 @01:51PM (#17069732) Journal
      Downloading the HTML via WGET and reading it VI is the only secure way to surf the net.

    • Re: (Score:3, Insightful)

      by owlnation ( 858981 )

      Best security practice has always been to turn off ActiveX, Javascript, Flash, and any other means by which untrusted executable content is automatically downloaded to one's machine and then automatically executed.

      Of course that is true. It's just that it's a real pain in the ass. Well, no mortal being requires ActiveX for any reason, and I block the horror that is Flash with the (truly joyous and wonderful) Flashblock extension - and rarely ever allow it to run, mostly just for YouTube.

      It's the Javasc

    • I do not get it about the security problems of AJAX. I just do not see the problem. I have yet to see an example where using the following senario is a security problem;

      1. user gets default web page, like "index.html" that is a combination of HTML/SVG/CSS.
      2. user reads web page.
      3. user fills out form.
      4. user 'submits' form to a web service, (for me, web services are like console programs, but output is to a web browser).
      5. web service edits input.
      6. web service creates XML with a XSLT preprocessor stateme

  • Yeah... (Score:1, Offtopic)

    by eno2001 ( 527078 )
    ...and in the movie Mars Attacks! the Martians kept telling the U.S. government they weren't going to invade. Hmmm.. Maybe THAT'S where the Bush administration got their inspiration from for the premptive strike. Certainly would explain a lot...

  • Existing Best Practices (Score:2, Insightful)

    by Anonymous Coward
    Yup, existing best practices takes care of all of the security issues for AJAX: disable Javascript. Problem solved.

    With open-source, you can examine the source before you run the program, and can take steps to ensure that the program you run is compiled from the source you examined and that it's unchanged since the last time you ran the program. There's no good way to do the same thing with Javascript ... you're expected to nod agreeably when the website says "just trust us".

    "Not trusting someone who /dema
    • You're either a troll or an idiot who chooses to speak about things he knows nothing about.

      JavaScript is open plain old text. You're free to review the code for every website you visit before running it.

  • Where the heck did this hype come from? (Score:3, Insightful)

    by Anonymous Coward on Friday December 01, 2006 @01:41PM (#17069556)
    And who is honestly saying these things? Am I alone in not seeing the percieved risks here?

    All AJAX really gives you is that first 'A': asynchronous. All the other underlying mechanics of client-to-server communications over HTTP apply. This means that your security checklist is absolutely no different than using a good old-fashioned [form].

    To slam AJAX as insecure as a technology is just bad thinking to begin with - it's a tool, that's all. Whether or not it's used in a secure fashion is really more a best-practice and/or training issue.

    Besides, didn't we already go over all this when Web-Services were a big deal?
    • Well, think of this. It wouldn't be all that hard to setup some javascript, use AJAX and have it call to http://192.168.1.1/ [192.168.1.1] and try a random smattering of common admin logins to modems (I know my DSL modem @ home supports it) and then report back to the server the IP address of the user. You could easily get their PPPoE login right there provided some other details. At the very least you could take down their modem.

      Sure this is kinda out there and the simple response is to change your modems password or t
      • Hah, well after posting this I decided to check out exactly how feasible it is. FF (2.0) w/Firebug will tell me that Firefox denied access to the call. I assume it sees any calls that start out with http:/// [http] that doesn't match the server and automatically denies it.

        IE 6.0 on the other hand merely says "This page is accessing information that is not under its control" and gives you a Yes/No choice.
        • Gah. I hate to keep posting things repeatedly but my thinking is fragmented today :)

          I don't think it's similar to a FORM at all, you can get the user to access other sites that they wouldn't normally access and get a parseable response from that site (as I mentioned above). I plan on testing this out some more with a friend of mine to see if I can grab their modems information remotely.

          If you're using AJAX in a legitimate fashion (eg, requesting information from the original server) then yeah, it is as si

  • That article was a mixed bag (Score:4, Interesting)

    by Beryllium Sphere(tm) ( 193358 ) on Friday December 01, 2006 @01:44PM (#17069606) Journal
    There's some justice in saying that Ajax doesn't introduce any new problems over and above Javascript, but that is faint praise and doesn't allow for the fact that buzzword-compliant organizations are now creating more web sites that require Javascript.

    His advice about keeping web apps secure is sound and practical but incomplete. The last OWASP conference I went to, one of the speakers pointed out that there's an Ajax development toolkit out there in which you can't tell a priori whether a piece of functionality you program will end up on the client or on the server. "Avoid toolkits like that" should be on the list of security precautions.

    >AJAX is a web browser (client-side) technology. It does not execute on the server.

    The XMLHttpRequest certainly does execute on the server and allows a range of parser attacks that you were less likely to get with other technologies. Which would you rather validate, a set of CGI parameters or a blob of XML?
    • > The XMLHttpRequest certainly does execute on the server

      Hm... does it? Wouldn't that require a Javascript interpreter in the web server?

      • Re: (Score:2)

        by grcumb ( 781340 )
        > The XMLHttpRequest certainly does execute on the server
        Hm... does it? Wouldn't that require a Javascript interpreter in the web server?

        I doubt it. I suspect that it just needs an XML parser to read data from an HTTP Request.

    • Re: (Score:2, Informative)

      by PacoSuarez ( 530275 )

      The XMLHttpRequest certainly does execute on the server and allows a range of parser attacks that you were less likely to get with other technologies. Which would you rather validate, a set of CGI parameters or a blob of XML?

      The XMLHttpRequest looks to the server just like any other HTTP request, with parameters passed the exact same way as you would pass them to a CGI program. The only side that needs to parse a bunch of XML is the client, which is not much of a security problem.

      • Well, judging from the fact that the default Content-Type for the request sent by an XMLHttpRequest is "text/xml", you're not quite correct. The default usage is to send an XML-encoded request in raw postdata which would be parsed by the server. You can override this and send urlencoded data (like your browser does when you submit a form), but you have to explicitly specify that this is what you're doing.

        So it seems that it was intended for bidirectional XML-based communication.

    • Re: (Score:2, Insightful)

      by leighklotz ( 192300 )
      >Which would you rather validate, a set of CGI parameters or a blob of XML?
      Um, a blob of XML. Quoting and escape characters are a big source of vulnerabilities. XML has well-defined quoting rules. CGI parameters have no structure, so structure must be done ad hoc. XML structure can be validated on the server using XML Schema or Relax, or other mechanisms.

  • Fortran in Haskell (Score:4, Interesting)

    by Fahrenheit 450 ( 765492 ) on Friday December 01, 2006 @01:50PM (#17069712)
    This appears to be yet another case of, "You can write Fortran in any language" where the author ignores that some technologies make it much easier to write Fortran than others. Obviously with a number of things you can avoid the bad stuff by avoiding the bad stuff -- but when bad stuff is the default mode of operation, rather than the odd, explicit corner case then yes... there's an issue.

    Put another way, it's a lot easier to not write Fortran in Haskell than it is in C.
  • It's your fault, jackass!

  • deadly cross-site scripting (Score:3, Insightful)

    by gad_zuki! ( 70830 ) on Friday December 01, 2006 @03:24PM (#17071598)
    I swear officer, he was alive a minute ago. He was just sitting in front of his PC trying to check his bank balance!
  • This is a worthwhile article to keep on file. Its offers a clear and practical analysis of AJAX in terms of security principles, though biased toward server security and dismissive or incorrect with respect to client security. Read it critically.

    Indeed AJAX is not a new technology but a set of existing technologies in combination. Here's the issue though. JavaScript is a known point of vulnerability for clients. Secure clients may be hardened against attacks by disabling JavaScript. Good web design

  • The first web game that I wrote in PHP 3/4, called Merchant Empires (www.merchantempires) was hacked mercilessly. Of course, those were the good old games of the web when SQL injection was possible on a large number of main stream sites.

    My second web game, called Grand Strategy (www.denizengames.com), is a full fledged Ajax application (written using DWR and Dojo) and the game hasn't been hacked (that I know of). Of course, I can only hope if those same Russian hackers hit it, they are as kind as they wer
    • I can only hope if those same Russian hackers hit it, they are as kind as they were before and they send details after they get tired of toying with the game.


      It looks like they fed your server polonium this time. :)
  • FTA: Furthermore, in my experience, AJAX-enabled web applications are no more functionally complex than standard web applications. ... Gmail is less complex than Outlook Web Access.

    Gmail and OWA both use AJAX. Heck, Microsoft created the XMLHTTPRequest object. Comparing Gmail to OWA to prove this point just doesn't make sense.

    • Re: (Score:3, Interesting)

      by jascat ( 602034 )
      It amazes me how people have such a false understanding of what exactly "AJAX" is. People talk about how complicated it is, which leads to insecurity. You're making requests and passing information back to the server via GET or POST. The only difference from the "traditional" way is that rather than visiting a different page, or having a self-processing page, you're having Javascript handle the sending and updating of a portion of the page. When you look at it from this perspective, you could potentially se
  • then AJAX would not exist.

    In the long term bandwidth will be (practically) infinite and whether processing is done on the server or the client will become irrelevant except that server-based processing will always be more secure and controllable.

    AJAX is a temporary tool to enhance client-server interactivity until almost everyone has a high-speed Internet connection. Once that occurs such hacks as AJAX will disappear.

    And good riddance! Because of it's arcane nature, security problems and greater developme
    • I don't think so, necessarily. Limited bandwidth is not the only reason Ajax exists. The Ajax technique is also great for providing a "hands-off" user interface. Digg Spy, for example (http://digg.com/spy).

      Although I suppose you could implement that by refreshing the whole page every time. But that would also use up a lot more CPU.
    • Bandwidth is not the issue, latency is. As long as we're limited by the speed of light, latency will be a problem. Hence the need for the 'A' in AJAX.
  • I think that there are none "inherently insecure" things. Anything can get somehow secured. I think that given a program that is specifically designed to be insecure one can still somehow (maybe by modyfiyng the enviroment it runs it or whatever) relatively secure. Well security in fact is quite relative.

    So it is not that using AJAX itself is insecure. It is that probably lot of people will try to make AJAX apps since it is trendy right now. But AJAX *is* quite complicated or just new stuff. Somebody withou
  • You allow excessive processes to be run on client side, yet you say its secure ?

    anything relegated to client side is exploitable to hell.
  • HTTP doesn't support client-side security. Not a single server supports client-side security. The only thing you can do is try to secure a client but you can't rely on the client not being compromised.
  • The original article is right that there aren't any really new problems with AJAX apps, but they are different, so some mistakes are easier to make and some mistakes are harder.

    Two of the mistakes that I've found easier to make with Ajax apps are XSS and drive-by-scripting attacks.

    XSS attacks arise when a user can put text on your site that runs with the domain privileges of your site. Once they can do that, it's easy to steal user information, cookies, etc. and send it back, or make modifications to user
  • It forces you down a design path that leads to insecure code. If you want to plug every hole, you've got to do ten times as much work.

    I wish there was some HTML attribute or some simple way of telling the user's browser things like "Don't let any of this part of the DOM tree be scripted from outside", or "this script is only allowed to do AJAX from these domains". Sort of like SELinux for HTML.

Slashdot Top Deals

Pascal is not a high-level language. -- Steven Feiner

Close