Securing the Gateway to Your Enterprise: Web Services

By Eugene Siu, CISSP and Senior Security Consultant, Microsoft ACE Team

See other Security Tip of the Month columns

Many development teams inside and outside Microsoft often express strong desires to better protect their Web applications during my security review debriefs. With the advent of Web Services, backend systems running in data centers and mainframes are available in well-published Web Service APIs. As a result, developers, architects and administrators become more concerned about the security of Web Services.

When Web applications in the form of CGI were born, it brought static HTML to life, and allowed users to interact with Web applications. That was a significant milestone in Web application evolution. As more Web applications were developed, they became isolated islands of information. To further harness Web technology, integration of isolated applications becomes more critical. Web Services were invented to fill the void so that developers can treat other systems on the Web as APIs exposed via Web Services.

Let’s analyze what Web Services are. The heart and soul of Web Service is the marriage of HTTP and XML technology as shown in Figure 1. If Microsoft Network Monitor (Netmon) or your favorite network capture tool is used to examine Web Service traffic, you will notice HTTP requests and responses passing back and forth between your Web Service clients and servers. The body of the HTTP requests and responses is filled with XML constructs standardized by Simple Object Access Protocol (SOAP).

Figure 1 shows the relationship among SOAP, HTTP and XML

Securing Web Services boils down to learning how to secure plain vanilla Web applications with XML payloads. Deployment and application security are two important aspects of securing Web Services.

Deployment Security

Deployment security involves reducing attack surface area and applying the principle of least privilege. Web Services must be given rights to do their tasks, but NO MORE. To reduce attack surface area, the fewest number of authentication protocols should be supported. For example, an Intranet Web Service should not need to support anonymous access or Basic authentication in a Windows domain environment. Authentication is configured under the Directory Security tab of Directory Properties as shown in Figure 2.

Figure 2 shows authentication and SSL settings in IIS Directory Properties

To observe the principle of least privilege, only a minimal set of authorization rights -- including file, service, and registry ACL entries -- should be given to the service account to perform its duties. If impersonation is not enabled, the authorization of the service account used to run the Web Service should be scrutinized for a least privilege configuration. It is best practice to use an unprivileged user account as the service account. Therefore, the use of local admin or domain admin account as a service account should be reviewed very carefully. The service account is configured under the Identity tab of ApplicationPool Properties as shown in Figure 3.

Figure 3 shows Identity service account in IIS Application Pool Properties

Confidentiality is critical to handling of personally identifiable information (PII), such as password, medical history and social security number. Confidentiality can be achieved through encryption technology. If confidentiality is required, Secure Socket Layer (SSL) can be applied by encrypting the transport channel that carries HTTP and XML payloads that contain PII. SSL can be configured for Web Services, and this can be done by navigating to the Directory Security tab of the Directory Properties as shown in Figure 2. In addition, WS-Security, supported by Web Services Enhancements (WSE) as a Microsoft .Net Framework class library, which provides a more detailed level of encryption control, for example, at the XML element level.

Application Security

In addition to deployment security, application security is another piece of a puzzle to properly secure Web Services. Proper input handling constitutes a large part of application security. The most infamous attacks against Web applications are cross-site scripting (XSS), various injection attacks and Denial of Service (DoS), which are made possible by mishandling input data. As XSS is a client-side attack on scripting-enabled Web browsers, Web Services are not affected. However, when Web browsers use Web Services, proper encoding of data returned by Web Services must be performed on the client side to avoid XSS.

In contrast to XSS, injection attacks are normally due to server-side vulnerabilities. Injection attacks can take place because user inputs are executed against target servers without proper filtering. The most well-known type of injection attack is SQL injection. Application data stored in database servers usually contain the enterprise crown jewel – confidential data. SQL injection vulnerabilities can allow attackers to illegitimately access and manipulate enterprise data, which make them very dangerous. In addition to SQL injection, other injection attacks can compromise other types of services, such as LDAP injection against LDAP stores and SMTP injection against email servers. Injection attacks can be mitigated by only accepting valid inputs, also known as whitelist input validation. An article that discusses comprehensive mitigation against SQL injection is listed in the reference section.

Web Services plagued by Denial of Service vulnerabilities serve incoming requests slowly or stop accepting them altogether. Parsing of XML requests and construction of XML responses is a heavy burden to Web Services. Attackers can craft devious incoming requests that trigger computationally intensive routines. Some common devious examples involve XML incoming requests with deeply nested XML elements or a large number of unnecessary XML tags. Similar to mitigating injection attacks, whitelist input validation can help mitigate DoS by only allowing “normal” inputs. Other techniques are also available to mitigate DoS by configuring Web Services properly (listed in the reference below).

Securing Web Services requires you to focus on both deployment and application security. A perfectly written application is susceptible to attacks if it is not properly deployed, and vice versa. Deployment and application security must go hand in hand; otherwise, attackers will take the path of least assistance to compromise invaluable enterprise data through Web Services. It is impossible to cover all details in an article, so please do not hesitate to contact me (eugenes@microsoft.com) if you want to discuss my favorite subject.

Author Background

Eugene, a CISSP holder, is a senior security consultant of Microsoft ACE Services. He has extensive experience in securing large-scale server products and systems. He is responsible for securing the design of Microsoft Exchange Server 2007 and identifying areas to carry out penetration testing. Prior to joining Microsoft, Eugene was a software consultant for Fortune 500 clients developing client-server and web-based financial systems.

Reference

Web Service Security Guide by OWASP
https://www.owasp.org/index.php/Web_Services

Cross-Site Scripting (XSS)
https://msdn2.microsoft.com/en-us/library/ms998274.aspx

SQL Injection
https://msdn2.microsoft.com/en-us/library/bb355989.aspx

Denial of Service (DoS)
https://support.microsoft.com/kb/832878/

Microsoft Network Monitor (Netmon)
https://www.microsoft.com/downloads/details.aspx?FamilyID=18b1d59d-f4d8-4213-8d17-2f6dde7d7aac&DisplayLang=en