| Gellenbeck | Wikis | CS 352 | CS 352 Wiki |

Notes Index

Information Sources for Web Security

There is a tremendous amount of information available about security issues on the Web. In particular, one could spend weeks going over the information on the Microsoft site

• Microsoft Security home page
• Microsoft Learning Paths for Security
• MSDN .NET Security
• Microsoft Security Development Center

Designing for the Web adds a number of security concerns.

Microsoft has developed Design Guidelines for Secure Web Applications to guide the ASP.NET developer. These guidelines are organized by categories where mistakes are made most often.

1. Input / Data Validation - Do not rely on client-side validation
2. Authentication - Who are you? Authentication is the process where an entity proves the identity of another entity, typically through credentials, such as a username and password
3. Authorization - What can you do? Authorization is how your application provides access controls for resources and operations
4. Configuration management
5. Sensitive data - Encrypt sensitive data (or do not store it)
6. Session management - Limit session lifetime
7. Cryptography - Use trusted libraries, do not try to develop your own
8. Parameter manipulation - Do not trust query strings, form fields, cookies, or HTTP headers
9. Exception management - Do no let revealing exception details get displayed in the browser
10. Auditing and logging - log suspicious-looking activity

While no panacea, managed programming languages like Java and C# have reduced the risk on several programming errors which lead to writing insecure code. (See Coding Horror's Sins of Software Security).

Likewise, use of the ASP.NET framework has reduced the exposure to writing insecure Web applications.

Input Validation

Best practices with input validation:

• Assume all input is harmful until proven otherwise. Validate all input
• Centralize your approach by using common validation and filtering code in shared libraries
• Look for valid data and reject everything else
• Do not rely on client-side validation
  • It s very easy for hackers to disable client-side validation. Always validate data on the server before committing it to a database.
• Be careful with canonicalization issues
  • Only execute files under the cgi directory (C:\inetpub\wwwroot\cgi-bin)
    • C:\inetpub\wwwroot\cgi-bin\..\..\..\Windows\System32\cmd.exe
• Constrain, reject, and sanitize your input with
  • Type checks
  • Length checks - Invalidate input that is too large
  • Range checks
  • Format checks

One of the most powerful ways to constrain data input is through validation controls and regular expressions

Some good references on the Microsoft site for input validation include

• How To: Protect From Injection Attacks in ASP.NET
• How To: Use Regular Expressions to Constrain Input in ASP.NET
• How To: Protect from SQL Injection in ASP.NET
• How To: Prevent Cross-Site Scripting in ASP.NET

Code Injection

A frequent security concern with input is code injection and cross site scripting. A good Web paper addressing the subject is HTML Code Injection and Cross-site scripting.

The .net platform provides HttpUtility.HtmlEncode(string) as a way to prevent malicious scripts from being displayed in the browser.

Hands-on Exercise

• Create a new Website on your desktop named Day37
• Add the following code to your Default.aspx page to display a textbox, button, and label

• Add an event handler to the button control to display "Hello ... " when the user clicks it, placing the content of the textbox in the label.
• See what happens when the user types into the textbox a JavaScript snippet

 <script>prompt('Please enter your password')</script>

By default, ASP.NET protects against Cross Site Scripting code injections via text boxes. For purposes of illustration, or if you want to allow users to be able to enter script, you can set the validateRequest property in your Page directive to false.

• Set ValidateRequest="false" in the Page directive and reload your page

validateRequest="false"

To protect against this type of risk use

  HttpUtility.HtmlEncode(TextBox1.Text)

Microsoft Microsoft Released a new Anti-XSS tool that follows an accept-only approach. That is, instead of filtering out bad input,this tool accepts only a finite set of valid input and everything else is considered invalid.

To use the tool in your project, you will need to download and include the AntiXSSLibrary.dll in the bin folder of your project.

In How To: Prevent Cross-Site Scripting in ASP.NET there are two things that need to be done:

1. Verify Input - Constrain the acceptable range of input characters using regular expressions
2. Encode Input - Use HttpUtility.HtmlEncode when generating html elements based on user input

SQL Injection

SQL injection can occur when an application uses input to construct dynamic SQL statements or when it uses stored procedures to connect to the database. In How To: Protect From SQL Injection in ASP.NET, Microsoft recommends

1. Constrain Input
2. Use Parameters with Stored Procedures or
3. Use Parameters with Dynamic SQL

To give you a feel for this, add a simple one table SQL Server express database to your website and use it to store usernames and passwords.

• Add two textboxes, one for username and the other for password
• Add a button for the user to login
• Add a label under your button to verify that the user is logged in. Use the following bad code to authenticate a user.

To hack into this login page, use

  hacker' or 1=1;-- 

Configuration Management

Configuration files, such as the Web.config, are often used to hold sensitive information, including user names, passwords, database connection strings, and encryption keys.

If you do not protect this information, your application is vulnerable to attackers or malicious users obtaining sensitive information such as account user names and passwords, database names and server names.

Encrypting and decrypting data incurs performance overhead. To keep this overhead to a minimum, encrypt only the sections of your configuration file that store sensitive data.

.NET 2.0 includes Aspnet_Regiis.exe tool that uses the Windows Data Protection API (DPAPI) to encrypt sections of your configuration file. ASP.NET automatically decrypts configuration sections when processing them; therefore, you do not need to write any additional decryption code.

To encrypt the connectionStrings section of Web.config stored at u:\Day37, use the command line promt to change directories to cd C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727 using the correct .NET Framework version number. then type

  aspnet_regiis.exe -pef "connectionStrings" u:\Day37

which changes

into

Detailed instructions are available at How To: Encrypt Configuration Sections in ASP.NET 2.0 Using DPAPI

More information is available at Encrypting Configuration Information in ASP.NET 2.0 Applications

Encryption through code

Rather than using the aspnet_regiis.exe tool, you can also do this through code.

See Encrypt Connection Strings AppSettings and Web.Config in ASP.NET 2.0 - Security Best Practices