Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?
Check out the new SourceForge HTML5 internet speed test! No Flash necessary and runs on all devices. ×
The Internet Bug Security

Cross-Site Scripting Enabled On 1000 Major Sites (thestack.com) 54

An anonymous reader writes: A CloudFlare engineer has discovered that 1000 of the top one million websites, including bitcoin holding sites and trading sites, are running a default setting that enables cross-site scripting. This article details his examination of the top 1 million Alexa sites for evidence of compromised settings and finds that about 1000 of the sites on the list are capable of being compromised because of running a header called Access-Allow-Origin. He found the vulnerability while working on a legitimate use of domain-communication called Cross Origin Resource Sharing for the Stripe API. The header, which Johnson claims the vulnerable websites are outputting, is concluded with a wild-card asterisk, meaning that the sites in question are giving full permission for cross-domain communication via venerable protocols such as SOAP/AJAX XML exchanges.
This discussion has been archived. No new comments can be posted.

Cross-Site Scripting Enabled On 1000 Major Sites

Comments Filter:
  • Bad Summary (Score:3, Informative)

    by Anonymous Coward on Tuesday February 23, 2016 @05:52PM (#51570451)

    Bad summary, as usual. Access-Control-Allow-Origin: * explicitly forbids requests with credentials. Even if the host reflects the Origin domain in the Access-Control-Allow-Origin header, it must also send Access-Control-Allow-Credentials: true to be vulnerable.

    • Re:Bad Summary (Score:4, Interesting)

      by DJ Rubbie ( 621940 ) on Tuesday February 23, 2016 @06:06PM (#51570549) Homepage Journal

      Not only that, this is not even Cross Site Scripting (XSS), but a straight up Cross Site Request Forgery (CSRF) even though XSS might be involved for this issue. XSS is where client-side scripts are injected directly into the response body of an affected website, typically through unescaped html input that gets rendered by web browsers belonged to victims who then make that subsequent client request. CSRF is where the victim's browser is told to do an action (via Javascript doing an asynchronous javascript/xml (AJAX) request) on the target's website by an unrelated website that the victim somehow visited, and sometimes this attack script is injected via XSS by attackers on a completely unrelated site. While XSS can be related, it is completely distinct to the CSRF issue which is what is being not properly mitigated against by these top websites (In fact, as parent said, they purposefully disabled this protection).

      • by jrumney ( 197329 )
        What proportion of the top million websites do we expect to be offering public APIs, designed to be used in this way (maps.google.com as just one example)? 1 in a thousand maybe?
  • I told you to stop picking on us! Leave Slashdotters alone! Leave them alooooone! /cry

  • Why are we trusting site X as to whether we should load XSS from it. Or better yet, why not just deny third-party scripts.

    • Exactly. Cross site scripting was bad from the beginning, and it only got worse when the advertising industry discovered how they could abuse it. Pretty much everything is blocked on my network. Screw the advertisers, and screw everyone who thinks that my bandwidth belongs to them. I want to read Slashdot, and that's all I want. If it becomes mandatory to load crap from third party sites, then I'll stop reading slashdot. It's that simple.

  • Access-Control-Allow-Origin: * allows all the same information (less, actually) that you would normally need a proxy to access (i.e. making an AJAX request to the same domain, that gateways the request to a remote server). There's no security vulnerability here, so long as the websites are on the public Internet (and not behind a firewall/private intranet).

    • Re: (Score:3, Interesting)

      by Anonymous Coward

      Step away from the keyboard and stop giving security advice! That header lets any site load any content from that site, so if you are logged into with-header.example.com and you're looking at bigbadwolf.example, then bigbadwolf.example can impersonate you on with-header.example.com, because it can use your logged-in browser to access with-header.example.com, instead of accessing only the public information that it could get by accessing it from the server of bigbadwolf.example.

  • I can't read TFA due to work blockage. The summary makes it sounds as if he discovered a vulnerability, analyzed a bunch of sites for it, then published a list of the vulnerable sites along with details of the vulnerability.
  • by Anonymous Coward

    So, we are saying that .1% of web sites have this vulnerability?

    And this is news?

    Also the poster is worried about bitcoin, which has bigger problems than XSS?


  • Another reason to run NoScript, which blocks these kinds of shenanigans.

  • by Anonymous Coward

    That's a very large net to catch a not so sensational number. Look at it another way: that's 99.9% of the top one million websites *don't* "run a default setting that allows cross-site scripting".

    Seriously, "top one million" means they're trawling pretty far down the pool to find these idiots.

  • Missing feature (Score:4, Insightful)

    by manu0601 ( 2221348 ) on Tuesday February 23, 2016 @10:54PM (#51572365)

    The problem is that Access-Allow-Origin cannot hold multiple value, which pushes developers to use * so that it works with more than one site

    The right solution is to read the requester site name and return the Access-Allow-Origin header with it if it is in a whitelist. But that require a few extra line of coding.

    • The spec is short-sighted and should've been designed to allow multiple origins. The spec puts the onus of implementing support for multiple origins back on the server-side developer, when it would've been better implemented in the browser.

  • There actually isn't any problem here, as all these sites are just as vulnerable to direct attacks irrelevant of the XSS headers. XSS only protects users which load data from suspicious websites, and those websites intend to make malicious calls to the vulnerable ones. Oh, did I mentioned the user has to be still logged in. This is nothing new, and why most browser default configuration is to prevent XSS. As a matter of fact XSS is required for all those social media APIs little icons to actually functi
  • by Anonymous Coward

    If you have to examine a million sites to find 1000 with that vulnerability, not only should you be trumpeting the fact that "...99.9% of the web is safe from this particular attack vector" (which doesn't sound NEARLY as inflammatory or click-baity) but you are also using a much broader definition of "major" in describing those websites.

    I'd be willing to bet that once you get below the top 1000 on Alexa not many people consider anything in the rest of the "top 1,000,000 web sites" as "MAJOR".

How come everyone's going so slow if it's called rush hour?