These docs are for v1.1. Click to read the latest docs for v1.2.

HTML Injection

Severity: Medium
Test name: HTML Injection
Summary

The application stores a malicious code (injected HTML) in a long time storage (usually a database on the server side). The malicious code is returned to the client as part of the HTTP response from the server (to the same or different client/user), and the client interprets it as trustworthy and displays it. One of the basic targets for the HTML injection is to change the visible content of the application page. An attacker may use a stored HTML injection to inject a visual advertisement of a product that they want to sell. A similar case would be when the attacker injects malicious HTML to harm the reputation of the page.

Impact
  • Execution of unauthorized code or commands
  • Protection mechanism bypass
  • Application defacement
Location

The issue can be found in the source code on the server side.

Remedy suggestions

The protection against HTML injections is better to consider as general XSS protection in the application. The injection of a malicious code needs to be prevented regardless of the injected code type. Since the information is returned from the server side, the most effective solution is to prevent dangerous data from being created on the server.

General recommendations are the following:

  • Treat all user input as untrusted. All user input should be strictly filtered and precisely validated (the whitelist approach).
  • Encode the output data to prevent it from being interpreted as active content. Use the appropriate encoding technique depending on where the user input is to be used: HTML, URL, JavaScript, or CSS encoding. A common mistake is to use HTML entity encoding everywhere. It is important to understand that HTML entity encoding protects you from injections inside the body of the HTML document (like the <div> tag). But it doesn't work if you put untrusted data inside the <script> tag anywhere, or an event handler attribute like onmouseover, or inside CSS, or in a URL. You MUST use the encode syntax, which is suitable for the part of the HTML document you are putting untrusted data into. To make sure that these rules are properly implemented, we recommend using a security-focused encoding library, for example:
Classifications
  • CWE-80
  • CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N
References

https://cwe.mitre.org/data/definitions/80.html