new·The score now tells you which way it movedA brain's exam only ever grows: its own material writes questions, and so does every question a real caller asked and did not get answered. The score is a percentage over that growing set, so a brain that learned more could post a smaller number — and this week three did. One of them answered two MORE questions than the week before and showed eighteen points less. Printed as a single percentage, that reads as decline to a reader and as punishment to anyone who contributes material.all news →
mozg.beta
Sign in

OWASP Cheat Sheets · all subjects

csrf/origin_verification

6 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.

Origin and Referer header verification for CSRF protection

Verify origin of requests in two steps: (1) Determine source origin (where request is coming from) via Origin or Referer headers; (2) Determine target origin (where request is going to). At server-side, verify if source and target origins match - accept as legitimate if they match, reject as cross-domain if they do not. These headers are forbidden headers and cannot be altered programmatically, only by browser.

Origin header verification priority

If Origin header is present, verify that its value matches the target origin. Unlike Referer, Origin header will be present in HTTP requests originating from HTTPS URLs, making it the primary source for origin verification.

Referer header verification when Origin is absent

If Origin header is not present, verify that the hostname in Referer header matches the target origin. Ensure target origin check is strong - for example, if site is example.org, verify that example.org.attacker.com does not pass the check by matching through trailing slash after the origin to ensure matching against entire origin.

Handling missing Origin and Referer headers

If neither Origin nor Referer headers are present, the server can either accept or block the request. Recommendation: block the request as a security-first approach. Alternatively, log all such instances to monitor use cases and behavior, then start blocking only after gaining confidence in the legitimate traffic patterns.

Target origin determination behind proxy

When application server sits behind one or more proxies, the original URL may differ from what the app server receives. Options to determine target origin: (1) Configure application to know its target origin via server configuration (most secure but requires maintenance across dev/test/QA/production deployments); (2) Use Host header, but proxy typically changes this to proxy's target origin; (3) Use X-Forwarded-Host header which contains the original Host header value received by the proxy - this is the original target origin needed for comparison.

Use cases where Origin/Referer headers absent

Origin/Referer headers may be absent in legitimate use cases: (1) Following a 302 redirect cross-origin (Origin not included to protect sensitive information); (2) Privacy contexts where Origin is set to 'null'; (3) Same-origin POST/DELETE/PUT requests (Origin included in most browsers) but not in same-origin GET requests; (4) Various cases where Referer is omitted due to privacy concerns, load balancers/proxies/embedded devices stripping it. Approximately 1-2% of legitimate traffic may lack these headers.

Give your agent this brain