Anti-CSRF tokens are much more reliable than relying on the Referer header or simple POST request checks to prevent Cross-Site Request Forgery (CSRF) attacks. This guide explains why and how to implement token-based protection.<\/p>\n
CSRF lets an attacker trick a logged-in user into performing unwanted actions on a web application they\u2019re currently using. Imagine you\u2019re logged into your bank, and an attacker sends you a malicious link or gets you to visit a compromised website. That site could then make requests *as if* it were you, potentially transferring money without your knowledge.<\/p>\n
The Referer header tells the server where the request came from. It seems like a good idea to only accept POST requests that originate from your own site. However, this is easily bypassed:<\/p>\n
Browser Settings: Users can disable sending the Referer header.
\nProxy Servers: Proxies can modify or remove the Referer header.
\nJavaScript: JavaScript can initiate requests without a Referer header, or spoof it.<\/p>\n
Therefore, relying solely on Referer checks is insecure.<\/p>\n
Checking if a POST request was made *at all* doesn\u2019t prevent CSRF. An attacker can still send a valid POST request; they just need to get the user to trigger it. This isn\u2019t protection, it\u2019s simply knowing a request happened.<\/p>\n
Anti-CSRF tokens add a secret, unique value to each form submission that the server validates. Here\u2019s how:<\/p>\n
When a user loads a page with a form (e.g., changing their password), generate a random, cryptographically secure token on the *server-side*. Don\u2019t use predictable values!<\/p>\n
# Example Python using secrets module
\nimport secrets
\ntoken = secrets.token_hex(16)<\/p>\n
Embed this token as a hidden field within your form.<\/p>\n
<form action=”\/change-password” method=”post”>
\n <input type=”hidden” name=”csrf_token” value=”{{ csrf_token }}”>
\n … other form fields …
\n<\/form><\/p>\n
Store the token associated with the user\u2019s session on the server. Common methods include:<\/p>\n
Session Variables: The simplest approach, but can be limited by session storage mechanisms.
\nDatabase: More robust for larger applications and scalability.<\/p>\n
When the form is submitted:<\/p>\n
Retrieve the token from the form submission.
\nRetrieve the stored token for that user\u2019s session.
\nCompare the tokens. If they match, the request is likely legitimate. If not, reject it.<\/p>\n
# Example Python (simplified)
\nif request.method == ‘POST’:
\n submitted_token = request.form[‘csrf_token’]
\n stored_token = session.get(‘csrf_token’)
\n if submitted_token == stored_token:
\n # Process the form data
\n …
\n else:
\n # Reject the request – CSRF detected!
\n abort(403)<\/p>\n
For extra security, regenerate the token after each successful submission or periodically (e.g., every hour). This limits the window of opportunity for an attacker if a token is compromised.<\/p>\n
HTTPS: Always use HTTPS to protect tokens in transit.
\nToken Length: Use sufficiently long and random tokens (at least 32 characters).
\nFramework Support: Most web frameworks (Django, Flask, Ruby on Rails, Laravel, etc.) provide built-in CSRF protection mechanisms \u2013 use them! They handle token generation, storage, and validation for you.<\/p>\n
The post CSRF Protection: Tokens vs Referer Checks<\/a> appeared first on Blog | G5 Cyber Security<\/a>.<\/p>","protected":false},"excerpt":{"rendered":" TL;DR Anti-CSRF tokens are much more reliable than relying on the Referer header or simple POST request checks to prevent Cross-Site Request Forgery (CSRF) attacks. This guide explains why and how to implement token-based protection. Understanding CSRF CSRF lets an attacker trick a logged-in user into performing unwanted actions on a web application they\u2019re currently […]<\/p>\n","protected":false},"author":0,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[2],"tags":[],"class_list":["post-6003","post","type-post","status-publish","format-standard","hentry","category-news"],"_links":{"self":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/posts\/6003"}],"collection":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"replies":[{"embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=6003"}],"version-history":[{"count":0,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/posts\/6003\/revisions"}],"wp:attachment":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=6003"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=6003"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=6003"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}