default security responses
We would like to thank you for the efforts you made in reporting this issue, but we’re afraid we can’t honor this as a valid bug-report.
The kind of bug you’re reporting is a:
- content injection attack
- XSS attack
- ‘missing features’ thingy (HSTS, X-XSS, DKIM, SPF, etc)
- set header because browser X is crappy and doing stupid, insecure things (X-Content-Type-Options,etc) report
- I think you should do X advisory
- valid bug
- Behavior that is there for a real purpose
- information disclosure report
- valid bug if it was exploitable on our platform
- Theoretical behavior that’s not exploitable in the real world (TM)
- Disclosure of info that might be used during the reconnaissance stage
The reason for not honoring the bug is that:
- The behavior is not a bug, it something that could be a precursor to a bug.
- Our bug bounty program is only valid for our systems, not for systems of our customers.
- a valid SPF record that permits soft-fail is correct usage of the SPF standard, and therefore not a bug or vulnerability, but simply policy
- disclosure of what version of what software is running is almost always default behavior, and although it might make it easier to use a automatic attack script, the disclosure itself is not a bug
- content-injection is not a real issue unless XSS and/or HTML injection is possible
- it’s the responsibility of the browser to make sure it does ‘the right thing’, even if the behavior can be mitigated by adjusting the server or DNS.
- if you would have actually tested it, you would have known it’s not exploitable
- the lack of extra, optional hardening (or “opt-in security enhancement”) is not a bug or vulnerability
- yes, we could have set this DNS record, but why bother? It’s not going to improve security
- Disclosure of info that might be used for a optional attack is not a vulnerability in itself
- it’s not exploitable
- you’re wrong
We would also like to point out that:
- if this where a valid bug, then the internet or WWW as we know it wouldn’t exist / couldn’t function
- Google, Bing, Yahoo, Facebook, etc. are also vulnerable to this “bug”. Why don’t you try to convince them first?
- This is dumb behavior of the browser, please file a bug with the browser vendor
- the fact that somebody said somewhere in a wiki that this is a bug doesn’t make it a real, exploitable bug
- this only works if a MITM attack is possible, which is unlikely, since the entire connection is encrypted
- the fact that MS screwed up big time in not simply honoring the mime-type the server send back, and introduced X-Content-Type-Options to let the server say that the browser should behave as it should behave in the first place is not a server bug.
- the fact that the client software vendor won’t pay for this bug doesn’t mean we’re willing to pay for it
- if this was as serious as you say it is, the entire internet would be vulnerable
- the CERT’s didn’t think it was necessary to warn for this and the NSA/CIA/KGB/FSB/hackingteam/Fancy Bear/Ghostnet (etc,etc) are not using this. We wonder why
- the behavior you think is a bug is actually the default behavior of the software. If you think this is a bug, please contact the authors of the software.
- the authors of the software don’t think its a security bug because it can’t be exploited in any way, and we agree
- if literally every web-server in the world is vulnerable unless header X is set, then the default client-side settings are clearly wrong, and those defaults should be fixed
- this can only be exploited by an attacker on the same physical network by saturation the ethernet connection for about a year before the key is sufficiently reduced to make an attack feasible. We think that this attack is really clever, but not really exploitable in the real world
- the fact that somebody else paid money for reporting this through hackerone doesn’t make it a real, exploitable bug
- We don’t know if a customer has it’s own bug reporting policy or bug bounty program
- the author(s) of the RFC specifically addresses security concerns, and the consensus of the IETF is that the author(s) is/are correct.
- the issue was already known, and additional measures had been taken to mitigate the issue. You would have known that if you had tested the issue before reporting it
- the fact that you don’t like it or wouldn’t do it like this does not mean it’s a bug
- Having a catch-all vhost is in itself not a bug. If a application running under it would blindly trust it, then that would be a bug.
- it’s totally OK to use a automated tool to find vulnerabilities, but you have to make sure at a lower level that what it’s saying is actually correct. You can’t just say that it’s a problem, just because tool X says so
- the issue you’re describing is only a bug if technology X is used in way Y, which is clearly not the case here
- the simplest way to prove that something is a real bug is a proof-of concept attack on the system
- silly fallback behavior will always be silly fallback behavior, no matter what headers you set. How do you get a HSTS header? By connection over a HTTP connection? In that case a MITM can strip out the HSTS header. And how long is the HSTS header valid? In short: The HSTS header is only valid for a short time, and useless for new connections to web-servers. The real solution is to make https the default protocol, and only use https if explicitly requested (don’t fall back to http unless another secure mechanism says so (dnssec)). A protocol that is only useful when a MITM is not interfering is not really useful against MITM attacks. (it’s actually worse, since it gives a false sense of security).
- keeping on compensating for browser silly stuff is dangerous, since the default behavior of browsers is centrally set (by software vendors), but the ‘setting a header to do the right thing’ has to be done manually for every web-server, which is bound to be forgotten / missed, etc.
- the correct behavior should be default. Insecure behavior should be explicitly enabled through headers / dns records, not the other way around.
- The DNS record is actually here because this is a hard requirement of SIDN (Dutch domain TLD)
- this idea / concept has been thoroughly debunked here: ………..
Finally you might consider that:
- if it is a bug in software X, then why doesn’t it have a CVE?
- the software name and version reported by the daemon are not really what it is saying it is.
- the fact that it’s software version N, doesn’t mean that it’s not patched
- in ‘the real world’(TM) there are many reasons why people do (or don’t do) things, and it’s not always laziness or incompetence
- Silicon-Based Lifeforms are possible. Don’t be carbon-centric!
- we don’t care what other people say is correct behavior. We make up our own mind
- we are also Independent Web Security Researchers !!!
- black swans actually exist
- this : ………..