info@azgadsecurity.com
+1 (305) 565-6218
Cross-site scripting (XSS) is an exploit where the attacker attaches code onto a legitimate website that will execute when the victim loads the website. That malicious code can be inserted in several ways. Most popularly, it is either added to the end of a URL or posted directly onto a page that displays user-generated content. In more technical terms, cross-site scripting is a client-side code injection attack.
The client-side code is JavaScript code that runs on a user’s machine. In terms of websites, client-side code is typically code that is executed by the web browser after the browser loads a web page. This is in contrast to the server-side code, which is executed on the host’s web server. Client-side code is very useful with interactive webpages; interactive content runs faster and more reliably since the user’s computer doesn’t have to communicate with the webserver every time there is an interaction. Browser-based games are one popular platform for client-side code since the client-side code can ensure the page runs smoothly regardless of connectivity issues.
The code that runs client-side is very popular in modern web development and is utilized on most modern websites such as sliders, or auto-refresh webpages, or content of a text box such as chat boxes. Since cross-site code is a staple of the modern web, cross-site scripting has become one of the most frequently reported cyber-security vulnerabilities, and cross-site scripting attacks have hit major sites such as YouTube, Facebook, and Twitter.
One useful example of cross-site scripting attacks is commonly seen on websites that have unvalidated comment forums. In this case, an attacker will post a comment consisting of executable code wrapped in ‘’ tags. These tags tell a web browser to interpret everything between the tags as JavaScript code. Once that comment is on the webpage when any other user loads that website, the malicious code between the script tags will be executed by their web browser, and they will become a victim of the attack.
JavaScript cross-site scripting attacks are popular because JavaScript has access to some sensitive data that can be used for identity theft and other malicious purposes. For example, JavaScript has access to cookies*, and an attacker could use an XSS attack to steal a user’s cookies and impersonate them online. JavaScript can also create HTTP requests, which can be used to send data (such as stolen cookies) back to the attacker. Additionally, client-side JavaScript can also help an attacker gain access to APIs that contain geolocation coordinates, webcam data, and other sensitive information.
A typical cross-site scripting attack flow is as follows:
*Cookies are temporary login credentials saved on a user’s computer. For example, when a user logs onto a site like Facebook, the site gives them a cookie so that if they close the browser window and go back to Facebook later that day, they are automatically authenticated by the cookie and won’t need to log in again.
The two most popular types of cross-site scripting attacks are reflected cross-site scripting and persistent cross-site scripting.
This is the most commonly seen cross-site scripting attack. With a reflected attack, malicious code is added onto the end of the URL of a website; often this will be a legitimate, trusted website. When the victim loads this link in their web browser, the browser will execute the code injected into the URL. The attacker usually uses some form of social engineering to trick the victim into clicking on the link.
For example, a user might receive a legitimate-looking email that claims to come from their bank. The email will ask them to take some action on the bank’s website and provide a link. The link may end up looking something like this:
http://legitamite-bank.com/index.php?user=&script>here is some bad code!
Although the first part of the URL looks safe and contains the domain of a trusted website, the code injected onto the end of the URL can be malicious.
This happens on sites that let users post content that other users will see, such as a comments forum or social media site, for example. If the site doesn’t properly validate the inputs for user-generated content, an attacker can insert code that other users’ browsers will execute when the page loads. For example, an attacker might go to an online dating site might put something like this in their profile:
"Hi! My name is Dave, I enjoy long walks on the beach and "< script >malicious code here < /script >"
Any user that tries to access Dave’s profile will become a victim of Dave’s persistent cross-site scripting attack.
There is no single strategy for neutralizing cross-site scripting, and different types of web applications require different levels of protection. A number of protective measures can be taken, below we will outline a few.
If possible, avoiding HTML in inputs - One very effective way to avoid persistent cross-site scripting attacks is to prevent users from posting HTML into form inputs. There are other options that let users create rich content without the use of HTML, such as markdown and WYSIWYG editors.
Validating inputs - Validation means implementing rules that prevent a user from posting data into a form that doesn’t meet certain criteria. For example, an input that asks for the user’s “Last Name” should have validation rules that only let the user submit data consisting of alphanumeric characters. Validation rules can also be set to reject any tags or characters commonly used in a cross-site scripting, such as “< script >“ tags.
Sanitizing data - Sanitizing data is similar to validation, but it happens after the data has already been posted to the webserver, yet still before it is displayed to another user. There are several online tools that can sanitize HTML and filter out any malicious code injections.
Taking cookie security measures - Web applications can also set special rules for their cookie handling that can mitigate cookie-theft via cross-site scripting attacks. Cookies can be tied to particular IP addresses so that cross-site scripting attackers cannot access them. Additionally, rules can be created to block JavaScript from accessing cookies altogether.
Setting Firewall rules - A firewall can also be configured to enforce rules which will prevent reflected cross-site scripting. These firewall rules employ strategies that will block strange requests to the server, including cross-site scripting attacks. Most of desktop security softwares have firewall.
[US] English