HN user

moloch

289 karma

[ my public key: https://keybase.io/moloch; my proof: https://keybase.io/moloch/sigs/fTjH7v0drtEtO5GkBwQk1HrndrW69IOMtmaXzdJ8Y0o ]

Posts11
Comments61
View on HN

No, they don't have access to the Wireguard keys and everything is point-to-point. They'd have to push a backdoored software update to gain access (and this is a threat with any vendor product).

No, unless combined with WebUSB trickery, and such an attack has been possible in the past. However, browsers currently implement blocklists of HIDs and other USB types from working with WebUSB.

I think their main mistake was requiring a user to change their password to upgrade the hash instead of upgrading the hash on the next user login.

Is that enabled by default in 4? I use and identical AOT build process with 2.4 and 4 (ng-cli) and there's no problems building with 2.4

Lol, if only the real world were that simple. I have an Angular 2.4 project that when updated to 4.0.0 produces about 300+ build time errors (guess you can't access `private` members from templates anymore, it'll be fuuuuuun updating every component and template to work with "backwards" compatible v4), but basically every other version of Angular breaks your code so you just sorta have to live with it.

This is bad but not horrible, especially in the example given leaking the reset token to Cloudfront. The application is loading JavaScript from the Cloudfront origin, so that origin by definition could already read the tokens by modifying the JavaScript (assuming no SRI). The request is sent over SSL/TLS so the token cannot be viewed by a MITM, and referers aren't sent across HTTP<->HTTPS transitions.

Again this is far from ideal, but also not readily exploitable by attackers that couldn't already access the data.

Well TypeScript is sort of "optionally typed" (variables can have a type of `any`) it's also superset of JavaScript so any valid js is valid ts.

Yes, blacklisting is insufficient in general. But it covers many cases, including the one here. Contextual encoding must be done each and every place you emit user input into HTML, and it's easy to screw this up.

Blacklists are only acceptable if you do it in addition to contextual encoding wherever you emit user controlled data, and even then a much stronger protection would be to whitelist acceptable characters. Either way, contextual encoding whenever you emit user data is the only real protection. --And even then it's not a good fallback protection, a strong Content-Security-Policy should be your fallback protection.

Unless you're intending for your user to post HTML, or math inequalities, or diff patches - there's no reason to allow angle brackets on a form post.

Form posts are not the only vector for XSS, any HTTP request can be potentially exploited to perform XSS (and any part of an HTTP request), doesn't matter if it's a Form, an AJAX request, an HTTP header value, or a GET parameter, they're all potential attack vectors.

The actual quote was:

“First of all, VR displays are a little too cumbersome. It has to be much more elegant, being connected by a wire has to be solved. The resolution has to be a lot higher. The physical worlds do not behave according to the laws of physics. The environment you’re in isn’t beautiful enough. We’re going to be solving this problem for the next 20 years.”

"Solving over 20 years" / "20 years from being solved" are very different things.

Well the lack of SOP is by design, since it's not a browser visiting multiple sites the idea of an "origin" doesn't always make sense. This is part of a larger body of work we've been researching, we found much more than this one (all known bugs have been patched, that's why we've been waiting to release this). We'll be submitting the full body of work to DEFCON/Blackhat, and a few other cons, hopefully we'll get accepted, be on the lookout if we do!