Hacking the Code ASP.NET Web Application Security [Electronic resources] نسخه متنی

1.

To allow users to send HTML markup from a form field, query string, or cookie, you must first disable the built-in validation feature. This setting is an attribute of the <pages> element in machine.config. You can also disable it on a per-page basis with this tag on the page itself:

<% @ Page validateRequest=”True” %>

Once you disable this feature, you must manually encode user input to make sure that it does not contain any HTML markup. Next, search for the encoded tags you want to allow and change them back to their original form. For example, to allow bold markup, search for the string &lt;b&gt; and replace it with <b>. Repeat this for each allowed tag. Likewise, replace all occurrences of &lt;/b&gt; with </b>.

Note that since you have disabled the built-in validation you must be very careful to always check user input for HTML markup.

2.

Managed code is generally not vulnerable to buffer overflow attacks, but that does not mean you are completely safe. Because fully trusted code has the capability of calling unmanaged code such as external components or Windows API calls, buffer overflows are still a risk. Always use caution to check string lengths when calling unmanaged code. Also, be sure to run code with a low privilege account, and use strong NTFS permissions to limit access to the file system. For example, Web users should not have access to files outside the Web content directories.

3.

You can often minimize the effects of file system attacks with how you configure IIS and the file system. Here are some tips:

In the Internet Services Manager, remove Read permissions for all scripts and executables. Neither scripts nor executables need read permissions to run.

Set strong NTFS permissions on Web content files and directories to prevent Web users from modifying or creating files. If you need Web users to be able to create and modify data files, consider placing these files outside the Web root. If you must allow users to create or modify files in a Web content directory, use specific NTFS permissions to allow access only to those particular files, rather than the entire directory.

Use the file system to set the read-only attribute on Web content files and directories to prevent easy modification of these files.

4.

IIS 6 has many security features that for the most part make URLScan irrelevant. However, there are still some features that can reduce the attack surface and help limit application level attacks. For example, you can use URLScan to block requests that contain certain strings and you can limit the length of specific HTTP headers. See www.microsoft.com/technet/security/_tools/urlscan.mspx for more information on using URLScan with IIS 6.