search

ietf-wg-acme / acme

A protocol for automating certificate issuance
https://datatracker.ietf.org/doc/draft-ietf-acme-acme/
933 stars 190 forks source link

Make the HTTP Challenge require a response MIME type #470

Open annevk opened 5 years ago

annevk commented 5 years ago

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).

hannob commented 5 years ago

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/

felixfontein commented 5 years ago

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.

bifurcation commented 5 years ago

@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).

annevk commented 5 years ago

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.)

bifurcation commented 5 years ago

@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.

annevk commented 5 years ago

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.