PRACTICAL WEB DEFENSE COURSE MODULE

13

ERROR
HANDLING AND
LOGGING
 PRACTICAL WEB DEFENSE COURSE

Error Handling and Logging

Author • Abraham Aranguren
Technical Editor • Giuseppe Trotta
Document version • 1.0
Last update • Friday, November 15, 2013

eLearnSecurity 2013 ©

All rights reserved. No part of this document may be reproduced in any form or by any electronic or
mechanical means, including information storage and retrieval systems, without written permission
from the publisher, except in the case of a reviewer, who may quote brief passages embodied in
critical articles or in a review.

eLearnSecurity s.r.l.
36,38 Via Matteucci
Pisa, ITALY 56124
P W D / P R A C T I C A L W E B D E F E N S E

1. TABLE OF CONTENTS
INTRODUCTION 1
1. ERROR HANDLING AND LOGGING 2
1.1 INTRODUCTION 2
1.2 WHAT THE PROBLEM IS 2
1.3 HOW CAN I SEE IF I AM VULNERABLE TO THIS? 4
1.3.1 Business logic flaws due to improper error handling 4
1.3.2 Platform error messages 4
1.3.3 Application error messages 4
1.3.4 Logging 5
1.4 HOW CAN I FIX THIS? 7
1.4.1 Fail Securely 7
1.4.2 Platform error messages 7
1.4.3 Application error messages 8
1.4.4 Logging 9
1.5 FURTHER READING 10
P W D / P R A C T I C A L W E B D E F E N S E
INTRODUCTION

I
INTRODUCTION
This module focuses on specific defense tactics to handle error conditions and logging.
Sooner or later all web applications face unexpected conditions, typically due to a
combination of input that was not anticipated but potentially also related to environment
factors such as server load. Regardless of the reason, web applications need to handle the
following very carefully:
• Handle errors gracefully
• Log errors so that they can be reviewed later
For example, most web attacks involve a combination of input that the application did not
anticipate, if there are no adequate logs in place (i.e. The POST body is not logged by
default on most web servers), it might not be possible to determine the root cause of the
problem, whether it is a security issue or not.
In addition to this, common misconfiguration errors such as displaying verbose error
messages on the screen may be of assistance to a prospective attacker.

ERROR HANDLING AND LOGGING - Introduction 1

P W D / P R A C T I C A L W E B D E F E N S E
CHAPTER

1
1. ERROR HANDLING AND LOGGING

1.1 Introduction
All applications, no matter what size they are, will eventually crash or hit an error
condition, either in production or during User Acceptance Testing (UAT) as well as
development.
Error handling defines how these unexpected error conditions will be dealt with by the
application and platform in use.
Logging defines how traces of errors or other events may be saved into persistent storage
(i.e. generally files or a database) in order to be reviewed later.

1.2 What the problem is

Logging is a necessary feature: It is often the only way to identify the root cause behind a
security incident. Failure to have adequate logging features may be not only a serious cause
for concern but also breach compliance in many industries.
Error messages, while helpful for end users, may sometimes facilitate other attacks. For
example, when the .NET padding Oracle vulnerability was published in 2010, exploitation
of the vulnerability relied on error messages, even if they were generic:
• How to check if your application is vulnerable to the ASP.NET Padding Oracle
Vulnerability
http://www.acunetix.com/blog/news/check-application-vulnerable-asp-
net-padding-oracle-vulnerability/

ERROR HANDLING AND LOGGING - Error Handling and Logging 2

P W D / P R A C T I C A L W E B D E F E N S E

Tools such as sqlmap1 will sometimes be significantly faster to exploit SQL injection
vulnerabilities when error messages are present:
• Netvolution referer header SQL injection vulnerability
[11:02:00] [INFO] testing 'AND boolean-based blind — WHERE or HAVING clause'
parsed error message(s) showed that the back-end DBMS could be Microsoft SQL Server.
Do you want to skip test payloads specific for other DBMSes? [Y/n] Y
[11:02:16] [INFO] testing 'Microsoft SQL Server/Sybase AND error-based
— WHERE or HAVING clause'
http://census-labs.com/news/2011/10/03/netvolution-referer-SQLi/

