Building Secure Web Services

An Introduction to Threat Modeling

You probably want to get right to the meat of how to build secure systems. But unfortunately, we need to first discuss the design phase because when software is designed in random fashion, security is often a victim of the chaos. One way to provide structure during the design phase is to create a threat model.

The principle behind threat modeling is that you cannot build secure systems unless you understand the threats to the application. The good news is that threat modeling is simple and enjoyable. As a bonus, it can form the basis of the security section of the design specifications! In my experience, services built with the aid of a threat model tend to have better-designed security features and thus more secure systems. So stick with me for a short while—it will be worth the effort.

It is important that you spend time doing threat modeling because it is cheaper to find a security design bug at the design stage and remedy it before coding starts. The threat modeling process has the following three main phases:

  1. Brainstorming threats

  2. Choosing techniques to mitigate the threats

  3. Choosing appropriate technologies to apply the techniques

Let's look at each part of this process in turn.

Brainstorming Threats

A brainstorming meeting involves setting aside two or three hours for the development team to discuss areas of potential vulnerability. During the meeting, have someone draw up the proposed architecture on a whiteboard. Make sure the diagram covers all critical aspects of the Web service, including:

  • Data storage technologies (file storage, SQL databases, XML files, and registry)

  • Interprocess communication techniques (including RPC, .NET Remoting, and sockets)

  • User input techniques (SOAP arguments and HTTP messages)

  • Nonpersistent data (such as on-the-wire data)

Next you look at how each of the core components can be compromised. One method is to use the STRIDE threat modeling technique.

Employing the STRIDE Threat Model

Before you build your systems, it is often useful to ask questions such as the following:

  • How can an attacker hijack the online shopping cart?

  • What would be the impact of an attacker denying valid users access to the service?

  • How could an attacker view or change the data traveling from the service to the consumer?

One way to make sure you ask all the important questions is to use threat categories. In this case, we will use the STRIDE threat model. STRIDE is an acronym derived from the following six threat categories:

  • Spoofing identity Identity spoofing often means illegally accessing and then using another user's authentication information, such as username and password.

  • Tampering with data Data tampering involves malicious modification of data. Examples include making unauthorized changes to persistent data, such as that held in a database, and altering data as it flows between two computers over an open network such as the Internet.

  • Repudiation Repudiation occurs when users deny performing actions without other parties having any way to prove otherwise—for example, a user performing an illegal operation in a system that lacks the ability to trace the prohibited operation. Nonrepudiation is the ability of a system to counter repudiation threats. For example, if a user purchases an item, he might have to sign for the item upon receipt. The vendor can then use the signed receipt as evidence that the user received the package. As you can imagine, nonrepudiation is extremely important for e-commerce. The simplest way to think about repudiation is to utter the words “It wasn't me!”

  • Information disclosure Information disclosure threats involve exposure of information to individuals who are not supposed to have access to it—for example, a user being able to read a file for which she was not granted access or an intruder's ability to read data in transit between two computers.

  • Denial of service Denial of service (DoS) attacks deny service to valid users—for example, by making a Web server temporarily unavailable or unusable. You must protect against certain types of DoS threats simply to improve system availability and reliability.

  • Elevation of privilege In this type of threat, an unprivileged user gains privileged access and thereby has sufficient access to compromise or destroy the entire system. Elevation of privilege threats include situations in which an attacker has effectively penetrated all system defenses and has become part of the trusted system itself—a dangerous situation indeed.

If you look back at the three example questions noted earlier, you will notice that the first question concerns a data-tampering threat (T), the second one concerns a DoS threat (D), and the third concerns an information disclosure threat and a tampering threat (I and T).

The simplest way, by far, to apply the STRIDE model to your application is to consider how each type of threat will affect each solution component and each component's connections or relationships with other solution components. Essentially, you look at each part of the application and determine whether any S, T, R, I, D, or E threats exist for that component or process. Most parts will have numerous threats—be sure to record all of them.

Choosing Techniques to Mitigate the Threats

The next step is to determine appropriate mitigation techniques. Table 10-1 outlines some techniques and technologies for mitigating threats in the STRIDE categories.

Table 10-1  Threat Mitigation Techniques 

Threat Type

Mitigation Technique

Spoofing identity

Authenticate principals using technologies such as basic authentication, digest authentication, NTLM authentication, Kerberos authentication, X.509 certificates, .NET Passport authentication, and forms-based authentication. Remember that sometimes you need to authenticate the client, and at other times you need to authenticate the server.

