|
|
|
|
|
|
by sopooneo
1046 days ago
|
|
|
My personal inclinations agree with yours, I think. I prefer as much detail as possible up front. Which is why I hate the vagueness of my dashboard's "check engine" light*. However, I bet automakers do that not just so the display is cheaper/simpler, but because most drivers are not interested in anything more detailed (or scary). * Which for me has almost always just meant some oil change "timer" was up, not even that any meter detected my oil was wearing out. |
|
|
1. the attacker can see (but not decrypt) the victim's TLS traffic to example.com
2. an attacker-controlled website makes the victim send many different invalid requests to example.com, each of which gets an error message
3. some data in each request is attacker-controlled, but authentication data in headers is filled in by the victim's browser
4. example.com compresses response data before encrypting it
5. because repetitions affect compression, the response size is smallest when the authentication data matches part of the attacker-controlled data
6. after enough requests, the attacker knows the authentication data to login to example.com as the victim
One workaround for CVE-2012-4929 was to set up the server so that an error message never depended on the request data. Before CVE-2012-4929 was announced, people thought it was sufficient to sanitize the error message (i.e., avoid XSS) but CVE-2012-4929 prompted a shift toward producing exactly the same error message for all invalid requests. (Not sure, but I think this was the original motivation for Google's famous "That's an error. That's all we know." messages.)
There were better CVE-2012-4929 defenses later, but the cargo cult had already formed. (Some subset of) a generation of developers believed that customized error messages were Very Bad because they enabled account takeover.