in-browser-localhostdiscovery

[utterances-bot]

rain-1.github.io

https://rain-1.github.io/in-browser-localhostdiscovery.html

[avineshwar]

TL;DR - You are vulnerable if you are browsing the web.

Some issues:

• May then you be a security engineer reviewing a phishing report (DNS rebinding aka inside-out issues)
• Enumeration for targeted exploitation (example you shared)
• Anything well known and established (CSRF, et cetera).

Some suggestion:

• Appropriate whitelisting with outbound inspection;
• following least privilege;
• avoiding processes running with higher privileges.

[ljmccarthy]

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.

[rain-1]

thank you for the comments :D

[Shamar]

Technically @ljmccarthy is right: "the worst security hole is JavaScript".

@rain-1 shows one of the many possible attacks.
With the best explaination I've seen so far. Clear and simple.

I described another PoC exploit here. Further exploits are described at the original bug report: feel free to add your own.

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.

:boom:

But here, the worse security issue is not technical: it's people's trust in IT.

[notriddle]

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.

[Shamar]

Very interesting, since with cache control and meta refresh you can hide evidence.
This basically means that invisible elements (form frames imgs) should not trigger connections (or any dom event or dom modification actually, that might be a bit complex if you consider CSS). This would also help against clickjacking.

However I think it's worth to notice that

• with JS these attacks are way easier
• some attacks are simply not possible without JS (or WASM): think for example mining bitcoins where it's not legal to do so
• with JS you do not need user interaction for most attacks
• with JS and cache control you can remove all evidences without any refresh that might be noticed by the users.

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!

[notriddle]

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.

[rain-1]

You could develop this further by:

• making it happen in parallel
• doing a port scan on the available hosts
• modules to interact with ports that seem to talk some protocol the web browser can talk, e.g. unauthenticated XML or JSON RPCs

[Shamar]

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.
It's pretty severe in some places around the world.

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).

[alvarezp]

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?

[Shamar]

Disabling JS is easy. Not breaking the Web while doing it, not so much.

If any website you visit can tunnel into your private network, the Web is badly broken already.
Very broken, if you consider such attacks are undetectable and can target specific people like Ads do.

Worse: most of people who understand the severity of these attacks omit to inform people.
People who trust them. Mozilla in primis, but many web developers too.

Yet, none of the mitigations proposed would "break the Web".
Java Applets and Flash were opt-in, without any drama.

Opt-in JavaScript on a per-website base will not break the web.
You will be able to run all applications you trust.
But you will have a chance to decide. And in the long run, people will learn to avoid JS bloat.

designing usable and much needed non-JS alternatives for common use cases

This is the research that @alcinnz is leading: PostJS Web. You can join us on the mailing list.

[alvarezp]

Disabling JS is easy. Not breaking the Web while doing it, not so much.

If any website you visit can tunnel into your private network, the Web is badly broken already. Very broken, if you consider such attacks are undetectable and can target specific people like Ads do.

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.

Opt-in JavaScript on a per-website base will not break the web. You will be able to run all applications you trust.

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.

designing usable and much needed non-JS alternatives for common use cases

This is the research that @alcinnz is leading: PostJS Web. You can join us on the mailing list.

I am so glad to read this! Count me in! I just subscribed. I have some ideas to share.

[Shamar]

Just like before HTML5 client-side form input validation was impossible without JS

You forget XForms.
The people who created HTML5 to spread JavaScript adoption are the same people who did not completed the implementation of XForms, despite it was addressing these same issues.
JavaScript was a (legit) political decision but not a technical one.

Developers are not supporting this development model.

This would be a legit decision, but it's not what they are doing.
They omit to inform their users: people, companies and organizations.

I have some ideas to share.

You are welcome! :-)

[Shamar]

Hi @rain-1, good catch on telegram!

What it “breaks” to is some kind of debugging utility and / or security test proxy. It is not clear why Roskomnadzor needs this.

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.