1. Requesting Login Form:
When we request the login page, Django’s response includes the requested login form with a hidden input field
csrfmiddlewaretoken and a cookie called
The cookie is generated by Django’s
CsrfViewMiddleware. The value of the
scrambled(key="salt", data="salt+secret") where salt and secret are random value known only to the server. The value of
csrfmiddlewaretoken in the page is also generated in a similar way except with a different salt value. These values will soon come in handy.
2. Authenticating User:
Next, the user will fill the login form and submit the values and the following happens:
If the user enters incorrect credentials, they are given the the login page again, notice that the
csrftoken value has not changed.
When the user enters correct credentials, they receive a new value for
csrftoken . In fact, the
csrftoken is changed every time the user logins. They also receive a new cookie called
sessionid is a string generated to keep track of the user. Remember HTTP is a stateless protocol and there is no in-build technique for the server to know if a subsequent request was made by the same user. That’s where this cookie comes in the picture, it is send back to the server with every request. When the server finds the
sessionid cookie in the request, it identifies the user and responds according to the permissions of the user. This is the reason we only need to login once and we get to use all the pages in the website. In the
django_session table a new record is created which has rows that map
sessionid to session data — the session data is used by Django to get information like permissions of user to access the requested page.
This is great for user experience but if someone gets access to your
sessionid , as far as Django is concerned, it’s you who is making the request and it will happily allow all actions to the hacker that only you were suppose to do. For this reason
But what if the user is tricked into making an undesired action? Say, if a hacker shows a popup advertisement to fix the “virus” infecting my Linux system (Ahem!). A less technically inclined user may be tempted to click on the advertisement. Now all the hacker has to do is redirect the click to your website to make an action to modify data that user did not want to do, as far as the browser is concerned, the user clicked on the link and it should allow the access to the
sessionid cookie. This is called CSRF attack and to protect from this attack the
csrftoken cookie comes into the picture.
3. Securely Modifying data
When a user wants to perform any action like modifying data, say add a new record in database, the following happens:
Before performing any action, the server gets the
csrfmiddlewaretoken from the form data of the request and the
csrftoken cookie. Then it removes the salt from the both of them and compares the values, if the values match the action is allowed. To prevent the hacker from performing the CSRF attack, the value of
csrfmiddlewaretoken is changed on every request, this ensures that the hacker will never get hold of the correct value of
csrfmiddlewaretoken and hence the user is safe.
I hope you learned something new today. Good Luck with your research!