Research on the security of ASP. Net Forms authentication -- why does the encryption code need to be configured as a service?

Statement: This post does not mean you have to do anything bad, but reminds you of possible security problems.

ASP. NET provides built-in login authentication, the most common is forms authentication. Explains how to configureArticleThere are many ways to configure and use this verification method. The following describes some of the security issues that have been ignored. In fact, it is no problem, and some problems will come out of the way it is used.

This article will focus on the security issues that will be encountered in practical applications in three parts, and study and try to propose solutions.

I. Simple forms cracking crisis
Ii. Vertical website Division forms cracking crisis
Iii. What are the consequences of the crisis?

 

I. Simple forms cracking crisis

The simplest form verification is to configure nodes in Web. config:

 

<Authentication mode = "forms">

<Forms name = ". mycookies"> </Forms>

</Authentication>

Compile a help class:

 

Cookiehelper class
Public   Static   Class Cookiehelper {
Public   Static   String Encrypt ( String Name, String Value ){
Formsauthenticationticket ticket =   New Formsauthenticationticket ( 1 , Name, datetime. Now, datetime. Now. adddays ( 1 ), True , Value, " / " );
String Authticket = Formsauthentication. Encrypt (ticket );
Return Authticket;
}

Public   Static   Void Set ( String Name, String Value ){
Httpcookie =   New Httpcookie (formsauthentication. formscookiename, encrypt (name, value ));
Cookie. Expires = Datetime. Now. adddays ( 1 );
If (Httpcontext. Current. response. Cookies [formsauthentication. formscookiename] =   Null )
Httpcontext. Current. response. Cookies. Add (cookie );
Else
Httpcontext. Current. response. Cookies. Set (cookie );
}

Public   Static   String Get (){
If (Httpcontext. Current. Request. Cookies [formsauthentication. formscookiename] =   Null )
Return   Null ;
Else {
Return Httpcontext. Current. Request. Cookies [formsauthentication. formscookiename]. value;
}
}

Public StaticFormsauthenticationticket decrypt (StringValue ){
ReturnFormsauthentication. decrypt (value );
}
}

Create site sitea

Create site siteb

Set the cookie on the sitea page:

Cookiehelper. Set ("yurow", "123123 ");

OK! In this way, a cookie is created in sitea, and there is no problem in itself. However, we often ignore some issues. As you can see, I have provided the decrypt method in the cookiehelper class, which can decrypt cookies. The problem lies here! Why? Don't know? Then let the poor man explain to the donor. On such a website, I will perform the following operations:
1. I have registered an account;
2. I use this account to log on (for convenience, I use Firefox );
3. Open firebug and enable Network Monitoring for the website;
4. Refresh the logon page;
5. You can see a piece of cookie ciphertext in the HTTP header monitored on this page. For example:

. Mycookie = 32dde0b4e858248037e4d082ef7e9c9bc607b7aa878f8dd
7de7c13630a5a38fd9a9da89b709e79f97d05deefc9d55a45d29051d
66955439055d01476e8659e34abdb42fa0018020194f26618fe74e11b
Such a string.

OK. Create a page in siteb, add an input box and a button in the middle, and write the following events:

Decryption code
Protected   Void Button#click ( Object Sender, eventargs e ){

StringText=Textbox1.text;

If(!String. Isnullorempty (text )){

Formsauthenticationticket ticket=Cookiehelper. decrypt (text );

Type type=Ticket. GetType ();

Propertyinfo [] Properties=Type. getproperties ();

Stringbuilder sb= NewStringbuilder ();

Foreach(Propertyinfo propertieInProperties ){

StringName=Propertie. Name;

StringVal=Propertie. getvalue (ticket,Null). Tostring ();

SB. append (name );

SB. append (":");

SB. append (VAL );

SB. append ("\ R \ n");

}

//Textbox2.text = sb. tostring ();

Response. Write (sb. tostring ());

}

}

Copy the ciphertext of the cookie above to the siteb page. Click the decrypt button to see what it is?
Version: 1 Name: yurow Expiration: 2009-9-23 19:12:44 issuedate: 2009-9-22 19:12:44 ispersistent: True expired: false userdata: 123123 cookiepath :/

How is it? All information is decrypted! However, it seems that it was too early to decrypt the data and the ciphertext of others' cookies. For the moment, let's talk about vertical division of site security risks.

Ii. Vertical website Division forms cracking crisis

Vertical division of the site its external performance is generally multi-domain name n multiple sites. For example, space.cnblogs.com and news.cnblogs.com in the blog Park. In the first part of the description above, the poor path seems to have missed the question about setting the machinekey. That's because it should be left here. If it's all said above, what should we talk about now?

Yes, we can set it in Web. config.

<Machinekey validationkey = "*********" decryptionkey = "*********" validation = "sha1" decryption = "3DES"/>

Such a node. If this is set on Site A, siteb will not be able to correctly decrypt the cookie ciphertext generated by sitea unless Site B also sets nodes with the same key. It seems that the General website has set this, as if we don't need to worry about it!

Yes. This is generally the case. However, many companies have high mobility, and I believe there are many people who can access web. config in Vertical Split sites. This makes it easy for some people to obtain this key data (of course, not including the poor path. What can this data do? Why? I have configured this node in the web. config of my own website on siteb, so that the cookie ciphertext of the target website can be easily unlocked. In order to ensure the security of this aspect, we have to make the cookie encryption and decryption part into a service, which is not only easy to update, but also allows as few people as possible to contact, to prevent security problems from being magnified. Otherwise, if someone leaves the company or suffers computer viruses, it is best to change the machinekey. Otherwise? Otherwise, problems may occur. What's wrong? This is what we will talk about below.

Iii. What are the consequences of the crisis?

What are the consequences of the leakage of encrypted keys? The consequences are serious. The preceding example shows the key information contained in the cookie ciphertext of the website. Instead, we need cookiehelper class. Based on this key information, we can easily create a cookie ciphertext.Write the cookie ciphertext into the coookies of the target website, and you will be deemed to have logged on. And this (Here we use the authentication may be the username or ID of the cookie .) Usernames can be forged at will, that is, users who do not exist can post messages!If you perform verification in the post operation every time, it will undoubtedly increase the burden on the server, and the best way is not to leak the Encrypted Key. If this method is inappropriate, users can be forged (I tried some websites a few months ago, and fake user posts will make a forum layout or even the homepage inaccessible ), it can also be forged into an administrator account. It is hard to imagine that if you use another user's account or administrator's account to post a message at will, what will happen to the negative impact?

OK. Are you aware of the problem? Then we will not talk much about the poor path.