Improving Web Application Security: Threats and Countermeasures
This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.
J.D. Meier, Alex Mackman, Michael Dunner, Srinath Vasireddy, Ray Escamilla and Anandha Murukan from Microsoft Corporation published Improving Web Application Security: Threats and Countermeasures in June 2003 and it has been last revised in January 2006. The document applies to the following versions of the .NET Framework:
- .NET Framework version 1.1
- .NET Framework version 2.0
You can find additional information about this document, including its starting point and a complete overview, on the landing page.
This chapter provides guidance on how to review code built using the .NET Framework for potential security vulnerabilities. It covers specific review questions to ask and discusses the tools you should use for the task. The chapter also includes general coding considerations, along with review questions designed to help you identify cross-site scripting (XSS), SQL injection, and buffer overflow vulnerabilities in your applications.
Contents:
I. In This Chapter
A. Overview
B. FxCop
C. Performing Text Searches
D. Cross-Site Scripting (XSS)
E. SQL Injection
F. Buffer Overflows
G. Managed Code
H. Code Access Security
I. Unmanaged Code
J. ASP.NET Pages and Controls
K. Web Services
L. Serviced Components
M. Remoting
N. Data Access Code
O. Summary
P. Additional Resource
II. Identifying cross-site scripting (XSS), SQL injection, and buffer overflow vulnerabilities
A. XSS vulnerabilities
1. What is XSS?
2. How does an attacker inject malicious scripts into a website?
3. Common types of XSS attacks and their effects.
4. How to prevent XSS attacks in your application.
5. Review questions to help locate XSS vulnerabilities in your codebase.
B. SQL injection vulnerabilities
1. What is SQL injection?
2. How do attackers exploit SQL injection vulnerabilities?
3. Common techniques used for SQL injection attacks.
4. How to prevent SQL injection attacks in your application.
5. Review questions to help locate SQL injection vulnerabilities in your codebase.
C. Buffer overflow vulnerabilities
1. What is a buffer overflow?
2. How do attackers exploit buffer overflows?
3. Common types of buffer overflow attacks and their effects.
4. How to prevent buffer overflow attacks in your application.
5. Review questions to help locate buffer overflow vulnerabilities in your codebase.
Security Issues Specific to Individual NET Framework Technologies
## Overview
Code reviews should be an integral part of your development process, particularly when it comes to security. Security code reviews focus on identifying insecure coding practices and vulnerabilities that could potentially lead to security issues. The goal of these reviews is to identify as many potential security vulnerabilities as possible before the code is deployed. Fixing security flaws at the development stage is far less expensive and time-consuming than doing so later in the product deployment cycle.
## Evaluating ASP.NET Web Applications Built Using Microsoft .NET Framework
This chapter provides guidance on reviewing managed ASP.NET Web application code built using the Microsoft .NET Framework. It also covers reviewing calls to unmanaged code. The chapter is structured by functional area, with sections that present general code review questions applicable to all types of managed code, as well as sections that focus on specific types of code such as Web services, serviced components, data access components, and more.
The following are potential security vulnerabilities that you can ask questions to expose. You will find solutions to these questions in the individual building chapters of Part III of this guide. In addition, the "Checklists" section of the guide contains code review checklists that can help you during the review process.
FxCop
Starting the review process is a good idea by running your compiled assemblies through FxCop analysis tool. This tool analyzes binary assemblies (not source code) to ensure they conform to .NET Framework Design Guidelines available on MSDN. FxCop also checks that your assemblies have strong names, which provide tamperproofing and other security benefits. The tool comes with a predefined set of rules, which you can customize and extend as needed.
For further information, refer to the following resources:
Performing Text Searches
The following instructions will help streamline the review process by providing guidance on utilizing a text search tool, which in turn, can be used to locate vulnerable code within your files. This particular tool offers significant advantages as it facilitates rapid identification of potentially problematic strings. The subsequent review questions will likely highlight specific strings that should be searched for when identifying vulnerabilities.
Should you already have a preferred method for performing searches, please proceed as you see fit. However, if not, there are two standard options available: Visual Studio's Find in Files feature or the more universal Findstr command line tool, both of which come bundled with the Microsoft Windows operating system.
It's important to note that while using the Windows XP Search function through Windows Explorer's File menu is convenient, if you choose to use the "A word or phrase in the file" option, ensure you have installed the latest Windows XP Service Pack, as this may impact the search's reliability. For additional details and troubleshooting steps, please consult Microsoft's Knowledge Base article 309173, entitled 'Using the "A Word or Phrase in the File" Search Criterion May Not Work.' Once you have located these potential issues, the next step would be to search for any instances of hard-coded strings.
Before conducting a comprehensive line-by-line code review, start by quickly scanning your entire codebase to identify hard-coded passwords, account names, and database connection strings. Look for common string patterns such as "key", "secret", "password", "pwd", and "connectionstring".
For instance, if you want to search for the string "password" in the Web directory of your application, use the Findstr tool from a command prompt as follows: findstr /S /M /I /d:c:\projects\yourweb "password" *.*
Here's what each parameter does in Findstr:
- /S: This option includes subdirectories in your search.
- /M: It lists only the file names that match the search criteria.
- /I: This enables a case-insensitive search.
- /D: This specifies the directory to search (in this example, c:\projectsyourweb). If the path you're searching for contains spaces, surround it with double quotes.
One way to automate Findstr is to create a text file containing all the common search strings you're looking for and read them into your script. Here's an example:
```markdown
Before you perform a detailed line-by-line analysis of your source code, start with a quick search through your entire code base to identify hard-coded passwords, account names, and database connection strings. Scan through your code and search for common string patterns such as the following: "key," "secret," "password," "pwd," and "connectionstring."
For example, to search for the string "password" in the Web directory of your application, use the Findstr tool from a command prompt as follows: findstr /S /M /I /d:c:\projects\yourweb "password" *.*
Findstr uses the following command-line parameters: /S /M /I /D:dir - include subdirectories. /M - list only the file names. /I - use a case insensitive search. /D:dir - search a semicolon-delimited list of directories. If the file path you want to search includes spaces, surround the path in double quotes. Automating Findstr You can create a text file with common search strings. Findstr
```
以下是如何使用findstr命令从包含.aspx文件的目录中读取搜索字符串。在运行以下命令时，请确保您当前所在的目录包含这些.aspx文件。
```batch
findstr /N /G:SearchStrings.txt *.aspx
```
参数解释：
* `/N`:找到匹配项时打印相应的行号。
* `/G`:指示包含搜索字符串的文件。在这个例子中，搜索所有ASP.NET页面(*.aspx)中的字符串，这些字符串存储在SearchStrings.txt文件中。
示例：
假设您的SearchStrings.txt文件内容如下：
```makefile
Username=admin
Password=123456
ConnectionString=Server=(local);Database=YourDatabase;User Id=sa;Password=YourStrong@Passw0rd;Trusted_Connection=Yes;MultipleActiveResultSets=False;App=EntityFramework;
```
您可以在包含.aspx文件的目录中运行以下命令来查找这些字符串：
```batch
findstr /N /G:SearchStrings.txt *.aspx
```
这将在所有aspx文件中查找与SearchStrings.txt中的任何字符串匹配的内容，并在找到匹配项时显示相应的行号。
The secureappdll file was disassembled using Ildasm.exe and the disassembly output was analyzed to identify strings of interest. The following is a step-by-step summary of the disassembly:
1. IL_000c: ldstr \"RegisterUser\"
2. IL_0027: ldstr \"@userName\"
3. IL_0046: ldstr \"@passwordHash\"
4. IL_0065: ldstr \"@salt\"
5. IL_008b: ldstr \"Exception adding account. \"
6. IL_000e: ldstr \"LookupUser\"
7. IL_0027: ldstr \"@userName\"
8. IL_007d: ldstr \"SHA1\"
9. IL_0097: ldstr \"Exeception verifying password. \"
10. IL_0009: ldstr \"SHA1\"
11. IL_003e: ldstr \"Logon successful: User is authenticated\"
12. IL_0050: ldstr \"Invalid username or password\"
13. IL_0001: ldstr \"Server=AppServer;database=users; username='sa' password=password\"
ildasm.exe is a tool used for disassembling .NET assemblies into their component parts. Its default location is in the `\Program Files\Microsoft Visual Studio {version number}\SDK\{Framework Version number}\bin` folder, where version number and framework version number refer to the specific Visual Studio version and the .NET Framework version you are using.
If you need more information about the supported command-line arguments, you can run `ildasm.exe /?` to get detailed help on how to use this tool.
One of the potential security risks associated with using ildasm.exe is cross-site scripting (XSS). XSS is a type of code injection attack that allows an attacker to inject malicious scripts into web pages viewed by other users. When your application uses input parameters in the output HTML stream returned to the client, it may be vulnerable to XSS attacks.
To test whether your application is vulnerable to XSS, you can perform a simple search for pages where user input information is sent back to the browser. If such pages are found, there may be an opportunity for attackers to inject malicious scripts into these responses and compromise the integrity of your application or steal sensitive information from users.
It's important to take proactive measures to protect against XSS attacks, such as validating and sanitizing user input before rendering it on the web page and using appropriate encoding techniques when transmitting data between servers and clients. By implementing these security best practices, you can reduce the risk of XSS attacks and enhance the security of your application.
SS bugs are a prime example of the risks that arise from placing too much trust in data entered by users. For instance, an application may be designed to accept a numerical value for a price, but an attacker might deliberately insert a price along with some HTML and JavaScript code. To mitigate this risk, it is crucial to always validate data that comes from untrusted sources.
When reviewing code, it is essential to ask yourself the question: "Is this data validated?" Keeping a comprehensive list of all entry points into your ASP.NET application is also important, as these can include HTTP headers, query strings, form data, and more. It is imperative that each piece of input is checked for validity at some point, as simply ignoring potentially risky input can lead to serious security vulnerabilities.
Testing for incorrect input values should not be relied upon as a means of security, as this approach assumes that you are aware of all potential risks. Instead, the most reliable way to validate data in ASP.NET applications is through the use of regular expressions. By employing these patterns, developers can ensure that user-provided data meets specific criteria and avoid XSS vulnerabilities.
SS (Cross-site Scripting) vulnerabilities can be easily identified by performing a simple test. To do this, type text such as "XYZ" into form fields and examine the output. If the browser displays "XYZ" or if you see "XYZ" when viewing the source of the HTML, your Web application is vulnerable to XSS.
If you want to test for more dynamic scenarios, inject the following code into the HTML:
```html
```
However, it's important to note that this technique may not work in all cases, as it depends on how the input is used to generate the output. To help identify common XSS vulnerabilities, follow these steps:
1. Identify Code That Outputs Input: The first step is to locate any code that generates output based on user input. This can include displaying user data in tables, generating pop-up messages, or updating parts of the page dynamically.
2. Identify Potentially Dangerous HTML Tags and Attributes: Look for any HTML tags or attributes that might allow untrusted input to be interpreted as part of the content. This includes using `