<!DOCTYPE qhelp PUBLIC

"-//Semmle//qhelp//EN"

"qhelp.dtd">

<qhelp>

<overview>

<p>

Software developers often add stack traces to error messages, as a

debugging aid. Whenever that error message occurs for an end user, the

developer can use the stack trace to help identify how to fix the

problem. In particular, stack traces can tell the developer more about

the sequence of events that led to a failure, as opposed to merely the

final state of the software when the error occurred.

</p>

<p>

Unfortunately, the same information can be useful to an attacker.

The sequence of class names in a stack trace can reveal the structure

of the application as well as any internal components it relies on.

Furthermore, the error message at the top of a stack trace can include

information such as server-side file names and SQL code that the

application relies on, allowing an attacker to fine-tune a subsequent

injection attack.

</p>

</overview>

<recommendation>

<p>

Send the user a more generic error message that reveals less information.

Either suppress the stack trace entirely, or log it only on the server.

</p>

</recommendation>

<example>

<p>

In the following example, an exception is handled in two different

ways. In the first version, labeled BAD, the exception is sent back to

the remote user by returning it from the function. As such,

the user is able to see a detailed stack trace, which may contain

sensitive information. In the second version, the error message is

logged only on the server, and a generic error message is displayed to

the user. That way, the developers can still access and use the error

log, but remote users will not see the information.

</p>

<sample src="StackTraceExposure.py" />

</example>

<references>

<li>OWASP: <a href="https://owasp.org/www-community/Improper_Error_Handling">Improper Error Handling</a>.</li>

</references>

</qhelp>