Prevent HTML reflection vulnerability in 500 error status handler - #142
Conversation
Certain IO errors containing the requested filename could be directly echoed back to the user without a Content-Type header. In some cases, browser sniffing could result in this document being treated as HTML, allowing XSS. This is resolved by sending the Content-Type header of text/plain. Includes a test case that can reproduce this behaviour on at least some Linux systems.
|
Just because I didn't merge this, doesn't mean I'm disinterested. I just hadn't gotten around to it. |
|
Oops! I'm very sorry. I didn't intend to close this, or realize that I had. I was trying out a new Git client, and must have done something silly. |
|
All good! I'll try to merge this tonight. |
|
So I think this is a sane PR and I want to merge it, but I'm really trying to get my browser to throw up an alert and it's just not havin' it. Any hints? I'd love to be able to before/after this before clicking the magic green button. |
|
I've just emailed you an example that should work. I didn't include one here because, though it probably won't make much of a difference, I didn't want to make things easier for anybody who might try to exploit this. |
|
Beautiful. <3 |
2 participants
Certain IO errors containing the requested path can be echoed directly back to the user without a Content-Type header. In some cases, browsers' sniffing can result in the document being treated as HTML, allowing XSS. This is resolved by sending a Content-Type header of text/plain.
Includes a test case that can reproduce this behaviour, at least on some Linux systems. (The test should simply pass on other systems.) You can observe this test failing as expected after an intentional regression in this Travis build.