XSS: How It Works

On the modern web, web applications on the client usually run JavaScript, 0:00 and they're built out of HTML and CSS. 0:04 However, even the simplest of websites that accept input 0:07 can be compromised when developers forget to sanitize user inputs. 0:11 According to OWASP, the third most common vulnerability in web applications is 0:15 cross-site scripting, or XSS. 0:19 XSS is exploited easily by attackers with little work, 0:22 leading to a wide-spread presence across the web. 0:26 However, XSS has a moderate impact. 0:29 Though, particularly severe cases have led to vulnerabilities on sites like Facebook 0:32 where any user could post on another user's wall without their permission. 0:37 When the researcher posted as Mark Zuckerberg, 0:43 after Facebook was slow to respond to his bug report. 0:45 XSS has flaws occur when the web application takes untrusted data and 0:49 sends it to the web browser, without proper validation or escaping. 0:54 XSS allows attackers to execute JavaScript in the victim's browser, 0:58 which can access any available cookies, 1:02 session tokens where any other sensitive information retained. 1:04 This also includes local store mechanisms used by frameworks like 1:08 AngularJS and React. 1:12 Even worse, malicious scripts can redirect users to malicious sites, and 1:13 completely compromise their computer by gaining access to the operating system 1:18 outside the browser. 1:21 In general, the two most common types of XSS flaws 1:23 around today are reflected XSS and stored XSS. 1:27 Reflected XSS is where the malicious data is echoed back by the server 1:31 in an immediate response to an HTTP request from the victim. 1:36 Stored XSS is where the malicious data is stored on the server or 1:40 in the browser and later gets embedded in HTML pages provided to the victim. 1:44 Each reflected and stored XSS can occur on the server or on the client. 1:49 When it's on the client, it is known as dom based XSS, 1:54 depending on when the malicious data gets injected in HTML markup. 1:57 Both reflected and stored XSS are critical vulnerabilities. 2:02 The stored XSS is far worse in most cases. 2:05 For example, imagine that an attacker discovers that they can maliciously 2:09 inject a script into tweets on Twitter when they're posted. 2:13 Also imagine this attacker has compromised the Twitter account of a user with 2:16 tens of thousands of followers, which as we discussed in our Treehouse course on 2:20 data security, it's not all that hard when the user has poorly chosen passwords. 2:25 With this kind of access, the attacker can post a tweet with a malicious script 2:29 hidden inside of it, which will then be stored inside of Twitter's database. 2:33 Then, when the tens of thousands of followers of this compromised user see 2:37 this tweet in their feed, the script will execute in each of their browsers, 2:41 which could do everything from download malware onto their machines, 2:45 to takeover their accounts. 2:48 Now you may be thinking, this seems far out of the realm of possibility. 2:50 However, studys conducted by prominent security firms have found that 2:54 even in2015, XSS likely exists in 47% of existing websites. 2:58 Hopefully, now you understand the consequences of a successful XSS attack. 3:03 So let's dig deeper into how these attacks actually work. 3:08 The only way for an attacker to run malicious JavaScript in a victim's browser 3:12 is to inject it into one of the pages that the victim uses. 3:16 Again, this can happen if the website directly includes 3:20 user input into its pages. 3:23 Since the attacker can insert a string, 3:24 they'll be treated as code by the victim's browser. 3:27 Here, we can see a simple server-side script is used to display the latest 3:30 comment on a website. 3:34 However, this script assumes that a comment consist of only text. 3:35 The sense user input is included directly, 3:39 an attacker could submit a comment with an embedded script. 3:41 At this point any user visiting the page would now see that embedded script 3:44 into the page. 3:48 Now, when a user's browser loads the page the user will be executing 3:50 whatever the attacker included inside those JavaScript script tags. 3:54 So that's how exercise works in practice and 3:58 it isn't only possible in a simple case we just demonstrated. 4:00 XSS occurs in the context when the developer forgets 4:04 to sanitize user input and most of this code can be inserted. 4:07 This means it can occur in HTML tags and attributes, CCS style sheets, XML tags and 4:10 last but not least any place with a client style application using JavaScript. 4:16 Now that you should have an understanding of how XSS works, let's look back at our 4:21 application and see a more complex storage XSS vulnerability in action. 4:25 And then we'll look at how to prevent them. 4:29