What is Cross-site scripting (XSS)?
Cross-Site Scripting (XSS) attacks introduce malicious code into online applications, often known as injection attacks.
An attacker will exploit a vulnerability in a target online application to deliver malicious code to an end-user, most typically client-side JavaScript.
XSS attacks target the application’s users directly rather than the application’s host.
Organizations and businesses that deploy web apps risk exposing themselves to cross site scripting attacks. If they show material from users or untrusted sources without sufficient escaping or validation.
For a long time, cross site scripting vulnerabilities have been one of the OWASP Top 10 security issues and they created Cheat sheet on XSS Filter Evasion. Since many firms rely significantly on online apps for consumer contact and validation.
Cross Site Scripting Fundamentals
- It is a web-based attack that is against insecure online applications.
- The victim of an XSS attack is the user, not the web application.
- Malicious material is sent to users using JavaScript in XSS attacks.
How does cross-site scripting works?
Cross-site scripting happens by modifying a vulnerable website to return malicious scripts to visitors.
Although attackers can use any client-side language other than JavaScript, it is frequently done with JavaScript.
Websites with vulnerable functionality that allow user input, such as search bars, comment boxes, or login forms, are targeted by attackers.
The attackers place their infected code on top of the legitimate website, tricking browsers into running their malicious code every time the site is loaded.
Attackers can extract information about the authorized user from the session because the JavaScript runs on the victim’s browser and allows target site administrators and compromised websites.
The malicious code may appear as a temporary element that only seems to be a part of the website during exploitation rather than on the actual page. It depends upon how the attacker injects the code.
The above paragraph might give the impression that the website hack when it is not.
Attackers can initiate a cross-site scripting attack in a variety of ways.
The execution might, for example, be the browser automatically executed when the website loads or when a user hovers over specified page components, such as hyperlinks.
Cross site scripting is executed more directly via certain circumstances, such as email.
Sometimes attackers do not have a specific target. Rather than exploit a vulnerability in the application or site, take advantage of anybody unlucky enough to fall any user.
Depending on the scope of the attack, user accounts were hacked, and page content was modified, duping people into disclosing sensitive information.
Session cookies might be exposed, allowing criminals to impersonate legitimate users and exploit their accounts.
A successful cross-site scripting attack may harm an online business’s reputation and client relationships.
Unfortunately, the weaknesses that enable cross site scripting attacks to succeed are relatively common.
Cross site scripting attacks may take advantage of a vulnerability in various programming environments, including VBScript, Flash, ActiveX, and JavaScript. With these programming languages’ deep interaction with most browsers, XSS primarily targets JavaScript. Because of their potential to target widely used platforms, cross site scripting attacks are hazardous and prevalent.
The effect of Cross Site Scripting
An attacker can carry out destructive functions by exploiting XSS vulnerabilities, such as:
- Users sent to a fraudulent website.
- Capturing keystrokes from users.
- Obtaining access to a user’s browser history and clipboard data.
- Obtaining cookie information from a logged-in user on a website.
- Taking the login session token and interacting with the program as the victim without knowing their password.
- Forcing the user to make queries to a server controlled by the attacker.
- Changing the page’s content.
- Trick the target into disclosing their password to the program or other applications.
- Using a weakness in the web browser infects the victim with additional malicious malware and potentially takes over the user’s machine.
Types of cross site scripting
Cross-site scripting is defined into four main categories:
- Reflected cross site scripting
- Stored cross site scripting
- DOM-based cross site scripting
- Blind cross site scripting
Reflected cross site scripting
Definition
Reflected XSS is the most general cross site scripting, also known as Non-persistent XSS.
In this situation, the attacker must include the payload in the parameter like the search box to request the webserver. It is then reflected back so that the HTTP request’s payload must be included in the HTTP response without any validation.
Attackers use malicious URLs, phishing emails, and other social engineering tactics to deceive the victim into requesting the server.
After that, the mirrored XSS payload is executed on the user’s browser.
Because reflected cross site scripting is not a persistent attack, the attacker must give the payload to each victim individually.
These attacks are frequently carried out via social media platforms.
Impact
An attacker may often totally compromise a user if they can manipulate a script performed in the victim’s browser. The attacker can, among other things:
- Perform any action available to the user within the program.
- View any information that the user has access to.
- Change any information that the user has the ability to change.
- Initiate interactions with other application users, including harmful attacks that appear to be initiated by the original victim user.
Stored cross site scripting
Definition
Stored XSS, also known as Persistent cross site scripting, is the most dangerous sort of XSS attack.
Stored XSS happens when user-supplied input is stored on the web page and rendered within a web page. Inputs are saved in the database of the web application.
Message boards, blog comments, user profiles, and username fields are common entry sites for cached cross site scripting.
When the victim accesses the website, the payload is executed client-side by the victim’s web browser.
Impact
An attacker may often totally compromise a user if they can manipulate a script performed in the victim’s browser. The attacker can do any of the activities that are relevant to the impact of reflected XSS vulnerabilities.
The fundamental distinction between reflected and stored XSS vulnerabilities in terms of exploitability is that a stored XSS vulnerability allows for self-contained attacks within the application itself.
The attacker does not need to discover a means to find a way to convince other users to create a specific request containing their exploit.
Instead, the attacker embeds their vulnerability in the program and waits for users to come across it.
The self-contained nature of stored cross-site scripting vulnerabilities is critical when an XSS vulnerability only affects users who are presently signed in to the application. If the XSS is reflected, the attack must be well-timed: a user convinced to perform the attacker’s request while not logged in will not be compromised. If the XSS is stored, the user is assumed to be logged in when the attack is encountered.
DOM-based cross site scripting
Definition
DOM-based XSS is a cross-site scripting vulnerability in the DOM (Document Object Model) rather than the HTML.
DOM Based XSS occurs when JavaScript is executed directly in the browser without needing additional pages to be loaded or data to be passed to backend programs. When the website’s JavaScript code reacts to user input or interaction, this is called execution.
It can only be seen at runtime or by inspecting the page’s DOM.
A DOM-based XSS attack is typically a client-side attack. The malicious payload never being delivered to the server.
Because they never witness the attack, Web Application Firewalls (WAFs) and security professionals who monitor server logs find it much more difficult to detect.
The URL (document.URL), the anchor component of the URL (location.hash), and the Referrer are the most often changed DOM objects (document.referrer).
Impact
An attacker can exploit cross site scripting vulnerability:
- An attacker can insert XSS payloads on popular pages of a site.
- By sending phishing links to a victim.
- Attracting them into accessing the page containing the stored XSS payload.
The impact of DOM-based cross site scripting is the same as stored and reflected cross site scripting. Still, the only difference is that DOM-based attackers manipulate Document Object Model elements.
Blind cross site scripting
Definition
Blind XSS is a form of Stored XSS in which the server saves the attacker’s input and displays it in the developer’s application. Essentially, the attacker’s payload is executed on the application used by team members or administrators.
In BXSS attacks, attackers inject their payload “blindly” on web pages that are likely to save their payload into the database (like contact forms, logs, etc.). The attacker then waits for a server-side user or team member [who works with website databases] to open or trigger the execution of that script or payload.
Impact
Attackers may use cross site scripting to launch a variety of attacks, including:
- Taking over a user’s active session.
- Phishing attacks are stepping up.
- Interception of data and man-in-the-middle attacks
Cross-site scripting prevention
To reduce the risk of cross-site scripting, web application developers should:
- Please ensure that each page on their website allows user input filters off code inputs like HTML and JavaScript.
- Scan for and repair any web application vulnerabilities that you find.
- Update their website and server software to avoid future exploitation of vulnerabilities that a cross site scripting attack might exploit.
Individual users should take the following precautions to prevent being a victim of a cross site scripting attack:
- Deactivate scripting on pages where it is unnecessary or disable it entirely.
- Clicking on links in suspicious emails or comment board postings might lead to hacked pages.
- Users can access websites directly by putting the URL into their browser rather than through a third-party source or link.
- Keep your program up to date to take advantage of the most recent bug fixes and security updates. Regular software updates will considerably decrease the vulnerabilities that expose a site or application to cross site scripting attacks.
What are the different types of Cross-Site Scripting attacks?
Several vectors are used in XSS attacks:
<script> tag: A script tag may use to access external JavaScript code. <script> tag is the most obvious cross site scripting location. An attacker can also include malicious code into the script element.
<!-- This script is used to steal cookie from browser -->
<script>
alert(document.cookie)
</script>JavaScript Events: Event attributes, another prominent cross site scripting vector utilized by attackers, may be employed in several tags. Examples are the properties “onerror” and “onload”.
<!-- This onerror attribute will trigger if cross-site scripting vulnerability occurs and show a alert box showing 1 -->
<img src=xss onerror=alert(1)><body> tag: Event attributes can also be used as the script’s source when given through the “body” tag.
<!-- This onload attribute will executes when body will completely loaded. onload attribute execute only when cross-site scripting vulnerability occurs and show a alert box showing XSS -->
<BODY ONLOAD=alert('XSS')><img> tag: Attackers may utilize this property to execute JavaScript code depending on the browser in use.
<!-- This onerror attribute inside image tag will trigger if cross-site scripting vulnerability occurs and show a alert box showing 1 -->
<img src=1 href=1 onerror="javascript:alert(1)"></img><iframe> tag: This tag, useful for phishing attacks, allows the cross site scripting to embed another HTML page inside the current website.
<!-- This iframe tag will trigger if cross-site scripting vulnerability occurs and show a alert box showing 1 -->
<iframe src iframe src="javascript:javascript:alert(1)"></iframe src><input> tag: Some browsers support vector manipulation, which can be used to embed a script.
<!-- When the page loads input tag automatically get focused and shows a alert box showing 1 if cross-site scripting vulnerability occurs -->
<input onfocus=javascript:alert(1) autofocus><link> tag: This element can include a script instead of connecting to external style sheets.
<!-- When the page loads, the browser will load the below code as an external stylesheet, but it will popup alert box showing 1 -->
<LINK REL="stylesheet" HREF="javascript:javascript:alert(1);"><table> tag: The background property, which ordinarily corresponds to an image, might be modified to redirect to the malicious script.
<!-- When the table tag loads in the browser instead of the URL of the background image, it will load cross-site scripting payload. A popup will appear showing 1 -->
<TABLE BACKGROUND="javascript:javascript:alert(1)"><div> tag: This tag also includes a background reference and may be used to refer to a script in the same manner that table> can.
<!-- When the div tag loads in the browser instead of the URL of the background image, it will load cross-site scripting payload. A popup will appear showing 1 -->
<DIV STYLE="background-image: url(javascript:javascript:alert(1))"><object> tag: This tag can add scripts from another website.
<!-- This onerror attribute inside object tag will trigger if cross-site scripting vulnerability occurs and show a alert box showing 1 -->
<object src=1 href=1 onerror="javascript:alert(1)"></object>While XSS attackers use more vectors to steal information and infect websites, these are the most frequent. To protect against such attacks, developers must use correct escaping and sanitizing methods.
For more payloads, go to the Github page and use different HTML and JavaScript elements.
Conclusion
The origins of cross site scripting may be traced back to late 1999, when a small group of Microsoft security experts discovered it.
XSS payloads maliciously inserted script and image tags into HTML pages recorded by Microsoft Security Response Center and the Microsoft Internet Explorer Security Team.
Every OWASP TOP 10 Web App Vulnerability report addresses cross site scripting (XSS).
For more articles related to cross site scripting (XSS), subscribe to our mailing list.
