I did many years maintained garden blog, notes when there is a beginner Django, record notes about the use django-csrftoekn, was almost a copy using the example of the official website, and later work with all the flask. Blog parks are also no maintenance. Until my blog received the following comments, really had me stumped, and I have carefully studied this issue.
1. Django is how to verify the legitimacy of csrfmiddlewaretoken?
2. Each time the page is refreshed <input> in csrf the value will be updated every time a cookie is repeated login csrf tokens are refreshed, then the two csrf-token What is the difference?
CSRF (Cross Site Request Forgery protection) , Chinese referred to as cross-site request forgery.
When django first response to a request from a client, it will randomly generate a token on the server side, we put the token in a cookie. POST requests are then each time will bring the token,
so as to avoid being CSRF attacks.
Like this it did not seem wrong, but the third question in the comments, each time you refresh the page, form the form will refresh the token, and the token cookie but only refresh every time you log on. I got a question about csrftoken authentication methods, but after I read some official interpretation of the document.
When validating the ‘csrfmiddlewaretoken’ field value, only the secret, not the full token, is compared with the secret in the cookie value. This allows the use of ever-changing tokens. While each request may use its own token, the secret remains common to all.
This check is done by CsrfViewMiddleware.
When it comes to official documents, when the test token, if the comparison only secret and secret, like the value of the cookie, instead of comparing the entire token.
I have a question, with single sign-on, form the form of token every time change, and the cookie token inconvenience, django where in order to ensure that the salt storage verified by it. Until you see the source code.
def _compare_salted_tokens(request_csrf_token, csrf_token):
# Assume both arguments are sanitized -- that is, strings of # length CSRF_TOKEN_LENGTH, all CSRF_ALLOWED_CHARS. return constant_time_compare( _unsalt_cipher_token(request_csrf_token), _unsalt_cipher_token(csrf_token), ) def _unsalt_cipher_token(token): """ Given a token (assumed to be a string of CSRF_ALLOWED_CHARS, of length CSRF_TOKEN_LENGTH, and that its first half is a salt), use it to decrypt the second half to produce the original secret. """ salt = token[:CSRF_SECRET_LENGTH] token = token[CSRF_SECRET_LENGTH:] chars = CSRF_ALLOWED_CHARS pairs = zip((chars.index(x) for x in token), (chars.index(x) for x in salt)) secret = ''.join(chars[x - y] for x, y in pairs) # Note negative values are ok return secret The first 32 bits is the salt token string, followed by a token encrypted, it can be decrypted by unique salt secret.
django will verify that the form of the token and the cookie can be solved the same token secret, secret, like this request is legitimate.
Is also not difficult to explain why when ajax request, you need to pick up token added to the request header from the cookie.
There are many online about django csrf token verification principle of the article is wrong, because they do not know csrf-token structure and composition, I was stuck in the third review that. Then read the official document, middleware and CsrfViewMiddleware Source before understood why.
Author: Zou mold mildew
link: https: //www.jianshu.com/p/7fbb60001018
Source: Jane book
Jane book copyright reserved by the authors, are reproduced in any form, please contact the author to obtain authorization and indicate the source.