Tags: gorilla/csrf
Tags
Merge commit from fork * csrf: use context to determine TLS state r.URL.Scheme is never populated for "server" requests, and so the referer check never runs. Instead we now ask the caller application to signal this explicitly via request conext, and then enforce the check accordingly. Separately, browsers do not always send the full URL as a Referer, especially in the same-origin context meaning we cannot compare its host against our trusted origin list. If the referer does not contain a host we populate r.URL.Host with r.Host which is expected to be sent by all clients as the first header of their request. Add tests against the Origin header before attempting to enforce same-origin restrictions using the Referer header. Matching the Django CSRF behavior: if the Origin is present in either the cleartext or TLS case we will evaluate it. IFF we are in TLS and we have no Origin we will evaluate the Referer against the allowlist. In doing so we take care to permit "path only" Referers that are sent in same-origin context. * add csrf.TLSRequest helper API to set request TLS context Add a csrf.TLSRequest public API method that sets the appropriate TLS context key and signals to the midldeware the need to run the additiontal Referer checks. * Enable Referer-based origin checks by default Reverse the default position and presume that that the server is using TLS either directly or via an upstream proxy and require the user to explicitly disable referer-based checks. This safe default means that users that upgrade the library without making any other code changes will benefit from the Referer checks that they thought were active already. Without this change we risk that some codebases will mistakenly remain vulnerable even while using a patched version of the library.
Updating gorilla/securecookie to v1.1.2 (#170) <!-- For Work In Progress Pull Requests, please use the Draft PR feature, see https://github.blog/2019-02-14-introducing-draft-pull-requests/ for further details. For a timely review/response, please avoid force-pushing additional commits if your PR already received reviews or comments. Before submitting a Pull Request, please ensure that you have: - 📖 Read the Contributing guide: https://github.com/gorilla/.github/blob/main/CONTRIBUTING.md - 📖 Read the Code of Conduct: https://github.com/gorilla/.github/blob/main/CODE_OF_CONDUCT.md - Provide tests for your changes. - Use descriptive commit messages. - Comment your code where appropriate. - Squash your commits - Update any related documentation. - Add gorilla/pull-request-reviewers as a Reviewer --> ## What type of PR is this? (check all applicable) - [ ] Refactor - [ ] Feature - [ ] Bug Fix - [ ] Optimization - [ ] Documentation Update - [ ] Go Version Update - [x] Dependency Update ## Description ## Related Tickets & Documents <!-- For pull requests that relate or close an issue, please include them below. We like to follow [Github's guidance on linking issues to pull requests](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue). For example having the text: "closes #1234" would connect the current pull request to issue 1234. And when we merge the pull request, Github will automatically close the issue. --> - Related Issue # - Closes # ## Added/updated tests? - [x] Yes - [ ] No, and this is why: _please replace this line with details on why tests have not been included_ - [ ] I need help with writing tests ## Run verifications and test - [x] `make verify` is passing - [x] `make test` is passing
bugfix: Not providing any token in requests results in wrong error me… …ssage (#149) * Fix wrong error being reported when token missing in request * Remove a condition that never becomes true * Add myself to the list of AUTHORS assuming this is good style * Fix minor style issue
PreviousNext