0x01 Preface
CSRF (Cross Site Request Forgery) cross site request forgery. The attacker embezzles your identity and sends malicious request to the third-party website in your name. The request is completely legal for the server, but it completes an operation that the attacker expects, such as sending email in your name, sending private mail, adding management users, and even transaction transfer.
This exploits a vulnerability of user authentication in the Web: simple authentication can only guarantee that the request is sent from a user's browser, but can't guarantee that the request itself is sent voluntarily by the user.
0x01 vulnerability case
Source code: doccms2016
Exploit:
1. Construct the CSRF exploit code, and only backup the administrator user table Doc "user:
CRSFTester
2. Submit the CSRF vulnerability utilization code in the online message on the homepage of the website:
3. When the administrator views the message information in the background, the database is automatically backed up to the directory / doccms / temp / data:
4. The database backup file is backed up in the / doccms / temp / data directory by default. The name of the backup file has rules. The naming format is: database name + underline + 8-bit backup date + underline + 6-bit random number + data table backup volume number. For example, doccms__.sql can obtain the SQL backup path by blasting 6-bit random number.
0x02 vulnerability prevention
1. Add token / referer verification
2. Add verification code
3. User secondary verification
0x03 bypass technique
CSRF can use the method of verifying the referer / token for defense, but if there is protection, it may be bypassed, and the verification method of the website server may still have vulnerabilities, so it needs to be tried constantly.
Conditionally, not all reference / token validation can be bypassed.
Referer around pose
1. Null referer bypass
The SRC code of iframe above is actually:
Automatically submit the form to the defective CGI.
2. Judge whether the referer is bypassed in a domain
For example, if the CSRF you are looking for is xxx.com, the referer you are looking for is *. Xx.com, you can find a secondary domain name and then send out the article address to forge.
3. Judge whether a keyword exists in the referer
Referer judges whether there is google.com
Create a new google.com directory on the website and store the CSRF in the google.com directory, which can be bypassed
4. Judge whether the referer has a domain name
Judge whether the referer starts with google.com and Google subdomain. If the root domain is not verified as 126.com, then I can construct the subdomain name x.google.com.xxx.com as the carrier server of worm propagation, which can be bypassed.
Token around pose
1. Invalid token validation
The server does not check the token, and directly removes the parameter token from the URL. In addition, some modules have token verification, while some modules do not have token. Look for those who do not have token verification.
2. Use XSS vulnerability to bypass CSRF defense
In the case of XSS, AJAX is used to obtain the token field in the DOM node across domains for construction.
3. Token is fixed
The token rule is too simple. For example, if one-way hash is obtained according to a user ID, it can be constructed directly.
4. Token leakage
The table data of token is leaked, or the algorithm is leaked, and the program logic is not rigorous.
Reference link: