Web Services and .NET

Whereas Passport does not currently have a SOAP interface, Microsoft’s .NET services already provide methods for implementing SOAP. It supports a variety of platforms and programming languages.

Framework

The .NET framework applies a sandboxing technique for application code that is reminiscent of Java. Application code falls into one of two groups: managed or unmanaged. The terms “managed” or “unmanaged” are in relation to the Common Language Runtime (CLR). Managed code, as defined within .NET, is controlled by a CLR host. The host is typically an ASP.NET ISAPI filter for IIS (for servers) or Internet Explorer (for clients). The host controls several aspects of code execution:

• How it is placed into memory Memory management leads to more efficient use of resources and protection of data during exceptions.

• Exception handling Buffer overflows and other user-generated errors can be handled to a greater degree. The ability to catch more errors or to “break securely” by default limits the attack vectors for a malicious user. Managed code should be able to catch more errors.

• Assemblies A programmer-friendly feature that describes a specific set of files and their version numbers for an application. One byproduct of this is that programmers can be assured of compatibility and functionality because code libraries (DLLs) correspond to specific applications. Thus, upgrading a DLL for one service application will not break functionality for a service application that requires a different DLL version.

Managed code is found in class libraries, such as cryptographic algorithms. Class libraries provide fundamental interfaces for data objects and access methods. An application built from the ground up to rely on class libraries will have more inherent security than a legacy application run from a .NET server.

SECURITY ALERT

A CLR host can conceivably run on any operating system or in embedded devices. Consequently, functions that access files ultimately fall into the security controls of the underlying operating system, not the CLR. Managed code with a poorly written input validation function could expose files outside of the Web document root.

The unmanaged code category would include most applications written for IIS today. There is only minimal separation of processes, memory, and security contexts. All of these can lead to buffer overflows and privilege escalation.

Security in .NET applications comes from three sources:

• Code Access Security This enforces security within the application in order to control file access, component access, and memory access. For example, it could be used to limit access to the G:\data directory so that a ViewProfile service may access the directory, but an UpdateEmail service cannot. In Visual Basic and C#, the PrincipalPermissionAttribute controls code access based on Name (the user’s account on a Windows 2000 domain, for example), Role (the group a user belongs to), Action (Deny, PermitOnly, RequestMinimum, RequestRefuse, and other security actions that explicitly allow or deny a command), or whether the user is authenticated or the object allows access.

• Evidence-Based Security Perhaps the most well-known aspect is Authenticode, which is related to assemblies. This enforces security based on certification of the code in question. This level enforces security based on environment, such as code origin (whether the origin is a URL or a, specific, Internet Explorer Security Zone).

• Role-Based Security This enforces security based on authentication and authorization of the user. On Windows platforms, the user is tracked by a security identifier (SID) that is checked each time a resource is requested or role is assumed.

On a system level, you can use the mscorcfg.msc Management Console to view the current settings for .NET assemblies, for remoting services (how remote services interact with your system), for code access security policy, and to configure managed applications. Figure 10-4 shows the basic MMC snap-in for the .NET framework.

Figure 10-4: Viewing assemblies with the .NET Framework Configuration console

Significant security options are available for Enterprise, Machine, or User permission sets. A permission set can be configured to permit or deny everything from accessing SQL databases with blank passwords, to defining which hosts can be trusted with Web access, to read/write/append access to individual files, to assembly permissions. Figure 10-5 shows the MMC menu for creating a new permission set. Figure 10-6 shows the specific options you can set for an assembly.

Figure 10-5: Creating a new permission set with the .NET MMC

Figure 10-6: Assigning security permissions to an assembly

Threats Against .NET Services

Like any Web Services application, a .NET application can be written insecurely. The majority of attacks against a .NET site are probably invalid input attacks. These attacks manipulate data to something that the server does not expect.

Input Validation

Input validation attacks take advantage of weak parsing functions and programmers who place too much trust in the client application. One of the most efficient, yet insecure, methods of input validation is to use client-side JavaScript in the Web browser. The JavaScript routines might be smart enough to strip out invalid characters, but it is trivial to bypass such methods. Input validation attacks can lead to user impersonation, privilege escalation, and arbitrary file access.

SQL Injection

SQL injection is a specific subset of input validation that can enable malicious users to extract arbitrary data from a database. A good method of mitigating such attacks is to rely on stored procedures. For example, if your application relies on the SqlCommandMethod to execute SQL statements, you should use the CommandType.StoreProcedure as opposed to the CommandType.Text method. A stored procedure receives a parameter list and generates an error if the list varies from the predetermined number of parameters or parameter types. On the other hand, it is easier to insert malicious characters into a SQL query constructed from a string.

Consider this function, written in C# pseudocode:

 [ SqlCommandMethod(CommandType.Text, "SELECT * FROM Users   WHERE Password = @Passwd AND ExpireDate > GetDate()") ] public static DataSet GetAnnouncements(SqlConnection connection, int moduleId) { ...functions } 

