In cross-site scripting (XSS) attacks, attackers place malicious scripts on a website that contains instructions directing a web browser to access a second site. In this video, learn how attackers wage cross-site scripting attacks and the ways that security professionals may defend against these attacks on their websites.
- [Instructor] Cross-site scripting attacks are one of the most dangerous web-based attacks on the internet today. They're easily executed by attackers and can take place without the knowledge of the victim. Cross-site scripting attacks commonly abbreviated as XSS attacks, occur when an attacker embeds malicious code in a third-party website that then runs within the web browsers of other visitors to that site. Let's take a look at how they work. As you may know, web pages are made using HTML code.
HTML is a markup language that allows web pages to have all sorts of advanced functionality, other than just displaying plain text. HTML authors can add different fonts, include images, link to other sites and even include small programs called scripts that run in the browsers of visitors to the site. HTML uses the concept of tags to perform all of these actions. For example, the <b> tag formats bold text.
The <i> tag formats italicized text and the <a> tag is used to include hyperlinks in a web page. When you're including a tag in a webpage, you write the tag inside of brackets made using the greater than and less than signs. You first open the tag, then include your text and then close the tag by including it again, but this time putting a forward slash in front of the tag. Here's an example of how you would bold some text and it would appear like this.
How you would italicize some text, which would appear like this and how you would include a link to another site which would then display with familiar hyperlink formatting. I mentioned earlier that you might also want to include some scripting in a web page that runs a program inside the user's browser. You do this using the script tag. For example, you might include this code in a webpage that pops up a window in the readers browser saying that the site is under construction.
Scripting is a powerful tool and is perfectly legitimate when the scripts are written by the creator of a legitimate website. However, in a cross-site scripting attack, the attacker manages to trick a legitimate website into sending its users copies of a malicious script. This often happens when the site allows users to enter input that is then displayed to other users. For example, an online auction site might accept postings from anyone in the world.
Users posting to the site may wish to dress up their auction listings with bold characters, images and other enhancements, so the auction site owners allow them to write HTML code in their listings. Maybe someone selling a boat might want to make their boring listing look a little more interesting by including HTML code in their input and then getting a catchier looking description that includes a picture. But what happens if the user includes unexpected HTML in their post? Like a script that takes some malicious action on the viewers computer? If the website simply takes this input and passes it along to other users, the users will see the same auction listing but the malicious script runs in the background without their knowledge.
Fortunately, it's easy to defend against cross-site scripting attacks. As with SQL injection attacks, the key is using input validation on any user input that includes HTML. Specifically, the input validation should watch for any attempts to use the script tag in user-supplied input and remove that script code from the input. Let's take a look at cross-site scripting in action. The Open Web Application Security Project or OWASP, produces a package called WebGoat that illustrates many common web security vulnerabilities.
I'm running WebGoat on my server and I'm going to show you how you can execute a cross-site scripting attack against it. You can see here that WebGoat has a fake Human Resources application, belong to Goat Hills Financial. I'm now going to login as a normal user. Tom Cat and I happen to know that the password here is Tom. I go ahead and log into the application and you can see I can only see information about myself because I'm a standard employee. I click on the View profile button and I can see all of the information that the company knows about me.
We can execute our own scripts on a victim's machine. What if, instead of the pop-up window we instructed Jerry's browser to visit a bank's website and transfer cash to Tom. If Jerry wasn't a customer of that bank or wasn't logged into that site, the attack would fail. But if he was logged into the bank's website in another tab, it might succeed. Cross-site scripting attackers try this thousands of times, waiting until they hit the jackpot once. They don't care if they have 999 failures before a single success.
As with many types of attack, the attacker is playing a numbers game waiting for that one victim.
- Comparing viruses, worms, and Trojans
- Backdoors and logic bombs
- Understanding the attacker
- Attack types: from denial of service to brute force attacks
- Preventing insider threats
- Wireless attacks
- Understanding cross-site scripting
- Preventing SQL injection
- Social engineering
- Scanning for vulnerabilities
- Penetration testing
- Assessing the impact of vulnerabilities