Proof of Concept
A New Data Validation Technique
for Microsoft ASP.NET Web Applications
Foundstone Professional Services
February 2005
Introduction
Despite significant awareness of security issues like Cross Site Scripting and SQL Injection, user input remains one of the primary causes of vulnerabilities in software applications. The process of screening the user entered input for malicious content is known as data validation. The Validator.NET tool from Foundstone was created from a research and development effort by Foundstone consultants to analyze the various options available to developers building Microsoft ASP.NET applications. It offers an alternative method to traditional techniques that may have some significant advantages over techniques like web application firewalls.
Background
Data validation has been traditionally used to capture and correct mistakes by the user and improve their usability experience. Validation checks play the role of a filter on user input, helping users enter valid and correct information. Data validation can be performed both on the client end and the server.
The advantage of using client side data validation techniques includes instant feedback to the client while they enter data and a reduction of network latency due to repeated submits. However, the big disadvantage of using client side validation is that any adversary can simply bypass it and therefore client side validation provides little or no security assurance.
Server side validation is performed under the control of the server systems and is therefore difficult to bypass. However understanding what to filter and how to do it is a constant challenge for software developers.
Many authorities preach that developers should consider that all input is evil. Hackers frequently compromise software by encoding malicious content into innocuous looking input. The results are vulnerabilities such as SQL injection, path traversal and cross-site scripting.
Microsoft has provided an extensive validation framework in ASP.NET to help developers perform data validation routines faster and in a more efficient manner.
There are several technology options available to a developer to perform validation. The diagram below includes popular choices and highlights the advantages of different options as the developer implements validation closer to the code.
1. On the Web Network – also known as a web application firewall or network proxies. Despite some marketing claims with revolutionary new categories, these tools intercept HTTP traffic to the application on the network and apply rules.
2. On the Web Server – using plug-in frameworks such as ISAPI and NSAPI to capture and filter HTTP traffic to the application.
3. In the Code – also known as Validation Filters.
Web application firewalls are not the best solution since they are removed from the application and therefore have less control over the validation process. Architecturally, they are clearly in the wrong place to do the most effective job. Software must protect itself and a data stream approach on a component that is not connected to the application will not
Foundstone software security experts always recommend that clients build validation into the software code where possible. To assist this approach, Foundstone has developed the Validator.NET free tool. Using Microsoft’s .NET reflection application programming interface (API), Foundstone has developed a system that takes the binary output assembly (DLL) from an ASP.NET application and programmatically determine all of the input locations from server controls. The tool then allows the developer to apply rules to the input field which are saved in an XML rules file. This rules file can then be loaded in an HTTP Module. This is very similar to an ISAPI filter is executed by the code.
Validator.NET Features
The major features of Validator.NET include:
• An efficient way to apply effective data validation techniques to existing ASP.NET applications
• Does not require access to source code and therefore does not change source code
• Integrates with any existing ASP.NET web application
• Is composed of 2 parts
o Design Component called the Configuration Console
o Runtime Component(HTTP Module)
• Provides a centralized repository of rule set, such that those rules can be repeatedly applied to multiple controls of the application
• Allows custom rules to be written to the granularity of every control on each form
Installation Instructions for Validator.NET
Step 1
Download Validator.NET from the Foundstone web site - http://www.foundstone.com/s3i.
Before running the installation program, you must have the .NET Framework Version 1.1 or later installed on a Windows XP or Windows 2003 PC. You can download the .NET framework here:
http://msdn.microsoft.com/netframework/howtoget/default.aspx
When you double click the installation file for Validator.NET, you will be presented with an installation splash screen like the one on the following page.
Step 3
Select the Folder where you would like to install Validator.NET. The default location is C:\Program Files\Foundstone Free Tools\Validator.NET\.
Step 4
Step 5
Click close and if no errors occurred during the installation process, you will be presented with an installation complete splash screen.
What to do if the Installer Fails
The installer checks to ensure you have the .NET Framework installed and that you meet the minimum requirements for installation. If installation fails for any reason we suggest running windows Update and reinstalling the latest .NET framework.
How to Use Validator.NET
To use Validator.NET, start the tool through the start menu. The first screen the user encounters is the Configuration Console (Design Component).
The file menu has the following options:
• Open Assembly File – This option loads an existing .NET web application Assembly i.e. a “.dll” file.
• Open Project – With this option the user can open a Project that has been previously saved.
• Export Current Project – The user can save the current/existing Project using this option.
The Rule menu has the following options
• Load Rule File – with this option, the user can load an existing rule file into the project. The rule file consists of validation rules that have previously been defined. Note that this file will have a .rule extension for identification
• Create Rule File – this option is used to create a new rule file that has custom rules defined by the user using the rule creating utility as described later
The Install menu has the following options:
• Install HTTP Module - option we can install HTTP runtime validation module for an asp.net web project. The HTTP runtime module uses the rule and project file for validation
The Help menu includes the following:
• Help – Provides a user guide with instructions and examples to use the tool
• About Foundstone Validator.NET – Version, copyright and developer credits
• About Foundstone Professional Services – Background about the people who developed this tool
Open Assembly File
The next step requires you to specify the path to open the Assembly file from. For example, the tool is provided with a test web application called “FooWeb” that has a corresponding FooWeb Assembly File (.dll) as shown below:
Opening the FooWeb Assembly file would load it in the Configuration console as shown in the screen shot below:
After the Assembly file has been successfully loaded in the configuration console, a tree structure is displayed as shown in the screen-shot above. The root of the tree is the name of the application, in this case “FooWeb”.
On expanding the FooWeb tree, another set of child nodes are displayed. These are the various web forms or web pages (Details, Login, Welcome) associated with the FooWeb application.
Loading the Rule File
On selecting the “Load Rule File”, the following screen appears and shows the existing Rule files.
Click the Open button to load an already defined Rule file. Using an existing Rule file you can add the previously defined validation rules to the controls in the forms.
The screen with all the existing rules will pop up. Choose an existing rule or create a new rule. More details on creating new rules can be found in the “Defining New Rules” section of this paper.
In our example “User name”, “Email”, “Zip Code US”, etc are the already defined rules.
For example, the txtUserName control has been selected and the rule “Username” has been added to it. The new rule gets appended to the tree structure as shown in the screen shot below:
Once a rule has been added, you can activate, deactivate, delete, copy and also move the rule up or down as per the requirement. On activating (by default the rule is activated) a rule the icon is blue and when you choose Deactivate, the icon becomes red.
Defining New Rules
One of the features of the “Validation Rule Chooser” is that it allows you to define new rules. The Validator Rule Chooser is shown below:
The important thing to note here is the “Create New Rule” button. Using the Create New Rule, we can add new rules to the existing rules. On selecting the Create New Rule option, the Rule Editor screen is displayed:
This screen can be used to add/edit/delete rules. To add a new rule, click the “New Rule” button and a new pop-up dialog box appears. You are prompted to enter a new rule name, for example we are adding a new rule “US Zip Code”, as shown below:
After adding a new rule, you can add the desired Validation Classes by clicking the “Add Validation Class” button. The Validation Classes available will be displayed by clicking the button and depending on the requirement, you can choose the validation class that needs to be added for the new rule.
Once the required number of Validation Classes has been selected and the modifications made for a particular rule, you can save these changes by clicking the save icon on top of the screen. You can modify the required number of rules and then click on the Ok button resulting in the modifications being saved in a rule file.
RunTime Component of Validator.NET
ASP.NET allows extensibility features to applications. This includes processing the requests before and after being serviced by the application. This is very useful for writing custom HTTP modules to handle special case scenarios on applications. These HTTP modules can be used for writing custom authentication, authorization, and request handling routines.
For ASP.NET applications, the request passes several stages before it is serviced by the application. The first handler in line is Internet Information Services (IIS). IIS maps the ASP.NET extensions to ASPNET_ISAPI.DLL. From there the request is forwarded to the working process of ASP.NET named ASPNET_WP.EXE. The request then becomes an instance of an HTTPContext and is handled by several ASP.NET classes. Later the request is passed to the HTTPApplication which maintains the application-scope methods, data and events. HTTPApplication then pushes the request to the available HTTPModule objects.
There are several system level HTTP modules provided by ASP.NET. Some of the services provided by these modules are acquiring request state, authorizing requests, and updating request cache. The host’s machine.config and the application’s web.config settings determine the number of modules that are called.
The final link in the chain of events is the HTTPHandler object that implements the interface IHttpHandler. For every request with an ASP.NET extension, ASP.NET checks the IHttpHandler implementation in web.config file. Here it is possible to map HTTP handlers to different URIs by making corresponding changes in the web.config file.
HTTP Modules
A HTTP module implements the System.Web.IHttpModule interface
public interface IHttpModule { void Dispose();
void Init(HttpApplication context); }
The HTTP modules can be called through the configuration of web.config file. The Init and Dispose methods are called by ASP.NET at runtime after mapping the entry from the web.config file. The Init and Dispose methods provide the ability to attach the module to HttpApplication. Using these methods, the module can hook into a number of events exposed by the HTTPApplication. The developer can now implement even handlers that provide access to request before the request is processed by the application.
Foundstone uses this extensibility feature of ASP.NET to implement data validation routines for all the fields of the application. The checks are implemented based on the validation rules applied for the various input fields of the application in the design phase. The run time component uses the .rule and .project files to ensure that all fields match the input validation conditions defined.
The installation utility in the next section, places the compiled assembly into the application’s bin directory along with the rule and project file created in the design phase.
The following are the changes made in the web.config of the application.
Under the <appSettings> add
<add key="FS_HttpModule_XMLRulesDatabase" value="bin"/> <add
key="FS_HttpModule_Validator_FormMappings" value="Project XML file path
for the web project" /> <add key="FS_HttpModule_Validator_Rules"
value="Rules XML file path for the web project" />
Under the <system.web> add
<httpModules>
<add name="FS_HttpModule" type="Foundstone.FS_HttpModule, FS_HttpModule" /> </httpModules>
For complete information on the working of HTTPModules please refer http://msdn.microsoft.com/msdnmag/issues/02/05/asp/.
Installing the HTTP Validation Module
The HTTP Validation Module validates the contents of the fields in a web page using the rule and project file. The HTTP Module for a web project is installed using menu option Install->Install HTTP Module.
It launches a program which installs the HTTP Module.
Enter the path to rule file or can browse to the rule file by clicking the button next to the field.
The third field is for the path to the root folder of the web project. Here the FooWeb project is located in the webroot directory of the IIS.
Clicking the install button copies the rule file, project file and HTTP module to the bin directory of the published web project and modifies the web.config file of the web project so that the HTTP runtime validation module uses the rule files.
Installing HTTP Validation Module on a Remote Server.
To install the HTTP Module on a remote server you need to copy the following files, along with the web project.
1. Rule file created with the main console application.
2. Project file for the project created by the console application.
3. FS_HTTP runtime validation module.
4. HTTP module installer.exe file located in the directory of installation of Validator.NET.
Once the web project is published on the server, you need to follow the same steps for installing the HTTP Module for a local web project explained earlier. Here the FS_HTTPmodule.dll should be in the same directory as the “HTTP module installer.exe”. After launching the module installer program, you need to set the path to the rule file, project file and directory to the root of the web project. Once the path fields are correctly set, clicking the install button installs the HTTP runtime validation module for the web project.
About Foundstone Professional Services
Foundstone Professional Services, a division of McAfee, offers a unique combination of services and education to help organizations continuously and measurably protect the most important assets from the most critical threats. Through a strategic approach to security, Foundstone identifies, recommends, and implements the right balance of technology, people, and process to manage digital risk and leverage security investments more effectively.
Foundstone’s Secure Software Security Initiative (S3i™) services help organizations design and engineer secure software. By building in security throughout the Software Development Lifecycle, organizations can significantly reduce their risk of malicious attacks and minimize costly remediation efforts. Services include:
• Source Code Audits
• Software Design and Architecture Reviews
• Threat Modeling
• Web Application Penetration Testing
• Software Security Metrics and Measurement
For more information about Foundstone S3i services, go to www.foundstone.com/s3i.
Foundstone S3i training is designed to teach programmers and application developers how to build secure software and to write secure code. Classes include:
• Building Secure Software
• Writing Secure Code – Java (J2EE)
• Writing Secure Code – ASP.NET (C#)
• Ultimate Web Hacking
Acknowledgements
Mark Curphey, Dinis Cruz, David Raphael, Rudolph Araujo, Shanit Gupta, Seemanta Patnaik, Sanjit Rath, and Saurabh Asthana provided time, dedication, knowledge, and support to make this possible.
