Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
×

Top 10 Web 2.0 Attack Vectors 64

Fred writes, "HNS is running a story about Web 2.0 and the new attack vectors it opens up. Worms of the Yamanner, Samy, and Spaceflash types are exploiting client-side AJAX frameworks, providing new avenues of attack and compromising confidential information. On the server side, XML-based Web services are providing distributed application access through Web services interfaces and opening up new vulnerabilities in the process." The article is spread over 6 short pages and there is no printer-friendly URL.
This discussion has been archived. No new comments can be posted.

Top 10 Web 2.0 Attack Vectors

Comments Filter:
  • Off-topic (Score:5, Funny)

    by DaveM753 ( 844913 ) on Monday October 09, 2006 @02:54PM (#16368775)
    > "The article is spread over 6 short pages and there is no printer-friendly URL."

    Boy...I really hope Web 2.0 markup language allows for longer page length. ;-)

    • > "The article is spread over 6 short pages and there is no printer-friendly URL."

      Its the first time that I've seen a slashdot article say something useful :)
    • Comment removed based on user account deletion
      • Re: (Score:1, Insightful)

        by Anonymous Coward
        Um.. in case you didn't know, the printer-friendly URL is favored by /.ers because it's usually not spread over those 6 pages, and there isn't the ton of ads that make them want to chop it up to get you to read 6x as many in the first place. In other words, it's possible to read TFA without hating life.
        • In other words, it's possible to read TFA without hating life

          Are you referring to this actual article about the so-called "Web 2.0"..? What's becoming of the world today? *cries quietly into his Amiga 1200*

          :(
      • Re: (Score:2, Funny)

        by Mixel ( 723232 )
        Dammit! I always print out both Slashdot discussions and source articles for archive purposes. Now what?
        I believe the "Print Screen" button is reserved specially for such emergencies. You can scroll the source article and print out the screenshots. As a bonus, you'd preserve the browser culture of this glorious era.
        • Alternatively, copy+paste the actual text.

          As a bonus, you won't preserve the browser culture of this era.
  • by zappepcs ( 820751 ) on Monday October 09, 2006 @02:54PM (#16368779) Journal
    to build you a sand box to take care of all the new features but still protect your pc from all the evils of the world wide web.

    Seriously, shouldn't 2.0 come equipped with some things that make it safer, not just more flashy?
    • Sadly, this is the way it's always been. Flash it up, then worry about securing it.
    • Seriously, shouldn't 2.0 come equipped with some things that make it safer, not just more flashy?
      Uh, "Web 2.0" isn't a product. It's a buzzword for flashy things, so it makes sense that it doesn't "come with" more security.
      • Holy cow! How is the grandparent marked insightful!

        I should start a business selling shrinkwrapped boxes labeled "Web 2.0" with install discs for IE 6 and Firefox 1.x. I'll make millions!

        • I'm way ahead of you, I've still got a few bugs to work out, but I think I'll be able to release Web 3.0 in time for the Christmas rush.
    • by k12linux ( 627320 ) on Monday October 09, 2006 @06:52PM (#16372193)
      Most of these come back to developers violating one of the key rules of web application development (from the web 1.0 stuff as well.) DON'T IMPLICITLY TRUST DATA YOU GET FROM THE CLIENT!

      You see it over and over again: Fantacy football sites that let you select players that aren't available by POSTing their id. A site that lets you delete your account but accepts the user ID you send in a POST without validating it (so replacing the ID with '%' deletes ALL accounts.)

      These things should only be rookie mistakes. Yeah, validating data takes time to code. But if you don't do it you are just asking to be hacked.
      • Parent is begging for insightful moderation with this one !
        I mean, it's obvious, a lot of developer are jumping on the Web 2.0 bandwagon but obviously they never worked with Web 1.0.
  • Article Text (Score:5, Informative)

    by Anonymous Coward on Monday October 09, 2006 @02:56PM (#16368807)
    Top 10 Web 2.0 Attack Vectors
    by Shreeraj Shah - net square - Monday, 9 October 2006.

    Web 2.0 is the novel term coined for new generation Web applications. start.com, Google maps, Writely and MySpace.com are a few examples. The shifting technological landscape is the driving force behind these Web 2.0 applications. On the one hand are Web services that are empowering server-side core technology components and on the other hand are AJAX and Rich Internet Application (RIA) clients that are enhancing client-end interfaces in the browser itself.

    XML is making a significant impact at both presentation and transport (HTTP/HTTPS) layers. To some extent XML is replacing HTML at the presentation layer while SOAP is becoming the XML-based transport mechanism of choice.

    Web 2.0 security concerns - reshaping the industry

    This technological transformation is bringing in new security concerns and attack vectors into existence. Yamanner, Samy and Spaceflash type worms are exploiting "client-side" AJAX frameworks, providing new avenues of attack and compromising some of the confidential information.

    On the "server-side", XML based Web services are replacing some of the key functionalities and providing distributed application access through Web services interfaces. These remote capabilities to invoke methods over GET, POST or SOAP from the Web browser itself provide new openings to applications. On other side, RIA frameworks running on XML, XUL, Flash, Applets and JavaScripts are adding new possible sets of vectors. RIA, AJAX and Web services are adding new dimensions to Web application security.

    Here is the list of 10 attack vectors along with a brief overview of each:
    1. Cross-site scripting in AJAX

      In the last few months, several cross-site scripting attacks have been observed, where malicious JavaScript code from a particular Web site gets executed on the victim's browser thereby compromising information. A recent example is the Yamanner worm that exploited cross-site scripting opportunities in Yahoo mail's AJAX call. Another recent example is the Samy worm that exploited MySpace.com's cross-site scripting flaw. AJAX gets executed on the client-side by allowing an incorrectly written script to be exploited by an attacker. The attacker is only required to craft a malicious link to coax unsuspecting users to visit a certain page from their Web browsers. This vulnerability existed in traditional applications as well but AJAX has added a new dimension to it.
    2. XML poisoning

      XML traffic goes back and forth between server and browser in many of the WEB 2.0 applications. Web applications consume XML blocks coming from AJAX clients. It is possible to poison this XML block. Not uncommon is the technique to apply recursive payloads to similar-producing XML nodes multiple times. If the engine's handling is poor this may result in a denial of services on the server. Many attackers also produce malformed XML documents that can disrupt logic depending on parsing mechanisms in use on the server. There are two types of parsing mechanisms available on the server side - SAX and DOM. This same attack vector is also used with Web services since they consume SOAP messages and SOAP messages are nothing but XML messages. Large-scale adaptation of XMLs at the application layer opens up new opportunities to use this new attack vector.

      XML external entity reference is an XML property which can be manipulated by an attacker. This can lead to arbitrary file or TCP connection openings that can be leveraged by an attacker. XML schema poisoning is another XML poisoning attack vector which can change execution flow. This vulnerability can help an attacker to compromise confidential information.
    3. Malicious AJAX code execution

      AJAX calls are very silent and end-users would not be able to determine whether or not the browser is making silent calls using the XMLHTTPRequest object. When the browser makes an AJAX call to any Web site it replay
  • Buzzwords (Score:5, Funny)

    by hsmith ( 818216 ) on Monday October 09, 2006 @02:57PM (#16368819)
    Christ, my eyes started to bleed SOAP XML SAX AJAX WEB2.0 XMLHTTPRequestObject RSS

    ojdsafdo fuck
    • Christ, my eyes started to bleed SOAP XML SAX AJAX WEB2.0 XMLHTTPRequestObject RSS

      Would this be better?

      Marklar, my eyes started to bleed Marklar Marklar Marklar Marklar WEB2.0 Marklar Marklar

      On second thought, maybe you are right.

    • by moco ( 222985 )
      Soap: Simple Object Access Protocol www.w3c.org/TR/soap, an object access protocol
      XML: Extensible Markup Language www.w3c.org/XML, a markup language
      SAX: Simple API for XML, an API for accessing XML
      AJAX: Asynchronous Javascript And XML, a BUZZWORD
      WEB2.0: a BUZZWORD
      XMLHTTPRequestObject: an object to post (or handle) XML requests made over HTTP (core of ajax).
      RSS: Really Simple Sindication, a protocol(?) for aggregating web content.

      Not all acronyms are buzzwords - N.A^3.B :)
  • XSRF (Score:5, Informative)

    by md17 ( 68506 ) * <james@jamesward . o rg> on Monday October 09, 2006 @03:01PM (#16368887) Homepage
    On this page the attacker has written silent AJAX code which makes backend calls to his bank without John's consent, fetches critical information from the pages and sends this information to the attacker's Web site. This leads to a security breach and leakage of confidential information.


    As far as I know this can't be done with Ajax, since XHR can't make crossdomain requests. However there are other techniques for this, including hidden forms, iframes, images, etc. This is commonly known as Cross-site request forgery (XSRF) [wikipedia.org] and is a major problem but not getting much publicity. I guess someone needs to write a MySpace worm that utilizes this technique before people start realizing it's a problem.
    • I guess someone needs to write a MySpace worm that utilizes this technique before people start realizing it's a problem.

      Screw over MySpace users and bring to light a potentially devestating new attack, all at the same time? That sounds win-win to me. I'm on it.
    • This is commonly known as Cross-site request forgery (XSRF) and is a major problem but not getting much publicity
      To be vulnerable, the website in question still has to allow users to enter HTML. That rules out a lot of website.
      • Above comment is faulty; I now understand the "cross" of "Cross-site request forgery".
      • by md17 ( 68506 ) *
        That's actually not true for XSRF. It's true for XSS.
        • I thought the point of XSRF was (from TFA):
          • Alice logs into website BuyStocks, forgets to log off
          • Alice visits forum H4x0r, which contains <img src="http://BuyStocks.com/buy.php?stock=MSFT&quant ity=5000">
    • As far as I know this can't be done with Ajax, since XHR can't make crossdomain requests.

      There are ways around that [dojotoolkit.org]...

      However in a way it doesn't matter if you're using pure Javascript or a XMLHTTPRequest to send the request to the remote server, the results are the same. If you're developing secure web sites you still need to worry about this possibility.
      • by md17 ( 68506 ) *
        AFAIK, those work arounds actually don't use XHR, but rather iframes. There is absolutely no way currently to make a cross domain XmlHTTPRequest. The browsers just don't let it happen.
  • No substance (Score:5, Interesting)

    by suv4x4 ( 956391 ) on Monday October 09, 2006 @03:02PM (#16368913)
    Most of those "attack vectors" boil down to injections and non-validated data, AKA "don't trust the user input". I don't know how they managed to multiply one single flaw into so many "vectors".

    And there's also this "attacking scripts in RSS": what was this supposed to mean? My RSS readers don't execute script in RSS. No examples, no links.

    One more talked about hijacking confidential information from a bank cookie. No example how this is done, just the author assumes we know how to automatically sniff the cookie, and that the bank doesn't use server-side sessions like 99% of them out there, but stores it all in a plain cookie.

    Basically the article is not as fun or informative as the title suggests.
    • Re: (Score:3, Interesting)

      by possible ( 123857 )
      I think the article does have some problems of clarity, but don't be so quick to dismiss the security issues. Using Cross-site request forgery (XSRF) against a vulnerable application, I can use a page with a hidden form (submitted automatically with JavaScript) to launch a silent cross-domain POST to your online bank (changing your password). Even if your online bank uses server-side sessions, the browser is nice enough to automatically send its cookies with my POST request. Chances are your bank is not pro
      • Re: (Score:2, Insightful)

        by profplump ( 309017 )
        No, but like every decent password-update system written since 1967, it does require me to enter my old password before I can choose a new one. Likewise, transfers and bill payments all require both an input and a validation step, in seperate page submissions, and the validation step includes a unique transaction ID. Could a sufficiently advanced JavaScript overcome these limitations? Certainly, but it's not as trivial as having a valid session ID and blindly submitting a form.
        • Re:No substance (Score:4, Interesting)

          by daviddennis ( 10926 ) <david@amazing.com> on Monday October 09, 2006 @07:55PM (#16372863) Homepage
          Guess what?

          Samy's worm did exactly that.

          Relevent extract from his fascinating account [www.namb.la], well worth reading in its entirety:

          9) Finally we can do a POST! However, when we send the post it never actually adds a friend. Why not? Myspace generates a random hash on a pre-POST page (for example, the "Are you sure you want to add this user as a friend" page). If this hash is not passed along with the POST, the POST is not successful. To get around this, we mimic a browser and send a GET to the page right before adding the user, parse the source for the hash, then perform the POST while passing the hash.

          I must say I was quite impressed, not to mention frightened half to death, by what Samy went through to create his worm. It was not a simple task at all. I had thought before that nobody would waste their time doing something like this; I was, of course, wrong.

          The consequence of his story is that I changed my own social networking site [amazing.com] to become a lot more secure. I didn't like doing it because I would have preferred to let people do what they want, but that artilce was a real eye opener as to how dangerous that would have been.

          D

      • He's not dismissing the security concerns. He's mearly stating that the article is nothing but fluff. Most of those attack vectors boil down to some kind of injection.

        I am disappointed by the lack of substance, as well. This piece is intended for managers, so they can sound like they know what they're talking about.
    • Re:No substance (Score:4, Insightful)

      by WWWWolf ( 2428 ) <wwwwolf@iki.fi> on Monday October 09, 2006 @03:15PM (#16369143) Homepage
      And there's also this "attacking scripts in RSS": what was this supposed to mean? My RSS readers don't execute script in RSS. No examples, no links.

      Not everyone's using an RSS reader from four years ago. =) Many RSS readers allow rendering of HTML. Heck, I'm using Bloglines, which is a web-based RSS reader; guess whether or not it supports HTML? However, it's up to the client to scrub the content properly and remove <script> crap.

      Another question is, exactly how can you expect to launch an attack in a web feed? People use bazillion different RSS/Atom readers, and in many cases they're entirely separate from their web browsers...

      Though, I hope people read the Atom spec [ietf.org] if they're implementing it, scrubbing HTML content is specifically addressed in the "Security Considerations": "Atom Processors should pay particular attention to the security of the IMG, SCRIPT, EMBED, OBJECT, FRAME, FRAMESET, IFRAME, META, and LINK elements, but other elements might also have negative security properties."

      • by scenic ( 4226 ) *
        I don't think bloglines executes JS in the feed. Sure, it's web-based, but it scrubs out script and object/embed tags. I've tried various methods of embedding YouTube or Google Video players into my blog posts, and they never show up in BlogLines.

        They do work in my desktop aggregator (NetNewsWire) and I've seen it work in some other aggregators.

        Sujal
    • With respect to the RSS issue, I assume that the author of the article was trying to explain in a very poorly-worded way discoveries like these:

      http://www.spidynamics.com/assets/documents/Hackin gFeeds.pdf [spidynamics.com] (warning: pdf)
      http://www.gnucitizen.org/blog/cross-context-scrip ting-with-sage/ [gnucitizen.org]

      etc, etc.

      However, I agree that most of the points were simply various different ways unchecked user input can be exploited, and the banking example was absolutely horrible.

      My overall impression was that the author either had n
    • And let's not forget HTTPS can be used to avoid all the problems the article mentions...
  • Use good practices (Score:2, Insightful)

    by Anonymous Coward
    Ajax does not inherently introduce new security vulnerabilities into the realm of web applications. Instead, the applications face the same security issues as regular web applications. Unfortunately, common Ajax best practices have not been developed, which leaves plenty of room to get things wrong. This includes proper authentication, authorization, access control and input validation.

    Consider the following:

    - Ajax inevitably increases the overall complexity of the system.
    - Typically, many web services with
  • The article is spread over 6 short pages and there is no printer-friendly URL.

    ...and that's just to start. The article is maybe 2 inches wide, flanked on either side by an ad tower and more "articles" broken up in no discernable fashion. Don't forget the google ads after the first paragraph of the article!

    Really, kdawson, we're not so hard up for stories around here that this should be an okay thing to do. And it isn't as if you didn't look at the article first... what's up?

  • The shifting technological landscape is the driving force behind these Web 2.0 applications. On the one hand are Web services that are empowering server-side core technology components and on the other hand are AJAX and Rich Internet Application (RIA) clients that are enhancing client-end interfaces in the browser itself.

    The shifting literary landscape is the driving force behind these Word 2.0 articles. On the one hand are buzzwords that are empowering author-side core diction components and on the othe

  • by possible ( 123857 ) on Monday October 09, 2006 @03:06PM (#16368981)
    Thanks to the use of AJAX, we are seeing new numbers of what Amit Klein called "DOM-based cross site scripting" in his paper of the same title [webappsec.org]. These are essentially browser-based cross-site scripting vulnerabilities that require JavaScript. Since these XSS vulnerabilities require a browser executing JavaScript to work, 99% of vulnerability scanning tools out there can only detect server-based XSS vulnerabilities. Server-based protection mechanisms will be completely ineffective because the attacks can be completely hidden from the server (e.g. as Amit Klein points out, you can include XSS scripting after the hash (#) part of the URL, denoting an anchor fragment which is actually stripped off before the request is made to the server, but the entire URL is still available to JavaScript as document.location.

    In order to detect these sorts of vulnerabilities in an automated fashion, there are only two decent approaches to choose from:

    1. Dynamic analysis: Feed the entire site, page by page, to a live browser and try to reproduce the XSS using a large number of browser actions as input. This is practically difficult and could also be quite risky (you can get owned yourself while doing it), and to get a good test you need to run a large number of inputs on several different browsers.
    2. Static analysis: Spider the site and run static analysis on the JavaScript on a page-by-page basis. This is much more promising, although obviously static analysis on a language like JavaScript, which is loosey-goosey with typing, is not trivial. Shameless plug: There are only a couple of tools which can do this: NeXpose from Rapid7 [rapid7.com] is one of them that I have worked on.
    JSON itself is kind of cool, but many AJAX toolkits (including the one from Google) do AJAX/JSON things like:

    var result = eval(document.responseText)

    which is a bit scary when you think that it may be possible to trick the server into emitting JavaScript (which, given the limited kinds of filterings that servers do, could be easier than tricking the server into emitting HTML).

  • Sounds like it was titled by a staff writer from 24. I expected to see a little headshot of Chloe on the first page of the article.
  • by Anonymous Coward on Monday October 09, 2006 @03:29PM (#16369377)
  • NO Surprise (Score:3, Insightful)

    by unity100 ( 970058 ) on Monday October 09, 2006 @03:29PM (#16369395) Homepage Journal
    If you allow more stuff to be run client-side, you allow for more mischief.
  • OMG... (Score:2, Funny)

    by Anonymous Coward
    My THING might have some STUFF done to it!
    These PEOPLE must be STOPPED before THE WORST happens!
  • Not News (Score:2, Informative)

    If you want to know about web application security visit owasp.org [owasp.org]
  • JavaScript, like all downloadable executables, cannot be trusted. There is no other way.

    "Carthago delenda est!" ("Carthage must be destroyed!")
      - Cato the Elder to the Roman Senate
  • .. on communities and how to community creators can avoid it can be found on http://www.alistapart.com/articles/secureyourcode/ [alistapart.com]

If the code and the comments disagree, then both are probably wrong. -- Norm Schryer

Working...