"Loose lips sink ships" was a phrase which became popular in the United States during World War II. In Britain, you heard "Careless talk costs lives." The main point of the saying was that careless speaking about sensitive information could be overheard by spies and lead to serious consequences.

The same principle holds true when building web applications. When your web app reveals too much information, it can make it easier for attackers to break into it.

In this post, we'll cover what information exposure is, why it's dangerous, and how to prevent it.

Understand Information Exposure

Information exposure refers to web applications which expose internal information to those who shouldn't see it. It can also refer to exposing sensitive customer information through log files or the user interface. Either way, attackers can use the information they find to attack your systems or your users.

Often, the first step for an attacker is to try to create an error within your application. Poor error handling and web application configuration leads to information exposure with error messages. What happens if the attacker creates an error within your application? If a technical error message appears, including technical details such as a stack trace, you've revealed too much information. These details can include what database you're using or what version of the application server you're running.

Sensitive information disclosure can occur in other ways. Are there hidden fields on a form that hold sensitive information? Attackers can simply view the source of the page and see the values.

In a nutshell, information exposure occurs when information which should be on a need-to-know basis with your users is made too easily accessible.

Understand Why Information Exposure is Dangerous

What can an attacker do with information exposed by the application? If the information is sensitive in nature, an attacker could steal identities or user credentials. This could lead to financial damages, privacy violations, and regulatory fines

If an attacker uses error messages to gain information about an application, that information could be used in a future attack. In fact, the OWASP Testing Guide has an entire section about information gathering.

The OWASP Testing Guide encourages the use of search engines to find out information about your website you may not intend. For example, are your administrative pages exposed to search engines? Use the robots.txt file to tell search engines not to index certain pages. At the same time, the robots.txt file can leak information as well. Sensitive URLs can at times reside on the robots.txt file. The attackers pull the file down and start learning some of the directory structure of the site.

Google has advanced search engine options which allow deep inspection of websites. For example, you can search on a specific site using the "site: <domain>" syntax. You can view cached pages which may have been deleted but still reside in a cache from a previous indexing job. Using different search engines, such as Bing and DuckDuckGo may yield different results, so test on each search engine what is revealed about your web application.</domain>

HTTP headers, website banners, and even comments within HTML and JavaScript code could have information attackers shouldn't see. HTTP headers can reveal application servers and version numbers. Attackers can use this information to find exploits to use against those specific versions. Make sure you understand all of the different places attackers could find your information and how to hide it appropriately.

Defeat Information Exposure

Information disclosure is often a problem with web application configuration. Many application servers return stack traces in error messages by default. Make sure to change this setting for production applications to redirect to a generic error page while logging the error for troubleshooting purposes. Detailed error messages should never be returned to the user's browser.

If you have any files necessary for the application which contain sensitive information, make sure proper access control ensures that only the application itself can read it. Disable directory listing on the server and move these files outside of the web root directory. This prevents attackers from navigating to the file using the browser using a directory traversal attack.

Logs can be used to gather information when not configured correctly. When an error occurs, don't log sensitive information such as passwords, session tokens, or personally identifiable information (PII). If an attacker could gain access to log files, they would find a treasure trove of sensitive information to steal. Don't log more than is necessary, which is usually an account identifier, a detailed error message, and maybe the method the error occurred in or the operation being performed. Assume log files aren't secret and you won't be tempted to place sensitive information within them.

Don't Sink Your Web Apps

Could you really have leaked information while speaking to a friend, directly leading to a battleship being lost in World War II? Maybe not. But why run the risk? That's the lesson of the saying, "Loose lips sink ships."

Similarly, there's no reason to expose the internal workings of your web application to the outside world. There's no reason to view entire credit card numbers or passwords. There's no reason to have PII data in log files. So don't do it. Check out our learning resources to learn more about information exposure.

Keep the internal workings of your applications where they belong. Don't sink your web apps.

Do you think you can put a stop to information exposure right now? Step up to the challenge, warrior: [Start Here]