A good write-up about how error messages can be helpful to exploit SQL injection faster
can be found here:
• Speeding up Blind SQL Injections using Conditional Errors in MySQL
http://ha.xxor.se/2011/06/speeding-up-blind-sql-injections-using.html

Other forms of information leakage or vulnerabilities introduced through error messages

are the following:
• CVE-2007-6271: Absolute News Manager.NET 5.1 allows remote attackers to
obtain sensitive information via a direct request to getpath.aspx, which reveals the
installation path in an error message
http://www.cvedetails.com/cve/CVE-2007-6271/
• Hardened-PHP Project: phpMyAdmin - error.php XSS Vulnerability
It was discovered that phpMyAdmin comes with a script to display error messages that supports
displaying the error in a user supplied charset.
http://www.phpdeveloper.org/news/6632

1 http://sqlmap.org/

ERROR HANDLING AND LOGGING - Error Handling and Logging 3

P W D / P R A C T I C A L W E B D E F E N S E

1.3 How can I see if I am vulnerable to this?

1.3.1 Business logic flaws due to improper error handling

Sometimes incorrect error handling leads to security flaws. For example, if you look at the
following code snippet you may notice that an unexpected exception in a library could
leave $allowed set to “true”:

$allowed = true;//Never do this: Defaulting to “allowed” means higher

likelihood of failure
try {
…
library_call(); //The library throws an exception: throw new
Exception('Unexpected ..');
…
$allowed = false;//Never do this: Only rejecting access after
code that could fail
}
catch (Exception $e) {}

1.3.2 Platform error messages

Platform error messages are perhaps the easiest to find. Typically, these only require
reviewing:
1. The platform configuration files
For example, php.ini for PHP and httpd.conf for Apache
2. Calls to the platform API to override the configuration
For example, ini_set for PHP and .htaccess files in Apache
If at any point, platform error messages are configured to be rendered on the screen, then
the web application is vulnerable.

1.3.3 Application error messages

Application error messages require more testing to be identified, global searches on the
source code may help to identify them best but this should be combined with dynamic
analysis whenever possible.
The vulnerability in application error messages will generally be on the message itself.

ERROR HANDLING AND LOGGING - Error Handling and Logging 4

P W D / P R A C T I C A L W E B D E F E N S E

For example:
Error message Security implication
“The username you provided does not exist” User enumeration
“This record can only be viewed by the User enumeration, information leakage
following users: …..” that might be leveraged to attack such
users in order to escalate privileges
“You have a syntax error in your SQL query Attacker assistance to exploit SQL
near …” injection more easily
“Invalid <unsanitized input here>” Classic XSS vulnerability when displaying
user input in an error message without
output encoding first
“Saving file in /home/www/payroll/…” Reveals the underlying operating system
being a Unix derivative and location of
files
“The SQL query is: SELECT column1, Full SQL query, tables and columns
column2 …” revealed

1.3.4 Logging
Logging needs will vary from application to application and from organization to
organization. But generally speaking, if logging is insufficient to track a security incident,
then there will likely be a problem.
It is important to note here that a security incident may be as simple as a direct object
reference2: Having a user change the record ID to a different number, in order to try to
view what they should not be allowed to view. Testing of logging issues should try to
answer questions such as:
• Are security occurrences recorded? Even when they happen at the application
layer?
• Is information stored in the logs sufficient for security, compliance and root-cause
identification?
• Can logs be tampered? If the web server is hacked and the attacker is root can the
logs be trusted?
• Are logs archived for long enough?
The answer to this question must take into account average breach
detection rates:
According to the Verizon Data Breach Investigation Report, 66 percent of breaches took months
or even years to discover. And a recent Ponemon Institute report sponsored by Solera Networks, a
Blue Coat company, found that, on average, it is taking companies three months to discover a
malicious breach and then more than four months to resolve it

