Use ASP. NET's built-in functions to defend against Web attacks (1)

1. ASP. NET developers should always adhere to the practice

If you are reading this article, you may not need to instill in you the fact that security in Web applications is becoming increasingly important. You may need some practical suggestions on how to implement security in ASP. NET applications. The bad news is that there is no development platform-including ASP. NET-to ensure that once this platform is adopted, you can write secure code. If anyone says so, they will be lying. The good news is that, for ASP. NET, ASP. NET, especially version 1.1 and the forthcoming version 2.0, integrate some easy-to-use built-in defense barriers.
Simply applying all of these features is not enough to protect Web applications from any possible and foreseeable attacks. However, if combined with other defense techniques and security policies, the built-in ASP. NET feature can constitute a powerful toolkit that helps ensure that applications run in a secure environment.
Web security is the sum of various factors and the result of a policy that is far beyond a single application. This policy involves database management, network configuration, social engineering, and phishing.
The purpose of this article is to demonstrate what ASP. NET developers should always adhere to in order to maintain a reasonable level of security standards. This is the most important aspect of security: remain vigilant and never relax, making it increasingly difficult for bad people to launch hacker attacks.
Next, let's take a look at what ASP. NET provides to simplify this job.
Ii. Sources of threats

In table 1, I have summarized the most common Web attack types and defects that may result in these attacks in applications.

Attack	Possible initiator of the attack
Cross-site scripting (XSS)	Untrusted user input displayed on the page
SQL Injection	Concatenate user input to form SQL commands
Session hijacking	Session ID prediction and stolen session ID Cookie
One click	Imperceptible HTTP posts sent through scripts
Hide domain tampering	Hidden domains that are not checked and trusted are filled with sensitive data.

Table 1. Common Web Attacks

What are the key facts displayed in the list? In my opinion, there are at least three points:
1. Whenever you insert user input into the browser tag, you may expose yourself to code injection attacks against any SQL injection and XSS variants.
2. Database Access must be implemented in a safe way, that is, the database should be given as few permissions as possible and roles should be used to divide the responsibilities of each user.
3. Never send sensitive data over the network, let alone plain text), and store sensitive data on the server in a secure manner.
Interestingly, the above three points respectively target three different aspects of Web security, and these three aspects are combined, it is the only reasonable way to generate anti-attack and anti-tampering applications. Various aspects of Web security can be summarized as follows:
1. Encoding practices: data verification, type and buffer length check, anti-tampering measures
2. Data Access Policy: use decision-making to protect the weakest account, and use stored procedures or at least parameterized commands.
3. Effective storage and management: Do not send key data to the client, use hash code to detect operations, verify the user's identity and protect the identity, and apply strict password policies
As you can see, only developers, architects, and administrators can work together to generate secure applications. Do not assume that you can achieve the same purpose in other ways.
When compiling ASP. NET applications, you are not alone facing the hacking army: the only weapon is the line of code typed through your own brain, skills, and fingers. ASP. NET 1.1 and later versions provide a helping hand. They have some specific functions that can automatically increase the defense against certain threats listed above. Next we will view them in detail.

3. ViewStateUserKey

