Csrf,cross site Request forgery, that is, cross-site requests for forgery.
This attack means that after the user logs on to the system, the attacker induces the user to access some illegal links to perform some illegal operations. For example, if you delete a user action (such as, yourdomain.com/deluser?id=123) has not been handled by CSRF, then, assuming that the user logged on to the system, An attacker who lures a user to access a link to the attacker's site at the same time (the link is just yourdomain.com/deluser?id=123), the system loses a user without the user's knowledge.
In this example, the link in the Cross station request is performed properly, first because the browser in the request normally sends the YourDomain authentication information (usually stored in a cookie) and the server does not know whether the request is user or malicious. Second, the parameters in the request can be guessed. These two conditions constitute all the conditions of the CSRF attack.
It is also necessary to emphasize that if the authentication is based on cookies, there is actually a third condition: if the cookie is a local cookie, the browser also needs to allow a cross-domain local cookie to be sent, that is, if the request originated from a Third-party Web site, the requested domain cookie should be taken. IE by default is not allowed to send a local cookie across domains (the session cookie does not have this limit), and Firefoxe is allowed by default.
1: Adopt the form of token.
The use of token refers to the request with the parameters of the change can not be guessed. That is, each request that needs to be protected takes an extra parameter, which can be sessionid (it must be an extra parameter, but its value can be SessionID), or it can be another value that cannot be guessed. The server then verifies that the value matches after the request is received.
May someone further propose, is not sessionid also can obtain illegally, or that the user's SessionID is not authorized to be operated? The answer is yes, but that's another way to attack (involving session hijacking and permission spoofing), where the only defense is CSRF attacks.
But for the sake of insurance, we can use Sessionid+salt, and then hash the way to generate this token.
In the form of token, we also need to consider the token, that is, the client with this parameter preservation problem. From the nature of the CSRF, token preservation cannot be stored in a cookie first, because the cookie itself can be brought on when the request is sent.
Second, token can be saved on the server side, for example, we can set a unique ID for the current request and then save it in session. The answer, of course, is no, and we can assume that the completion of a request consists of two parts: the URL (or program) that initiates the request, the URL (or program) that handles the request, and, admittedly, the way we defend against the CSRF attack, which individually requests the "process request URL". However, since the attacker gets the page that handles the request, he can still complete an attack when he forges the CSRF with a page that sends the request.
Therefore, the token save can only be saved in the page sent to the client, and then the client in the next request to send, take this parameter on it. Of course, if the page itself has been compromised by XSS, the attacker can still forge a legitimate request, but this is no longer a precaution against CSRF, but a precaution against XSS.
2: Each need to be protected when the request is sent, users are required to enter the password;
3: Every time a request to be protected is sent, referrer is taken. But this is not the best strategy to deal with, because referrer can be easily forged.
The following specific measures are in the form of token.
n Traverse all the places where the receptionist sends the request
1: File Find all the front desk "Svc", "Ajax", ". aspx", ". html", ". htm"
2: File Find all the "form" at the front desk
Based on the above search, summary to the following table:
|
Serial number
|
File
|
Line of code
|
Get/post
|
Process Completion No
|
|
|
|
|
|
|
Filter out requests that require CSRF processing. The request is then processed as follows:
If the request is sent by a GET method, the parameter Token=[value] is added to the request, where [value] is the SessionID value;
In the case of a post-send request, the form is added with the hidden input, whose name is token and its value is SessionID.
n Traverse all Request processing places
1: Traverse All SVC, add token parameter for Svc method
2: Traversal of all ASPX pages code-behind
3: Traverse all other backend methods, if present, such as the Controller method (not present in El).
Based on the above search, summary to the following table
|
Serial number
|
File
|
Line of code
|
Process Completion No
|
|
|
|
|
|
n Processing Request Processing office
Processing the token in the parameter, detecting whether the token exists in the current SessionID, if it exists, releasing it, otherwise it is abnormal;
All of the above logic is expressed in code, roughly as follows
| The code is as follows |
Copy Code |
| protected void Page_Load (object sender, EventArgs e)
{
String token = Createtoken ();
Puttokentoclient (token);
Savetokeninserver (token);
} protected void Buttondosomething_click (object sender, EventArgs e)
{
String token = Gettokenfromrequest ();
Where CSRF protection is needed, check is released.
if (Tokenisok (token))
{
Todo:go
}
Else
{
Todo:block
}
} private String Gettokenfromrequest ()
{
Todo gets coken from the request, typically a URL querystring or form element
throw new NotImplementedException ();
} private void Puttokentoclient (String token)
{
Todo saves it to the foreground, such as the URL requested, or the hidden input
} private void Savetokeninserver (String token)
{
Generally saved in session
session["Crsftoken"] = token;
} private bool Tokenisok (string token)
{
String tokeninserver = session["Crsftoken"]. ToString ();
return Tokeninserver = = token? True:false;
} public string _salt = "asdfkl@,.; #sss13131313 "; public string Createtoken ()
{
Return MD5 (Session.SessionID + _salt);
} private void Cleartoken ()
{
session["Crsftoken"] = string. Empty;
} private String MD5 (String p)
{
throw new NotImplementedException ();
} |
