Common Web Application Vulnerabilities

February 25, 2005 (Computerworld) While the World Wide Web has evolved into a critical delivery pipeline for companies to interact with their customers, partners and employees, it also may also provide a back door through your security perimeter.

Web application vulnerabilities provide the potential for an unauthorized party to gain access to critical and proprietary information, use resources inappropriately, interrupt business or commit fraud.

A Web application is a software program that typically contains scripts to interact with the end user. A Web application consists of three components:

• The Web server sends pages to the end user's browser,


• The application server processes the data for the user, and


• The database stores all of required data.

See graphic below
Web applications have become a universal conduit because of the rapid growth of the Internet. Some commonly used types of Web applications are webmail, shopping carts and portals. These applications allow masses of people to access systems quickly without geographic restrictions. However, Web applications introduce a magnitude of security risks and challenges so it's essential to implement strong security measures to mitigate significant risks.

Security professionals have devoted a lot of time and energy identifying and correcting vulnerabilities in operating systems and server administration setup. Because server security is being hardened, hackers are forced to find alternative ways to hack into computing resources to achieve their goals. So hackers are becoming knowledgeable about exploiting legitimate avenues to gain access to computing resources, and the Web application has become their target. The Gartner Group states, "Today over 70% of attacks against a company's Web site or Web application come at the 'Application Layer' not the Network or System layer." To defend this approach, more time and effort has been recently dedicated to understanding, identifying and correcting Web application-related vulnerabilities.



Hackers will examine a Web application and infrastructure to understand its design, identify any potentially weak aspects, and use these weaknesses to break or exploit the application. Web vulnerabilities can come from exposures in the server's operating system, server administration practices, or from flaws in the Web application's programming itself. Unlike traditional legacy applications, Web-based HTML source code is public and therefore viewable by anyone by selecting View Source from a Web browser's menu.

HTML source code information, such as programmer-created comments, passwords and IDs within the code, can provide information that could help hackers better understand your system. The code and comments within the code may not only be helpful to the authorized programmer, it may also be good information for the hacker to discern file paths and find other opportunities.

Is your institute at risk of unauthorized hacking through your Web applications? Would you know? How can you reduce your risks? This article explains some Web application risks your business may face and how to mitigate those risks.

Authentication

One of the biggest Web application weaknesses is the failure to provide a means of strong authentication to verify the end user is who they claim. Prior to accessing a Web application, a server may require the end user to authenticate themselves to identify the user or to determine the user's access privileges. Without such authentication employed, attackers could access to another user's account, view sensitive information or perform unauthorized functions.

To mitigate this risk:

• Employ strong authentication, such as HTTPS, with encrypted credentials.


• Require reauthentication at specified time intervals or movement between Web pages.


• Enforce what authenticated users are allowed to do.


• Regularly test authentication and all potential ways to circumvent authentication.


• Implement authorization (access control).

Session Security and Session IDs

Most Web sites maintain session state to determine access rights or user settings during the users' sessions. When users log in to an application, the Web server issues an identifier to the user known as a session ID. This session ID can, and should, be random and also set to expire at the completion of the session.

However, the session ID can also be predetermined (or sequential) and persistent (or not set to expire). The server uses the session identifier with associated data with each successive request. Session tokens often are not properly protected allowing attackers to compromise passwords, keys, session cookies, or other tokens that can defeat authentication restrictions and assume other users' identities. For example, the user's session ID is displayed in the URL.

Even if authentication is required, it may be possible for a user to authenticate using legitimate credentials, but then change the session ID in the URL line to access another user's data without requiring reauthentication.

To mitigate this risk:

• Assign random, nonsequential session IDs and require reauthentication when accessing additional records.


• Protect account credentials and session tokens.


• Require all cookies have an expiration date so that session tokens are only valid for a predetermined period after the last request by the user.


• Change session tokens when the user moves from an SSL-protected resource to a non-SSL-protected resource.


• Invalidate the session token at the server-side when the user logs out.


• Confirm that the session token is nonpersistent and is never written to the browser's history or cache.

SQL Injection Vulnerabilities

Many Web applications don't properly strip user input of unnecessary, special characters or validate information contained in a Web request before using that input directly in SQL queries. SQL is a programming language that is used by many applications to talk with back-end databases. SQL Injection is an attack technique that takes advantage of the Web application to extract or alter information from the database. Hackers enter SQL queries or characters into the Web application to execute an unexpected action that can then act in a malicious way.

Such queries can result in access to unauthorized data, bypassing of authentication or the shut down of a database even if the database resides on the Web server or on a separate server. Without proper controls in place, attackers can attack back-end components through a Web application.

To mitigate this risk:

• Validate user input to ensure only legitimate data is sent to the Web server. Strip user input of and valid special characters before using that input directly in SQL queries. Check input for appropriate/expected length.


• Ensure the application will not process SQL commands from the user.


• Design and program Web applications in a manner that prevents client-supplied values from being treated as SQL syntax.


• Perform strict input validation on any client input.


• Apply default error handling.


• Implement logical security at the database level -- specify users, roles, and permissions at the database layer.


• Conduct regular testing and identification of potential SQL injection vulnerabilities. Often the most effective method of locating SQL injection vulnerabilities is by hand. Examine application inputs and insert special characters to understand database query syntax and the responses to such queries. Informative errors pages are displayed by default and often give clues to the SQL query in use.

Buffer Overflows

Web applications may be vulnerable to buffer overflows, which occur when a program attempts to store more data in a static buffer than it was designed to manage. The additional data overwrites and corrupts memory, allowing an attacker to insert arbitrary instructions on the Web server or to crash the system.

Applications may not adequately prevent the introduction of arbitrary code into the system that could be executed with the administrator privileges of the operating system. For example, a hacker may enter a command-line executable statement, such as , into a legitimate Web site form under the guise of an "http request" to gain access to the Web server. If your security configuration allows, the hacker would receive the /etc/passwd file and have access to files, and ultimately access to usernames and passwords, that are stored on the Web server.

To mitigate this risk:

• Identify buffer overflows during testing by entering progressively larger values into form inputs, header and cookie fields.


• Prevent code insertion by unauthenticated sources.


• Validate input field length.

Cross-Site Scripting (XSS)

A Web application can bring an attack to an end-user's browser by using the Web browser of other Web users who are viewing the page. A hacker could create a Web site that takes advantage of a cross site scripting flaw. An unknowing user could visit this hacker's Web site (for example, by clicking on a link within an e-mail they have received from a friend) and the hacker's malicious code could then be executed on the unknowing user's system. A successful attack can disclose the end user's session token, attack the local machine, or spoof content to fool the user.

To mitigate this risk:

• Filter input so end-user data cannot be interpreted as scripted content (i.e.


• Perform data integrity checks on data prior to its submission to ensure the data is reasonable.


• When possible, restrict all end-user input to alphanumeric content.

Stay tuned for Part 2 next week when Kennedy examines error handling, remote Web site administration, server configuration and more.