Slashdot Mirror
Cross-Site Scripting Enabled On 1000 Major Sites (thestack.com)
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.
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.
https://annevankesteren.nl/2012/12/cors-101
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.
Your ad here. Ask me how!
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).
Wonder what the public key field is for?
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.
This posting is provided 'AS IS' without warranty of any kind, implied or otherwise.
Nobody goes and clicks a button to "enable" cross-site scripting.
They simply fail to prevent it.
Like how Slashdot fails to provide any real News for Nerds.
Is it to support third-party advertising and "telemetry" and analytics and a dozen other varieties of tracking what we do?
What in the fuck?
This is the kind of shit that can happen when using the web, because it's just one filthy hack layered on top of another. The web has been bent and twisted into a really half-arsed application development platform, built around one of the worst programming languages around (JavaScript), combined with a print-oriented style description language (CSS), tied together with a goddamn markup language (HTML). Given its origins and evolution, we shouldn't expect it to be anything less than broken, even in the hands of the most talented users. It's shit from its bottom to its top.
As bad as the web stack is, what I'm extremely concerned about is Rust. It's being portrayed as the holy savior of software security, yet it's very doubtful that it offers any benefits at all. Scarier, though, is how anyone who questions Rust tends to get attacked. I saw an example of this today, where somebody questioned Rust and was swiftly attacked by Rust supporters who downmodded the comment. Remember that Rust is being developed by Mozilla, who are using it to develop Servo, which is supposed to be their next-generation web engine.
Things are bad enough already when it comes to the web. It really scares the shit out of me that anyone who questions Rust gets attacked and silenced in such a manner. We can't move software security forward when we have people buying into hype, rather than substance. We surely can't move software security forward when anybody who questions Rust gets attacked with censorship.
Like any sane web user, I use a ton of browser extensions that warn me about requests to questionable third-party hosts.
When I browse Slashdot, requests are attempted to "Taboola" and "Janrain" and "ScoreCard" and "NTV" and "rpxnow" and "StackSocial".
Now I don't know what the fuck any of those are, and TBH I don't care to know.
So let's say I made an HTTP request to slashdot.org. As far as I'm concerned, the page served up by slashdot.org doesn't need to require requests be made to any other host to show me the stories and comments here.
whipslash, can you give us more information about what these questionable third-party hosts are doing, and why the pages served up by Slashdot try to trigger requests to these questionable hosts?
More importantly, when will slashdot.org stop trying to get my browser to make requests to them?
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?
lol
>
More importantly, when will slashdot.org stop trying to get my browser to make requests to them?
maybe when u start 1337 ad blocking like its 2001, hax0r? hth k thx bye
Another reason to run NoScript, which blocks these kinds of shenanigans.
8chan did this for a while (and likely still does, not checked), and it led to a hilarious exploit that worked via another Reddit exploit or something like that.
It abused the in-page "extension" system to store data inside one of its fields.
It is shocking how many sites have this enabled without a care in the world to look up what it actually means.
Worse when they have it on domains that are "secure".
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.
Also vendor SDKs that are loaded from their canonical sources, etc...
This doesn't allow traditional cross-site-request-forgery. The browser won't send authentication information or cookies unless the code explicitly enables it.
Even if it does, the destination server needs to return a "Access-Control-Allow-Credentials: true" header for the response to be made available to the caller.
Without that extra header sent in the response, it's no different than adding a hidden form to the DOM and submitting it. All you can do it send a request, you can't read the response.
If you web application is vulnerable to the form submission attack vector, the "Access-Control-Allow-Origin" header won't help you at all. Setting it to * isn't going to make it any worse.
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.
>
More importantly, when will slashdot.org stop trying to get my browser to make requests to them?
maybe when u start 1337 ad blocking like its 2001, hax0r? hth k thx bye
fuck your gay adblocking, get a scriptblocker which actually protects against cross site scripting attacks, moron
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 function, it isn't a vulnerability, it's a feature, and a useful one at that.
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".
Given that the web is an interconnected place, it isn't unreasonable to use resources from other hosts. That's been going on since at least '95. Sigh. Your objection is companies are using that to track you, allowing them to pay slashdot and others to keep websites running.
. Define sqrt(x) as something really evil like (x / rand()), and bury it deep. Watch your coworkers go nuts.
APK Hosts File Engine 9.0++ SR-4 32/64-bit http://www.start64.com/index.p...
* Accept NO substitutes... Custom hosts files blocking entries stops requests to known "bad actors" in 3rd parties linked to on websites.
APK
P.S.=> Does more for speed (hardcoded favorites + adblocking), security (adblocking + blocking known bad sites/servers & dns issues avoiding DNS), reliability (vs. downed or dns poisoned dns), & anonymity (avoiding dns request logs) than ANY other SINGLE "so-called -solution'" out there, bar-none, for less using what you already natively have - unlike "AlmostALLAdsBlocked", UBlock, Ghostery etc. it's not detectable & blockable by ClarityRay/BlockIQ + it uses FAR LESS RESOURCES yet does far more (especially vs. DNS security issues)... apk
You're right. Those 1000 hosts probably used the APK hosts tool, and thus got the security vulnerability mentioned in the article.
See subject: If anything IF they used it they'd have been safer for it as my program blocks online threats...
APK
P.S.=> You dimwit trolls + shills for inferior competing products are so desperate you'd lie - which only makes me stronger knowing you're resorting to that... apk