As old as web browsers themselves, cross-site scripting (XSS) has been an ongoing issue in the security world. Its’ consistent appearance on the OWASP Top 10 and in news reports of cross-site scripting attacks has kept the security issue in the spotlight over the years. Yet after two decades the security issue remains one of the most common attacks on web applications, with consistent reports of over 70% of sites at risk.
So, what is Cross-Site Scripting and how do we change our habits as users, developers and security professionals so we can prevent attacks once and for all?
What Is XSS & Why Should I Care?
At its core, cross-site scripting is a vulnerability potentially found in dynamic applications that allow user input and don’t have control over output. An XSS attack is a hacking technique that preys on an application’s weak code, allowing an attacker to send malicious content and receive data from the victim in return, unsolicited and often without their knowledge. The true purpose of an XSS attack is to trick the victim into never knowing their activity has been intercepted, causing the victim to continue being compromised. Unlike attacks like SQL Injection, whose end goal is to hack an applications back end, XSS attacks go after the user – though they can be just as damaging to the organization.
E-Commerce and banking sites are some of the most targeted with XSS because the ability to read and modify the information sent by the victim (bank account number, credit card details, etc.) makes those types of sites perfect for a higher ROI. But, in essence, any site with dynamic content is a potential victim of XSS and because it affects the user as well as the company’s reputation, cross-site scripting is not to be ignored.
What’s the History of Cross-Site Scripting?
A decade after Netscape’s arrival on the scene we saw the first major cross-site scripting attack with the Samy Worm. When a technically advanced 17 year old named Samy discovered an XSS vulnerability on MySpace, which at the time was the biggest social platform, he wanted to see how far the worm would go. The resulting chaos definitely surprised Samy, along with MySpace, the FBI and the security world: 1 million profiles were infected before MySpace fixed the issue, each showing the phrase “Samy is my hero” and adding Samy as a friend. For a good read, Samy’s write-up of the attack is actually still up online.
Since that first attack a decade ago, Cross Site Scripting has held steady in top spots on the OWASP Top 10 in the 2007, 2010 and 2013 reports. XSS vulnerabilities have been found on government, Fortune 500 and the biggest tech companies’ sites – in short, nobody is truly safe from cross-site scripting, especially since vulnerabilities are so easy to re-introduce during development. For a disheartening look at how many sites are still affected by these vulnerabilities today, take a look at this XSSposed.org list.
What kinds of Cross-Site Scripting are there?
There are three types of cross-site scripting attacks: Reflected, Stored, and DOM-based, but because attackers use a mix to achieve different malicious effects, they can overlap with each other.
While SQL injection exploits often get a reputation for being the most prevalent vulnerability in web apps and takes top place in the OWASP Top 10, XSS actually takes the cake for being the most widespread security issue today.
How can XSS affect your apps?
Companies and individuals developing client-server applications should always assume untrusted clients might be controlled by hackers and take steps to bridge any gaps there may be that would allow for untrusted inputs. Cross-site scripting vulnerabilities take the following shapes:
-Stealing browser and cookie data (the most common purpose)
-Stealing client data
-Stealing user data, including Personally Identifying Information (PII) like credit card numbers, usernames and passwords, and more
-Redirecting victim to the attacker’s site, which could still look like a legitimate subdomain of the original website
-Performing actions on the victim’s browser, acting as the legitimate site
-Installing an XSS proxy, allowing hacker to see and redirect user behavior
-Undermining CSRF defenses
-Rewriting/defacing portions of the page (though this is more of a nuisance than attack)
XSS: 11 Fast Facts
XSS Prevention Steps: The Do’s and Don’ts of Cross-Site Scripting
Further Cross-Site Scripting Reading and Resources
Sign up today & never miss an update from the Checkmarx blog
Interested in trying CxSAST on your own code? You can now use Checkmarx's solution to scan uncompiled / unbuilt source code in 18 coding and scripting languages and identify the vulnerable lines of code. CxSAST will even find the best-fix locations for you and suggest the best remediation techniques. Sign up for your FREE trial now.
Checkmarx is now offering you the opportunity to see how CxSAST identifies application-layer vulnerabilities in real-time. Our in-house security experts will run the scan and demonstrate how the solution's queries can be tweaked as per your specific needs and requirements. Fill in your details and we'll schedule a FREE live demo with you.