CSRF / XSRF CSRF
CSRF (Cross Site Request Forgery, cross-site request forgery domain), also known as XSRF, is a network attack, it was listed as one of the big security risk Internet 20 in 2007. Other security risks, such as SQL script injection, cross-site scripting attacks and other people familiar with the domain in recent years has been gradually, many sites are also a defense against them. However, for most people, CSRF is still an alien concept. Even the famous Gmail, at the end of 2007 there are CSRF vulnerability, so the user Gmail being hacked caused huge losses.
Origin policy to bring security risks
Review the contents of the last chapter we have mentioned, within the constraints of the browser's same-origin policy, when processing resources for cross-domain interactions [generally allow cross-domain resource embedding (Cross-origin embedding)].
The following are common examples of cross-domain resource embedded:
<script src="..."></script>Tags embedded in cross-domain scripting. Syntax error information can only be captured in homologous script.<img>Embedded picture. Supported image formats include PNG, JPEG, GIF, BMP, SVG, ...<video>And<audio>embedded multimedia resources.
Principle CSRF attack is to use the browser's same-origin policy due to the above embedding behavior is not limited in resources of conduct cross-site request forgery.
CSRF Attacks
- Users browse the site located on the target server A's. And verified by logging.
- Get to cookie_session_id, saved to a browser cookie.
- In the not out server A, and failure session_id before users browse the site located on the hacked server B.
- server B site
<img src = "http://www.altoromutual.com/bank/transfer.aspx?creditAccount=1001160141&transferAmount=1000">embedded resources played a role, forcing users to access a target server A - Since the user is not logged out and the server A sessionId not expired, the request is verified, the request is executed illegally.
How to defend against CSRF
- referer verification solutions.
The easiest way to rely on the browser page references head. Most browsers will tell the Web server, which sends the page request. Such as:
POST /bank/transfer.aspx HTTP/1.1 Referer: http://evilsite.com/myevilblog User-Agent: Mozilla/4.... Host: www.altoromutual.com Content-Length: 42 Cookie: SessionId=x3q2v0qpjc0n1c55mf35fxid; Many sites to prevent the site Daolian picture referer resources through verification.
However, because of the possibility of tampering http header may be present on some versions of the browser, so this solution is not perfect.
- Token Solutions
token solutions add a parameter to a form, or a form so that after the time-out period expires when the user logs off
<form id="transferForm" action="https://www.altoromutual.com/bank/transfer.aspx" method="post"> Enter the credit account: <input type="text" name="creditAccount" value=""> Enter the transfer amount: <input type="text" name="transferAmount" value=""> <input type="hidden" name="xsrftoken" value="JKBS38633jjhg0987PPll"> <input type="submit" value="Submit"> </form> The server or dynamically generated Token added to the custom request header parameter in the http
POST /bank/transfer.aspx HTTP/1.1 Referer: https://www.altoromutual.com/bank xsrftoken: JKBS38633jjhg0987PPll User-Agent: Mozilla/4.... Host: www.altoromutual.com Content-Length: 42 Cookie: SessionId=x3q2v0qpjc0n1c55mf35fxid; creditAccount=1001160141&transferAmount=10 Issue token solution is a huge change before and after the end of the code. And every step of dynamically generated token and token for authentication, it can also cause additional resource overhead. You can try to place critical operations plus token validation logic. However, changes in the front and rear side code verification token brought brought consumption, it will need to be carefully considered.
- userId solution
with respect to such a need before and after the change token-side logic, and cause there is a small additional precautions other than resource overhead way. When the user each time the key is the data request, the back-end interface design requires users to submit relevant userId. userId localStorage can be stored in the browser, so that the interface will be able to further enhance security against cross-site request forgery.
to sum up
Remember CSRF is not the only hacker attacks, no matter how closely you guard against CSRF there, if you have other system security vulnerabilities, such as cross-site scripting attacks domain XSS, the hacker can bypass your security, including expansion in CSRF a variety of attacks within your line of defense will be a rubber stamp.
CSRF is a very big hazard to attack, and very difficult to prevent. Several current defense strategy Although largely against CSRF attacks, but not the perfect solution. Some new programs are being investigated, such as for each request using a different dynamic password, the program combines Referer and token, or even attempt to modify the HTTP specification, but these new programs is not yet mature, and to be officially put into use widely accepted industry needs time. Prior to this, we only pay full attention to CSRF, select the most appropriate strategy based on the actual situation of the system, so as to minimize the harm to CSRF.