Analysis of CSRF Vulnerabilities in PHP Code Audit

1 Overview

What kind of attack process is CSRF? To give a simple example, for example, a direct request http://x.com/del.php?id=1can delete the account with ID 1, but only the administrator has this permission to delete, and if someone joins in another website page and <img src=”http://x.com/del.php?id=1”>then sends this page to the administrator, as long as the administrator opens At the same time, the browser will also use the currently logged-in administrator authority to send http://x.com/del.php?id=1this request, thus hijacking the account to do something that the attacker does not have authority to do.


2. Mining method

Black box mining method:

CSRF is mainly used for unauthorized operations, and all vulnerabilities are naturally in places with authority control, such as the management background, member center, forum posts, and transaction management. In these scenarios, the management background is the most dangerous place, and CSRF It has rarely been noticed, so there are still many programs that have this problem. When mining CSRF, we can first set up a good environment, open several pages with non-static operations, capture packets to see if there is a token, and if there is no token, then directly request this page without a referer. If the returned data is still the same, it means that there is a CSRF vulnerability.

White box audit method:

From the perspective of white box, just read the code to see if there are verification tokenand refererrelated codes in several core files. The core files here refer to the basic files that are referenced by a large number of files, or directly search for the tokenkey of " " Words can also be found, if there is no core file, then go to see if the code of the function point you are more concerned about has been verified


3. Vulnerability prevention

Token Verification

Token is translated into Chinese as "sign", and it is called token in the field of computer authentication. The method of verifying Token is currently the most used one, and it is also the one with the best effect. It can be simply understood as adding an unpredictable string in the page or cookie, and the server only needs to verify this when receiving the operation request. Whether the string is left from the last visit can determine whether it is a credible request, because if you do not visit the previous page, you cannot get this Token, unless you combine XSS vulnerabilities or have other means to obtain communication data.

Token implementation test code is as follows:

?php
session_start();
function set_token() {
    
    
$_SESSION['token'] = md5(time()+rand(1,1000));
}
function check_token() {
    
    
    if(isset($_POST['token'])&&$_POST['token'] === $_SESSION['token']) {
    
    
        return true;
    }
    else {
    
    
        return false;
    }
}
if(isset($_SESSION['token'])&&check_token()) {
    
    
    echo "success";
}
else {
    
    
  echo "failed";
}
set_token();
?
<form method="post"
    <input type="hidden" name="token" value="<?=$_SESSION['token']?>"
    <input type="submit"//form>

As a result of the operation, if the Token value in the request is consistent with that on the server side, it will output "success", otherwise it will output "failed"

Verification code verification

Verification code verification is not as practical as Token. Considering the user experience, it is impossible for users to enter the verification code once on every page

Guess you like

Origin blog.csdn.net/Gherbirthday0916/article/details/130184696