If the Web application does not perform proper input validation for the @Passwd variables, a malicious user could attempt a SQL injection attack. For example, @Passwd might be manipulated to contain SQL formatting such as “a OR 1=1’--.” The final SQL query would end up as “SELECT * FROM Users WHERE Password = a OR 1=1.” Thus, the SQL query is reduced to selecting all data (SELECT *) from the table containing user information. Depending on the error handling within the application, a few actions might occur. The application will return an error because it received more fields than it expected. This field information (such as passwords) could be returned in the error string. On the other hand, the application may simply take the first series returned. In that case, the user would log in with the credentials of the first user defined in the Users table.

SECURITY ALERT

The .NET version of Microsoft Visual Basic introduces Java’s error-handling concept of the try, catch, finally statements. Any time the application must parse user-generated data, place the parsing function within a try statement. The catch statement should handle known possible errors, such as letters entered as a U.S. ZIP code, as well as a default handler for unknown errors, such as receiving null input. Even if the catch statement does not consider every attack, the finally statement should perform a graceful exit of the function and display a polite error message to the user. Remember, this error message should not contain any references to application constants, variables, line numbers, or filenames.

Threats Against .NET Servers

System administrators can easily lose sleep when their .NET applications run on Microsoft’s IIS Web server. A vulnerable Web server is often the point of entry into any Web-based application. A buffer overflow or an incorrect parsing algorithm could provide a malicious user access to encryption keys, user data, and application source code. IIS has had a history of such vulnerabilities. For example, Microsoft has issued the following security advisories for IIS:

• IIS Directory Traversal and Superfluous Decode (MS00-086, MS01-026) These enabled malicious users to access arbitrary files and run arbitrary commands on the Web server. Placing the Web document root on a drive volume separate from the SYSTEMROOT greatly reduces the impact of this attack.

• IIS ISAPI DLL buffer overflow (MS01-023, MS01-033) Buffer overflows in the .printer and .ida ISAPI filters granted malicious users command-line access to vulnerable servers. Removing unused filters from the IIS install would have protected servers.

• IIS FrontPage Server Extensions (MS01-035) Another buffer overflow that granted command-line access. Again, removing unnecessary components from the IIS install would have protected many servers.

Attacking Protocols

Servers are always susceptible to denial of service (DoS) attacks. These attacks usually consist of excessive amounts of traffic being sent to the victim Web servers. For example, if the Passport authentication servers were taken down due to a flood attack or a backhoe slicing fiber lines, any partner site that requires Passport authentication would be out of commission as well. A successful DoS attack would be difficult to accomplish against networks specifically designed to handle high bandwidth.

Still, there are some measures you should take to protect your own servers:

• Apply rate limiting to border routers Cisco IOS supports committed access rate (CAR) controls with the access-list and rate-limit configuration options. Using CAR can aid your network against DoS attacks, but requires careful configuration to make sure they work appropriately for your network’s average bandwidth, peak utilization, and traffic composition. Here is an example designed to protect against SYN floods. It permits traffic to TCP port 80, but limits SYN packets (new connection requests) while permitting all established connections to continue normally. You would change the numbers 64000 8000 8000 in order to set the average allowable bandwidth and maximum burst numbers:

   access-list 101 permit tcp any any eq www     access-list 102 permit tcp any any eq www established     access-list 103 permit tcp any any syn     interface <interface><interface #>     rate-limit input access-group 103 64000 8000 8000  conform-action transmit exceed-action drop 

• Design redundancy into the network and remove or limit single points of failure Network equipment such as routers, load balancers, and firewalls should be deployed such that they have failover components. If a single load balancer serves a farm of 20 Web servers, a failure in the load balancer would prevent access to all of the Web servers.

• Deploy a geographically diverse network This can be difficult to accomplish for applications that rely heavily on database transactions. However, networks that are distributed geographically are more resistant to power failures, bandwidth flooding attacks, or equipment failure. It is similar to redundancy.

• Ensure servers are maintained at a current security patch level If application servers lack security patches, malicious users could more easily create a denial of service or compromise a system. After all, it’s easier to bring down a server with only a few dozen packets against a known vulnerability as opposed to flooding the server with millions.

Protecting Your Servers

The IIS ISAPI filters caused a great deal of headaches for administrators. The default installation for IIS is notoriously insecure and includes several items that can be removed in order to make it more secure while not hampering its performance. Here’s a quick checklist of recommended settings for IIS:

• Remove all unused ISAPI filters. This is a simple measure that buys a lot of security. Figure 10-7 shows the Properties window from the MMC tool for configuring IIS.

  
  Figure 10-7: Remove every unused ISAPI filter

• Place the Web document root on a drive volume that does not contain the system root (WINNT directory). Preferably, this will be a volume that holds no other data but the Web application’s code.

• Network access lists should only permit inbound Internet access to ports 80 and 443.

• Network access lists should not allow Web servers to establish outbound Internet connections. This means that the Web server can still answer incoming connections, but the server cannot be used to access an FTP server, a TFTP server, or any other service on the Internet. This makes it more difficult for a malicious user or a worm to use the server as a platform for further attacks.

• Database servers should only use integrated authentication. Regardless, the “sa” user password should not be blank!