CRSF verification in cookies - Added

[BnGx]

What does this PR do?

The changes I propose allow you to search cookies for the CSRF token associated with a request to the server.

Previous Behavior

The search for the CSRF token is performed exclusively in the Headers or form data associated with a client request. This behavior also occurs when the access, refresh and CSRF token are sent via cookies.

Since in the browser with javascript it is not possible to access the HttpOnly cookies to fetch the CSRF token to build the X-CSRF-TOKEN header, the verification of the CSRF by the server will always be nullified.

New Behavior

The search for the CSRF token occurs first in the headers, then in the cookies and finally in the form data of a request to the server.

[coveralls]

Coverage remained the same at 100.0% when pulling 890d2c8 on BnGx:master into 5bd8b1e on vimalloc:master.

[coveralls]

Coverage decreased (-0.1%) to 99.868% when pulling 3a513f0 on BnGx:master into 5bd8b1e on vimalloc:master.

[vimalloc]

This is fundamentally wrong. A CSRF attack works by having a malicious site make a request to a "victim" site. This is accomplished this by leveraging the fact that browsers will automatically send any relevant cookies when making the malicious request, specifically cookies that tell the victim site that the user is logged in and thus authorized to perform this malicious request.

The CSRF protection implemented in this application protects against this by using a double submit token, you can read all about it here: https://medium.com/cross-site-request-forgery-csrf/double-submit-cookie-pattern-65bb71d80d9f. The TL;DR for this approach is that the caller needs to manually include this double submit token when making the request. If it was sent in automatically as a cookie in each request there would not in fact be any CSRF protection happening.

Since in the browser with javascript it is not possible to access the HttpOnly cookies to fetch the CSRF token to build the X-CSRF-TOKEN header, the verification of the CSRF by the server will always be nullified.

This is not the case. The CSRF double submit values are by default stored in separate csrf_access_token and csrf_refresh_token cookies, which are not httponly, precisely so they can be read via javascript and included as a header in each request.