The Challenge

A website is open to the public on an anonymous basis. It must be easy to use, but also protect both the user and the business. A website which does not deploy reasonable security precautions is open to hacking. Hacking is not mysterious and in some cases may be done quite easily, but can result in the following huge problems:

The site displaying unwanted or inappropriate messages
The users web identity being hijacked
A loss of critical data for the company
Public loss of confidence

A site’s security depends upon many components from the IT infrastructure down to the user’s desktop. This discussion will assume all appropriate environment controls are in place and effective. And the user has taken reasonable precautions. The focus will be on the most common vulnerabilities in public facing web applications and the best practices to close the gaps. However, there is no single countermeasure that will guarantee web security. However, a suite of careful protections that is designed into the web architecture can deliver a reasonable level of security.

Unfortunately, HTML was originally used to simply markup documents; then, the use was expanded dramatically on the web. Thus, by tasking it beyond its original design, many vulnerabilities have surfaced which can easily be exploited unless specific safeguards are deployed.

There are many good benchmarks for web application security designs from the SANS Institute, MITRE, and Open Web Application Security Project (OWASP) 3.0. These guides show the most common problems and generally accepted best practice solutions. The following discussion drills down into some of the key problem issues that often result from coding, design, or implementation errors or omissions. The goal herein is to show how vulnerability within web applications can be limited or even prevented. Here are the most common vulnerabilities and their reported occurrences:

Common problems

A website can be made vulnerable to attack either through ignorance, bad design, or sloppy implementation. In some cases, the website builder is just not aware of the gaps in HTML. A site that is well designed from the ground up with the common problems in mind will have few problems. But it all requires careful and thoughtful implementation and testing for a complete security umbrella. Some of the most common issues that a good design must guard against are:

Failure to preserve the web page integrity which opens the door for the insertion of cross site scripting (XSS). This occurs whenever a site accepts input directly without sufficient validation. The malicious input is typically a script which can steal the user’s session identity, display unauthorized messages, and/or collect unauthorized data. The injection is typically done with short scripts using common languages, such as javascript. The vulnerability exploits the trust the user has in an existing site. The approaches are:
- Non-persistent or reflected –script commands used immediately to generate page content to collect information about the site.
- Persistent or stored – script commands imbedded in comments on a site to collect information about other users
- DOM (Document Object Model) – client-side hijacking during the assembly of the html, typically with error messages.

A typical example:

Failure to preserve SQL query structure (SQL injection) within the page. This occurs most commonly where a site uses resolved SQL commands to collect data from a host database. This is where the SQL commands contain variables which are populated by user input. However, the attacker realizes this by examining the page source; then inputs additional commands as the input. The input simply terminates the existing SQL command prematurely and inserts their request with valid SQL query structure. The newly expanded SQL query is included in the execution of the original SQL code, which returns the information the attacker requested. This gives an attacker an opportunity to search the site database for progressively deeper and deeper information. Items that can be retrieved and/or modified include:

List of users
User credentials
Change user’s email

Input: username

“’’ or ‘1’=’1’

statement = “SELECT * FROM users WHERE name = ‘” + userName + “‘;”

becomes SELECT * FROM users WHERE name = '' OR '1'='1';

Inadequate session management invalidates the authentication and rights controls for the website usage. When a user is initially authenticated upon entering a site, they are provided a session ID (SID). However, the challenge is how to store and pass the SID between pages as the user navigates the site. This is necessary because HTML is essentially stateless without additional controls. There are 3 methods to provide state to a set of pages:
- Get Method. This simply passes the ID in the query strin http://mysite.com/page1.aspx?session=123456789
- Post Method. In this case, the SID is contained in the input, select, and text form tag in the html page.
- Cookie. This writes the SID to the local browser temporary space. Modern browsers do a better job of restricting access to the SID to only the authorized and originating site, but older browsers have big gaps. However, the access control significantly depends upon the data in the Cookie.

All of these methods can be made secure or insecure depending upon the application. According to the SANs institute, “all of the methods can be made reasonably secure through intelligent design.”

The vulnerability exists when a valid SID is stolen or an imposter SID is created. The goal of many of the site attacks is purposely to get a SID. In other cases, weak sites are developed with downloaded widgets to create the site SIDS; however, the construction of SIDS using public domain tools is often predictable. There are several web resources available to show the construction of SIDs for many popular web frameworks.

Cross-site request forgery (or CSRF) is where the user’s browser is tricked into sending unauthorized requests to a target site on the user’s behalf without any action on the part of the user. A malicious instruction set is placed in a public forum, often in an image, which gives hidden instructions to the browser acting as a deputy for the user. As an example, the scripts can request the browser to:
- logon to sites on behalf of the user
- send out weak stored passwords and SIDs
- engage transactions

Fortunately, the most damage CSRF can inflict is only when the user is simultaneously logged onto the attacking site and the target site. However, multiple site browsing is common.

Clear text transmission of sensitive information can expose both user and site data. This problem can arise either between the desktop browser and web; or between the web server and the database host. The most critical zone is the public internet space between the end user and the website. While in route the data can travel through many hops and be deposited many caches and logs. This is where it is vulnerable to sniffers and other monitors.

Application Best Practices

The following are common methods used to minimize the most common web vulnerabilities. There is not one single element that will make a website secure; however, when taken in combination with active monitoring, a website can be made reasonably secure. A website must be designed to:

Contain strong field validations on ALL input

