. NET MVC CSRF/XSRF Vulnerability

Recently, I have a loophole with a group of AH three dry up ...

Background:

My client is a world-renowned pharmaceutical enterprises, recently this customer came to the stage of an AH three managers, the first thing on the line is to put the existing software vendors to shuffle again. Because our customer relationship maintenance is very good, the direct counterpart of the early disclosure to us that the manager is to let a three companies monopoly their software supply, and expressed a great contempt. We expressed understanding, after all, any company just go in a three, slowly ... Slowly ... becomes Full House All is three o ...

Then one of the three companies secretly won the bid, and then we face kt. Because we maintain 12 highly active systems, KT's workload is also very large.

but! Three o of the cool place at this time, he will look for you from all dimensions of the matter, one of which is to find a loophole (he found a three O flaw detection company free to do) reported to the customer and threatened to resolve not to take over, to lengthen KT cycle (originally KT only three weeks time).

Then the client's chief of the three agreed ...

This loophole is originally, the customer has been said not to deal with, because most of the website is too old, many are not developed by us.

But this time seems to be not dry, fortunately, the customer said that will pay, OK ... That's the whole.

Now let the loophole debut!

Hello everyone! My name CSRF, the full name is Cross-site Request forgery (CSRF) prevention Cheat Sheet

This is my resume: Www.owasp.org/index.php/Cross-Site_Request_Forgery_ (CSRF) _prevention_cheat_sheet#viewstate_.28asp.net.29

(Google Translate understand)

This thing is a disguise attack, the camouflage tool is a cookie.

This is how this thing works:

(Please do not care about this ugly force figure ...) ）

A simple description is

Other sites use your identity (Cookie) to pretend that you did what you don't know, and then think about your online bank transfer.

Then there is a big doubt in this:

Why does the request that WEBSITEB send over Websitea receive? Did IIS eat the dirty stuff anyway?

Because our website supports cross-domain requests! (is not watching the thief glaring!) The focus of the painting AH)

Now the problem is basically OK, left is the plan.

And csrf this thing is still very high visibility, online a search a lot of

. NET MVC comes with a solution that only targets the normal MVC project, the back-and-forth separation of the bypass, and I'll write it later if I fix it ...

The solution is also very rude, one sentence is:

Our servers only receive requests from our own pages.

Put on the implementation is: each page according to a certain rules to generate a token, and then send the request when the past, the server first look at token and then do other

At this time someone said: What if other sites forge tokens?

Saying goes Confucius said: Not afraid of thieves stealing is afraid of thieves, if he wants to engage you, you will sooner or later, Ah, brother die

Here are the key codes:

@Html. AntiForgeryToken ()

This is the code for the Cshtml page, the ASPX is almost

The effect of this thing is to generate a hidden,value on the page that is token

The end becomes HTML long:

<input name= "__requestverificationtoken" type= "hidden" value= "mbnndb3t64quxyvixlsvoi_ Flbm2sihwiipcgszawal0dumy7h6sbuf0lkuaxod-dwf4p_4kxlyravohgxsq_ervpm5f3oa3owg6lz26wrw1 "/>

That ball is a mess of tokens.

So how does this thing work?

Type 1,form Request:

@using (Html.BeginForm ("Action", "Controller", NULL, FormMethod.Post, new {id = "formId"})) {    @ Html.antiforgerytoken ();    Other Code ...}

　　

Type 2,ajax Request:

var token = $ (' @Html. AntiForgeryToken () '). Val (); var headers = {};headers["__requestverificationtoken"] = token;            $.ajax ({                type: "Post",                headers:headers,                URL: "@Url. Action (" Action "," Controller ")",                data: {},                DataType: "JSON",                success:function (response) {                                   }            });

　　

After all, the page is generated tokens, to do everything possible to send to the background, not rigidly and form

form is directly wrapped into the inside, the background directly with the name is OK, Ajax is placed in the header.

Next is the background verification, because most of the action needs to plug the vulnerability, so directly wrote a filter

    Using System.Net;    Using System.Web.Helpers;    Using SYSTEM.WEB.MVC; public class Extendedvalidateantiforgerytoken:authorizeattribute {public override void Onauthorization (Author            Izationcontext filtercontext) {var request = FilterContext.HttpContext.Request; if (Request.            HttpMethod! = WebRequestMethods.Http.Post) return; if (Request. Isajaxrequest ()) {var Antiforgerycookie = Request.                Cookies[antiforgeryconfig.cookiename]; var cookievalue = Antiforgerycookie! = null?                AntiForgeryCookie.Value:null; Verify the security mark from cookies and Headers//Try-catch//try//{A can be added here Ntiforgery.validate (Cookievalue, request.)                headers["__requestverificationtoken"]); }//catch (Exception e)//{////filtercontext.result = new Redirectresu       Lt ("/account/login?returnurl=" +         Httputility.urlencode (FilterContext.HttpContext.Request.Url.ToString ()));                Contentresult result = new Contentresult (); Result.                Content = "<div style= ' text-align:center;padding:1em; ' > is currently in the exiting state, please login </div> again";                Filtercontext.result = Result; }} else {//try//{new Validateantiforge Rytokenattribute ().                Onauthorization (Filtercontext);        }//catch (Exception ex)//{/////}} }    }

The core of the code is to verify the validity of token, using the official API method, but to distinguish one thing, is the previous article mentioned that we Ajax and form with token of the way different, so need to determine whether Ajax request, walk two branches.

Then just hang the filter on the action.

OK, the loophole blocked, spents 2 days, Customer thief happy, is preparing to find Asangan Battle of time went awry.

Careful old iron may have found, the above solution is POST request Ah, get it?

This is a matter of, from the online survey when learned that this csrf is all for post, regardless of get.

For example, this article:

Stackoverflow.com/questions/35473856/asp-net-mvc-csrf-on-a-get-request

A three which what flaw detection company sent back a bunch get URL ...

After explaining the story to the customer, the customer blew up ... To do three, and then sent a series of sharp messages, but also CC of their third leader

In the end, the three see a little out of control, one is our post changed too fast (47), the second is, did not expect the customer's it Jiyan ...

At this time, ah three very embarrassed, in the mail back: We have a lot of experience in modifying the vulnerability

wtf?!!

Not waiting for us to talk, the customer directly back to a sentence: good! I'm going to have a meeting now, so what do you say about the GET request?

Come on... I'm going to help the client fight.

Think with the Indians, Koreans, Australians plus me a Chinese people to open English will be my brain benevolence pain ...

Additionally attach a connection:

Weblogs.asp.net/dixin/anti-forgery-request-recipes-for-asp-net-mvc-and-ajax