Although it may not be feasible or desirable to prevent the disclosure of absolutely any information that an attacker may find useful, various relatively straightforward measures can be taken to reduce information leakage to a minimum and to withhold the most sensitive data that can critically undermine an application’s security if disclosed to an attacker.
Use Generic Error Messages
The application should never return verbose error messages or debug information to the user’s browser. When an unexpected event occurs (such as an error in a database query, a failure to read a file from disk, or an exception in an external API call), the application should return the same generic message informing the user that an error occurred. If it is necessary to record debug information for support or diagnostic purposes, this should be held in a server-side log that is not publicly accessible. An index number to the relevant log entry may be
returned to the user, enabling him or her to report this when contacting the help desk, if required. Most application platforms and web servers can be configured to mask error
information from being returned to the browser:
-In ASP.NET, you can suppress verbose error messages using the customErrors element of the Web.config fi le by setting the mode attribute to On or RemoteOnly and specifying a custom error page in the defaultRedirect node.
-In the Java Platform, you can confi gure customized error messages using the error-page element of the web.xml fi le. You can use the exception-type node to specify a Java exception type, or you can use the error-code node to specify an HTTP status code. You can use the location node to set the custom page to be displayed in the event of the specified error.
-In Microsoft IIS, you can specify custom error pages for different HTTP status codes using the Custom Errors tab on a website’s Properties tab. A different custom page can be set for each status code, and on a perdirectory basis if required.
-In Apache, custom error pages can be configured using the ErrorDocument directive in httpd.conf: ErrorDocument 500 /generalerror.html
Protect Sensitive Information
Wherever possible, the application should not publish information that may be of use to an attacker, including usernames, log entries, and user profi le details. If certain users need access to this information, it should be protected by effective access controls and made available only where strictly necessary.
In cases where sensitive information must be disclosed to an authorized user (for example, where users can update their own account information), existing data should not be disclosed where it is not necessary. For example, stored credit card numbers should be displayed in truncated form, and password fields should never be prefilled, even if masked on-screen. These defensive measures help mitigate the impact of any serious vulnerabilities that may exist within the application’s core security mechanisms of authentication, session management, and access control.
Minimize Client-Side Information Leakage
Where possible, service banners should be removed or modified to minimize the disclosure of specific software versions and so on. The steps needed to implement this measure depend on the technologies in use. For example, in Microsoft IIS, the Server header can be removed using URLScan in the IISLockDown tool.
In later versions of Apache, this can be achieved using the mod_headers module. Because this information is subject to change, it is recommended that you consult your server documentation before carrying out any modifications.
No sensitive information should be hidden within these components. A skilled attacker can decompile or reverse engineer these components to effectively recover their source code.