 Welcome to Cross Site Scripting Defined. Today we'll learn about the various forms of Cross Site Scripting, also known as XSS. Cross Site Scripting is a significant issue across all web programming technologies. When you are creating a website, you may want to think about how to prevent XSS. It's important to understand so that you can guard against it and even test your site for vulnerabilities. An estimated 90% of all websites have at least one vulnerability, and of these, 70% are XSS-related. Websites are vulnerable anywhere script can be injected, for example search fields, cookies, forums, or even feedback forums and comment sections. One way to protect your site might be to eliminate the ability to make hyperlinks, use divs, and pop-ups. A website is vulnerable if it allows a user to input text that is immediately visible on the page. For example, a search result or a custom error message. The goal of XSS is to insert a malicious script into a site and get the page to render it. Typically this is JavaScript or HTML code. Let's look at an example. A hacker will find a vulnerable site and test it by typing something into the URL and seeing if it has passed into the page. You can use the message command and see if you want the text to be prominent. H1 is a great place to put it. But what if the hacker wants a wider distribution? He might decide to put the code into an email and distribute it to a number of people. When people clicked on the link in the email, the code would be activated and pass the payload into the web page. Anything that is server-side code has the potential to be written in a way that is XSS. This is because the website doesn't know what is content and what is code. Hackers get crafty and will write a URL to pass in funny messages into a web page. They may get really clever and write code to pass in a link that might say, Click here and win a prize. When in fact there is no prize. What actually happens is that the user is passed through to an evil website. Another place XSS might occur is on a blog. A hacker might use the comment box to inject harmful code. A static web page, say that ends in HTML, can't be cross-site scripted. In order to understand today's terminology, it helps to understand the history. Before 2012, XSS was described as either persistent or non-persistent. So what is a persistent or stored XSS attack? A stored attack is when injures code is injected into an existing and trusted website. It's called persistent or stored because the code then lives there and continues to execute for the life of the website. It will persist until it's discovered or eliminated. Then what is a non-persistent attack? Also called a reflected XSS attack. In this type of attack, the malicious script is delivered as part of a URL. Usually it is part of what seems to be a genuine link in an email. This reflective type of attack is the most common attack today. The link might appear to be a genuine domain and chances are it is, but it also has a complex URL that contains parameters. This makes it a great place to hide a call to inject script. There are two categories of XSS based on where the untrusted data is used, server-side XSS and client-side XSS. Let's take a closer look at these. Server-side XSS occurs when an untrusted user supplies data that is included in an HTML response generated by a server. This data might come from a single request or from a stored location. This means it could be either persistent or non-persistent, as both fall under the category of server-side XSS. How about client-side XSS? Well, as you can imagine, client-side XSS comes from untrusted user-supplied data. When this untrusted data is used to update the DOM with an unsafe JavaScript call, the DOM allows objects on the web page to be manipulated. This means they can be deleted, added, or changed. If the data being supplied is malicious, it's considered to be an attack. This also means that client-side XSS can be both reflected and stored at the same time. So DOM-based attacks are simply a subset of client-side XSS. The focus is on the source of the data. Here is a chart that should help with understanding the relationship between current categories of XSS and historically used terms of XSS attacks. Congratulations! You have just completed cross-site scripting defined.