If you are not familiar with the concept of Information Leakage, we suggest that you review the article entitled “What is Information Leakage ?“.
Keep Your Eyes Open During Testing
In my experience, you don’t do much testing for Information Leakage directly, rather you keep your eyes open for it as the result of other testing.
For example, you might be testing for SQL Injection by providing some malicious SQLi payloads against a form, and suddenly find yourself looking at a database error that describes what went wrong with your SQL. You might be surprised to see that the message can be used to identify the database vendor, and might even regurgitate the SQL statement that failed to execute, along with a helpful suggestion as to where the syntax error lies.
You may or may not have found a SQL Injection vulnerability, but you definitely have found an Information Leakage issue.
Another example might occur when you are fuzzing parameters with Cross-site Scripting (XSS) payloads, and find that yourself looking at a stack trace. The error messages not only describes the class and line at which the Exception occurred, but also the details entire stack making up the thread. You have not yet found an XSS problem, but you have found Information Leakage.
Looking For Information Leakage
In addition to keeping your eyes open as you do your normal security testing, there are some places you can look that you might not otherwise normally do:
- If you are not accustomed to checking for Account Enumeration at the login page/screen, you should add that to your repertoire, as Account Enumeration is an Information Leakage vulnerability.
- Assuming we are dealing with a web-application, you may also want to look at the Banner returned by the web-server when a simple GET request is submitted. The server and version information that web-servers provide by default is a bit over-informative from a security point of view and represents Information Leakage.
- You also might want to examine the source code of any pages you encounter, looking for comments containing file paths, email addresses, employee information, “to do” items, and even “bug” notices.
- Examine the parameters provided with each request and look for “debug” type flags. The ability to turn debugging on with parameter value can yield a host of information useful to an attacker.
- Look at URLs and parameters for predictable values; if a pattern can be discerned, or values predicted, the application has leaked important design information.
For additional information about preventing and/or fixing this vulnerability within a web-application, please see the article entitled “How to Prevent Information Leakage“.
About Affinity IT Security
We hope you found this article to be useful. Affinity IT Security is available to help you with your security testing and train your developers and testers. In fact, we train developers and IT staff how to hack applications and networks.
Perhaps it was a network scan or website vulnerability test that brought you here. If so, you are likely researching how to find, fix, or avoid a particular vulnerability. We urge you to be proactive and ensure that key individuals in your organization understand not only this issue, but also are more broadly aware of application security.
Contact us to learn how to better protect your enterprise.
Although every effort has been made to provide the most useful and highest quality information, it is unfortunate but inevitable that some errors, omissions, and typographical mistakes will appear in these articles. Consequently, Affinity IT Security will not be responsible for any loss or damages resulting directly or indirectly from any error, misunderstanding, software defect, example, or misuse of any content herein.