IDS33-PL. Sanitize untrusted data passed across a trust boundary

Many programs accept untrusted data originating from arbitrary users, network connections, and other untrusted sources and then pass the (modified or unmodified) data across a trust boundary to a different trusted domain. Frequently the data is in the form of a string with some internal syntactic structure, which the subsystem must parse. Such data must be sanitized both because the subsystem may be unprepared to handle the malformed input and because unsanitized input may include an injection attack.

In particular, programs must sanitize all string data that is passed to command interpreters or parsers so that the resulting string is innocuous in the context in which it is parsed or interpreted.

Many command interpreters and parsers provide their own sanitization and validation methods. When available, their use is preferred over custom sanitization techniques because custom developed sanitization can often neglect special cases or hidden complexities in the parser. Another problem with custom sanitization code is that it may not be adequately maintained when new capabilities are added to the command interpreter or parser software.

Noncompliant Code Example (XSS)

This noncompliant code example demonstrates a XSS exploit. This code uses the CGI library to display a web form, and is adopted from an example from the CGI.pm documentation The form queries the user for a name, and displays the resulting name on the page when the user clicks Submit.

use warnings;
use strict;
use CGI qw(:standard);

print header;
print start_html('A Simple Example'),
  h1('A Simple Example'),
  start_form,
  "What's your name? ",textfield('name'),
  submit,
  end_form,
  hr;

if (param()) {
  print "Your name is: ",em(param('name')),
    hr;
}
print end_html;

When fed a benign name, such as Larry, this script works well enough:

But this code will happily parse image tags, HTML markup, Javascript, or any other commands an attacker may wish to send. The following picture demonstrates a remote image being loaded into the page on the request of the attacker:

In this case the trust boundary exists between the untrusted data and the CGI script, whereas the trusted domain is the web browser; or rather the HTML parsing and rendering engine within the web browser.

Compliant Solution (XSS)

To prevent injection of HTML, Javascript, or malicious images, any untrusted input must be sanitized. This compliant solution sanitizes the input using the escapeHTML() subroutine from the CGI library.

# rest of code unchanged

if (param()) {
  print "Your name is: ", em(escapeHTML(param('name'))),
    hr;
}
print end_html;

When fed the malicious image tag demonstrated above, the escapeHTML() subroutine sanitizes characters that might be misinterpreted by a web browser, causing the name to appear exactly as it was entered:

Risk Assessment

Related Guidelines

Bibliography

[CPAN] Stosberg, Mark. CGI
Vulnerability Note VU#246409: "Input validation error in quikstore.cgi allows attackers to execute commands"

Vulnerability Note VU#282403: "AdCycle does not adequately validate user input thereby allowing for SQL injection"

IDS32-PL. Validate any integer that is used an array index      01. Input Validation and Data Sanitization      02. Declarations and Initialization