Have you ever wondered what does the cookies created by Django do or how exactly do they work? Django uses cookies in very simple yet effective manner. This blog explains the purpose of the cookies set by Django with the help of Illustrations.
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 csrftoken.
The cookie is generated by Django’s CsrfViewMiddleware. The value of the csrftoken is 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 .
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 sessionid has a flag called “HTTPOnly”, if the browser sees this flag, they don’t allow JavaScript to access the cookie, helping prevent attacks from malicious scripts. Moreover “SameSite” flag ensures only your domain name has access to your secret sessionid cookie.
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!
![Paypal Payment with django rest framework [Best practices]](https://miro.medium.com/v2/resize:fit:1358/1*yuVzMhCJyDENbyhwAsrkwA.png)
