CompTIA Pentest+ PT0-002 – Section 12: Application Attacks Part 2

114. Cross-Site Scripting (XXS) (OBJ 3.3)

In this lesson, we’re going to discuss cross-site scripting, also known as XSS. Now, cross-site scripting is a malicious script that’s hosted on an attacker site or coded inside of a link that’s injected into a trusted site, designed to compromise the client that is browsing that trusted site. Now this allows the attacker to circumvent the browser security model or trusted zones. Now, the attacker’s goal in using cross-site scripting is to get you to run some kind of malicious script so that your system will process this thing and bypass its normal security mechanisms. Cross-site scripting is a powerful exploit that relies on your website not conducting proper input validation. If you’re not doing proper input validation, you are most like going to fall victim to a cross-site scripting attack. So let’s take a look at how cross-site scripting works in the real world by looking at the four basic steps of a cross-site scripting attack. First, the attacker identifies an input validation vulnerability within a trusted website. For example, if my website doesn’t conduct proper input validation for the username and password fields used by my students, that could become a good candidate for cross-site scripting attacks. Second, the attacker crafts a URL to perform the code injection against that trusted website.

At the same time, the attacker needs get somebody to click on that maliciously encoded URL. So they might post it to a trusted website, embed it in an email message using a phishing campaign or post it to an online forum. The goal here is that the attacker needs to get somebody to click on that encoded URL. Third, the trusted site will return a page containing the malicious code injected, as well as the regular site code. This occurs once the user clicks the encoded URL and the trusted site executes the code that was injected. At this point, the user’s going to be presented with malicious content, which they believe is trusted, because it came from the trusted website that they were visiting. Fourth, the malicious code is now run in the client’s browser, finalizing the cross-site scripting attack. When this occurs, the code will run the permission level of the trusted site because the system believes the trusted site sent that code, which technically it did, because it was injected into the reply coming from that trusted server to the end user’s browser. This is why we call it a cross-site scripting attack, because malicious code is actually going to be injected and served by the trusted site to their users. Now, for example, let’s say I was scrolling Facebook and somebody was able to perform a cross-site scripting attack there, and they could inject code into my newsfeed.

Now, it’s going to cross that threat actor site into the trusted site, in this case Facebook, and then it’s delivered to me, the end user who’s scrolling my newsfeed. That’s how a cross-site scripting attack works. Now, cross-site scripting attacks can be used to run malicious code that perform many different functions. One attack may focus on defacing the trusted website by injecting extra HTML code into it. Another attack by focus on stealing the user’s data by stealing protected cookies from that user. Another might try to intercept data or communications as they’re being entered into the web forms. And yet another might try to install malware on your client system. As you can imagine, there are lots of different things we can do with the malicious code being run. But cross-site scripting is the initial delivery mechanism that the threat actor is going to use to get that malicious code to your system and have it run by your web browser. Now, the reason cross-site scripting is so dangerous is because it breaks the browser security and trust model, because browsers are going to assume that scripts it receives from a trusted site should be safe to run. Now, this isn’t the browser’s fault. It’s just because they’re designed to run scripts they receive from trusted sites. That’s how the internet is designed.

After all, if you go to my website, there are lots of different scripts we’re running in order to provide you with the training videos, quizzes and practice exams that you want. Your browser knows that it can trust my website, because that has a valid digital certificate and you’ve logged into our site, and therefore, you’re a trusted client and we’re a trusted site. Without this level of trust, webpages would be extremely boring, because no scripts could ever be run or operated. So let’s take a quick look at what cross-site scripting might look like if we used it against a vulnerable website. First, we’re going to craft the URL by adding the script to an otherwise safe URL. For example, if my site was vulnerable, we could use a URL like diontraining.com/search?q=, and then you’ll see something like alert(‘xss’). Now, what does this really say? Well, the first part here is simply saying we’re going to use a trusted website like diontraining.com. The next part that says search?q= would normally be used for a website to conduct a search for anything found after the q= because that is my query. For example, maybe you’re on my site and you’re searching for the word CompTIA, so you would see in the URL q=comptia, and that would send the word CompTIA to my server to able to search its database for any pages that have the word CompTIA in it. Now, because we’re attempting a cross-site scripting attack here, we’re actually going to replace the query with the script that we want to insert. In this case, I have a really short piece of JavaScript code that’s going to pop up an alert box that says XSS when it goes and reaches the server. Now, if you try to run this code, it probably won’t work on my website, because my site is already protected from this type of cross-site scripting attack. But if you want to attempt these on your own, you could check out the cross-site scripting game set up by google at xss-game.appspot.com which has six different challenges where you try to create a cross-site scripting attack against their servers. The first one can be completed using the example I just covered in this lesson. Now, the example I just showed you is what’s known as a reflected or non-persistent cross-site scripting attack. This type of attack only occurs when it’s launched because you’re clicking on that link or you’re entering it into your web browser and pressing Enter.

When it happens, it happens once and then it stops, because it is considered non-persistent. Now there are other types of cross-site scripting attacks though, and these can be more dangerous. For example, a persistent cross-site scripting attack allows an attacker to insert code into the backend database used by that trusted website. By doing this, the attacker doesn’t have to wait for somebody to actually click on a link anymore, because the malicious code is now embedded into that website’s database. Anytime a user loads the page or content from the database, they’re going to be loading the persistent cross-site script as well. Now, both persistent and non-persistent cross-site scripting attacks are considered forms of server-side scripting attacks, because it’s a server that is executing the scripts that we’re injecting. Now, there’s also a client-side attack known as a DOM cross-site scripting attack. Now, DOM or D-O-M is the document object model, and the document object model cross-site scripting attack is going to exploit the client’s web browser using client-side scripts to modify the content and layout of the webpage. The document object model, or DOM, is how things are displayed in the client’s browser. But by injecting scripts into the DOM, you can actually change this.

Now, let me show you a quick example of a DOM-based cross-site scripting attack. In this simple example, you can see a URL of diontraining.com/index.html#default=