Shulou(Shulou.com)06/03 Report--

I want to learn ASP.NET MVC 3. 0 (13): MVC 3. 0 to prevent cross-site request forgery (CSRF) *

Overview

As we all know, ASP.Net MVC programs generate standard Html tags when the browser is running, including the key data to be sent by the browser, which is all in the Html content, which sounds good, but what if we fake similar Html content and change the key data in it? Okay, let's take such an example.

CSRF*** example

First of all, let's take the previously made person/edit as an example.

Let's look at the controller code first.

/ / initial page

/ / GET: / Person/Edit/5

Public ActionResult Edit (int id)

{

Return View ()

}

/ / modify the method

/ / POST: / Person/Edit/5

[HttpPost]

Public ActionResult Edit (int id, Person person)

{

Try

{

/ / Database operation code

Return RedirectToAction ("Success", person)

}

Catch

{

Return View ()

}

}

Then let's look at the view code.

@ model MvcApplication.Models.Person

@ {

ViewBag.Title = "modifier"

Layout = "~ / Views/Shared/_Layout.cshtml"

}

Modifier

Using (Html.BeginForm ())

{

@ Html.ValidationSummary (true)

Personnel information

@ Html.HiddenFor (model = > model.ID)

@ Html.LabelFor (model = > model.Name)

@ Html.EditorFor (model = > model.Name)

@ Html.ValidationMessageFor (model = > model.Name)

@ Html.LabelFor (model = > model.Age)

@ Html.EditorFor (model = > model.Age)

@ Html.ValidationMessageFor (model = > model.Age)

}

@ Html.ActionLink ("return list", "Index")

Run it and have a look.

After clicking Save

As you can see, the code in the above example is correct and running normally, so let's implement CSRF***.

Implement CSRF***

Open notepad and write the following code

Save as a Html file.

Double-click the file to run.

After what is allowed to be blocked:

Huh? ~ ~ No way, you may have been stupid by now. This is called CSRF***.

What is CSRF***?

CSRF (Cross-site request forgery), Chinese name: cross-site request forgery, also known as: one click attack/session riding, abbreviated as: CSRF/XSRF.

Because in the ASP.NET program, our user information is stored in the cookies, at this time, for the users themselves, the program can be regarded as streaking. Because of this, the normal client requests accepted by Web programs usually come from behaviors such as user clicks on links and form submissions. However, malicious people can rely on scripts and browser security flaws to hijack client sessions and forge client requests. People steal your identity, send malicious requests in your name, send e-mails, send messages, steal your account, and even buy goods and transfer money in virtual currency. The problems include: disclosure of personal privacy and property security. This is CSRF***.

CSRF vulnerabilities are generally divided into two types: on-site and off-site:

The vulnerability of CSRF site type is to some extent caused by programmers' abuse of $_ REQUEST class variables. Some sensitive operations originally require users to initiate POST requests from form submissions to send parameters to the program, but due to the use of variables such as $_ REQUEST, the program also receives GET requests to pass parameters, thus creating conditions for * * users to use CSRF*** Generally speaking, as long as the predicted request parameters are placed in a picture link of a post or message on the site, the victim will be forced to initiate a request after browsing such a page.

The vulnerability of off-site type of CSRF is actually the problem of external submission of data in the traditional sense. General programmers will consider adding watermarks to some forms such as comments and comments to prevent SPAM problems, but for the sake of user experience, some operations may not have any restrictions, so * * users can predict the parameters of the request first. Write a javascript script in the Web page outside the station to forge file requests or auto-submitted forms to realize GET and POST requests. When users click on the link to visit the Web page outside the station in the session state, the client is forced to initiate the request.

Security defects of browsers

Today's Web applications almost use Cookie to identify users and save session state, but all browsers do not take security into account when they first join the Cookie function, and file requests from WEB pages are accompanied by COOKIE.

Prevent CSRF*** in MVC

Using AntiForgeryToken tokens, we are provided with a token in the core of ASP.NET to detect and organize CSRF***.

CSRF*** can be blocked as long as @ Html.AntiForgeryToken () is used in the Html form.

@ model MvcApplication.Models.Person

@ {

ViewBag.Title = "modifier"

Layout = "~ / Views/Shared/_Layout.cshtml"

}

Modifier

