Cross-site scripting (XSS)

- A cross-site scripting attack occurs when an attacker injects code, primarily HTLM and JavaScript into your webpages, so that other users browsers will execute it. It gets it's name because an attacker sends scripts across your website to someone else's browser. Cross-site scripting becomes possible when webpages output user supplied data in the HTML response without sanitizing the data first. Cross-site scripting, often abbreviated as XSS, is ranked as one of the top 10 security threats and is the most common web application security flaw. There are three types of cross-site scripting; reflected, stored, and DOM-based. Reflected attacks are the most common type. Let's look closer at them because they will help us to understand all three types. In a reflected XSS attack, an attacker puts JavaScript code to be run in a URL string or in the form data sent with the request. When the page loads, the script runs immediately, in the victim's browser. It's called reflected because it bounces right back. Let's look at an example. Suppose that a user clicks on a link, which sends a request for the register.php page and includes a URL parameter for email. The web application gets the value of email from the parameters, drops it into a page template, and then returns the resulting HTML. Now let's imagine, that an attacker posts a link somewhere. The link could be on webpage, perhaps as a blog comment or on Twitter, but often it will be a link sent in a phishing email. The link still sends a request to the register.php page, but instead of sending an email address, the attackers adds HTML and JavaScript. When the page processes the request, it inserts the value of the email parameter in the template, which includes malicious HTML and JavaScript. The JavaScript will be immediately executed by the user's browser. Now this example uses a harmless JavaScript popup alert. This is a good way to test for XSS. It's important to recognize that this alert is just a placeholder, a proof of concept. The actual JavaScript code could do anything. It can alter the page, it can access and steal the stored cookie data, which may contain stored login information, it can send additional browser requests, and download other scripts. The JavaScript may also be encoded to avoid detection. Here's an HTML link where the URL has been encoded. Most web languages will automatically decode it when it's received. Notice also that when it's decoded, it includes a reference to a JavaScript on another website. This script may contain hundreds of lines of code. If it's put into the return HTML, a user's browser immediately makes a request to that URL and executes the JavaScript file it receives. Stored and DOM-based attacks use the same principle as reflected attacks. The difference is that they're not immediate and do not originate from links. Stored cross-site scripting attacks occur when a malicious JavaScript is planted in storage, such as databases, files, cookies, or sessions. It's like planting a landmine in the application data. When the data is retrieved and dropped into HTML, the script will execute. Imagine submitting JavaScript in a customer feedback form. When an admin reviews the feedback, the JavaScript will be triggered. A DOM-based cross-site scripting attack, embeds a script into the existing page. In HTML the current page is known as the DOM, short for document object model. DOM-based attacks are a result of the trend toward having web pages, which handle a lot of user interaction, on the client side using JavaScript. Instead of sending a request to a remote server, the page already has the code necessary to respond to an action. A DOM-based attack is similar to a reflected attack but it works with the existing page instead of using a server to return a response. To prevent cross-site scripting, begin with a map of data passageways and exposure points. The places where data is output are primary areas for concern. The places where data is input, transferred, and stored can help you to see the big picture and not overlook something. After that, the first defense it to use the best practices we've already discussed for incoming data: Write validations to enforce expectations. Use a allow-lists when you can; if a value's required to be a four digit number, well then it can't contain a script. The primary defense will be to sanitize all data before output. The correct sanitizing technique depends on the output destination. There are five primary output types to monitor. Use HTML sanitization if the data will be used in HTML. Use JavaScript sanitization if it will be used in JavaScript, and so on. Another important defense is to use HTTPOnly cookies. This prevents JavaScript from accessing and stealing cookie data. You do this by adding the HTTPOnly option when you set a cookie. Most web languages and frameworks have cookie functions that accept an optional parameter to enable it. Remember, it's on a per cookie basis, and you should also use it on cookies which keep track of your session files. A strong layer of defense against cross-site scripting attacks, is to define a content security policy. A CSP provides instructions to a browser about which types of resources can be used and which websites are allowed to provide them. It can prevent both the loading of remote and inline JavaScript. It's a best practice to send the policy in the header of a HTTP response, but it could also be in the HTML head in a meta attack. This example policy restricts scripts and plugins to the current domain only. It would not permit remote loading of JavaScripts. The CSP acts as an allow list for the browser. You could add domains that should be allowed to provide resources. Here, I've added a fake domain called analytics.com, to the allow list, so it can provide JavaScript code. CSPs can regulate other resources, such as style sheets, images, fonts, audio and video. You can learn more about content security policies at content-security-policy.com. Google also has a tool which examines the CSP of websites and makes recommendations for improvements. The combined defenses of validating input, sanitizing output, using HTTPOnly cookies, and setting a content security policy, will be a good protection against cross-site scripting.