ASP

Active Server Pages (ASP or Classic ASP) is a popular Microsoft technology for server-side scripting of Web applications. The program code is embedded in the HTML page within special tags, and a server-side parser evaluates the code as the page is displayed. The actual language can be any ActiveScript-compliant language, including VBScript, JavaScript, and PerlScript. In practice, however, VBScript is the most common choice, so this discussion focuses on that language.

ASP is primarily intended to function as a presentation tier in enterprise web applications. The Microsoft Distributed Network Architecture (DNA) 1.0 guidelines recommend COM objects for any logic tiers. They are generally implemented in Visual Basic or C++. However, many small- to medium-sized applications are developed entirely in ASP.

ASP auditing comes pretty naturally to anyone familiar with PHP or JSP. The general structure and techniques are very similar, and the major differences are just language and platform semantics.

SQL Injection

Database access in ASP is typically performed using ActiveX Data Objects (ADO). You want to look for three main objects: Connection, Command, and RecordSet. The Connection object represents a full connection to an external database. It has an Execute() method that runs a SQL query on that connection and returns a RecordSet. The following code shows the most common way SQL queries are performed with the Connection object:

    user = Request.Form("username")     Set Connection = Server.CreateObject("ADODB.Connection")     Connection.Open "DSN=testdsn; UID=xxx"     sqlStmt = "SELECT * FROM users WHERE name= '" & user & "'"     Set rs = Connection.Execute(sqlStmt)

Developers can also use an ADO Command object, which is more flexible for stored procedures and parameterized queries. With this approach, users set properties in the Command object to tell it which connection to use and what SQL query it should run. The SQL query runs when the Command object's Execute() method is called. This process is demonstrated in the following code:

  set cmd = Server.CreateObject("ADODB.Command")   Command.ActiveConnection = Connection   querystr = "SELECT * FROM users WHERE name='" & user & "'"   cmd.CommandText = querystr   Command.Execute

A third common way to run a SQL query is for the application to create a RecordSet object and then call the Open() method, as shown in the following code:

  user = Request.Form("username")   querystr = "SELECT * FROM users WHERE name='" & user & "'"   Set rs = Server.CreateObject("ADODB.Recordset")   rs.Open querystr, "DSN=testdsn"

All three of these types of statements are vulnerable to SQL injection attacks when handling user supplied data, so you should look for any instances of their use. ADO also supports parameterized queries via the Command object. You can identify these queries by the ? placeholder in the query string and the use of the CreateParameter() method to add bound parameters.

For the sake of thoroughness, when auditing an ASP application for SQL problems, you will also want to search for specific strings to try to find all the database interaction code. Good search candidates are SQL substrings, such as INSERT, SELECT, or WHERE, as well as methods that manipulate the database, such as Execute() or Open().

File Access

ASP access to the file system is usually performed with the Scripting.FileSystemObject object, which defines a number of methods for standard file manipulation tasks, such as creating, deleting, reading, writing, and renaming files. When performing a security audit, examine every use of the FileSystemObject, as most of the methods have security consequences if user input is involved. Here's an example of a problem-prone attempt to write a file with the CreateTextFile() method:

