Cross-site request forgery referred to as "CSRF"
In CSRF attack scenario an attacker can fake a request (this request is usually a link), and fool the target user to click, once the user clicks on this request, the entire attack is finished, so CSRF attacks are also known as " one click "attack.
CSRF attack to be successful requires specific conditions:
1. Log in our website is not for us critical information (such as passwords and other sensitive information) CSRF protection, when we submit the information to modify (additions and deletions) request, the request susceptible to forgery
2. When the user clicks on the link and must forge the landing site
The difference CSRF and XSS: CSRF is completed by the user's privileges attack, the attacker did not get the user's permission, and steal XSS directly to the user's permission, and then implement damage.
Let me show you in pikachu platform specific CSRF Vulnerability
CSRF（get）：
First we enter the login user name password has been registered, such as kobe, 123456
Kobe change information, and packet capture
We found it to be submitted through the request and did not get the anti-CSRF token
So we can get this link to get his request, and then modify the information submitted by him, such as the phone number 6666666 change, and then get after the change request to kobe in any way.
http：//192.168.131.246 /pikachu-master/vul/csrf/csrfget/csrf_get_edit.php?sex=%E7%94%B7&phonenum=6666666&add=111&email=111&submit=submit
Kobe assume in his browser to access this URL, his cell phone number will be changed.
CRSF (post):
Or login kobe account, modify their information and get caught, you can see the request is submitted by post way, so there is no way to fake requests by URL
We can do a site, and then do a form on the site, let kobe to click on a malicious URL our site form. Submit a request to the post page CSRF vulnerabilities exist by this malicious form, similar to the post-type XSS vulnerability
CRSF Token:
We can go Token prevent CSRF vulnerabilities, each request, gave him the background to add a random code to allow verification to ensure that the request can not be forged
We can look at the Token pikachu platform use
Login pikachu's CSRF Token page kobe account, modify its information, and packet capture
We found an increase Token on the basis of requests submitted get on, when we refresh the page Token value change will happen, so it completely prevents the generation of GRSF vulnerabilities.
CRSF vulnerability Common precautions:
Increasing the token verification (a common practice):
1, an increase of key operating parameters token, token value must be random, each is different;
on secure session management (session to avoid being used, close the login state)
1, not the customer end save sensitive information (such as authentication information);
2, test directly off, when you exit the session expires mechanism;
3, set the session expired mechanisms, such as no operation within 15 minutes, the automatic login timeout;
access control security management:
1 the need to modify sensitive information when the identity of the second certification, such as when modifying an account, you need to determine your old password;
2, modify sensitive information using the post as much as possible, rather than get; (security post than get higher)
3, to restrict the original page at http referer header
is generally used in the login (anti brute force), it can also be used in the form of other important information on the operation of the (need to consider the availability)