Timeline for Why is the absence of a Content-Type header with a HTTP 204 response considered a security vulnerability and what should we do about it?
Current License: CC BY-SA 4.0
13 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Nov 30, 2023 at 14:13 | comment | added | Prem | I could not include some Points in my Previous Comment , @RememberMonica , hence I will conclude with this : I am not agreeing with that requirement or the threat. I am only giving reasons why it was made that way. Nobody will be held responsible when some requirement was followed & things go wrong. If that requirement was not followed & things go wrong , somebody will be held responsible. Once the rules are made , following such rules is safer way & compliant way , though not necessarily secure way. | |
| Nov 30, 2023 at 11:58 | comment | added | Prem | Last comment ( StackExchange warning about too many comments ) from me : Security folks take a call which Possibility is risky. When the call is made , it is hard to change , @RememberMonica , Eg1 : Though I can not execute SQL Queries , I could not message a Bank with the word UPDATE : The Bank will not change the Policy ! Eg2 : In Airlines , we can not take more than 100ml water. It is hard to imagine what threat there is with 200ml water ! Eg3 : Makes sense : Indian Airports do not allow scissors. Does not make sense : Singapore Airports allow scissors smaller than 6cm ,though it is risky ! | |
| Nov 30, 2023 at 11:13 | comment | added | Remember Monica | @Prem I agree that existence is not necessary, but possibility is certainly not enough. I can come up with "possible" fantasy bugs all day, practically forever. It is simply impossible to shield against all "possible" bugs in software that might ot even exist. There needs to be more than just a made-up fantasy possiblity, i.e. concrete evidence. | |
| Nov 24, 2023 at 19:54 | comment | added | phyrfox | If an intermediary does that, it should raise alarms. That's the point of the specifications that headers must not be added/removed/modified. No proxy should ever be setting a default Content-Type, as that indicates it is misconfigured or compromised. | |
| Nov 24, 2023 at 19:41 | comment | added | Prem | I know what you mean & I agree with that , I am only giving some justification for why that PCI DSS requirement is there & why the scanner is checking for that , @phyrfox , though I am not even claiming that the client will break : I only Point to the PCI DSS Document which says that Headers should not be added/removed/modified & I then Point to the Possibility that some Intermediary might set Default unwanted Headers which will unintentionally generate false failures. | |
| Nov 24, 2023 at 17:56 | comment | added | phyrfox | "There should be no unknowns and no defaults." 204 is well known to not have any content, and all programmers assume that there is no need to check a Content-Type header for content that doesn't exist. Even a broken proxy adding a default Content-Type would be harmless. If there were any possibility of that header not being present could break a client, that is a security vulnerability of the client, not the server or the network at large. | |
| Nov 24, 2023 at 11:49 | comment | added | Prem | In Security Environments , "Possibility" is enough & "Existence" is not necessary , @RememberMonica , & there are lots of Proxies [ & Web Pipelines ] where Headers get inserted. This is a Paranoid Safeguard ! [[ I am reminded of my Queries + Comments to my Bank getting deleted , because I used the word "UPDATE" & the Paranoid Bank Process deleted those Comments , imagining it to be SQL ! When I changed the wording to "I want to let you know" , the Comments went though ! ]] | |
| Nov 23, 2023 at 23:03 | comment | added | Remember Monica | I don't think this makes sense - this posits the existance of a specific type of broken proxy (are any known to exist?). The same way one could posit the existance of proxies that tamper with data when the content-type header exists on a 204 response. There is no way to predict how a hypothetical broken proxy will behave. This would only make sense if this was a known bug in proxies that are used in reality, and only if no other proxies exist that malfunction in other ways. | |
| Nov 23, 2023 at 15:53 | comment | added | LvB | hmm, this still wouldn't make the mising header a security issue... it would make it a compliancy issue (and using it is in general a goof idea anyway). Great find anyway, | |
| Nov 23, 2023 at 15:22 | history | edited | Prem | CC BY-SA 4.0 |
added 128 characters in body
|
| Nov 23, 2023 at 15:01 | comment | added | Dantre | Interesting find. It could explain where this is coming from in the first place. | |
| S Nov 23, 2023 at 12:30 | review | First answers | |||
| Nov 23, 2023 at 23:09 | |||||
| S Nov 23, 2023 at 12:30 | history | answered | Prem | CC BY-SA 4.0 |