2 https://www.owasp.org/index.php/Top_10_2013-A4-Insecure_Direct_Object_References

ERROR HANDLING AND LOGGING - Error Handling and Logging 5

P W D / P R A C T I C A L W E B D E F E N S E

http://www.darkreading.com/attacks-breaches/why-are-we-so-slow-to-
detect-data-breach/240156987
Verizon's latest annual "Data Breach Investigations Report" was not able to find a single
company it studied that was able to discover a breach within minutes or hours. Meanwhile, a
study from security firm Trustwave found the average time between breach and detection was 210
days.
http://www.scmagazine.com/it-decision-makers-are-more-optimistic-
about-breach-detection-than-they-should-be/article/299103/

OWASP guidelines to test for this issue can be found here:

• Testing for Error Code
https://www.owasp.org/index.php/Testing_for_Error_Code_(OWASP-IG-
006)
• Testing for Stack Traces
https://www.owasp.org/index.php/Testing_for_Stack_Traces_(OWASP-
IG-XXX)

ERROR HANDLING AND LOGGING - Error Handling and Logging 6

P W D / P R A C T I C A L W E B D E F E N S E

1.4 How can I fix this?

1.4.1 Fail Securely

Always default to “not allowed” in order to fail securely when unexpected conditions
occur. For example, if you look at the following code snippet you may notice that an
unexpected exception in a library would still leave $allowed set to “false”:

$allowed = false;//Always defaulting to “disallowed” means lower

likelihood of mistakes
try {
…
library_call(); //The library throws an exception: throw new
Exception('Unexpected ..');
…
$allowed = true;//Only allow access after code that could fail
}
catch (Exception $e) {
log($e); //Log errors for later review
}

1.4.2 Platform error messages

The following guidelines should help implementing platform error messages correctly:
• Never display platform stack traces or error messages on the screen
Instead, log errors and fail silently. For example in php.ini3:

display_startup_errors = Off
display_errors = Off
html_errors = Off
error_log = /path/to/error_log

• Research ways in which configuration may be bypassed and review them in the
application
For example, in PHP it may be possible to override php.ini settings via the ini_set4:

ini_set('display_errors', 'Off');
ini_set('html_errors', 'Off');
ini_set('error_log', 'path/to/error_log');

3 http://www.php.net/manual/en/errorfunc.configuration.php
4 http://www.php.net/ini_set

ERROR HANDLING AND LOGGING - Error Handling and Logging 7

P W D / P R A C T I C A L W E B D E F E N S E

• Make it easy to swap environments and use separate files for development and
production
It can save a lot of time to have errors displayed on the screen during development,
ensuring that the mechanism to swap files from development to production is easy is a
guarantee, by itself, that procedures will be followed. If developers are forbidden error
messages on the screen they will find ways around this restriction to meet their (usually)
tight deadlines. Occasional debug messages will make it through to production more than
once if this principle is not followed.

1.4.3 Application error messages

The following guidelines should help implementing application error messages correctly:
• When in doubt err on the side of “less verbose” error messages
• Making application errors more helpful for you and your users
Descriptive error messages such as debug errors, SQL traces, etc. can be extremely helpful
to debug certain problems, but they usually do not mean too much to your end users and
additionally will definitely facilitate attacking any web application.
A great balance to solve all these problems is to save error and debug messages in a
database and, when needed, provide your users with an error id. For example, turn this
message:
“The SQL query failed! – Query: SELECT column1, column2 …”
Into this message:
“An unexpected error has occurred - please indicate the following reference for assistance:
123456”
Where 123456 is the error id in the relevant database table with the full stack trace, SQL
queries, debug messages, etc. Now your users can help you, you do not introduce security
problems and on top of all that, you have a great tool at your fingertips to debug even
non-security issues down the line.
• Whenever possible avoid including user input in error messages
• If you must include user input in error messages then carefully validate it and
output encode it.
Many times, information in log messages may be viewed by external applications, perhaps
an administrator screen of some internal application, etc. If such applications are
vulnerable to XSS, having the raw payload as the user entered it may cause security issues.
Similarly, if the SQL function saving the information in the database is vulnerable to SQL
injection there is another serious problem.
• Carefully review all existing error messages to verify that they do not introduce
security problems

