How to Manage Security Vulnerability (CSRF)

In computer security, a vulnerability is a weakness which allows an attacker to reduce a system’s information assurance. Vulnerability is the intersection of three elements: a system susceptibility or flaw, attacker access to the flaw, and attacker capability to exploit the flaw.  In this blog, I will focus only on Cross-Site Request Forgery (CSRF).

Cross-Site Request Forgery (CSRF):

(CSRF) is an attack outlined in which a malicious website will send a request to a user authenticated web application from a different website. In this manner an attacker can access functionality in a target web application via the victim’s already authenticated browser. Targets include web applications like social media, in-browser email clients, online banking and web interfaces for network devices.

How to prevent CSRF?

There are two ways to restrict CSRF attack

1. Generate token per request.
2. Generate token per user.

Generate a token per user

In general, developers need only generate this token once for the current session. After initial generation of this token, the value is stored in the session and is utilized for each subsequent request until the session expires. When a request is issued by the end-user, the server-side component must verify the existence and validity of the token in the request as compared to the token found in the session. If the token was not found within the request or the value provided does not match the value within the session, then the request should be aborted, token should be reset and the event logged as a potential CSRF attack in progress.

Example : Same code written as below just comment token generation in page_init page:

Session["AntiXsrfToken"] = Guid.NewGuid().ToString("N");

Generate a token per request (each page request):

To further enhance the security of this proposed design, consider randomizing the CSRF token parameter name and or value for each request. Implementing this approach results in the generation of per-request tokens as opposed to per-session tokens. Note, however, that this may result in usability concerns. For example, the “Back” button browser capability is often hindered as the previous page may contain a token that is no longer valid. Interaction with this previous page will result in a CSRF false positive security event at the server. Regardless of the approach taken, developers are encouraged to protect the CSRF token the same way they protect authenticated session identifiers, such as the use of SSLv3/TLS

Sample Code to generate token for each request:

protected void btnSubmit_Click(object sender, EventArgs e)
 {
 if (txtUserName.Text == "admin" && txtPassword.Text == "admin")
 {
 string AntiXsrfTokenKey = "__AntiXsrfToken";
 var token = Guid.NewGuid().ToString("N");
 Session["AntiXsrfToken"] = token;
 //Create the non-persistent CSRF cookie
 var responseCookie = new HttpCookie(AntiXsrfTokenKey)
 {
 //Set the HttpOnly property to prevent the cookie from
 //being accessed by client side script
 HttpOnly = true,

//Add the Anti-XSRF token to the cookie value
Value = token
};
Response.Cookies.Set(responseCookie);
Response.Redirect(“~/MyFirstPage.aspx”);
}}

From the home page if the user performs any kind of server side request, then the application will validate the current token and generate a new token and assign it to the session and send the token to browser through cookie or hidden field. It is advisable to keep the token validation code in page_init or any global place.

protected void Page_Init(object sender, EventArgs e)
 {
 var requestCookie = Request.Cookies[AntiXsrfTokenKey];

string token = Session[“AntiXsrfToken”].ToString();

if (requestCookie != null && token == requestCookie.Value)
{
Session[“AntiXsrfToken”] = Guid.NewGuid().ToString(“N”);

var responseCookie = new HttpCookie(AntiXsrfTokenKey)
{
//Set the HttpOnly property to prevent the cookie from
//being accessed by client side script
HttpOnly = true

//Add the Anti-XSRF token to the cookie value
Value = Session[“AntiXsrfToken”].ToString()
};
Response.Cookies.Set(responseCookie);
}
else
{
throw new InvalidOperationException(“Validation of Anti-XSRF token failed.”);
}
}