Slashdot Mirror

← Back to Stories (view on slashdot.org)

Cross-Site Scripting Hits Major Sites

Posted by ryuzaki0 on from the scriptdidy-doo-daa-scriptdidy-day dept.

An anonymous reader writes "Dark Reading and SC Magazine covered a story about hackers posting cross-site scripting (XSS) vulnerabilies en mass on dozens of high profile websites including Dell, MSN, HP, Apple, Myspace, YouTube, MSN, Cingular, etc. The media coverage drew the hacker's attention to the publication's websites where they got a taste first-hand. On message board wall-of-shame is PC World, MacWorld, Fox News, the Independent, and ZDNet UK. "...not only did we get the "scoop" on the XSS site problems, but we also got the message loud and clear: Don't assume you're immune to XSS vulnerabilities. They're everywhere." The news comes shortly after Mitre (CVE) released statistics showing XSS has become the most popular exploit. Unfortunately new XSS attacks are growing increasingly severe and scanners are unable to find many of the issues on modern websites."

4 of 161 comments (clear)

  1. The Cross Site Scripting FAQ by mrkitty · · Score: 5, Informative



    The Cross Site Scripting FAQ

    --
    Believe me, if I started murdering people, there would be none of you left.
    1. Re:The Cross Site Scripting FAQ by blowdart · · Score: 5, Informative
      No it doesn't. Cross site scripting works by adding a script tag to the source page. For example, imagine you have allowed scripts from slashdot because you can't use the new comments system without it.

      Now an evil hax0r manages to insert an XSS attack on slashdot what would happen is the attack would be embedded in a normal slashdot page, as a block. So the source would be from slashdot.org, and noscript would view it as being allowed.

  2. I do my duty and report them. . . by Hero+Zzyzzx · · Score: 5, Insightful

    but it's probably pointless. Not enough developers care about their craft.

    There's a prominent "popular science" website out there (no, it's not this one that I'm thinking of) that has ENORMOUS XSS vulnerabilities in its image gallery. They pass captions and img src in URL encoded query string parameters. Yuck.

    I noticed this about a year ago and reported it to the development team, with a demonstration link that put in a (sorta not nice) image and caption. No response, and when I checked six months ago the vulnerability was still there. So much for being a nice guy.

  3. Validate, Validate AND Validate by Joe+U · · Score: 5, Insightful

    I'm a web developer and I've said this dozens of times.

    VALIDATE ALL INPUT EVERYWHERE.

    Validate on the client. (For bandwidth reduction)
    Validate at the APP Tier (For security)
    Validate at the Data Tier(For security and integrity)

    If you accept input from a web page, scrub it, and that doesn't mean stripping brackets or quotes, it means putting in a list of valid characters and tossing or replacing absolutely everything else.

    Yes, you might wind up validating something that doesn't need to be validated or scrubbing something that doesn't need to be, the performance hit is worth it.

    Also, Stored Procedures are a great resource, if you design them properly you add an extra layer of security that can actually improve your application performance. (All my recent projects have Stored Procedure execute only rights.

    If your db code has select * from table in it, you're doing it wrong.

    Ok, enough ranting from me.