What Is a Cross-Site Scripting (XSS) Attack?
A cross-site scripting attack involves a malicious actor targeting a victim by inserting surreptitious code through a website. “There are a few ways it can play out, but basically the attacker injects a malicious script into the database of a website, causing a user who browses that website’s browser to execute the script,” says Adam Meyers, senior vice president of intelligence at CrowdStrike.
A client-side code injection attack, XSS enables an attacker to execute malicious actions via a victim’s web browser. The government agency’s web page or web application essentially becomes a vehicle to deliver the malicious script. When the victim visits the web page or web application, the code executes.
LEARN MORE: How can next-gen endpoint tools protect users at home?
How Do XSS Attacks Work?
Although there are several forms of XSS attacks, all essentially result in the same thing: the execution of malicious code in a user’s browser.
“Normally when a user interacts with a web application or a website, data is sent back and forth between the client and the site or the front end of the application,” says Greg Bailey, an instructor for the SANS Institute. “It could be mostly innocuous data, casual browsing, or there could be certain pages or inputs in the application that gather data from the user.”
XSS leverages those inputs to insert its ill-intended instructions.
A good example of this is a simple blog or forum. “Generally, the author posts a blog entry on a website, which other users can then comment on. The comments are gathered via a free-form text box with a submit button,” Bailey says.
“Behind the scenes, the application is gathering data from these input fields — name, email address, comment,” he says. “What is stopping someone from putting something else in that text box that gets passed back to the web application? Possibly nothing. In that case, the site itself can be leveraged to perform a cross-site scripting attack.”
What Is Cookie Stealing?
A tool in the cross-site scripting attack arsenal, cookie stealing leverages the information stored in a user’s web browser cache to identify the user in a particular connection or session.
“If an attacker can steal the user’s cookies, that attacker can impersonate that end user,” says Kayne McGladrey, a senior member and impact creator of the Institute of Electrical and Electronics Engineers. “In an XSS exploit, if I can steal your cookies, I can become you or impersonate you. I can change your password. I can change your backup email account. I can take over that entire account.”
Such an attack could allow a bad actor to harvest keystrokes to steal usernames and passwords. If that user has administrative credentials on a government network, the potential damage can spiral exponentially.
EXPLORE: How are feds approaching zero trust?
XSS vs. Cross-Site Request Forgery
A variation on the XSS approach, a cross-site request forgery attack forces an end user to execute unwanted actions. The attacker might trick a web application’s users into changing email addresses, for example, or transferring funds.
“With XSS, it is attacking the user, changing what appears on their page or how the page in the browser is rendered. It exploits the user’s trust in the website,” Tanner says.
“With the cross-site request forgery, it’s pretending to be the user, to exploit the web server’s trust in the user,” he says. “You authenticate to the web page, and the server knows you are logged in. That token is then used by the attacker to make requests on behalf of the user, usually without their knowledge, and they can change anything that the user can change.”
How to Detect a Cross-Site Scripting Attack
XSS attacks can be notoriously difficult to detect because the browser cannot distinguish between legitimate and illegitimate actions.
“You can do vulnerability scanning against the code after the fact to make sure that nothing slips through,” Tanner says. “There are a number of free and paid resources that will do this, looking for these specific kinds of attacks or the fields that could be vulnerable to such attacks.”
Web application filtering tools also offer some protection. “When the server gets to see the payload of the attack, that is a good mechanism for detecting an attack in progress,” Tanner says. “Web application filters will look for requests that have specific context to them that reflect an XSS attack. It comes down to anomaly detection, which you can also do through a logging product that is integrated to detect threats.”
Overall, though, experts say prevention rather than detection is the best way to defend against XSS attacks.
READ MORE: How are agencies approaching cybersecurity automation?
Cross-Site Scripting Prevention Tips
Basic hygiene on the part of end users is a first step toward prevention. “Ensure that your browser is patched. Ensure that you log out of sites when you have finished what you are doing. This ensures the cookie is no longer valid,” Meyers says. “Be thoughtful about what websites you visit. Another good strategy is to use multiple browsers: Use one for trusted sites and another for untrusted sites.”
At a higher level, IT can be thoughtful about its development processes, building in safeguards to protect applications and websites against such incursions. XSS “is easily preventable, but it gets overlooked when security is bolted on after the fact, if you do not have secure principles underlying your design,” McGladrey says.
“The easiest thing is to put filters on arrival. When a user adds input, make it reasonable: A phone number should be a phone number, a date should be a date and not a piece of Java script,” he says. “Make sure that if you have an application that asks for a first name, that shouldn’t be active content and you encode it before you show it back to the user. Then the malicious actor cannot make it execute. It’s just plain text.”
Much will depend on the skill level of the developers, and experts say federal agencies would do well to ensure that these professionals are trained in the relevant techniques to help them build and deploy safely.
“Coding can be very complicated, with all the libraries and all the frameworks. There are lots of ways for these vulnerabilities to be introduced,” Tanner says.
At a minimum, developers need working knowledge of the vulnerabilities identified by the Open Web Application Security Project, which include cross-site scripting and the recommended mitigations, he says. “That is a very complete resource in terms of how these attacks work and how to prevent them.”
Although there is no silver bullet to prevent XSS attacks, a combination of sound development practices and strong defensive tools can help federal agencies limit the likelihood of attackers leveraging their websites or applications for nefarious purposes.
