Api prevents access to GET requests without Content-Type

Environment: CTFD in docker using official container CTFd Version/Commit: ctfd/ctfd:latest Operating System: docker Web Browser and Version: N/A What happened? HTML response with login page

What did you expect to happen? JSON result for the api request (/api/v1/challenges in my case, but really any get)

How to reproduce your issue Try to get a json api on any ctfd instance using “Authorizaion: Token <token>” and without session cookies.

Today I tried to install a challenge using ctfcli and got greeted by an error message. I have it attached below, but it is not really relevant as the issue seems to be with ctfd and not the api. I tried the same request using a http client and got the login page instead even though the token clearly was valid in the right format. So I dug into the code and found this line, which only accepts tokens if the content-type is set to application/json, which for a GET request is not the case. I tried it and indeed adding the “Content-Type” header to my request made it work.

• If this is expected behaviour (which I highly doubt) then this is a documentation issue since it is not documented anywhere.
• If it is not a documentation issue (more likely since my rest tool even warned me that content-type is not supposed to be on a get request), then this is the relevant line for the check.

Note: This is hard to test in a browser since any successfully request sets the session cookie which takes precedence over the Auth header.

traceback.txt

[Thalhammer]

You are right I could not find a RFC that says “you can’t use content-type without a body”. That said, I have also never seen any api that requires having a content-type set without having a body. Usually it’s as follows:

• Set content-type if there is a body in the message (post,put,patch,…)
• Don’t care if there is none (get & usually delete)
• Set Accept to indicate the content type you want back

If ctfd chooses to always require a content-type (which it is obviously free to do, albeit unusual) it should be clearly documented in the api docs. Because right now there is no mention of this at all, unless you dig deep into the code and all indicators ctfd gives is that the token is invalid or the authorization header is wrong.

Accept is different from Content-type. Content-Type indicated the type of the current message (e.g. upload), Accept indicates what the client wishes to get back (download).

A detailed answer about the topic including links to RFC 7231: https://stackoverflow.com/a/35722727 The RFC nowhere says (or at least I could not find it) that content-type should not be on an empty request though.

[nikitastupin]

Hey 👋 Just made a PR to clarify this behaviour in the documentation.