Protect against Web attacks with the built-in capabilities of ASP (1)

Summary: Dino summarizes the most common types of web attacks and describes how Web developers can use the built-in capabilities of ASP to improve security.

The practice that ASP. NET developers should always adhere to
If you are reading this article, you may not need to instill the fact that security in WEB applications is becoming increasingly important. What you need may be some practical advice on how to implement security in an ASP. The bad news is that there is no development platform-including ASP. NET-to ensure that once the platform is adopted, you will be able to write hundred-percent security code. If anyone says so, paramilitary is lying. The good news is that, for ASP. ASP. NET, especially version 1.1 and upcoming release 2.0, integrates some easy-to-use built-in defense barriers.

Applying all of these features alone is not enough to protect WEB applications from any possible and predictable attack. However, if combined with other defensive techniques and security policies, the built-in ASP. NET functionality will be a powerful toolkit to help ensure that your application runs in a secure environment.

Web security is the sum of factors that are the result of a strategy that spans far beyond a single application, involving database management, network configuration, and social engineering and phishing.

The purpose of this article is to demonstrate how the ASP. NET developers should always adhere to the practice of keeping security standards at a reasonable level. That's the main thing about security: Stay alert, never completely relax, and make it harder for the bad guys to launch a hacker attack.

Let's take a look at the features that ASP. NET provides to simplify this work.

Ii. sources of threats
In table 1, I summarize the most common types of Web attacks and the flaws in the application that could lead to these attacks.

Potential initiators of attack attacks
Cross-site scripting (XSS)
Non-trusted user input to echo back to page

SQL Injection
Concatenate user input to form SQL commands

Session Hijacking
Session ID guessing and stolen session ID Cookie

One click
Undetected HTTP posting via script

Hidden domain Tampering
Hidden fields that are not checked (and are trusted) are populated with sensitive data

Table 1. Common Web attacks

What are the key facts that appear in the list? In my opinion, there are at least the following three points:

1. Whenever you insert any user input into the browser's markup, you potentially expose yourself to code injection attacks (any SQL injection and XSS variant).

2. Database access must be implemented in a secure manner, that is, you should use as few permissions as possible for the database and divide the responsibilities of individual users through roles.

3. Never send sensitive data over the network (not to mention clear text), and you must store sensitive data on the server in a secure manner.

Interestingly, the three points above are for three different aspects of WEB security, and these three aspects are the only logical way to build an anti-attack, tamper-proof application. The various facets of WEB security can be summarized as follows:

1. Coding practices: Data validation, type and buffer length checking, tamper-proof measures

2. Data access Policy: Use decisions to protect potentially weakest accounts, use stored procedures, or at least parameterized commands.

3. Efficient storage and management: Do not send critical data to clients, use hash codes to detect operations, authenticate users and protect identities, apply strict password policies

As you can see, it is only through the joint efforts of developers, architects, and administrators that a secure application can be produced. Please do not assume that you can achieve the same purpose in other ways.

When you write an ASP. NET application, you are not alone in the army of hackers: the only weapon is the line of code you type through your brain, skills, and fingers. ASP. NET 1.1 and later will help, and they have specific features that automatically improve the defenses against some of the threats listed above. We examine them in detail below.

Third, ViewStateUserKey
Starting with ASP. 1.1, ViewStateUserKey is a string property of the Page class, and only a few developers are really familiar with the property. Why is it? Let's take a look at what the document says.

Assigns an identifier to a single user in the view-state variable associated with the current page

The meaning of this sentence is quite clear except for some of the burden, but can you honestly tell me that it illustrates the purpose of the property in its original way? To understand the role of viewstateuserkey, you need to continue reading down until the Remarks section.

This property helps prevent a single-click attack because it provides additional input to create a hash value that prevents the view state from being tampered with. In other words, ViewStateUserKey makes it much harder for hackers to use the content of Client view state to prepare malicious postings against the site. You can assign any non-empty string to the property, but preferably a session ID or a user's ID. To better understand the importance of this attribute, let's briefly describe the basics of one-click attack.