username = Request.Form("username") path = server.MapPath("/profiles/") Set objFSO = Server.CreateObject("Scripting.FileSystemObject") Set objFSOFile = objFSO.CreateTextFile(path + "\" + username)

This example is vulnerable to a direct path traversal attack, allowing an attacker to create an arbitrary text file on the system. The NUL-byte issue affects ASP code as well, so attackers can easily circumvent code that appends a suffix or file extension to a user-supplied filename. This code also demonstrates a good method for identifying locations that handle user supplied paths. The Server.MapPath() function is commonly used when manipulating file paths. It's responsible for converting a path in the Web tree into a real physical drive path. Therefore, it ends up being used in most code dealing with the file system, even if that code uses a mechanism other than FileSystemObject. In practice, you can find most file system manipulation code by performing a non-case-sensitive search for FileSystemObject, MapPath, and filename.

Shell Invocation

Shell invocation is not as natural of a task in ASP as it is in UNIX-based Web technologies. Typically, it's done using the Windows Scripting Host shell object, WshShell. This object provides Exec() and Run() methods; Run() starts a new Windows application, and Exec() starts a program within a child command shell and handles redirection of standard input, output, and error. Code that calls the shell is usually easy to find, as it generally has this idiom:

set objShell = Server.CreateObject( "WScript.Shell" ) objShell.Run( thecommand )

If users can manipulate portions of the command string passed to WshShell, it's likely a serious exposure.

File Inclusion

Most file inclusion in ASP code is actually done by using SSIs. Because these directives are processed before the ASP interpreter runs, it isn't possible for dynamically constructed #include statements to work. In other words, you can't write code to create a filename at runtime and then include that file by using the <!-- #include file=<> --> tag.

That said, as of IIS 5.0 and ASP 3.0, two new methods are available for directing the ASP interpreter to process other files at runtime. The Server.Execute() method calls and embeds a separate ASP in the current ASP. It works like an include function but is a bit more involved in how it preserves the object model associated with the HTTP request. Effectively, it calls another ASP page like a subroutine. The MSDN entry provides a good example, which has been modified in the following example to demonstrate a security vulnerability.

<HTML> <BODY> <H1>Company Name</H1> <%   Lang = Request.ServerVariables("HTTP_ACCEPT_LANGUAGE")   Server.Execute(Lang & "Welcome.asp") %> </BODY> </HTML>

This code attempts to open a regionally localized page by constructing a filename from the language specified by the client. So the following ASP pages would be sitting in the same directory as the main welcome page:

- EnWelcome.asp - <% Response.Write "Welcome to my Web site!" %> - DeWelcome.asp <% Response.Write "Willkommen zu meinem Web site!" %> - EsWelcome.asp - <% Response.Write "Recepcion a mi Web site!" %>

The obvious security hole is that the language isn't filtered, and users can control the argument to Server.Execute(). Because ASP is also susceptible to the NUL-byte termination issue, this means appending Welcome.asp doesn't interfere with the attacker's ability to specify arbitrary files. Note that this vulnerability is nowhere near as bad in the ASP environment as it is in PHP. In ASP, an attacker must supply a filename in the Web tree, and can't specify external files, which limits the attack somewhat. The best bet for attackers is to try to find a temporary file directory in the Web tree where they can upload a file containing VBScript. It also might be worthwhile to include other configuration and content files in the Web tree, as the ASP parser likely exposes their contents even if it doesn't see valid ASP. Often, if a system is built around ASP chaining mechanisms like this one, merely calling the wrong "inside" ASP file is enough to let attackers bypass authentication or authorization checks.

Server.Transfer() transfers control from one ASP file to another. It's different from Execute() in that it hands complete control over and stops execution of the initial ASP page. The state of the system and the objects that make up the ASP environment are maintained, and the transfer occurs totally on the server side. Other Web technologies have implemented this feature in some fashion, as it works well for separating code and presentation logic. Developers could create one ASP file that does all the work with the database and business logic. This file could populate several temporary variables with the data that needs to be displayed. If this ASP code uses Server.Transfer() to transfer control to a second ASP, the second ASP can read those variables from the runtime environment it inherited, and then its code can focus on displaying the information in a graphically appealing fashion.

Manipulation of the Server.Transfer() destination filename has more or less the same impact as with Server.Execute(). If developers mistakenly use these functions as analogues for Response.Redirect(), they can run into unexpected security issues. These methods seem to work similarly to a redirect, but they perform a full transfer of control on the server side. The impact of improper filtering with these methods can lead to running arbitrary code and disclosing sensitive files.

Inline Evaluation

VBScript is the most common scripting language used for ASP. It provides a few mechanisms for dynamic runtime evaluation of code that prove interesting for security review. Execute() takes a string containing VBScript code and runs it through the interpreter. Eval() does more or less the same thing, except it treats its string as an expression, not a statement. These function are much the same, but the separation into two functions helps resolve an ambiguity in VBScript about interpreting the = operator. In Execute(), it's used for assignment, and in Eval(), it tests for equality. VBScript also has ExecuteGlobal(), which is just like Execute(), except it runs dynamically provided code in the global namespace of the currently running application. Thus, the dynamic code can define or modify variables used by other functions.

Note the difference between this Execute() function and the Server.Execute() ASP method. This Execute() function is a VBScript language directive for dynamically interpreting code, and the Server.Execute() function is part of the ASP runtime object model/API for transferring control flow to another ASP script. If attackers can sneak metacharacter data into dynamically evaluated code for any of these methods, the results are categorically bad. They can use script code to perform whatever operations they choose or simply open a remote shell.

Cross-Site Scripting

ASP encodes HTML content using the Server.HTMLEncode() function for normal HTML and the Server.URLEncode() function for URLs. You should look for any user-malleable HTML output via other methods including Response.Write() and <% = <expression> %>.

Configuration

ASP programmers often use the .inc file extension for include files just as PHP programmers do. If the Web server isn't set up to handle the .inc file extension correctly, more often than not it just serves the include files as plain text when directly queried for them. It's usually worth checking for this error, as it's a common operational oversight.