01 Vulnerability Description
HTTP is stateless, leading Web application must use the session mechanism to identify users. Once the connection (access log) to the Web site, the user will normally be assigned to a Cookie, subsequent requests, will bring the cookies, so it is easy to distinguish the Web site from which users request, which the user data is modified. If you initiate a request for the current site from a third party, the request will bring the Cookie current site. This is exactly what this defect led to the creation of the CSRF, take advantage of this vulnerability could hijack the user performs the operation of non-intention.
02 vulnerability detection
CSRF use scenario is often the case where the user is logged in, the user wishes to initiate forged requests from outside the station. More in-depth analysis of: initiating a request from the external station (cross-site), and the requested parameter values can fake (fake request), and therefore, these two points are detected CSRF start.
To transfer, for example, enter the account and the amount, click Transfer to complete the transfer. We examined whether the feature exists CSRF.
Can Cross Station
To detect whether cross station, only you need to operate referer header field to the request. referer field records origin of the request, if the request is not referer header field, or deleted referer request header field are successful response, the server does not verify the source of the request, there is "cross-site."
First submit a normal request packet, it found that the transfer was successful.
We can see that there is a Referer request header fields, the values indicate which page we are requesting from over. Referer field we try to delete and re-submitted to view the account balance has not changed.
Found that the account balance becomes 980 from 990, indicating that the server does not verify the source of the request can be "cross-site."
Can Request Forgery
Request Forgery premise is that we know how to forge the request parameters and values, that we know what the parameters included in the request, or know the exact value of the parameter range. Therefore, the detection whether the request can be forged only need to see if we can not fake the parameters and values to the request.
You can see, there are four parameters in the request, account represents the account number, amount represents the amount of the transfer, the two forged a good, action to represent an action, without falsification, can be used directly. token is what? (Token Token find out)
Token parameter values so long, to see that bad forgery. Delete token that try, and in case referer field, the server does not verify it on the token.
Repeatedly replayed the request several times and found that the account balance remains unchanged, it is clear that, token parameter must have. Then we just change it's value token, see the request as long as there is not a token parameters on the line, but the server does not verify the value of the token.
Repeatedly replay a few times and found that the account balance remains unchanged, indicating that the server did a check of the Token, the request can not be missing token or token error.
Was about to give up when bored re-lay the original request packet, suddenly found that the account balance into a 900.
WTF, the same value as if a token can be used repeatedly, can by check, is this token is permanent? Later I discovered that they do not re-Log, token remains in effect, to understand, is called "Korean semi-permanent."
CSRF verification
Both "cross-site", but also forged the request, verify that CSRF is very simple. Re-capture, generation of POC use CSRF capture tool.
Which copy the HTML code, create a local HTML page, copy the code to save it, and then open in the same browser (do not understand, please go to learn gun Cookie aspects).
Click the button CSRF page, find the page will jump to transfers and account balances only 400, less than 500.
CSRF detection of this successful conclusion. Regarding the use of CSRF simply say a few words, you can construct a link (GET), hidden form (POST), pictures, etc., and then find ways to let users click or visit it.
03 bug fixes
Request to verify the origin; HTTP referer request header has a field that records the source current HTTP request. By checking whether a request from a station outside to outside the station initiated CSRF defense, but does not protect against CSRF initiated from the station, and there is the risk of bypass.
Token validation; adding an attacker can not predict the token Token in the request, when the deletion request Token Token value or not, the request is denied. Use disposable Token, and remember to update, or may or bypassed. (In this case, the work has met numerous times)
CAPTCHA use, but it may affect the user experience.
04 PS
I cite here an example of both a referer also contains token, in order to give you a better understanding of CSRF detection, layout may be different from the actual situation. Practical work, my personal habits to replay several times to see whether the token can be reused, if reusable, natural token value without modification or deletion, need only to detect whether "cross-site" can; if you can not re-use, Description will check token value, then there is no need to modify token value, simply delete token to try, and finally test whether "cross-site." And in actual utilization, token values get not so simple. Just in the testing process, we found to be defective token mechanism, then we should take preventive measures to reduce the risk to zero. Here is a brief explanation about the content of the article and the actual work phase and out points.
Author: Security white group
link: https: //www.jianshu.com/p/2524ab092914
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.