Introduced from ASP. NET 1.1, ViewStateUserKey is a string attribute of the Page class. Only a few developers are really familiar with this attribute. Why? Let's take a look at what the document says.
Assign an identifier to a single user in view status variables associated with the current page
Aside from being cumbersome, the meaning of this sentence is quite clear. But can you tell me honestly that it illustrates the original purpose of this attribute? To understand the role of ViewStateUserKey, You need to continue to read until the Remarks section.
This attribute helps prevent one click attack because it provides additional input to create a hash value that prevents view status tampering. In other words, ViewStateUserKey makes it much more difficult for hackers to use the content of the client view status to prepare for malicious website posting. You can assign any non-null string to this attribute, but it is best to use the session ID or user ID. To better understand the importance of this attribute, we will briefly introduce the basic knowledge of a click attack.
One-click attack includes posting malicious HTTP forms to known and vulnerable Web sites. It is called "one-click" because it usually starts with the tempting link that the victim accidentally clicks to send via email or browses in a crowded forum. By clicking this link, the user accidentally triggers a remote process and finally submits malicious <form> to a site. Everyone should be honest: Can you tell me that you have never clicked here to win $1,000,000 for curiosity? Obviously, nothing bad happens to you. Let's assume this is true. Can you say that all others in the Web community are spared? Who knows.
To succeed, a single click attack requires specific background conditions:
1. Attackers must fully understand the websites with vulnerabilities. This is possible because an attacker can "diligently" study the file, or he/she is an angry internal employee, for example, an employee who is fired but not honest ). Therefore, the consequences of such attacks may be extremely serious.
2. The site must use a Cookie. If it is a persistent Cookie, the effect is better.) to achieve a single login, the attacker has received a valid authentication cookie.
3. Some users of the site perform sensitive transactions.
4. Attackers must be able to access the target page.
As mentioned earlier, attacks include submitting malicious HTTP forms to pages waiting for forms. It can be inferred that this page will use the posted data to perform some sensitive operations. It is conceivable that attackers can clearly understand how to use various domains and come up with false values for their purposes. This is usually a specific target attack, and due to its triangular relationship, it is difficult to trace the source-that is, hackers trick victims into clicking a link on the hacker site, this will cause malicious code to be posted to the third site. See Figure 1 .)

Figure 1. One-Click Attack

Why is it a victim of no doubt? This is because, in this case, the IP address displayed in the server log that sends a malicious request is the IP address of the victim. As mentioned above, this tool is not as common as the "classic" XSS and is easy to initiate). However, its nature determines that its consequences may be disastrous. How to deal with it? Next, let's take a look at the working mechanism of this attack in the ASP. NET environment.
Unless the operation code is in the Page_Load event, the ASP. NET page cannot execute sensitive code beyond the event. View status fields are required for sending back events. Remember that ASP. NET checks the request sending status and sets IsPostBack based on whether the _ VIEWSTATE field exists. Therefore, no matter who sends a false request to the ASP. NET page, a valid view State domain must be provided.
A hacker must be able to access this page if one-click attack is desired. In this case, a visionary hacker will save the page locally. In this way, he/she can access the _ VIEWSTATE domain and use the domain to create requests with the old view status and malicious values in other domains. The problem is, can this work?
Why not? If an attacker can provide valid authentication cookies, the hacker can access and the request will be processed as usual. The server does not check the view status content when EnableViewStataMac is off), or only checks whether the view status content has been tampered. By default, there is no mechanism in the attempt state to associate the content with a specific user. Attackers can easily reuse the obtained view status and impersonate another user to access the page legally to generate false requests. This is exactly where ViewStateUserKey is involved.
If you select the correct option, you can add user-specific information to the view status. When processing a request, ASP. NET extracts the key from the view State and compares it with the ViewStateUserKey of the running page. If the two match, the request is considered legal; otherwise, an exception is thrown. What values are valid for this attribute?
Set ViewStateUserKey as a constant string for all users, which is equivalent to leaving it empty. You must set it to the user ID, which is better for each user. Due to some technical and social reasons, session IDs are more suitable, because session IDs are unpredictable, timeout will fail, and are different for each user.
The following are some code that is essential to all your pages:

Void Page_Init (object sender, EventArgs e ){
ViewStateUserKey = Session. SessionID;
:
}

To avoid repeated Writing of the code, you can fix it in the OnInit virtual method of the class derived from Page. Note that you must set this attribute in the Page. Init event .)

Protected override OnInit (EventArgs e ){
Base. OnInit (e );
ViewStateUserKey = Session. SessionID;
}

In general, using the base page class is always a good thing. I have explained it in Build Your ASP. NET Pages on a Richer Bedrock. If you want to learn more about the one-click attacker trick, you can find an excellent article on aspnetpro.com.