You can also prove that data came from a principal by signing and verifying digital signatures, such as those employed by XMLDSIG and PKCS #7. These are both explained later in this chapter.

Do not store secret data insecurely, especially authentication data such as passwords and PINs.

Tampering with data

Protect data with appropriate Access Control Lists (ACLs) or permissions. Determine whether data has been tampered with using hashes or message authentication codes. Protect on-the-wire data using SSL/TLS or IPSec.

Repudiation

Protection from repudiation often involves strong authentication and signed data, as well as extensive and secure logging or auditing.

Information disclosure

Data can be protected from prying eyes using appropriate ACLs and permissions. Also, consider that if you do not store the data in the first place, the data cannot be disclosed. Privacy techniques such as encryption can help if the keys used to encrypt and decrypt the data are also protected from disclosure threats. SSL/TLS and IPSec provide on-the-wire secrecy, and Encrypting File System (EFS) provides privacy for files and directories.

Denial of service

DoS threats are difficult to defend against because it is difficult to tell whether a busy server is simply busy or is under attack. If you throttle user requests, you might lock out access to valid users. Some simple defenses include limiting what nonauthenticated users can do. For example, you might allocate 10 percent of resources for anonymous users and 90 percent for validated users. (Resources include cache data, CPU time, disk space, network bandwidth, and connections to databases.)

Some of these solutions are beyond your direct control in an application and might include firewalls and packet-filtering routers.

Elevation of privilege

Do not require privileges or permissions you do not need. That way, if your code has a security flaw and the attacker can execute malicious code or cause an insecure event to occur, he cannot cause much damage because the permissions are suppressed.

A Web Service Example

If all of this makes little sense to you so far, do not worry. An example will help. Let's look at a simple scenario in which a Web service client communicates with a Web service, which in turn communicates with a database and returns content to the client, as depicted in Figure 10-1. We will assume that the client is a user, not a peer process.

Figure 10-1 A sample Web service scenario.

This generic scenario applies to many Web services. Table 10-2 lists some of the threats to the system and how they can be mitigated.

Table 10-2  Threats to Web Services and Appropriate Mitigation Techniques

Target

ID

Threat Types

Description

Mitigation Techniques

Web service

1

S

Attacker knocks out Web service using distributed DoS attack and places his own rogue Web service on the Internet. The client application does not know that it is communicating with a rogue.

Use a client-initiated SSL/TLS connection to authenticate the server.

On-the-wire data from client to service

2

T and I

Attacker views or modifies data en route from the client to the server and vice versa.

Use SSL/TLS or IPSec to encrypt data as it travels to and from the Web service.

On-the-wire data from client to service

3

E

Attacker views password data en route from the client to the server; if the user is an administrator, the attacker can use the username and password.

Use an authentication mechanism that does not pass the password in the clear across the wire, or use SSL/TLS or IPSec to protect the channel.

Web Service

4

D

Attacker floods the Web service with thousands of bogus requests and slows down the Web service.

Use a firewall to restrict what data is allowable. Build logic that limits how much data can be sent by one user or IP address. Limiting by IP address can be problematic, however, because many legitimate users use ISPs that have a limited number of IP addresses, so numerous requests might appear to come from the same IP address when they are in fact coming from users behind a proxy server.

SQL Server data

5

T and I

Attacker accesses data in SQL Server directly rather than via the Web service.

Limit what is allowable in data used to construct SQL queries.

SQL Server

6

S, T, R, I, D, and E

Attacker uses the xp_cmdshell extended stored procedure built into SQL Server to call malicious code at the SQL database. This command can call any command at the server.

Limit what is allowable in data used to construct SQL queries. Remove unused extended stored procedures such as xp_cmdshell. Do not connect to SQL Server as the sysadmin account (sa) because this account can perform any SQL Server task, including calling xm_cmdshell.

This scenario should help you understand the process for determining what techniques and technologies to employ to build secure solutions. This approach is much better than simply sprinkling “magic security pixie dust” on an application and hoping that the application will be secure from attack.

Now let's turn our attention to the panoply of security technologies available to developers who build Web services on the Windows platform.

 

You can learn more about threat analysis and building secure systems in Writing Secure Code by Michael Howard and David LeBlanc (Microsoft Press, 2001).

 



Building XML Web Services for the Microsoft  .NET Platform
Building XML Web Services for the Microsoft .NET Platform
ISBN: 0735614067
EAN: 2147483647
Year: 2002
Pages: 94
Authors: Scott Short

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net