What is Cross-Site Scripting and How to Prevent it?
This week, Blackwired would like touch on one of the oldest and yet most common and most dangerous purely technical vulnerabilities a business will face: Cross-Site Scripting, or XSS. XSS has to do with vulnerabilities in websites. By exploiting such vulnerabilities, a threat actor can inject malicious JavaScript code into a website, which is then executed when a user interacts with that website through their browser. Despite attacking client-side users, this is a server-side attack, where the code supporting the website is itself modified. This generally takes the form of either a reflected XSS attack, where the payload is stored separately, and the injected code redirects the user to the attacking payloads through an injected script, or a stored XSS attack, where the payload is embedded on the server, causing it to execute automatically without needing the additional traffic.
Cross-site scripting is often used to scrape information from user browsers. A great deal of sensitive information passes through browsers: not only passwords, but also PII used for security questions, sensitive data intended to be transmitted to authorized parties, and transactions containing financial data. If a threat actor achieves browser compromise, not only can all this data be harvested, but additionally the threat actor can initiate new actions on the browser with the data they’ve obtained, such as initiating wire transfers.
How can enterprises mitigate the risk of cross-site scripting? Since many begin with zero-day vulnerabilities, having an IT team keep tabs on newly discovered vulnerabilities and rapidly prepare patches is an important component. More generally, having a system in place for detecting malicious code in HTML inputs and sanitizing it before it can be executed as code is the most important basic protection. Enterprises are strongly advised to use trusted, well-maintained libraries for HTML sanitization in web applications to ensure robust protection.
