Welcome to our Secure Development Tips blog

Every other week, we provide expert tech tips on how to build and deploy secure applications.  These best practices, derived from Security Innovation’s assessments of the worlds’ most dominant software applications,  are taken directly from our TeamMentor product, which includes more than 3,500 guidance assets and articles on secure software design, coding and testing.    

Recent Security Innovation Blog Post:

Subscribe by Email

Your email:

Secure Development Tips

a blog with tips relating to secure application development, from Security Innovation's eknowledge database, TeamMentor

Current Articles | RSS Feed RSS Feed

Prevent Information Disclosure in Error Messages

  
  

What to Do

Ensure that error messages only contain minimal details that are useful to the intended audience, and nobody else. The messages need to strike the balance between being too cryptic and not being cryptic enough. They should not necessarily reveal the methods that were used to determine the error. Such detailed information can be used to refine the original attack to increase the chances of success.

If errors must be tracked in some detail, capture them in log messages - but consider what could occur if the log messages can be viewed by attackers. Avoid recording highly sensitive information such as passwords in any form.

Why

In the context of path traversal, error messages which disclose path information can help attackers craft the appropriate attack strings to move through the file system hierarchy.

In the context of OS Command Injection, error information passed back to the user might reveal whether an OS command is being executed and possibly which command is being used.

In the context of SQL Injection, error messages revealing the structure of a SQL query can help attackers tailor successful attack strings.

How

Perform the following actions to prevent disclosure of sensitive information in error messages:

  1. Identify error messages. Review error handling code and find all instances of error messages being presented to the user, including errors displayed by the framework.
  2. Write simple error messages. Write simple messages and warnings explaining the error to the user but don't include any of the following sensitive information:
    1. File locations. Filesystem information, such as the locations of Operating System files, databases, or other sensitive information may be used by an attacker to coordinate his attacks, so this information should not be included in error messages.
    2. System information. System information, such as Operating System version, network names, internal network addresses, etc should not be included in error messages because it may help an attacker identify vulnerable software, choose exploits, or attack other systems on the network.
    3. User account information. Information such as usernames, personal names, e-mail addresses, or other user information should not be revealed in error messages, because it may help an attacker attack that user account.
    4. Secrets. It goes without saying that secret information, such as passwords, password hashes, cardholder data, etc should not be disclosed in error messages.
  3. Use simple error messages. Rewrite code that displays verbose error messages that display sensitive information to the user to display new, simple error messages.

 

Comments

Post Comment
Name
 *
Email
 *
Website (optional)
Comment
 *

Allowed tags: <a> link, <b> bold, <i> italics