Hacker News Reader

Comment by baybal2 | Hacker News Reader

> A technical solution could be to add a strict CSP policy but in general the problem is broader and applies to a lot of banks.

The Web is broken, and CORS/CSP headers will only be able to fix only some individual cases, of a bigger, currently unfixable design problem.

The tons of random JS APIs brought into the browser without a any real critical review are making the initial design of scripts on the web being inherently secure, to them not being so.

The state of things needs to be brought back to the point where arbitrary JS simply cannot mess up your browser by design, and when you can load resources from everywhere safely regardless of tricky settings of now 10+ CSP related headers.

Or alternatively, there needs to be a solution to completely shut down those APIs, any "advanced" functionality to load 3rd party resources, reinforced by cryptohashes, and signature checks to verify loaded resources.

View on HN

No bank should ever use third party resources. Problem solved.

Imagine a situation where somebody manages to inject own script into bank's page not through employee's negligence, but through some exploit.

You would still have an issue where there is simply no functionality to killswitch all those novel APIs of arguable safety, and tell the browser to shut down any script not explicitly listed as allowed on the site.

"tell the browser to shut down any script not explicitly listed as allowed on the site"

Isn't that what CSP headers are for?

CSP has been an inconsistent, ever growing standard, with a history of implementation breakages. I think only CSP 3.0, and a long WIP safe types standard have approached the level of being actually useful.

I saw websites with a screen long CSP header to work around standard's inconsistencies like frame-src/child-src, and form redirects. I think it's only a matter of time when somebody will find a chink in that weak armour.

The lack of sane by-default policy makes you vulnerable the moment attacker finds a way to redirect a browser to a non-CSP protected page on your domain. Mitigations exist, but... many buts.

Reflection attacks, when attacker injects your own hashed scripts, and data exfiltrating css on pages where they shouldn't be are still possible in various scenarios unless you inline all scripts, and set CSP per every URL.

Other data exfiltration sources, and injection sinks keep being found few times a year.

CSP is a paint over rust.

> The state of things needs to be brought back to the point where arbitrary JS simply cannot mess up your browser by design

What do you imagine your more restricted JavaScript being permitted to do, where it is safe to run on a banking website?

The same thing the language was originally intended for? Namely, the <marquee> content.

WASM needs to be killed with fire before it's too late.

Hard disagree. WASM is as good an opportunity as any to enforce better security habits, and indeed seems to be designed specifically with browser security/sandboxing in mind. "Killing" WASM does precisely nothing to fix the status quo around JS insecurity.

Yes, so were Java and applets. And we all know what happened there.

Why? I don't know much about WASM, but surely it is better than the cobbled together monstrosity that is JavaScript.

All the insecurity of js, but with the opaqueness of assembly.

Hard disagree. WebASM and emscripten is the way away from JavaScript, into a better future where code is more cross platform and more performant.

Fully agreed!

Reply on news.ycombinator.com