Make the HTTP Challenge require a response MIME type
annevk opened this issue · 6 comments
Otherwise this can lead to an XSS endpoint on naïve server implementations. Validating the MIME type of the response seems like good practice and ensures the response cannot be used for other purposes.
https://www.youtube.com/watch?v=dBJt3eR8-bg outlines this at the beginning (should take a couple minutes max).
FYI this was my talk, but the ACME/XSS thing wasn't from me, I just mention it, original source is:
https://labs.detectify.com/2018/09/04/xss-using-quirky-implementations-of-acme-http-01/
What MIME type should be used? I guess not text/html :-)
I guess text/plain would be a simple solution, since every server should have support for that.
@annevk Would it be sufficient to require an existing media type here (probably text/plain)? Or would it be safer to define a new media type? If it's all the same from a security POV, I would probably go with the former, but the latter could be done (it's jut more work).
Per https://mimesniff.spec.whatwg.org/#interpreting-the-resource-metadata text/plain might be dangerous (end up getting sniffed in certain contexts), but application/octet-stream as the draft suggests in the example response would be fine.
(Semantically you'd expect this kind of thing to have its own MIME type, but I'll leave that for someone else to argue for.)
@annevk - In light of the late stage in the process, I've tried to address this in a minimally-invasive way. As I noted in that PR, there's still some risk that there's overlap between the ACME key authorization syntax and something else, but this seems much less risky than the status quo. If we want to make more major changes, it would be better just to start up a new HTTP challenge type.
That helps and it seems a test suite can test it which is good. (Any reason the "shoulds" are lowercase?)
I think it violates HTTP to not include a Content-Type though. HTTP has a SHOULD on senders which can only be ignored if they don't know what they're sending, which can't be argued here I think, even though there's no Content-Type value defined: https://tools.ietf.org/html/rfc7231#section-3.1.1.5. I don't know how big a deal that is. Perhaps it's not as nobody spotted it until now.