You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
* 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.
0 commit comments