Analyze for Threats

You should go through the following process when performing a threat analysis of your application:

• Allocate time for the threat analysis.

• Plan and document your threat analysis.

• Create a laundry list of threats.

• Prioritize threats.

Allocate Time

There comes a time when you need to release your application. Although it would be fantastic if you could spend as much time as necessary to identify threats and fortify your application against all conceivable threats, practical constraints such as time and cost limit the extent of what you can reasonably do.

Fortunately, talk is cheap. The threat-analysis phase mostly involves talk along with drawing some architectural diagrams. The developer in charge, testers, and any security-savvy personnel related to the features being discussed should meet to perform the threat analysis. A small team of people should be able to generate a list of threats rather quickly by looking at architectural diagrams. Cost should not be an issue when it comes to generating a list of threats.

Cost, however, does become a significant issue when

• You perform a threat analysis against an existing project for which code has already been written and for which a threat analysis has never been done.

• You implement the changes needed to make your application more attack resistant.

Cost is significant for existing projects (not involved in ongoing threat- analysis reviews) because as part of the threat analysis you need to review existing code to ensure it is safe from attack. In addition, if serious security issues are found in existing projects, you might need to spend a considerable amount of time fixing these problems—problems you might have otherwise avoided if the threat analysis had been performed before the code was written. You can see then that if you’re starting a new project where code has not yet been written, it pays to perform a threat analysis up front using the proposed product specification as a basis for the analysis. The more you incorporate up front the cost of making your application more secure before developing (writing code for) the application, the more time and money you’ll save down the road.

Prioritize Analysis Based on the Function of Each Component

Clearly some components in your application might be at a greater risk than others, depending on the purpose of the component. For example, a component that is accessible and called from the Internet or across the network is generally more at risk than a component used internally by the application, such as an internal math library component. Components at greater risk should be given a higher level of scrutiny. For example, you should perform a full-threat analysis by reviewing the application design, architecture, and code (if it’s written). For low-risk components you might decide no threat analysis is needed, or you could limit your threat analysis to a cursory inspection of the Public methods exposed by the component.

Plan and Document Your Threat Analysis

You should create a document as part of your threat analysis. The document should include a plan on how you will conduct the threat analysis—including the team members involved, the analysis approaches used, a proposed schedule, and comments indicating what analyses won’t be done because of cost or other priorities.

As you go through the threat-analysis process, include in the document a high-level architectural diagram of your application, the list of threats identified for each component, and a summary of the vulnerabilities uncovered in your application. This information will come in handy in the future when you add new features to the application. A review of the threat analysis might help to create a more secure feature based on threats already identified.

Create a Laundry List of Threats

You can use a number of techniques to generate an exhaustive list of threats. Some useful techniques include:

• Drawing an architectural sketch of your application, and evaluating components that make up your application, relationships between the components, and inputs accepted by the components

• Reviewing the specification or code for the application

Draw Architectural Sketch and Review for Threats

You should meet with the relevant members of your team (as mentioned in the preceding section)—preferably in a room with a whiteboard—and draw an architectural diagram of your application. The diagram should include the major components (.EXEs and .DLLs) that make up the application, with lines drawn between the components to indicate communication or data flow between them. If you’re working on a large project, each feature team for the project can create a diagram limited to the components that make up the feature they are evaluating—although a separate team should also look at the broad application diagram to ensure that no threats are overlooked by the feature teams.

Figure 15-1 is an example of an application design diagram for the completed employee management system Web sample application. The diagram focuses on the logon scenario for the application. You should create one or more similar diagrams for your application. You don’t need to create anything fancy. Sketch the design diagram on a piece of paper or whiteboard, and use it as the basis for generating a list of threats.

Figure 15-1: Employee management system Web design diagram for user logon scenario

Figure 15-1 shows the logon user interface (UI) displayed in an Internet browser having an HTTP connection to the ASP.NET server application. When the user logs on, the user name and password is sent from the client browser to the employee management system Web ASP.NET server application.

You should think like an attacker and come up with all ways that you would try to compromise the application. Based on this diagram, what threats do you see? What would an attacker try to do? Here are some suggestions to get you started:

• The password for a user could be cracked, allowing an attacker to log on as that user.

• An attacker could attempt to log on for another user more than the number of times allowed by the application’s security settings to prevent the user from logging on for the designated period of time. For example, suppose your application is designed to lock a user account after 3 unsuccessful logon attempts.

• The attacker could try entering SQL or VBScript in the user name and password fields to cause a SQL-injection or cross-site scripting attack. For example, if the user name is shown as part of the error message, this could lead to a cross-site scripting attack as discussed in Chapter 6.

