Cross-Site Scripting (XSS)

Jul 09 2021

XSS Classification by Attack Vector
XSS classification by way of exposure
Example of XSS vulnerability
Additional Resources

XSS (cross-site scripting) is a type of attack on web applications. Malicious code is injected into a web page. This code interacts with the attacker's web server. Malicious code can get to a page as a vulnerability in the web server, or on a user's computer. When a user opens an affected web page in a browser, the introduced code will run. For example, it can steal sensitive user data stored in the browser or on the page.

XSS is subdivided into several types by attack vector and way of exposure.

XSS Classification by Attack Vector

Reflected XSS (non-persistent). In this type of attack, a malicious script hits the page and executes when the page opens due to lack of proper processing. Most often the code appears in the page through HTTP query parameters or through HTML forms.
Stored XSS (persistent). This type of XSS is more dangerous than reflected. With this type of XSS, an attacker introduces malicious code to the server. Most often, data with malicious code is saved to a database and used on a page. As a result, every time a page is displayed in a browser, you run the introduced code.
XSS in the DOM model. In this type, malicious code appears when a JavaScript script executes in the user's browser and changes the DOM of the site being attacked. This is why this code executes in terms of the site.

XSS classification by way of exposure

Active XSS. As a user, you don't need any action other than to open the page to execute the malicious script.
Passive XSS. As a user, you need additional actions other than to open a page in a browser, such as hover or click on an HTML page item. This will execute the malicious code.

Example of XSS vulnerability

protected void Page_Load(object sender, EventArgs e)
{
  Response.Cookies.Add(new HttpCookie("User_Cookie_Key", 
                                      "User_Cookie_Value"));

  const string CenterAlignFormat = "<p style='text-align: center'>{0}</p>";

  var userName = Request.Params["userName"];                          // <=
  
  string message;
  if (string.IsNullOrWhiteSpace(userName))
  {
    message = string.Format(CenterAlignFormat, 
                            "Empty 'userName' parameter");
  }
  else
  {
    message = string.Format(CenterAlignFormat, 
                            $"'{userName}' data has been processed.");
  }
  
  Response.Write(message);                                            // <=
}

PVS-Studio warning: V5610 Possible XSS vulnerability. Potentially tainted data in the 'message' variable might be used to execute a malicious script. Default.aspx.cs 61

Data from the UserName query parameter is used directly without additional processing to write to Response:

This allows an attacker to sneak a user a link with malicious code that, for example, will steal a cookie from the user's browser:

In the example above, cookies are simply displayed as a demonstration using the alert(document.cookie) expression. There is nothing stopping an attacker from sending them to their server, though. By taking advantage of stolen cookies, an attacker can access a user's account. This allows them to, for example, steal sensitive data or commit malicious acts on behalf of a user.

To fix such a XSS vulnerability, you only need to encode HTML entities in a message before writing to Response using a special method:

protected void Page_Load(object sender, EventArgs e)
{
  ....
  else
  {
    var encodedUserName = 
      System.Net.WebUtility.HtmlEncode(userName);
    message = string.Format(CenterAlignFormat,
                            $"'{encodedUserName}' data has been processed.");
  }
  Response.Write(encodedUserName);
}

This way, when you open a link with a malicious script, the latter will simply appear on the page but will not be executed: