ASP.NET

ASP.NET is Microsoft's successor to the Classic ASP platform; it provides the Web Services component of the .NET framework. The .NET framework is a language-independent virtual machine and a set of associated libraries. It's similar in many ways to the Java platform; both are platform-independent virtual machine environments, provide robust code access control, and have extremely rich default libraries. In practice, you can leverage a lot of the same techniques with both Java and ASP.NET, although naming and certain conventions differ. In particular, .NET provides the Common Language Runtime (CLR), which supports a variety of languages, so a source review of a .NET application might require knowledge of several languages. Fortunately, the most popular .NET languages are C# and VB.NET, which are similar to Java and Visual Basic, respectively. You will also want to be familiar with Classic ASP, as many of its conventions and potential security issues are share with ASP.NET.

SQL Injection

The .NET runtime provides the System.Data namespace for interacting with all data sources (collectively referred to as ADO.NET). A connection to a data source is generally established by using the SQLConnection class in the System.Data.SqlClient namespace, although a database-specific connection can be used, such as the OracleConnection class from the System.Data.Client namespace. The semantics are essentially the same, so this section sticks with the basic provider.

After the connection is established, queries can be issued in a number of ways. The safest approach is to use parameterized SQL via the SqlCommand and SqlParameter classes. This approach follows the same general structure of parameterized queries discussed in Chapter 17. Here's an example of a parameterized query in C#:

SqlCommand cmd = new SqlCommand(     "SELECT * FROM table WHERE name=@name", cn); cmd.CommandType= CommandType.Text; SqlParameter prm = new SqlParameter("@name",SqlDbType.VarChar,50); prm.Direction=ParameterDirection.Input; prm.Value = userInput; cmd.Parameters.Add(prm); SqlDataReader rdr = cmd.ExecuteReader();

This code fragment runs the parameterized command and attaches the result set to the data reader. It's a fairly common approach to SQL in .NET. However, here's a much shorter approach to the same statement:

SqlCommand cmd = new SqlCommand(     "SELECT * FROM table WHERE name='" + userInput + "'", cn); cmd.CommandType= CommandType.Text; SqlDataReader rdr = cmd.ExecuteReader();

This second statement is obviously vulnerable; the parameters aren't bound, and an attacker could supply SQL metacharacters for input. However, it still uses the same SqlCommand class as the parameterized query, so you need to make sure you look for any dynamic input in the query string.

File Access

Input and output are handled by the System.IO namespace, but you need to watch for other possible mechanisms. Like Java, .NET is an extensible language, and developers make use of various frameworks and wrappers. You can do simple searches for common file variable names, as suggested in the Java section. You can also look for calls to the path-handling methods of the Request object, especially Request.MapPath() and Request.MapPathSecure(), which are used to translate relative paths in the server context.

Another consideration is that the vast majority of ASP.NET applications are on Windows systems (although the Mono project and DotGNU do produce cross-platform implementations). Therefore, you need to be aware of Windows file-handling quirks (discussed in Chapter 11, "Windows I: Objects and the File System").

Shell Invocation

The Process class from the System.Diagnostics namespace is used for running and controlling other processes. By default, this class calls the appropriate shell handler based on the extension of the provided filename, so it is very similar to the ShellExecuteEx Win32 function. For example, this function calls cmd.exe if a file named test.bat is passed to it. This behavior can be controlled by setting the UseShellExecute property to false in the ProcessStartInfo class passed to Process.Start(). Here's a simple example of starting a batch file with a manually supplied command shell:

ProcessStartInfo si = new ProcessStartInfo("cmd.exe"); si.Arguments = "/c test.bat" si.UseShellExecute = false; Process proc = Process.Start(si);

However, here's an example that executes the file the using the default batch file handler:

Process proc = Process.Start("test.bat");

The file extension is particularly important when starting a process, unless the ProcessStartInfo is set explicitly. Attackers who can manipulate the filename might be able to leverage this to start entirely different applications or force the interpretation of shell metacharacters.

File Inclusion

ASP.NET is like Java, in that it doesn't allow dynamic inclusion of script files. Files can be included, however, via this preprocessor directive:

<!--#include file="inc_footer.aspx"-->

Of course, a vulnerability that allows a file to be written to the Web root could result in a dynamic execution vulnerability. Also, ASP.NET supports the Server.Transfer() and Server.Execute() methods provided by Classic ASP, so the security issues in the Classic ASP discussion also apply. Finally, there are situations that make it possible for developers to implement their own dynamic include capabilities, discussed in the next section.

Inline Evaluation

The .NET framework is language independent, so it doesn't quite support direct script evaluation. However, the System.CodeDom.Compiler namespace includes CodeProvider classes for common languages, such as C# and VB.NET. Using this namespace, developers can implement an inline evaluation routine fairly easily by just compiling and running the source code programmatically. Oddly enough, you might actually see this approach in production Web code, so you need to watch for any use of the System.CodeDom.Compiler namespace.

Cross-Site Scripting

ASP.NET prevents cross-site scripting attacks with the same basic filtering mechanisms as Classic ASP, including the Server.HTMLEncode() function for normal HTML and the Server.URLEncode() function for URLs. ASP.NET also provides some extra protection by explicitly denying requests containing the < and > characters; this behavior is controlled via the ValidateRequest page attribute. Some page controls also escape script data, although you will need to consult the documentation for each control to determine its exact behavior.

Configuration

ASP.NET applications are configured by using the web.config file at the root of the application directory. This file can override some settings in the global machine.config file found in the CONFIG subfolder of the .NET framework installation directory. The web.config file includes settings for application-wide authentication, ViewState security, server runtime parameters, and a variety of other details. The MSDN provides extensive information on details of the web.config file, but the following sections touch on a few important points.

ViewState

The ViewState, stored in a client-side cookie, contains information on form parameter content, control status, and other display-specific information. By default, ViewState is protected with a secure message digest by using a secret in the validationKey attribute of the machineKey field in web.config. However, some controls can be bound to data sources that reveal column and table names along with other potential database schema. To address this problem, ViewState can also be encrypted by setting the validation attribute to AES or DES and providing a value for decryptionKey. If ViewState isn't encrypted, you can use one of many ViewState decoder tools to search for interesting information (a ViewState decoder is available from www.pluralsight.com/tools.aspx). The following simple ViewState section requires both authentication and encryption for all pages:

<pages enableViewStateMac="true" ... /> <machineKey validationKey="AutoGenerate,IsolateApps"             decryptionKey="AutoGenerate,IsolateApps"             validation="SHA1" decryption="AES" />

Access Control

ASP.NET allows an application to set sitewide access control enforced by the runtime engine. One of the most popular types of authentication is forms-based authentication; here's an example of a forms-based authentication section in web.config:

<authentication mode="Forms">     <forms  name="AuthLogin"             loginURL="login.aspx"             protection="All"             timeout="1200"             path="/" /> </authentication>

This code causes a request from an unauthenticated user to be redirected to login.aspx. This page can then process the login and, if needed, forwards the user to the original URL on success.

The login page is generally the first page you want to examine in an ASP.NET application. Often, developers include backdoor mechanisms for testing purposes or Web service requests, or the login could simply have vulnerabilities of its own.

Authorization

The authorization section of the web.config file can also contain useful information and be used to restrict request methods, users, groups, and roles. Typically, you see a small number of roles to separate normal and administrative users. Here's a typical authorization section for a Web application's administrative interface:

<authorization>     <allow roles="Administrator"/>     <deny users="?" /> </authorization>

The location tag can also be used to limit the scope of the authorization section. For example, you could wrap this section in a location tag that includes only the administrative page or directory.

AppSettings

The appSettings section of the web.config file can be used to provide application-specific parameters. They are passed as simple key value pairs and retrieved later by using ConfigurationSettings.AppSettings(). These parameters can be important to how the application performs, so make note of them and see where they're used in the code. In particular, database and middleware connection information is often stored in this section. Here's an example of an appSettings section of the web.config file:

<appSettings>     <add key="myparam" value="testval" /> </appSettings>