CAPEC-54 - Probe Application Error Reporting

An Attacker, aware of an application's location (and possibly authorized to use the application) can probe the application's structure and evaluate its robustness by probing its error conditions (not unlike one would during a 'fuzz' test, but more purposefully here) in order to support attacks such as blind SQL injection, or for the more general task of mapping the application to mount another subsequent attack.






  • Attack Methods 2
  • Injection
  • Brute Force
  • Purposes 1
  • Reconnaissance
  • Sec Principles 2
  • Failing Securely
  • Defense in Depth
  • Scopes 1
  • Read memory
  • Read application data
  • Confidentiality

Medium level: Although fuzzing parameters is not difficult, and often possible with automated fuzzers, interpreting the error conditions and modifying the parameters so as to move further in the process of mapping the application requires detailed knowledge of target platform, the languages and packages used as well as software design.

This class of attacks does not strictly require authorized access to the application. As Attackers use this attack process to classify, map, and identify vulnerable aspects of an application, it simply requires hypotheses to be verified, interaction with the application, and time to conduct trial-and-error activities.

The Attacker needs the ability to probe application functionality and provide it erroneous directives or data without triggering intrusion detection schemes or making enough of an impact on application logging that steps are taken against the attacker.

Never Use Input as Part of a Directive to any Internal Component

Handle All Errors Safely

Step 1 -

Determine user-controllable parameters of the application.

Step 1 -

Inject each parameter with content that causes an error condition to manifest.

Step 2 -

Modify the content of each parameter according to observed error conditions.

Step 3 -

Repeat above steps with enough parameters until the application has been sufficiently mapped out to launch desired attack (for example, Blind SQL Injection).

Custom error pages must be used to handle exceptions such that they do not reveal any information about the architecture of the application or the database.

Employ application-level safeguards to filter data and handle exceptions gracefully.

Application designers can construct a 'code book' for error messages. When using a code book, application error messages aren't generated in string or stack trace form, but are cataloged and replaced with a unique (often integer-based) value 'coding' for the error. Such a technique will require helpdesk and hosting personnel to use a 'code book' or similar mapping to decode application errors/logs in order to respond to them normally.

Application designers can wrap application functionality (preferably through the underlying framework) in an output encoding scheme that obscures or cleanses error messages to prevent such attacks. Such a technique is often used in conjunction with the above 'code book' suggestion.