ConceptDBISAI-written · not yet proofread

Code Injection Protection

Also Code Injection · Cross-Site Scripting · XSS

Code injection (cross-site scripting, XSS) is an exploit in which attacker-controlled input is inserted into a web page as HTML/JavaScript and executed in the victim's browser; protection means never inserting untrusted content as HTML, i.e. writing it as text or sanitizing it first.

Know these firstDOM Manipulation

Properties#

Attack vectors#

If user input is inserted via .innerHTML (or jQuery .html()):

// UNSAFE: attacker can inject tags or event handlers
element.innerHTML = userInput;

the input is parsed as HTML. Examples from the lecture and beyond:

Search box: enter <a href="javascript:alert('Hacked!')">Click me!</a>; the result page shows a link that runs JavaScript.
Link in a mail: ...index.html?user=guest<script>alert("Ha!")</script>. The <script> part can be made less suspicious by URL-encoding it: ...index.html?user=guest%3C%73%63%72%69%70....
Forum post: I have a question<script>…sends user info by mail to evil person…</script>. The script does not show on the page but is executed by every client viewing the post; it could, e.g., open a Gmail tab and read private mail.
Event handler: <img src=x onerror="alert('hacked')"> runs its handler as soon as the image fails to load.

It is one of three kinds of web-app vulnerabilities, next to access to private data (HTTP Server) and leaking trusted information to untrusted sites (Same-Origin Policy); overview: the OWASP Top Ten.

Prevention methods#

Use .textContent instead of .innerHTML (jQuery: .text() instead of .html()). The content is treated as plain text: <script> becomes visible text, not executed code.
```
// SAFE
document.querySelector("#result").textContent = userInput;
```

Input sanitization via regex (whitelist the allowed characters):

// Remove all characters except letters, comma, and space
let safe = userInput.replace(/[^A-Za-z, ]/g, "");

General principle: never trust user input; always escape or sanitize before inserting into the DOM; prefer text-only insertion (.textContent, .text()) over HTML insertion (.innerHTML, .html()).

.textContent escapes all HTML; .innerHTML parses the string as HTML, so injected markup and event handlers become live.
Server-side templates need the same care: a server that substitutes the raw query into %QUERY%/%RESULT% (HTML Form > Template variables) injects it into the page. Sheet 10 asks for an option --party-pooper that protects the app against code injection.

Example#

ExampleWS19/20, T3.2 (jQuery, sanitized)

The backend returns a JSON array of strings that, for non-malicious responses, consist of A-Z, a-z and spaces.

$.get(url, function(result) {
  $("#result").html(result.join(", ").replace(/[^A-Za-z, ]/g, ""))
})

A malicious element <img src=x onerror=alert(1)> becomes img srcx onerroralert and is harmless. Equivalent and simpler: resultEl.textContent = result.join(", ").

Sources#

Slides 10, p. 17 (vulnerabilities, OWASP), pp. 19–20 (code injection)
DBIS_VL10 > Motivation, DBIS_VL10 > Code injection, DBIS_VL10 > Communicating with other machines via fetch (the innerHTML hole in search.js)
Sheet 10, Exercise 1.5
DBIS Exam WS1920 (not published) T3.2

Connections

Prerequisites know first1

DOM Manipulation

Mentioned in inline links7

AJAX and Fetch API
Every keystroke sends a request; the server answers with a JSON array, which is joined and shown. Writing query via innerHTML is a code-injection hole. §
DOM Manipulation
Always prefer .textContent over .innerHTML for untrusted content, to prevent code injection. §
HTML Form
%QUERY% is replaced by the query, %RESULT% by the result (e.g. the fuzzy prefix matches). Substituting raw user input here is a code-injection risk. §
Same-Origin Policy
The SOP addresses the third kind of web-app vulnerability, “communication of trusted information to an untrusted site”; the other two are access to private data (HTTP Server) and executing injected code (Code Injection Protection). §
URL Encoding
URL encoding hides content from the human eye but not from the browser: %3C%73%63%72%69%70%74 is <script (Code Injection Protection). §
VL10 – Web Applications, Part 2
Exploit that makes a web site execute malicious code, by getting attacker-controlled input inserted into the page as HTML/JavaScript (Code Injection Protection). §
Code Injection Protection — injected <script>/javascript: content via search box, links and forum posts §
Web Applications
Code Injection Protection — untrusted input inserted as HTML executes; use text insertion or sanitize §
| Execution of injected code | <script> in a search box, link or forum post | .textContent instead of .innerHTML, sanitize, escape templates | Code Injection Protection | §

Search in these mentions →