Tag Archives: web application

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 192.168.1.100 and identify the following:

Interesting ports on 192.168.38.132:
PORT    STATE SERVICE  VERSION
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.