A single click attack involves posting a malicious HTTP form to a known, vulnerable Web site. It is called a "one-click" because it is usually started with the temptation of a victim accidentally clicking through an email or browsing in a crowded forum. By clicking on the link, the user unintentionally triggers a remote process that eventually leads to the submission of a malicious <form> to a site. Let's be honest: can you tell me that you've never clicked on a link like this to win $1,000,000 because you're curious? Obviously, there's nothing bad happening to you. Let's assume this is true; Can you say that all the other people in the Web community survived? Who knows.

To succeed, a single click attack requires a specific background condition:

1. An attacker must be fully aware of the vulnerable site. This is possible because an attacker can "diligently" study the file, or he or she is an angry insider (for example, an employee who is dismissed and dishonest). As a result, the consequences of such an attack could be extremely serious.

2. The site must use a cookie (if it is a persistent cookie that works better) to achieve a single sign-on, and an attacker has received a valid authentication cookie.

3. Some users of the site have a sensitive transaction.

4. The attacker must be able to access the target page.

As mentioned earlier, the attack involves submitting a malicious HTTP form to a page waiting for a form. It can be inferred that the page will perform some sensitive operations using the posted data. It is conceivable that attackers clearly understand how to use each domain, and can come up with some false values to achieve his purpose. This is usually a target-specific attack, and because of its triangular relationship, it can be difficult to trace back-that is, hackers entice victims to click on a link on the hacker's site, which in turn causes malicious code to be posted to a third site. (see Figure 1.) ）

Figure 1. One-click attack

Why not a victim of suspicion? This is because, in this case, the IP address of the malicious request that is displayed in the server log is the IP address of the victim. As mentioned earlier, this tool is not as common (and easy to initiate) as "classic" XSS, but its nature determines that its consequences can be catastrophic. How to deal with it? Let's look at how this attack works in an ASP. NET environment.

Unless the operation is encoded in the Page_Load event, it is simply not possible for an ASP to execute sensitive code outside of postback events. The View state field is required for postback events to occur. Keep in mind that ASP. NET checks the postback status of the request and sets the IsPostBack accordingly, depending on whether the _viewstate input domain exists. Therefore, whoever wants to send a bogus request to an ASP. NET page must provide a valid view-state field.

One click Attack to succeed, the hacker must be able to access the page. At this point, a visionary hacker will save the page locally. In this way, he or she can access the _viewstate domain and use that domain to create requests with old view state and malicious values from other domains. The question is, can this be done?

Why not? If an attacker can provide a valid authentication cookie, the hacker can enter and the request will be processed as usual. The view state content (when Enableviewstatamac is off) is not checked at all on the server, or it is only checked for tampering. By default, there is no mechanism in the attempt state to associate the content with a specific user. An attacker could easily reuse the acquired view state and impersonate another user to access the page legitimately to generate a false request. This is where ViewStateUserKey is involved.

If selected accurately, this property can add user-specific information to view state. When a request is processed, ASP. NET extracts the secret key from view state and compares it to the viewstateuserkey of the running page. If the two matches, the request will be considered valid, otherwise an exception will be thrown. For this property, what value is valid?

Setting ViewStateUserKey to a constant string for all users is equivalent to leaving it blank. You must set it to a value that is different for each user-the user ID, and the session ID is better. For some technical and social reasons, the session ID is more appropriate because the session ID is unpredictable, the timeout expires, and is different for each user.

Here are some of the code that is essential for all your pages:

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

To avoid repeating this code, you can pin them in the OnInit virtual method of a class derived from Page. (Note that you must set this property 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, and I've explained it in the article Build Your ASP. NET Pages on a Richer bedrock. If you want to learn more about one-click attackers ' tricks, you can find a very good article in aspnetpro.com.

Protect against Web attacks with the built-in capabilities of ASP (1)