Today, I will talk about the vulnerability CSRF.
Table of contents:
Cross-Site Request Forgery (CSRF) is an attack that forces an end user to execute unwanted actions on a web application in which they’re currently authenticated. CSRF attacks specifically target state-changing requests, not theft of data, since the attacker has no way to see the response to the forged request. With a little help of social engineering (such as sending a link via email or chat), an attacker may trick the users of a web application into executing actions of the attacker’s choosing. If the victim is a normal user, a successful CSRF attack can force the user to perform state changing requests like transferring funds, changing their email address, and so forth.
The page from the client side to change the user password:
If I launch the request that pass through a HTTP GET:
It renders this html source code:
The server source code:
It gives this algorithmic view:
Now I will forge a malicious link that change password when hit in the web browser:
Verify user request with technical and functional mechanism:
- Ask the user for the current password to validate any changes on the account
- Implement client/server token verification
The new server side secure code:
Algorithmic view of the secure code:
2 exit security conditions can be seen throught the “If not” arrow.
Flowgraph for a legitimate password change along with a session token verification mechanism:
If the victim hit again the malicious link sent by the attacker:
The attack does not work anymore ! Admin not tricks again if he executes a malicious link ! No token send to the server because he was not grab on index.php before.. So an error appears !
Server side :
- Implement the password verification to validate any strong changes on the account & add anti-CSRF token mechanism with a session cookie (user_token) [PHP code]
- Always use « disconnect » button when authenticated to delete the cookie associated to the session website. [web browser]