On the modern web, web applications on the client usually run JavaScript,

and they're built out of HTML and CSS.

However, even the simplest of websites that accept input

can be compromised when developers forget to sanitize user inputs.

According to OWASP, the third most common vulnerability in web applications is

cross-site scripting, or XSS.

XSS is exploited easily by attackers with little work,

leading to a wide-spread presence across the web.

However, XSS has a moderate impact.

Though, particularly severe cases have led to vulnerabilities on sites like Facebook

where any user could post on another user's wall without their permission.

When the researcher posted as Mark Zuckerberg,

after Facebook was slow to respond to his bug report.

XSS has flaws occur when the web application takes untrusted data and

sends it to the web browser, without proper validation or escaping.

XSS allows attackers to execute JavaScript in the victim's browser,

which can access any available cookies,

session tokens where any other sensitive information retained.

This also includes local store mechanisms used by frameworks like

AngularJS and React.

Even worse, malicious scripts can redirect users to malicious sites, and

completely compromise their computer by gaining access to the operating system

outside the browser.

In general, the two most common types of XSS flaws

around today are reflected XSS and stored XSS.

Reflected XSS is where the malicious data is echoed back by the server

in an immediate response to an HTTP request from the victim.

Stored XSS is where the malicious data is stored on the server or

in the browser and later gets embedded in HTML pages provided to the victim.

Each reflected and stored XSS can occur on the server or on the client.

When it's on the client, it is known as dom based XSS,

depending on when the malicious data gets injected in HTML markup.

Both reflected and stored XSS are critical vulnerabilities.

The stored XSS is far worse in most cases.

For example, imagine that an attacker discovers that they can maliciously

inject a script into tweets on Twitter when they're posted.

Also imagine this attacker has compromised the Twitter account of a user with

tens of thousands of followers, which as we discussed in our Treehouse course on

data security, it's not all that hard when the user has poorly chosen passwords.

With this kind of access, the attacker can post a tweet with a malicious script

hidden inside of it, which will then be stored inside of Twitter's database.

Then, when the tens of thousands of followers of this compromised user see

this tweet in their feed, the script will execute in each of their browsers,

which could do everything from download malware onto their machines,

to takeover their accounts.

Now you may be thinking, this seems far out of the realm of possibility.

However, studys conducted by prominent security firms have found that

even in2015, XSS likely exists in 47% of existing websites.

Hopefully, now you understand the consequences of a successful XSS attack.

So let's dig deeper into how these attacks actually work.

The only way for an attacker to run malicious JavaScript in a victim's browser

is to inject it into one of the pages that the victim uses.

Again, this can happen if the website directly includes

user input into its pages.

Since the attacker can insert a string,

they'll be treated as code by the victim's browser.

Here, we can see a simple server-side script is used to display the latest

comment on a website.

However, this script assumes that a comment consist of only text.

The sense user input is included directly,

an attacker could submit a comment with an embedded script.

At this point any user visiting the page would now see that embedded script

into the page.

Now, when a user's browser loads the page the user will be executing

whatever the attacker included inside those JavaScript script tags.

So that's how exercise works in practice and

it isn't only possible in a simple case we just demonstrated.

XSS occurs in the context when the developer forgets

to sanitize user input and most of this code can be inserted.

This means it can occur in HTML tags and attributes, CCS style sheets, XML tags and

last but not least any place with a client style application using JavaScript.

Now that you should have an understanding of how XSS works, let's look back at our

application and see a more complex storage XSS vulnerability in action.

And then we'll look at how to prevent them.