S 4.400 Restrictive disclosure of security-related information in web applications

Initiation responsibility: Persons responsible for individual applications, Specialists Responsible

Implementation responsibility: Developer, Administrator

Websites and replies from the web application can contain security-related information which can be used by attackers to bypass security mechanisms and to exploit vulnerabilities. Therefore, no security-related information must be displayed which is not absolutely necessary for the operation and use of the web application.

The following examples illustrate which information may contain security-related information and how its disclosure can be prevented.

No security-related information in error messages

If an error occurs during operation of the web application (e.g. access error) the user should receive neutral error messages. The error message must not permit direct conclusions regarding the techniques and security mechanisms employed or the web application state.

The following examples show information which should not be contained in error messages:

• Stack traces and debugging information
• Messages such as "User name invalid" or "Password invalid" (instead of general error messages such as "User name or password invalid")
• Error messages passed on by background systems such as, for example, SQL error messages of a database instead of a message "Error while verifying the access data"
• Error codes instead of, for example, the message "An error occurred"

In the event of a failed authentication attempt, for example, a general message such as "Incorrect or invalid access data" should always be displayed regardless of the validity of the user name so that an attacker can not deduce the existence of user accounts.

In general, different HTML code can result in the same output in the web browser. For example, two HTML pages with a different number of spaces are displayed in the same way in the browser even though they have a different HTML code. Therefore, it must be ensured that the error messages are not only identical in the browser display but also in the HTML code. This is to prevent an attacker being able to deduce the validity of partial input (e.g. valid user name with incorrect password) due to a modified HTML code.

For additional information on error handling see S 4.395 Error handling by web applications.

Avoidance of security-related comments in delivered websites

Comments may be written in the HTML code during the development of websites. These comments may contain security-related information (e.g. to do lists, version numbers, access data or uninterpreted source code) which can be easily read by the user as HTML comments in the website. Therefore, it must be ensured that no security-related information is contained in the comments. Ideally, no comments should be used in the source texts and HTML code of productive web applications.

Restricted access to documentation

Information in the documentation of a web application (e.g. documents for administration of the web application) can point out potential vulnerabilities (e.g. standard users after installation) to an attacker and be misused to prepare attacks. Therefore, dispensable documentation concerning the web application and the associated components (e.g. database) should be deleted. If the documentation of the web application is available online, then the only the relevant target group should be able to access it. For example, it should not be possible to access the documentation for administration from the internet.

Deletion of unneeded files

During live operation of a web application, often files are created which are not required for the productive operation (e.g. temporary files or backup files). These files can contain information that is critical to security (e.g. test results) or offer functions (e.g. test tools for determination of version numbers of the libraries used) which can be used for attacks on the web application.

Furthermore, it must be taken into account that especially in temporary files or backup files, other file extensions (e.g. *.bak files as backup copy of an editor) are often used. If these files are called up by the web server it may be possible that these files can no longer be interpreted due to the unknown file extension and the source text of the web application is delivered instead.

Therefore, all files not required for productive operation of the web application must be deleted. Furthermore, it should be checked regularly whether new files were created and if these can be deleted. If this is not possible the access to these files by the web application can be blocked.

Secure detection by external search engines

Search engines use so-called agents (also referred to as robots or crawlers) for indexation of new or modified content in the network. By means of the file robots.txt in the root directory of the web application, these agents can be instructed to ignore indicated resources (e.g. paths) of the web application. In this manner, information requiring protection can be excluded from the indexation in the search engine. The confidential resources (e.g. directory paths) should be executed in the file robots.txt under the directive "Disallow". This prevents the agents from indexing the listed resources.

To avoid the entries in the file robots.txt making the attacker aware of security-critical resources of the web application, all directories requiring protection should be summarised in a separate directory of the web application. This directory should be the only entry in the file robots.txt so that the latter does not contain any internal directory structures with security-related information.

Avoidance of product and version information

In many cases, replies and output by the individual components of the web application contain information on product names and version numbers. This information can be contained, for example, in HTTP headers or in comments in the HTML source text of the delivered websites. An attacker can use this information to search specifically for known vulnerabilities of the product and use these to attack the web application. Therefore, information regarding the products and versions used should be avoided (e.g. application framework, web server).

Not using absolute path information

Absolute path information often allows conclusions regarding the internal structure and the layout of the web application. For example, it is possible to determine the storage location of information requiring protection. Therefore, no absolute path information of the web application should be disclosed whenever this is possible.

Review questions:

• Is only information disclosed which is necessary for the operation or use of the web application?
• Are all error messages displayed by the web application to the user neutral and is their source text identical?
• Is security-related information in websites (e.g. in comments) deleted prior to delivery by the web application to the users?
• Is access to the documentation of the web application only possible for the relevant target group?
• Are all files that are not required for operation of the web application deleted prior to the initial productive operation of the web application and are regular checks for unneeded files performed?
• Does the file robots.txt only contain URLs containing no security-related information of the web application?