Relying on HTML, XML and other types of encoding to validate user input can result in the browser executing malicious code.
The use of certain encoding function modules, such as cl_http_utility=>escape_html
, will prevent some, but not all cross-site scripting attacks. Depending on the context in which the data appear, characters beyond the basic <, >, &, and " that are HTML-encoded and those beyond <, >, &, ", and ' that are XML-encoded may take on meta-meaning. Relying on such encoding function modules is equivalent to using a weak blacklist to prevent cross-site scripting and might allow an attacker to inject malicious code that will be executed in the browser. Because accurately identifying the context in which the data appear statically is not always possible, the HP Fortify Secure Coding Rulepacks report cross-site scripting findings even when encoding is applied and presents them as Cross-Site Scripting: Poor Validation issues.
Cross-site scripting (XSS) vulnerabilities occur when:
1. Data enters a web application through an untrusted source. In the case of Reflected XSS, an untrusted source is most frequently a web request, and in the case of Persistent (a.k.a. Stored) XSS -- it is the results of a database query.
2. The data is included in dynamic content that is sent to a web user without being validated for malicious code.
The malicious content sent to the web browser often takes the form of a segment of JavaScript, but may also include HTML, Flash or any other type of code that the browser may execute. The variety of attacks based on XSS is almost limitless, but they commonly include transmitting private data like cookies or other session information to the attacker, redirecting the victim to web content controlled by the attacker, or performing other malicious operations on the user's machine under the guise of the vulnerable site.
Example 1: The following ABAP code segment reads an employee ID, eid
, from an HTTP request, HTML-encodes it, and displays it to the user.
...
eid = request->get_form_field( 'eid' ).
...
CALL METHOD cl_http_utility=>escape_html
EXPORTING
UNESCAPED = eid
KEEP_NUM_CHAR_REF = '-'
RECEIVING
ESCAPED = e_eid.
...
response->append_cdata( 'Employee ID: ').
response->append_cdata( e_eid ).
...
eid
contains only standard alphanumeric text. If eid
has a value that includes meta-characters or source code, then the code will be executed by the web browser as it displays the HTTP response.
...
DATA: BEGIN OF itab_employees,
eid TYPE employees-itm,
name TYPE employees-name,
END OF itab_employees,
itab LIKE TABLE OF itab_employees.
...
itab_employees-eid = '...'.
APPEND itab_employees TO itab.
SELECT *
FROM employees
INTO CORRESPONDING FIELDS OF TABLE itab_employees
FOR ALL ENTRIES IN itab
WHERE eid = itab-eid.
ENDSELECT.
...
CALL METHOD cl_http_utility=>escape_html
EXPORTING
UNESCAPED = itab_employees-name
KEEP_NUM_CHAR_REF = '-'
RECEIVING
ESCAPED = e_name.
...
response->append_cdata( 'Employee Name: ').
response->append_cdata( e_name ).
...
name
are well-behaved, but it does nothing to prevent exploits if they are not. Again, this code can appear less dangerous because the value of name
is read from a database, whose contents are apparently managed by the application. However, if the value of name
originates from user-supplied data, then the database can be a conduit for malicious content. Without proper input validation on all data stored in the database, an attacker can execute malicious commands in the user's web browser. This type of exploit, known as Persistent (or Stored) XSS, is particularly insidious because the indirection caused by the data store makes it more difficult to identify the threat and increases the possibility that the attack will affect multiple users. XSS got its start in this form with web sites that offered a "guestbook" to visitors. Attackers would include JavaScript in their guestbook entries, and all subsequent visitors to the guestbook page would execute the malicious code.[1] Standards Mapping - OWASP Top 10 2007 - (OWASP 2007) A1 Cross Site Scripting (XSS)
[2] Standards Mapping - OWASP Top 10 2010 - (OWASP 2010) A2 Cross-Site Scripting (XSS)
[3] Standards Mapping - OWASP Top 10 2004 - (OWASP 2004) A4 Cross Site Scripting
[4] Standards Mapping - Security Technical Implementation Guide Version 3 - (STIG 3) APP3510 CAT I, APP3580 CAT I
[5] Standards Mapping - Web Application Security Consortium 24 + 2 - (WASC 24 + 2) Cross-site Scripting, Content Spoofing
[6] Standards Mapping - Common Weakness Enumeration - (CWE) CWE ID 82, CWE ID 83, CWE ID 87, CWE ID 692
[7] HTML 4.01 Specification W3
[8] Standards Mapping - SANS Top 25 2009 - (SANS 2009) Insecure Interaction - CWE ID 116
[9] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 - (PCI 1.2) Requirement 6.3.1.1, Requirement 6.5.1
[10] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 - (PCI 1.1) Requirement 6.5.4
[11] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 - (PCI 2.0) Requirement 6.5.7
[12] Standards Mapping - FIPS200 - (FISMA) SI
[13] Understanding Malicious Content Mitigation for Web Developers CERT