When the attacker posts this comment on a victim’s profile, it is stored in the database. The next time the victim views their profile, the malicious comment is displayed on the page and the victim’s browser executes the script tag, displaying an alert box with the message “Stored XSS attack!”

Unlike a reflected XSS attack, the malicious code is not included in the URL parameter and is not dependent on the victim clicking on a malicious link. Instead, the code is stored on the server and is executed every time the victim views their profile, potentially allowing the attacker to steal sensitive information or perform unauthorized actions on behalf of the victim without their knowledge.

DOM-based XSS: In this type of attack, the attacker injects malicious code into a webpage that is executed by the user’s browser, usually through JavaScript.Let’s say there is a webpage that contains a search box, and the search results are displayed dynamically using JavaScript. The JavaScript code that handles the search functionality contains a vulnerability that allows an attacker to inject malicious code into the DOM.

For example, consider the following search box:

<input type="text" id="searchBox">
<button onclick="search()">Search</button>
<div id="results"></div>

HTML

And the following JavaScript code that handles the search functionality:

function search() {
  var query = document.getElementById("searchBox").value;
  var resultsDiv=cument.getElementById("results");
  resultsDiv.innerHTML = "Search results for:" + query;
}

JavaScript

The vulnerability here is that the search term entered by the user is directly added to the DOM using the innerHTML property, without being properly sanitized or encoded.

An attacker can exploit this vulnerability by entering a search term that contains malicious JavaScript code, such as:

<script>alert('DOM-based XSS attack!')</script>

HTML

If the user enters this search term and clicks the search button, the attacker’s code will be executed by the victim’s browser, displaying an alert box with the message “DOM-based XSS attack!”

Preventing Cross-Site Scripting in JavaScript

Sanitize User Input

The first step in preventing XSS is to sanitize all user input before it is displayed on the webpage. This can be done using a variety of techniques, including input validation and output encoding.

Input validation involves checking user input to check that it meets certain criteria. For example, if you are expecting a user to enter an email address, you can check that the input contains the “@” symbol and a domain name. If the input does not meet these criteria, it should be rejected.

Output encoding involves encoding user input so that it is not interpreted as HTML or JavaScript code. This can be done using a variety of techniques, including HTML escaping and JavaScript encoding.

Here is an example of HTML escaping in JavaScript:

function escapeHTML(str) {
  return str.replace(/[&<>"'\/]/g, function (char) (
  switch (char) {
    case '&':
      return '&amp;';
    case '<':
      return '&lt;';
    case '>':
      return '&gt;';
    case '"':
      return '&quot;';
    case '\':
      return '&#39;';
    case '/':
      return '&#x2F;';
    default:
      return char;
    }
  });
}

JavaScript

This function takes a string as input and replaces any characters that have special meaning in HTML (such as < and >) with their corresponding HTML entities.

Use a Content Security Policy

A Content Security Policy (CSP) is a security feature that allows you to specify which sources of content are allowed to be loaded on your webpage. This can help prevent XSS attacks by preventing malicious code from being loaded from untrusted sources.

Here is an example of how to use CSP in JavaScript:

// Set the Content Security Policy header
app.use(function (req, res, next) {
  res.setHeader('Content-Security-Policy, "default-src 'self' ");
  next();
});

// Load scripts only from trusted sources
<script src="[https://trusted-site.com/script.js](https://trusted-site.com/script.js)"></script>

JavaScript

This code sets the Content-Security-Policy header to only allow content from the same domain as the webpage. It also specifies that scripts can only be loaded from a trusted source.

Another example is a CSP with an HTTP header:

Content-Security-Policy: default-src 'self'

HTTP

This header specifies that only content from the same origin as the page is allowed to be loaded.

Use Input Validation

The most effective way to prevent cross-site scripting is to validate all user input before it is displayed on a page. This can be achieved using regular expressions or other validation techniques to check that the input only contains allowed characters and is not malicious. For example, to validate a user’s email address, you can use the following regular expression:

function validateEmail (email) {
  const pattern = /^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$/;
    return pattern.test(email);
}

JavaScript

This function uses a regular expression to validate that the email address contains only valid characters and follows the standard email address format.

Encode User Input

Another way to prevent cross-site scripting is to encode all user input before it is displayed on a page. Encoding involves converting special characters into their corresponding HTML entities, which are not executable by a web browser. For example, to encode a user’s input, you can use the following function:

function encodeInput (input)  {
  const encoded = document.createElement('div');
  encoded.innerText = input;
  return encoded.innerHTML;
}

JavaScript

This function creates a new div element and sets its inner text to the user input. The inner HTML of the div element is then returned, which contains the encoded input.

Using HTTP-Only Cookies

HTTP-only cookies are cookies that can only be accessed by the web server, not by client-side JavaScript code. This prevents attackers from stealing sensitive information, such as login credentials, by injecting malicious code into your webpages.

Here is an example of using HTTP-only cookies in JavaScript:

document.cookie = "sessionID=12345; HttpOnly";

JavaScript

This code sets a cookie named “sessionID” with a value of “12345” and sets the HttpOnly flag to true. This makes it so that the cookie can only be accessed by the web server and not by client-side JavaScript code.

Conclusion

In conclusion, cross-site scripting (XSS) is a serious security vulnerability that allows attackers to inject malicious code into webpages that can steal sensitive information or perform unauthorized actions on behalf of the victim. There are three types of XSS attacks: Reflected XSS, Stored XSS and DOM-based XSS.

To prevent XSS attacks, it is crucial to sanitize all user input before it is displayed on a webpage using techniques like input validation and output encoding. It is also essential to use a Content Security Policy (CSP) and input validation to help establish that only trusted sources and allowed characters are loaded on a webpage. By implementing these measures, developers can significantly reduce the risk of XSS attacks and protect their users’ sensitive information.