ERROR HANDLING AND LOGGING - Error Handling and Logging 8

P W D / P R A C T I C A L W E B D E F E N S E

1.4.4 Logging
The following guidelines should help to address this problem:
• Ensure all security occurrences are recorded
When in doubt: record it and err on the side of “record more”.
• Ensure the application has adequate exception handlers and checks in place for
logging
The goal here is to ensure that as close to 100% of the security incidents are
correctly logged by the application. This will depend on the platform but the
business logic may also require modifications to ensure even invalid direct object
references are recorded.
Whenever possible, try to centralize the code that handles logging at the
application layer, consider the following ideas: Would changing the code to throw
“security exceptions” simplify logging? Can (all or part of) access control be
incorporated in a central component such as base class that is inherited, known
foreign keys or database permissions?
• Is information stored in the logs sufficient for security, compliance and root-cause
identification?
Time synchronization between logs is very important for correlation purposes
later. In addition to this, the logs should have sufficient information to identify
both the root cause and facilitate attribution5. Things like logging the IP address,
time, username (if possible), etc. of an attack is essential.
• Preserving log integrity
Log integrity is very important. Whenever budget allows it, it is a very good idea to
write the logs to write-once media and/or another server. The reason for this is
that, if the web server is compromised and the adversary escalates to get root
privileges, then the logs simply cannot be trusted if they are on the same server.
This may be crucial in a case where prosecution is being sought: If all the proof is
in the logs and log integrity cannot be guaranteed, then the proof will likely be
invalidated by most courts.
• Implement an adequate log retention policy
Log retention policies of at least 1 year are highly recommended based on
measured breach to breach detection duration (i.e. 210 days on average6).
Compliance and industry regulations are another factor to consider appropriate log
retention policies.

5 http://www.hacksurfer.com/amplifications/270-experts-weigh-in-8211-the-attribution-problem-8230-or-non-

problem
6

http://www2.trustwave.com/rs/trustwave/images/Trustwave_GSR_ExecutiveSummary_4page_Final_Digita
l.pdf

ERROR HANDLING AND LOGGING - Error Handling and Logging 9

 P W D / P R A C T I C A L W E B D E F E N S E

1.5 Further reading

The following resources provide more information on this topic:
• OWASP Logging Cheat Sheet
https://www.owasp.org/index.php/Logging_Cheat_Sheet
• OWASP Development Guide: Error Handling, Auditing and Logging
https://www.owasp.org/index.php/Error_Handling,_Auditing_and_Loggi
ng
• Information Leakage
https://www.owasp.org/index.php/Information_Leakage
• CWE-209: Information Exposure Through an Error Message
http://cwe.mitre.org/data/definitions/209.html
• Logging policy: data protection, interception and Freedom of Information
(Includes Data Protection Act considerations)
http://computing.help.inf.ed.ac.uk/logging-policy
• Log file retention policy example
https://security.ias.edu/system/files/documents/policies/logfile_retentio
n/logfile_retention_policy.pdf
• IIS Logging
http://www.iis.net/configreference/system.webserver/httplogging
• Apache Log files
http://httpd.apache.org/docs/2.2/logs.html
• Windows log retention policy
http://technet.microsoft.com/en-us/library/cc721981.aspx
• Windows Logging
http://msdn.microsoft.com/en-
us/library/windows/desktop/aa369776(v=vs.85).aspx
• Logging on Linux: What to Look Out For With Lots of Linux Boxes
http://server.dzone.com/articles/logging-linux-what-look-out

ERROR HANDLING AND LOGGING - Error Handling and Logging 10

Powered by TCPDF (www.tcpdf.org)