All inputs must be validated. The simple form of validating using escaping of string input is a good start, but it is not sufficient. This is the process of simply replacing the 5 significant html characters. Unfortunately, the scripting variations are too complex and clever.

The simplest control is to limit the field size for ONLY the expected input. The inputs must be validated for length, type, and syntax before being used or displayed.
Then only look for and accept the values expected (referred to as a white list). As it has not proven to be successful to sanitize the input, it is best to simply reject invalid input.
And if still needing additional validation, use the Microsoft .Net XSS Library 1.5

As it is impossible to eliminate the use of cookies, the cookies must be protected as much as possible. The cookies can be set to only allow access to the originating IP and for http only requests. However, there are still exceptions around these protections.

Use a strong output encoding for all pages generated such as (such as ISO 8859-1 or UTF 8). Do not allow the attacker to select it.

Deploy a Strong Session Management Strategy

Building in a strong session management approach will significantly limit the exposure if the site is penetrated by one of the other vulnerabilities. And conversely, no additional controls, including encryption, can compensate for weak session management. The basic logon controls usually start out solid, but often times the gaps occur when implementing ancillary functions such as logout, timeout, remember me, and keep alive. The best methods for maintaining control of the session are:

Store only general information in the SID. Even if hashed, do not store any user credentials as part of the SID.
If using the GET METHOD, use referrer filtering. This simply means washing each page through a link filter page so the referring page is dropped. Without this step, the SID remains part of the page because of the referring page. However, some graphics and advertisements can still thwart this protection.
Verify that public error message and crash dumps do not contain the SID.
Automatically expire SIDs after a period of inactivity or absolute time. This also means not allowing users to inherit an existing open SID or provide a SID. If the user logs on and a SID is still open, it must be expired and a new one generated. A site must be ‘strict’ about assigning a unique SID to each user. (A permissive site accepts user supplied SIDs or allows inheriting SIDs.) The reason sites do not allow multiple concurrent logons is to make it possible to determine if a SID has been stolen or duplicated.
Use a strong SID construction of at least 32 characters. This means there 2.27e(57) number of possible combinations – that is sufficient. It is best to use built in SID generators that come with many of the popular platforms and avoid home grown controls or downloaded widgets.
Manage the generated SIDs on the server side within a database. Do not store them in a temporary location subject to alternate rights authentication. It is best to also hash the SIDs within the database to force their use only through the application.
Build in a logging and alerting system to record attempted uses of expired SIDs. This will aid in the detection of a site attack and also identify the presence of a DoS (Denial of Service) attack. This is accomplished by sending invalid SIDs to the system to force the logout of legitimate users.
Every page should have a ‘Logout’ button which is clearly displayed. Too many sites in their effort to keep users on the site make the logout button difficult to find. Thus, all too many users simple close the browser window and rely upon the SID timeout.

Deploy Forging Prevention

A site must recognize that it may be subject to automated actions on behalf of users. These CSRF actions often have tell-tale signs that can be recognized and stopped. A site is less exposed to unauthorized deputy actions when it:

Does not rely solely upon a cookie
Requires and validates the HTML referrer. This is the tag in each request showing the page where the user request originated.
Uses of additional transaction confirmation authentication. This is common when changing a password, but can also be used upon confirmation of a final purchase or action. The use of multiple factor authentication such as a random picture code effectively disables unattended scripted actions.

Use Secure Socket Layer (SSL)

In today’s world, secure transmission is largely handled by Secure Socket Layer (SSL). This is a 3^rd party certificate used to encrypt the data in transit. It is observed with an https: address. This virtually handles the communication in the public internet zone. However, it does not handle the connection between the web and the database host. This connection can be secured by using a closely routed switched network and setting the NIC interfaces to non-promiscuous mode. In this manner, internal networks are substantially secure (except for WAN). However, some implementations are looking at transmission encryption on the backside. This can be done with Microsoft’s transparent data encryption for SQL 2008 (TDE).

Explore Alternative Measures

In some cases, users may opt to suspend scripting on their browser. However, this eliminates much of the modern functionality demanded for usability. There are domain/zone based controls for client-side scripting but this requires advanced knowledge and skills that are usually unavailable to the average user. So scripting is probably here to stay, but a site can still educate the users on best practices and show them how to properly identify the official site.

Use Intermediary Page Generation Handlers

For new websites, the best approach is to architect the site engine to use an intermediary page assembler. This processor accepts only expected input parameters, consumes the XML data from various sources, adds static content, and then responds with the HTML page. The user inputs from the browser are never directly used by the page or SQL. Instead, the specific user inputs are validated and used in a managed replacement process to generate dynamic actions. This buffer not only makes it difficult for the attacker to see how the variables are used, but prevents unexpected inputs from getting into the final assembly and being executed. An example of this secure modular web framework is used by Planserve Data Systems.

Conclusion

The purpose of this discussion is to help application developers avoid the common issues when designing, coding, and implementing an external facing web application. These items must be considered before the first page is constructed or the site colors picked.

Before going into production, every website should be subjected to a thorough ‘penetration’ test. There are several 3^rd parties and tools which can be used to conduct an independent test. However, it is costly and difficult to address vulnerabilities found at late stages of a web deployment project. Any mitigation steps at that point are likely to be patchwork workarounds which will either fail or introduce other vulnerabilities.

In order to prevent this project nightmare, the discussion here presented methods to address or mitigate the common vulnerabilities during the initial design and architecting of the site. The site security must be baked in from the initial design all the way through to the final implementation. If these key measures are implemented in a structured manner, the site will be reasonably secure.