3 ms·
What security? The very narrow instance where your browser allows a MITM attack, and for some bizarre reason the attacker can't change the user agent to match C
by danShumway 7y ago
What security? The very narrow instance where your browser allows a MITM attack, and for some bizarre reason the attacker can't change the user agent to match Chrome's?
I am of the feeling that if Google's security practices require trusting an attacker not to change a user agent -- well frankly, in that case I am skeptical these changes are actually about security. Because the Google security team is smart, and I assume they wouldn't do stupid things.
But I am cautious about jumping to "this is malicious." There is certainly enough anecdotal evidence for a reasonable person to claim that Google targets competitors and tries to use changes like this to hurt them. However, it's not (currently) enough evidence for me. I am still naive enough to believe there is some semblance of good will at the company.
But I feel very comfortable saying that this is security change won't do much good, and the Google security team probably just thought, "why not turn it on?" without caring about potential consequences to competitors, because they don't think about anything outside of Google's ecosystem. I generally don't get the feeling that Google engineers are malicious, just that they're thoughtless and/or careless. I don't get the feeling that they're trying to mess up the web ecosystem, just that they act impulsively and feel very strongly that people shouldn't be questioning them; and that when people do question them, they tend to dig in their heels and become very condescending very quickly.
But again, I know there are Edge devs and Vivaldi devs that would call me naive.
- shadowgovt 7y agoIf the browsers in question don't correctly implement all necessary standards to guard against XSS, frame-busting, and MITM attacks, Google will do what it can to protect its users against foot-shooting. Changing the UA is equivalent to "voiding the warranty," so I'm not surprised Google isn't taking extraordinary measures. At some point, if your users really want to shoot their feet, there's only but so much you can do to stop them.
- danShumway 7y agoIf a browser doesn't implement the standards to guard against MITM attacks, what makes you think it implements the standards to guard against user-agent manipulation during the MITM attack? You've misunderstood what I'm getting at here. It's not the user that's going to purposefully change their agent -- it's that a browser that is insecure to the point that you can't trust it to log in is also insecure to the point that you can't trust its user agent to be reported correctly. The entire security exercise is pointless because compromised browsers lie. They don't respect user preferences. An attacker who intercepts and modifies a request isn't going to suddenly start being honest with you when you ask what browser that request came from.
- shadowgovt 7y agoThe code paths to change UA and implement XSS protection are different code paths.
- danShumway 7y agoNo, User-Agent is no longer a forbidden header for Javascript fetch requests[0]. To be fair, both Chrome and Firefox have outstanding bugs where they haven't yet implemented the correct specs. But there is no reason to assume that a spec-compliant browser will block Javascript from setting the User Agent for a request. It's likely to allow it, because allowing it is the correct behavior. Even if it wasn't the correct behavior, it's silly to assume that a browser that doesn't implement XSS protection is suddenly going to get good security when it comes to implementing UA freezing in request headers. I don't think there's a world where a browser maintainer says, "it's too much work for me to respect CORS, but I really want to make sure I'm following this obscure forbidden headers list". [0]: https://developer.mozilla.org/en-US/docs/Glossary/Forbidden_header_name https://developer.mozilla.org/en-US/docs/Glossary/Forbidden_...