• An attacker could intercept the user name and password being sent over the HTTP connection between the client and the server and then log on as that user.

• The attacker could attempt to turn off script to prevent client-side validation of input.

• An attacker could view the HTML file in the browser to try to find comments that reveal the directory structure of the application or the back-end database being used.

• If a cookie is used to log on (as is the case when the “Log me in automatically” check box is selected), the attacker could try to intercept the cookie to log on as the user whom the cookie is assigned to. By doing so, the attacker could log on as that user without having to know that user’s name or password.

• The attacker could attempt to connect directly to the Internet Information Services (IIS) Web server that hosts the employee management system Web ASP.NET application to gain direct access to files such as the Web.Config file or the back-end database.

As this list illustrates, when identifying threats it’s not so important to answer questions such as, “Is my Visual Basic .NET application protected against this threat?” In some cases, your Visual Basic .NET application will be sufficiently protected. In some cases, it might not be. In fact, the employee management system (with security improvements having been added in previous chapters) is protected against many of these threats. The point of the exercise is to quickly enumerate all the things an attacker might try to compromise your application or server.

Review Code for Threats

A design diagram as illustrated in Figure 15-1 is helpful for taking a component- level view of your application to identify threats to your Visual Basic .NET application, server, computer, and network. You should also consider taking a close-up view of your application by looking at your code. An effective technique involves scanning your code for Visual Basic .NET methods or keywords that indicate your application is exposed to a threat. An example of this is code that uses the keyword Open to open a file. You should examine the code around the Open statement to see whether you are passing nonvalidated user input to the Open statement. If the user input is not validated, an attacker could include relative directory paths such as “..\..” as part of the input to open any file on your computer. If the application is run on the server, this could provide a means for an attacker to discover information about your computer.

As a quick check of your code, look for the keywords listed in Table 15-1.

Table 15-1: Visual Basic .NET Keywords to Look For_ (continued)

Visual Basic .NET Keyword	Description
ChDrive, ChDir, MkDir, RmDir	If user input is allowed to participate in any of these commands, an attacker could possibly glean information about the directory structure where the application is running from or he could add or remove directories on the computer.
Create	This keyword relates to any number of uses, the most popular uses being file, registry key, and process creation.
Declare	Carefully scrutinize all Windows API functions declared by means of the Declare statement you’re using within your application. In particular, look for the usage of the API functions you’ve declared where you pass a string buffer to ensure that a buffer overrun does not occur.
Delete	Generally, this is a dangerous command that is used in a number of situations, such as file, database, and registry-key manipulation.
Dir	The Dir command enumerates files and directories on the computer. Check your use of the Dir command to make sure file or directory details are not accessible to an attacker. For example, if you enumerate the files in a directory, add the files to a collection, and return the collection as part of a Public method on a class library, an attacker might be able to call the Public function in an unexpected way to obtain information about the server computer where the application is running.
Environment	When code contains the Environment keyword, it’s an indication that the code might be using environment variables as input. Consider possible threats related to an attacker changing environment-variable values to unexpected values. You should apply input-validation techniques to environment- variable input, as presented in Chapter 7.
Execute	Execute is generally used to execute SQL queries. Check the SQL string to make sure that any user input passed as part of the SQL string has been properly validated.
Kill	This statement deletes files. As implied by the name, this statement is inherently dangerous to have in your code. Check all calls to Kill to make sure a user cannot supply input.
Open	The Open statement is used to open any number of resources, such as a file or database connection. Check how all Open statements in your application use input to open a file or device; or how related statements (such as Read and Write) appearing after the Open statement handle data read in or written to a file or device. In particular, check to make sure an attacker cannot supply input used as a parameter to the call to Open. Also make sure Open cannot be called on multiple resources or the same resource to force a denial of service attack. There should be an associated Close statement that gets executed even if an error occurs.
Params, QueryString, Form	The Params, QueryString, and Form collections are found with the ASP.NET Request object. These collections represent a set of unchecked input to your application—although Visual Basic .NET 2003 offers automatic protection against cross-site scripting attacks. Make sure you validate all values in the collection before you use them.
Public	This keyword forces you to look at all publicly exposed methods. Any methods that are meant for internal purposes only should be changed to Friend or Private to reduce the application attack surface.
Reflection, Type, Assembly	These commands are generally used to explore an application and look at the types and attributes exposed by it. One potential threat is that if you expose a publicly accessible class member (or function return value) of a type such as Assembly, Type or Reflection, an attacker could use the publicly accessible class member (or function return value) to learn more about the structure of your application. This is an example of a problem where the application elevates the caller’s privileges by providing information the caller shouldn’t have access to.
Shell, Start	Either of these commands generally indicates a new application or thread is being launched. Make sure a person cannot supply input to arbitrarily launch applications such as Format or Delete. If Start is used with the Thread object, carefully review your code for threading issues. In particular, check your code to make sure an attacker could not cause an unlimited number of threads to be created and to run. Also make sure an attacker could not manipulate the application by using multiple clients or requests to cause a thread-lock condition, where each thread is waiting for the other to release a lock. Either of these problems can lead to a denial of service (DoS) attack.

