Cross-Site Scripting: Reflected

ABSTRACT

Sending unvalidated data to a web browser can result in the browser executing malicious code.

EXPLANATION

Cross-site scripting (XSS) vulnerabilities occur when:

1. Data enters a web application through an untrusted source. In the case of Reflected XSS, the untrusted source is typically a web request, while in the case of Persisted (also known as Stored) XSS it is typically a database or other back-end datastore.


2. The data is included in dynamic content that is sent to a web user without being validated.

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 ASP.NET Web Form reads an employee ID number from an HTTP request and displays it to the user.


<script runat="server">
...
EmployeeID.Text = Login.Text;
...
</script>


Where Login and EmployeeID are form controls defined as follows:


<form runat="server">
<asp:TextBox runat="server" id="Login"/>
...
<asp:Label runat="server" id="EmployeeID"/>
</form>




Example 2: The following ASP.NET code segment shows the programmatic way to implement Example 1 above.


protected System.Web.UI.WebControls.TextBox Login;
protected System.Web.UI.WebControls.Label EmployeeID;
...
EmployeeID.Text = Login.Text;




The code in these examples operates correctly if Login contains only standard alphanumeric text. If Login 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.

Initially this might not appear to be much of a vulnerability. After all, why would someone enter a URL that causes malicious code to run on their own computer? The real danger is that an attacker will create the malicious URL, then use e-mail or social engineering tricks in order to lure victims into clicking a link. When the victims click the link, they unwittingly reflect the malicious content through the vulnerable web application and back to their own computers. This mechanism of exploiting vulnerable web applications is known as Reflected XSS.

Example 3: The following ASP.NET Web Form queries a database for an employee with a given employee ID and prints the name corresponding with the ID.


<script runat="server">
...
string query = "select * from emp where id=" + eid;
sda = new SqlDataAdapter(query, conn);
DataTable dt = new DataTable();
sda.Fill(dt);
string name = dt.Rows[0]["Name"];
...
EmployeeName.Text = name;
</script>


Where EmployeeName is a form control defined as follows:


<form runat="server">
...
<asp:Label id="EmployeeName" runat="server">
...
</form>




Example 4: The following ASP.NET code segment is functionally equivalent to Example 3 above, but implements all of the form elements programmatically.


protected System.Web.UI.WebControls.Label EmployeeName;
...
string query = "select * from emp where id=" + eid;
sda = new SqlDataAdapter(query, conn);
DataTable dt = new DataTable();
sda.Fill(dt);
string name = dt.Rows[0]["Name"];
...
EmployeeName.Text = name;




As in Examples 1 and 2, these code examples function correctly when the values of name are well-behaved, but they nothing to prevent exploits if the values are not. Again, these 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.

As the examples demonstrate, XSS vulnerabilities are caused by code that includes unvalidated data in an HTTP response. There are three vectors by which an XSS attack can reach a victim:

- As in Examples 1 and 2, data is read directly from the HTTP request and reflected back in the HTTP response. Reflected XSS exploits occur when an attacker causes a user to supply dangerous content to a vulnerable web application, which is then reflected back to the user and executed by the web browser. The most common mechanism for delivering malicious content is to include it as a parameter in a URL that is posted publicly or e-mailed directly to victims. URLs constructed in this manner constitute the core of many phishing schemes, whereby an attacker convinces victims to visit a URL that refers to a vulnerable site. After the site reflects the attacker's content back to the user, the content is executed and proceeds to transfer private information, such as cookies that may include session information, from the user's machine to the attacker or perform other nefarious activities.

- As in Examples 3 and 4, the application stores dangerous data in a database or other trusted data store. The dangerous data is subsequently read back into the application and included in dynamic content. Persistent XSS exploits occur when an attacker injects dangerous content into a data store that is later read and included in dynamic content. From an attacker's perspective, the optimal place to inject malicious content is in an area that is displayed to either many users or particularly interesting users. Interesting users typically have elevated privileges in the application or interact with sensitive data that is valuable to the attacker. If one of these users executes malicious content, the attacker may be able to perform privileged operations on behalf of the user or gain access to sensitive data belonging to the user.

- A source outside the application stores dangerous data in a database or other data store, and the dangerous data is subsequently read back into the application as trusted data and included in dynamic content.



A number of modern web frameworks provide mechanisms for performing validation of user input. ASP.NET Request Validation and WCF are among them. To highlight the unvalidated sources of input, the rulepacks dynamically re-prioritize the issues reported by HP Fortify Static Code Analyzer by lowering their probability of exploit and providing pointers to the supporting evidence whenever the framework validation mechanism is in use. In case of ASP.NET Request Validation, we also provide evidence for when validation is explicitly disabled. We refer to this feature as Context-Sensitive Ranking. To further assist the HP Fortify user with the auditing process, the HP Fortify Software Security Research Group makes available the Data Validation project template that groups the issues into folders based on the validation mechanism applied to their source of input.

REFERENCES

[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 2013 - (OWASP 2013) A3 Cross-Site Scripting (XSS)

[4] Standards Mapping - OWASP Top 10 2004 - (OWASP 2004) A4 Cross Site Scripting

[5] Anti-Cross Site Scripting Library MSDN

[6] Standards Mapping - Security Technical Implementation Guide Version 3 - (STIG 3) APP3510 CAT I, APP3580 CAT I

[7] Standards Mapping - Security Technical Implementation Guide Version 3.4 - (STIG 3.4) APP3510 CAT I, APP3580 CAT I

[8] Standards Mapping - Security Technical Implementation Guide Version 3.5 - (STIG 3.5) APP3510 CAT I, APP3580 CAT I

[9] Standards Mapping - Security Technical Implementation Guide Version 3.6 - (STIG 3.6) APP3510 CAT I, APP3580 CAT I

[10] Standards Mapping - Security Technical Implementation Guide Version 3.7 - (STIG 3.7) APP3510 CAT I, APP3580 CAT I

[11] Standards Mapping - Web Application Security Consortium 24 + 2 - (WASC 24 + 2) Cross-site Scripting

[12] Standards Mapping - Common Weakness Enumeration - (CWE) CWE ID 79, CWE ID 80

[13] HTML 4.01 Specification W3

[14] Standards Mapping - SANS Top 25 2009 - (SANS 2009) Insecure Interaction - CWE ID 079

[15] Standards Mapping - SANS Top 25 2010 - (SANS 2010) Insecure Interaction - CWE ID 079

[16] Standards Mapping - SANS Top 25 2011 - (SANS Top 25 2011) Insecure Interaction - CWE ID 079

[17] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 - (PCI 1.2) Requirement 6.3.1.1, Requirement 6.5.1

[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 - (PCI 1.1) Requirement 6.5.4

[19] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 - (PCI 2.0) Requirement 6.5.7

[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 - (PCI 3.0) Requirement 6.5.7

[21] Standards Mapping - FIPS200 - (FISMA) SI

[22] Standards Mapping - NIST Special Publication 800-53 Revision 4 - (NIST SP 800-53 Rev.4) SI-10 Information Input Validation (P1)

[23] Understanding Malicious Content Mitigation for Web Developers CERT


Copyright 2014 Fortify Software - All rights reserved.
(Generated from version 2014.2.0.0007 of the Fortify Secure Coding Rulepacks)
desc.dataflow.dotnet.cross_site_scripting_reflected