Only use session tokens for auth for GET requests
#1488
Conversation
Since we do not have any form of CSRF protection in place, we should not be allowing session tokens to be used for non-get requests. We don't currently have any CSRF vulnerabilities, as there are no `POST` requests in our router today. In the event that one does get added in the future, this will prevent a CSRF vulnerability from appearing, without us having to remember this detail in the future. It will also force us to properly add some form of protection if we want to accept a POST request sent by an HTML form in the future.
|
We've definitely had issues like this in the past, for instance 2a46845. I believe we have some front-end PUT routes that use the session cookie. For instance, |
|
The browser is only capable of sending |
|
Yes, but the current PR only sets the session for GET, and I think the PUT routes will fail without a session. The cargo routes (such as publish) will still get a user session from the "Authorization" header, but PUT routes used by the front-end, such as creating a new token, will not know which user to create a token for. |
|
Are there any non-get requests sent through the browser? |
|
Ah I guess token management is handled through the browser. I'll change this to exclude POST rather than include only GET |
Hi @sgrif, could you make this change please? |
|
Closing after discussion with @sgrif. |
Since we do not have any form of CSRF protection in place, we should not
be allowing session tokens to be used for non-get requests. We don't
currently have any CSRF vulnerabilities, as there are no
POSTrequestsin our router today.
In the event that one does get added in the future, this will prevent
a CSRF vulnerability from appearing, without us having to remember this
detail in the future. It will also force us to properly add some form of
protection if we want to accept a POST request sent by an HTML form in
the future.