Using (Html.BeginForm ())

{

@ Html.AntiForgeryToken ()

@ Html.ValidationSummary (true)

Personnel information

@ Html.HiddenFor (model = > model.ID)

@ Html.LabelFor (model = > model.Name)

@ Html.EditorFor (model = > model.Name)

@ Html.ValidationMessageFor (model = > model.Name)

@ Html.LabelFor (model = > model.Age)

@ Html.EditorFor (model = > model.Age)

@ Html.ValidationMessageFor (model = > model.Age)

}

@ Html.ActionLink ("return list", "Index")

Accordingly, we also need to add [ValidateAntiForgeryToken] filtering feature to Controller.

This feature means to detect whether the server request has been tampered with.

Note: this feature can only be used for post requests, and get requests are not valid.

/ / modify the method

/ / POST: / Person/Edit/5

[ValidateAntiForgeryToken]

[HttpPost]

Public ActionResult Edit (int id, Person person)

{

Try

{

/ / Database operation code

Return RedirectToAction ("Success", person)

}

Catch

{

Return View ()

}

}

The running effect is the same as above.

Then we are running the Html file that we just saved to see

Haha, wrong report. That proves that our current efforts to stop CSRF*** are effective.

Use Salt values to enhance protection

To ensure that our AntiForgeryToken blocks a unique and better encrypted AntiForgeryToken in the program, we can set the Salt value for AntiForgeryToken.

In this way, even if the * * person manages to get the token, the post operation cannot be performed if the Salt values do not match.

/ / modify the method

/ / POST: / Person/Edit/5

[ValidateAntiForgeryToken (Salt = "aa")]

[HttpPost]

Public ActionResult Edit (int id, Person person)

{

Try

{

/ / Database operation code

Return RedirectToAction ("Success", person)

}

Catch

{

Return View ()

}

}

Let's not modify the View code for the time being.

Run it and have a look

You can see that even the page of the MVC program itself cannot be requested after adding the Salt value, let alone the * person, unless he can guess our Salt value.

We modify the view code

@ Html.AntiForgeryToken ("aa")

Continue to run the project

You can see that blocking becomes purposeful after adding the Salt value to the view.

Summary

Session security features of browsers:

We refer to the standard format of Set-Cookie

Set-Cookie: = [; =] [; expires=] [; domain=] [; path=] [; secure] [; HttpOnly]

There are actually two forms of cookie supported by browsers:

One is memory COOKIE. If the expires parameter of COOKIE value is not set, that is, the expiration time of COOKIE is not set, the COOKIE will expire after closing the browser and will not be saved locally. The other is to save the COOKIE locally, that is, to set the expires parameter, and the value of COOKIE specifies the expiration time, then the COOKIE will be saved locally, and the browser will be closed before visiting the website. All requests within the valid time of the COOKIE will be saved locally with this COOKIE.

Internet Explorer has a privacy reporting function, which is actually a security feature, which will block all third-party COOKIE, such as files embedded in domain B in the Web page of domain A, and the COOKIE on the file request for domain B initiated by the client browser after visiting the Web page of domain A will be intercepted by IE. In addition to file requests, if the Web page in domain A uses IFRAME frames to contain the Web page in domain B, after visiting the Web page in domain A, all requests in the Web page in domain B, including the COOKIE on the file request, will also be intercepted by IE. However, this security feature of Internet Explorer has two features, one is that it will not block memory COOKIE, and the other is that if the P3P header is set on the website, it will allow cross-domain access to COOKIE, so the privacy reporting function will not work.

Therefore, under the premise of this security feature of Internet Explorer, if * * users want to use file requests from off-site CSRF*** to forge GET requests, the victim can only succeed when using in-memory COOKIE, that is, the session state where login is not saved. Firefox browsers do not consider using such a feature, and there are no restrictions on off-site CSRF***.

About Javascript hijacking technology:

In recent years, web programs frequently use Ajax technology, and JSON has begun to replace XML as the data transmission format of AJAX. JSON is actually a piece of javascript, most of which are defined array formats. In 2007, three security personnel of fortify proposed Javascript hijacking technology, which is a * * method for JSON dynamic data, in fact, it is also a disguised CSRF***. * the user calls a script tag from outside the station, which includes a JSON dynamic data interface within the station, because

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.