-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
in-browser-localhostdiscovery #4
Comments
TL;DR - You are vulnerable if you are browsing the web. Some issues:
Some suggestion:
|
Webpages should not be able to load resources from other domains. This would close a lot of security holes. Of course the worst security hole is JavaScript, which allows anyone to execute arbitrary code on your computer. No matter how carefully sandboxed, this is a very bad idea. Combined with the ability to load resources from other domains, it's a disaster. |
thank you for the comments :D |
Technically @ljmccarthy is right: "the worst security hole is JavaScript". @rain-1 shows one of the many possible attacks. I described another PoC exploit here. Also consider how HTTP Cache-Control makes these JS attacks undetectable (and how worse it would be with GCC/CLang optimized WebAssembly). And then add BeEF (The Browser Exploitation Framework) to the mix. 💥 But here, the worse security issue is not technical: it's people's trust in IT. |
You're right that JavaScript can be an exploit vector, but disabling JavaScript isn't enough to fix intranet-busting attacks. A site can request resources from another domain even if JavaScript is turned off. Forms alone are enough. |
Very interesting, since with cache control and meta refresh you can hide evidence. However I think it's worth to notice that
Now my point is: there are many many dangerous security issues in the current Web, but it's pointless to address each of them separately while JS is bindly executed by browsers anyway. It's like curing a fever while pretending to ignore thar the patient has a deathly cancer! |
The attack listed on the wikipedia page used a perfectly visible image element that just happened to have side effects when the browser would GET it. It came out broken, but broken images in a forum thread are like dandelions in a field. The security problem described in the OP is caused by cross-origin requests. And I personally think it's way more severe than Bitcoin mining scripts, which are effectively the same thing as Rickrolling. |
You could develop this further by:
|
Indeed. These are just examples. You could learn the political orientation of a user timing the load of specific images from third parties to see if they are in the cache (effectively bypassing history access rules). And so on. Also you shouldn't dismiss the legal issues. The point is: there are many security flawns in mainstream browsers, with JavaScript being the biggest one. People do not really understand these. Nor do companies or governments. We shouldn't use the existence of less severe issues to justify the worst one. We should simply fix them, starting from the biggest (which fortunately is relatively easy to address). |
What do you mean? Disabling JS is easy. Not breaking the Web while doing it, not so much. I mean: designing usable and much needed non-JS alternatives for common use cases. Or do you mean something else? |
If any website you visit can tunnel into your private network, the Web is badly broken already. Worse: most of people who understand the severity of these attacks omit to inform people. Yet, none of the mitigations proposed would "break the Web". Opt-in JavaScript on a per-website base will not break the web.
This is the research that @alcinnz is leading: PostJS Web. |
I understand (and support) your point. However, I don't want to go into terminology nitpicking. It is important to acknowledge that, today, there are common use cases that are only available through JS. Just like before HTML5 client-side form input validation was impossible without JS, nowadays, multi-column (multi-control) dropdowns are impossible without JS. We must acknowledge these use cases and not assume that plain-disabling JS will be accepted by others just because.
That's exactly how I think. But it breaks people's current Web mental models. People will immediately push back: "so, you want to go back to the full page reloads as in the 2000s?" Idea: shipping a browser with JS disabled by default for non-technical users "breaks the Web" (for some definition of "breaks" and "Web", of course) despite also fitting the definition of "Per-website JS opt-in". Developers are not supporting this development model.
I am so glad to read this! Count me in! I just subscribed. I have some ideas to share. |
You forget XForms.
This would be a legit decision, but it's not what they are doing.
You are welcome! :-) |
Hi @rain-1, good catch on telegram!
This puzzled me a bit too, till I realized that such tools can be used to detect the evidence removal I described in the Mozilla bug report. In practice they want to know who could detect a JavaScript attack despite the clever use of cache control header. |
rain-1.github.io
https://rain-1.github.io/in-browser-localhostdiscovery.html
The text was updated successfully, but these errors were encountered: