PowerPoint Presentation
Outline
CSRF secret token simple example
Demo – 1 CSRF on Get request Add friend
Demo –2 CSRF on Post request Profile edit
Countermeasures
Secret token easy example
//csrf token validation
//generate token
“
Countermeasures: Secret Token
The server embeds a random secret value inside each web page.
When a request is initiated from this page, the secret value is included with the request.
The server checks this value to see whether a request is cross-site or not.
Pages from a different origin will not be able to access the secret value. This is guaranteed by browsers (the same origin policy)
The secret is randomly generated and is different for different users. So, there is no way for attackers to guess or find out this secret.
Further resource:
https://www.netsparker.com/blog/web-security/protecting-website-using-anti-csrf-token/
https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html
Same origin policy: https://en.wikipedia.org/wiki/Same-origin_policy
Elgg’s Countermeasure
Uses secret-token approach : _elgg_tc and _elgg_token.
The values are stored inside two JavaScript variables and also in all the forms where user action is required.
The two hidden parameters are added to the form so that when the form is submitted via an HTTP request, these two values are included in the request.
These two hidden values are generated by the server and added as a hidden field in each page.
Elgg’s Countermeasure
JavaScript variables to access using JavaScript code.
Elgg’s security token is a MD5 digest of four pieces of information :
Site secret value
Timestamp
User session ID
Randomly generated session string
Fundamental Causes of CSRF
The server cannot distinguish whether a request is cross-site or same-site
Same-site request: coming from the server’s own page. Trusted.
Cross-site request: coming from other site’s pages. Not Trusted.
We cannot treat these two types of requests the same.
Does the browser know the difference?
Of course. The browser knows from which page a request is generated.
Can browser help?
How to help server?
Referer header (browser’s help)
Same-site cookie (browser’s help)
Secret token (the server helps itself to defend against CSRF)
Countermeasures: Referer Header
HTTP header field identifying the address of the web page from where the request is generated.
A server can check whether the request is originated from its own pages or not.
This field reveals part of browsing history causing privacy concern and hence, this field is mostly removed from the header.
The server cannot use this unreliable source.
Countermeasures: Same-Site Cookies
A special type of cookie in browsers like Chrome and Opera, which provide a special attribute to cookies called SameSite.
This attribute is set by the servers and it tells the browsers whether a cookie should be attached to a cross-site request or not.
Cookies with this attribute are always sent along with same-site requests, but whether they are sent along with cross-site depends on the value of this attribute.
Values: Strict (Not sent along with cross-site requests) and Lax (Sent with cross-site requests)
Further resource: https://php.watch/articles/PHP-Samesite-cookies
https://www.netsparker.com/blog/web-security/same-site-cookie-attribute-prevent-cross-site-request-forgery/
/docProps/thumbnail.jpeg