XSS, known formally as CROSS SITE SCRIPTING, is an attack specific to websites and web-based applications that involves the injection of malicious code into otherwise trusted domains. This type of exploit targets scripts that are executed on the client-side, or specifically, through a web browser. By compromising the front end, an XSS attack can avoid detection and being flagged as malicious, which is what would happen in most cases on the server-side.
Forums and message boards are known channels for XSS attacks, given their platforms for commenting and other user-generated content. These “target sites,” known for their lack of sanitization techniques, are often injected with malicious code in the form of active comments. These simple links, when invoked, redirect users to mirrored websites that either embed additional malware into their systems or collect their personal data. This leads to the two (2) main types of cross site scripting attacks, described below.
Stored XSS Attacks
This type of cross site scripting attack involves the permanent storage of malicious code on the server of a targeted web application. As described above, the code is injected in the form of hyperlinked comments or messages in the comment section of a site, which serves as its entry into the site’s database. It then lays wait for an unsuspecting user to click and activate it. Stored XSS attacks are often referred to as persistent attacks given their potential to reside perpetually on an infected site. This is especially true for websites with heavy traffic that lack techniques for archiving and backward sanitization.
Reflected XSS Attacks
Also known as a Type 2 or non-persistent attack, reflected XSS scripts require the use of a third party to instantiate a user session. From here, the user is duped into entering data that will be used as active comments on a targeted website. Examples of how this is implemented can be seen in phishing campaigns and email spoofing, which often end with a connection to a replicated website that presents a bogus form for a user to fill out. This data will be sent containing active elements which, if not sanitized the legitimate website, will be used as redirect links back to its malicious replica.
Preventing Cross Site Scripting Attacks on the Front and Back Ends
The end result of a cross site scripting attack depends on the one who implements it. This is also true for its level of severity, although in most cases, the overall goal is obtain the end user’s data. Some XSS exploits lead to the user downloading Trojans which kick off a string of other attacks, while those less severe in nature may simply reveal a user’s cookie and browsing information. Either case could lead to abuse and the loss of trust among those who frequent your website.
If you are the system administrator of a shared commenting environment like those described above, or if you’re lowly webmaster of a brochure-style website, it is incumbent on you to protect your visitors and users. The first step in this process is sanitization. Most scripting languages have simple, predetermined functions that sanitize code and prevent active elements from being embedded. An example of this is PHP’s htmlpsecialchars function.
Beyond this, it is always a good idea to use an antivirus (AV) for your website, and to make a habit of testing it with services like Nessus and Nikto. The administration of your system isn’t a achieved through a single attempt or action, but is rather an ongoing effort to protect it along with those who frequently use it.