Prioritize Threats

Once you’ve created an exhaustive list of threats, you need to prioritize the threats to determine which ones you’re going to address. The threats should be prioritized by the likelihood of an attack combined with the severity of the threat. In addition, you need to factor in the degree to which the application is vulnerable to the threat.

Let’s take the list of threats shown previously, associate a priority value for each threat, and arrange the threats by priority. For example, you could create a threat-priority scheme having values of 1 to 3, where priority 1 threats are the most pressing issues that must be fixed. Table 15-2 defines each level of threat.

Table 15-2: Priority Scheme

Priority	Meaning
1	Ranks high in likelihood to occur, severity, and vulnerability. These are must-fix issues.
2	Moderate risk in terms of the likelihood to occur, severity, and application vulnerability. These should be fixed.
3	Low in likelihood to occur, severity, and application vulnerability. You can ship your application without fixing these issues.

Table 15-3 demonstrates how, using the employee management system Web sample application, you might tabulate the threats from your brainstorming sessions and assign priority values to each threat. In addition, comments regarding each threat to the employee management system application are listed in the table. You should provide similar comments when performing a threat analysis of your own application. You should add comments (as shown in the table) that help to explain the threat level you’ve chosen for each threat.

Table 15-3: Prioritize Threats for the Employee Management System_ (continued)

Threat	Priority	Comments
The password for a user could be cracked, allowing an attacker to log on as that user.	1	In the current state, the employee management system uses extremely weak passwords. In fact, the passwords match the usernames. The application should be changed to support a strong password policy.
An attacker could intercept the username and password being sent over the HTTP connection between the client and the server, allowing the attacker to log on as that user.	1	The employee management system application is vulnerable to this attack if the username and password are sent over an unencrypted HTTP channel—as is currently the case. The application should be set up to use Secure Sockets Layer (SSL) to protect the username and password sent from client to server. See Chapter 5 for more information on setting up SSL.
The attacker could try entering SQL or VBScript in the username and password fields to cause a SQL-injection or cross-site scripting attack. For example, if the username is shown as part of the error message, this could lead to a cross-site scripting attack as discussed in Chapter 6.	1	Based on how the employee management system application uses the passed-in username to look up the password in a database by means of a SQL statement, there is a good chance that it is susceptible to a SQL-injection attack. See Chapter 6 for ways to mitigate this threat.
The attacker could attempt to connect directly to the IIS Web server hosting the Visual Basic ASP.NET employee management system application to gain access to files such as the Web.Config file or to gain access to the back-end database directly.	1	Depending on how the server running the employee management system application is configured, you might need to lock down the IIS server and back-end database as described in Chapter 11 and Chapter 12.
If a cookie is used to log on to the employee management system application (as is the case when the “Log me in automatically” button is pressed), the attacker could try to intercept the cookie to log on as the user who the cookie is assigned to. By doing so, the attacker could log on as that user without having to know that user’s name or password.	1	Although ASP.NET encrypts the cookie stored by the client, an attacker could still make use of the encrypted cookie (without knowing its contents) to log on as the user based on this cookie. To help prevent an attacker from intercepting a cookie, you should pass the cookie in the context of an SSL connection as presented in Chapter 5.
An attacker could view the HTML file in the browser to look for comments that reveal the directory structure of the application or back-end database being used.	2	Currently the employee management system application does not include any questionable information in comments. This scenario should be reviewed on an ongoing basis if comments are ever added to the logon page (or any other Web page for that matter).
The attacker could attempt to log on for another user more times than the system’s security settings allow to prevent the user from logging on for a designated period of time.	3	The employee management system application is not vulnerable to this form of attack because it does not lock user accounts.
The attacker could attempt to turn off script to prevent client-side validation of input.	3	In the case of the logon scenario, the employee management system application does not rely on client-side validation for anything.