Information Disclosures

To find information disclosure bugs , observe the information that your application discloses and that an attacker can obtain. Sometimes the information disclosed might not seem like a security flaw unless it is a password or something else that is obvious; however, attackers generally use information to assist them in additional attacks. Refer to Chapter 7.

Sample Test Cases
Test Case	Description
Monitor data sent across the network	An attacker can potentially monitor and even tamper with data that is sent over a network. Use tools, such as Ethereal, to monitor the network traffic. Sensitive data should be encrypted, such as by using SSL.
Monitor data stored in files	Every file the application uses can potentially disclose information, including the application s program files, any temporary files the applic ation might create, and the output files that are generated by the application.
Monitor the information stored in memory	Information stored in memory can potentially be accessible to other users in ways you wouldn t expect. For instance, the system could potentially dump the memory to a page file or a file used when the system hibernates.
Look for secrets	Any binary files that contain secrets, such as keys, passwords, and so forth, that the application uses to encrypt or protect data should never be stored in the file because an attacker can reverse engineer the file and extract them.
Look for credentials stored in clear text	Credentials, passwords, database connection strings, and so forth should never be stored in clear text, especially if they aren t protected with access control.
Look at the contents of binary files for sensitive data	Files can contain more information than might be obvious. Use tools, such as Strings or a binary editor, to look at the data stored in a binary file.
Look for internal server names	Sometimes internal server names are considered sensitive information because an attacker can use those names to aid them in attacking your internal network.
Look for file path disclosures returned by a Web application	A Web application should disclose information about the Web server itself. Look for places, especially error conditions, where file paths of the server are disclosed.
Exercise error conditions	Often, error conditions can reveal useful information to an attacker. Exercise all the error conditions that are possible and observe the results.
Look for more information returned than is needed	Even simple information, such as whether a logon was unsuccessful , can be a security vulnerability that an attacker can use against your system. Question whether the information returned to a user is too much and too revealing .
Look for places where data is obfuscated	Obfuscated data, including encoded data, does not protect sensitive information. For instance, using certain encodings, such as base64 orhexadecimal, might not make a password understandable at first glance however, after an attacker figures out which encoding was used, the attacker can easily determine the unencoded password.
Look for sensitive data that is part of the URL	Even if the connection uses SSL, the URL is still readable in clear text. Also, the HTTP Referer can disclose sensitive information.
Make sure sensitive data the application uses cannot be guessed easily	If the data can be guessed easily, it can t be protected from an attacker. For example, if a Web application uses consecutive numbers for the session ID, an attacker will easily be able to guess someone else s valid session ID.