S 4.399 Controlled integration of data and content in web applications

Initiation responsibility: Head of IT, IT Security Officer

Implementation responsibility: Developer, Administrator

A web application creates websites the content of which may be composed of different sources. This content is integrated dynamically in the form of files when creating the websites or generated by the web application. Since the user is provided with the finished website, he/she often does not see which source the displayed content was taken from. Therefore, the web application must ensure that only designated data and content is integrated and delivered to the user.

The content may be integrated using different techniques. Therefore, instructions regarding the safe use of common techniques are summarised in the following sections.

File inclusion

Commonly, parts of the delivered website from different files are integrated dynamically when websites are generated by the web application (e.g. a navigation bar). This reduces the maintenance efforts during modifications to the website (e.g. a new navigation entry). Here, only the administrator or privileged users of the web application should be able to change the content and the path of the files to be integrated. On the other hand, normal users should not be allowed to freely select or modify the files for integration (e.g. by means of changed parameters). For this reason, processing user input regarding the integration of files should be avoided as a matter of principle.

If the web application requires user input as a source for file inclusion, the designated path information about the source files should not be freely selectable. Users should not be able to specify the entire path but user input should be encapsulated in pre-defined path information.

Attacks such as Path Traversal attempt to implement the path on files worthy of protection by means of relative references (e.g. /../../../etc/passwd) and to leave the defined path information this way. In order to prevent such attacks, the user input should be filtered for undesired characters for manipulating the path (e.g. "/.." and "\..") (see also S 4.393 Comprehensive input and output validation for web applications).

Indices file names stored on the server are assigned to can be used instead of file names when selecting the source file. This way, an attacker cannot directly influence the file name and cannot directly integrate random content by manipulating the index.

Along with files on the server system, web applications may also integrate remotely stored resources using a network connection via URL (Remote File Inclusion). If possible, the integration of remote content should be prohibited completely. If integrating external content is necessary, the trustworthy origin of these files must be ensured in every case (e.g. on the basis of a white list limited to a server or a list of absolute URLs).

Use of file uploads

For many web applications, the user may transfer content using an upload function. A typical application case is uploading a profile photo. The uploaded data must be limited to the required file formats (e.g. only image files should be admissible for the profile photo). In this, the content of the file should be checked by analysing the file header, for example, along with a review of the file extension.

If possible, uploaded files should be stored to a directory which is not available using the web interface (e.g. outside of the root directory of the web server). This way, users are prevented from directly accessing their uploaded files (e.g. access to malicious scripts). If uploaded files are initially stored to a temporary directory, it must be ensured that other users are not allowed to access this file in an unauthorised manner.

If a web application provides the user with a file upload function, the following points must be observed:

• The functionality should only be available to logged in users, if possible.
• Uploaded files must not be stored to the root directory of the web server service. Either fix directory structures should be specified the folders and files can be created in or the files should be stored in a different context (such as in a database or a fixedly specified path). An attacker should not be able to exit the specified context.
• The users must not be allowed to modify the specified path for storing the uploaded files.
• The file size should be limited in order to provide protection against denial-of-service attacks.
• The authorisations for uploaded files should be configured restrictively in order to prevent unauthorised access. This is to prevent uploaded files of an attacker from being executed.
• An anti-virus program should check the uploaded files for malware.
• The selection of the file name should be restricted as follows:
• The file name, including the extension, should be limited to a fix number of characters (e.g. 200 characters).
• All invisible characters (e.g. control characters) and all coded variants of these characters should be removed from the file name (e.g. Unicode).
• All characters with a specific meaning for interpreters should be removed (e.g. ; : > < / \ . * % $).
• If possible, only alphanumeric characters and the full stop should be allowed for the file extension.

Integration of content from transferred parameters

Web applications frequently accept input in the form of parameters (e.g. from forms), process this input, and represent the input in the response (e.g. the search item during web search). An attacker may use this in order to manipulate the representation of the website by means of selected input. Therefore, all parameters used by the web application for representing websites require validation according to S 4.393 Comprehensive input and output validation for web applications.

Securely redirecting requests (redirect)

The redirection function of a web application should not allow for just any website as redirection destination so that the user is forwarded only to trustworthy, designated websites. For example, users being directed to a phishing site by means of a prepared link to the redirection function of the web application should be avoided.

The following items contain information about limitation options regarding redirection destinations:

• Limitation to local sites
  
  If redirecting to external websites is not necessary, the redirection destination may be checked for external addresses and only local sites may be admitted. In this case, only relative path information for destinations within the web application should be admissible input and the required host part should be added statically subsequently.
• Pre-defined redirection destinations
  
  If redirection to only known, static destinations is designed, these should be stored in a pre-defined list containing indices on the server. Thus, static index values are assigned to the destinations. Instead of the destination address, the client transmits an index value (e.g. from a drop-down list of a form) assigned to a listed destination address by the server.
• Manual confirmation
  
  Before redirecting, the user must check and confirm the destination address and therewith the trustworthiness of the redirection destination (e.g. by means of a shown redirection site). This way, the user is warned before leaving the web application and therefore the security context.
• Referrer test
  
  The referrer field of the HTTP request may be checked by the redirection function as an additional feature for intended use. Redirection should only be performed when the referrer field contains the address for a website of the web application with a reference to the redirection destination.

Integration of third party content

Data and content integrated by partners (e.g. advertisements) should be deemed less trustworthy as a matter of principle. Therefore, strong control of this content is required, since there is the risk that malicious code or untrustworthy content is embedded.

Review questions:

• Does the web application prevent any manipulation of resources to be integrated (e.g. File Inclusion and Remote File Inclusion)?
• Is the file upload using a possible upload function of the web application limited (e.g. to required file types) and are access and execution rights assigned restrictively?
• Is any deviation from the specified path for storing the files prohibited (e.g. by means of Path Traversal)?
• Are the destinations of the redirection functions of a web application restricted sufficiently (e.g. only local sites) and is the user informed when leaving the trustworthy domain?