Cross-site scripting (XSS) is a web application vulnerability that allows attackers to embed malicious HTML or JavaScript code into an email or web site error message. If a user responds to the email or error message, it executes the code. Many times, this gives the attacker access to user cookies or other information about the user.
You may be wondering why the acronym isn’t CSS instead of XSS. The reason is that web sites use Cascading Style Sheets, which are identified as CSS. CSS files are not malicious.
HTML and JavaScript code use tags surrounded by the less-than (<) and greater-than (>) characters. For example, images are placed within a web page with the <img> tag. These tags support many additional options and commands, which developers use to create feature-rich web pages. However, attackers can manipulate these tags to run malicious code. Attackers often embed cross-scripting code into comments on blog pages or forums when the page allows users to include HTML tags.
As an example, a bug in Twitter’s web site resulted in a cross-site scripting problem in 2010. A malicious Twitter user discovered the bug and embedded JavaScript code into a tweet. When innocent users opened a web page that included the malicious tweet, the code ran on their systems. In this case, the malicious code used the onMouseOver event. When users hovered their mouse over the tweet, it did two things. It retweeted the tweet, sending it out to all of the user’s followers. It also launched a pop-up window displaying content from a hard-core Japanese pornography web site.
Although this attack was more embarrassing to Twitter than harmful to end users, many other cross-site scripting attacks are malicious. They can allow attackers to redirect users to other web sites, steal cookies off a user’s system, read passwords from a web browser’s cache, and more. If a web site stored private data in a user’s cookie, such as a username and password, an attacker can use a cross-site scripting attack to retrieve this information.
The primary protection against cross-site scripting attacks is at the web application with input validation techniques to block the use of HTML tags and JavaScript tags. Tags are embedded within the < and > characters, so it’s possible to block these tags by rejecting any text that includes these characters. It’s also important to educate users about the dangers of clicking links. Some XSS attacks send emails with malicious links within them. The XSS attack fails if users do not click the link.
Cross-Site Scripting Practice Test Question
Can you answer this sample Security+ exam practice test question?
Q. While creating a web application, a developer adds code to limit data provided by users. The code prevents users from entering special characters. Which of the following attacks will this code MOST likely prevent?
A. Sniffing
B. Spoofing
C. XSS
D. Pharming
The answer and explanation is at the end of the post.
Real-Life Cross-Site Scripting Scans
Interestingly, I’ve been noticing a lot of suspicious activity on one my sites recently that prompted me to dig into this a little deeper. Specifically, I saw that multiple systems were querying the exact same URL within seconds of each other. In about three minutes I received 30 identical queries from multiple locations such as:
- Rr.com (a public ISP)
- Caci.com (An IT contractor)
- Afnoc.af.mil (Multiple proxy servers used by Air Force personnel)
- Comcast.net (a public ISP)
- Several IP addresses that didn’t resolve to a hostname (probably using an anonymizer)
- Usafricom.mil (United States Africa Command)
Part of the URL included “ckeditor.js” and a little research shows that some versions of this script are susceptible to cross-site scripting and remote shell upload vulnerabilities.
These queries look like they are the reconnaissance phase of an attack, attempting to check the site for the javascript file and gain details from it. If they can identify a vulnerability, they can exploit it.
Gratefully, the site in question is up-to-date so it isn’t susceptible to this specific exploit.
Why are Attacks Coming from Military Sites and Government Contractors?
That’s a puzzler.
I can understand how a random query might come from a curious military member or government contractor. However, I don’t understand how a set of 30 queries can come from so many different locations at almost the same time.
More, this isn’t an isolated incident. I’ve seen the same pattern almost every day from Air Force, Navy, and Army military proxy servers, though they are probing for different vulnerabilities.
Unless…
What if criminals from overseas locations could successfully infiltrate a network?
What if they have successfully installed remote access Trojans (RATs) within these networks.
Could they have tools that allow them to configure a reconnaissance scan and simply click a button labeled “Attack” that directs pwned computers to test the URL?
But wouldn’t cyber security experts within military networks know if these RATs are operating within their network?
Unfortunately, no. Some advanced persistent threats (APTs) have remained undetected for years.
I’m not sure what I think is worse.
- These scans could be coordinated by government personnel within these military networks, or
- These scans could be coordinated APTs that have infiltrated the military networks.
Remember this
Cross-site scripting (XSS) attacks allow attackers to capture user information such as cookies. Input validation techniques at the server help prevent XSS attacks. Vendors that create web applications will typically update their code when they discover a vulnerability and release an update. Keeping systems up-to-date is always a good security practice.
Q. While creating a web application, a developer adds code to limit data provided by users. The code prevents users from entering special characters. Which of the following attacks will this code MOST likely prevent?
A. Sniffing
B. Spoofing
C. XSS
D. Pharming
C is the correct answer. A cross-site scripting (XSS) attack can be blocked by using input validation techniques to filter special characters such as the < and > characters used in HTML code. None of the other attacks requires the use of special characters.
Sniffing captures data with a protocol analyzer.
Spoofing hides the identity of the original entity.
Pharming redirects a user from one web site to another web site.