Cross site scripting
Date: March 11, 2023
Cross site scripting
Introduction
The intricacy and complexity of XSS make it one of my favourite vulnerability types. When you truly look at XSS, there is a world of marvel to discover even if everything seems to be so very basic. In addition to the various XSS varieties (including reflected, stored, and DOM; blind XSS is a sort of stored XSS), there are other circumstances that most people seem to completely overlook. HTML injection is the sole aspect of XSS that is typically covered in courses and articles, yet this is simply a small portion of what XSS is all about. Any front-end protection is merely there to prevent user errors, which is where API security really shines. Malicious scripts are injected into otherwise safe and reputable websites via Cross-Site Scripting (XSS) assaults, a sort of injection. XSS attacks happen when a hacker utilizes an online application to deliver harmful code, typically in the form of a browser side script, to a separate end user. Wherever a web application incorporates user input without verifying or encoding it in the output it produces is susceptible to flaws that make these attacks successful. An attacker may transmit a malicious script to an unwary user using XSS. The end user's browser will run the script regardless of whether it should be trusted because it has no means of knowing. The malicious script has access to any cookies, session tokens, or other sensitive data that the browser has stored and used with that site since it believes the script is from a reliable source.
How Does Cross-Site Scripting Work? (XSS)
We must first understand why this particular vulnerability type exists, and we can say that it can happen anywhere a developer publishes user input onto the website without first sanitizing it. The safest but also most restricted method of input sanitization appears to be whitelist-based filtering. By examining each individual piece of user content and only permitting it if it is listed on a whitelist, whitelist-based filtering is put into practise. As you can see, this can be highly time-consuming because we have to specify every single input we want to accept, which may result in a number of unanticipated problems.
Types of XSS attacks
We have briefly discussed the various types of XSS, but I believe it will help if we go over them in greater detail to explain the differences to you and to demonstrate the type of testing that is expected of you as an ethical hacker since we will also be talking about the minor variations in test objectives between the various types of XSS.
1. Stored (Persistent) XSS: Due to the fact that you must test each and every input field you encounter, stored XSS requires a little more computer expertise to be successful. Although it appears unattainable, this enormous undertaking is unquestionably necessary. No low-hanging fruit will be available in bug bounties. Pen testers already have all of it picked apart. The bounty hunters are in charge of locating the one field that everyone missed when putting security measures in place because our wonderful co-workers have already completed a portion of the work.
I just start using the same assault vector I normally do. I turn on some music, log in, and every single input field I see receives an attack vector. Do not forget to test everything. Examine each link on each page, and also keep an eye out for any hidden links. Because developers frequently place test calls in JS files rather than calling them directly from production applications, you can often spot those in those files. Although we can test for things like XSS on pages that other hunters haven't even seen yet, this is typically a utopian dream.
2. Reflected XSS: A search result, error message, or other HTTP response that contains user input that has not been sanitized is the simplest form of an XSS attack. Without securing it or retaining user-generated data, the application logic returns an unsafe input as part of the answer. Data about users never leaves the browser in the majority of reflected XSS attacks. When we discover a mirrored parameter, an XSS is not yet present. On our page, all we have discovered is a mirrored value, however it may have been adequately filtered or cleaned. When we discover a mirrored parameter, an XSS is not yet present. On our page, all we have discovered is a mirrored value, however it may have been adequately filtered or cleaned. We must now determine where it is mirrored in order to create the appropriate attack string for that situation. For instance, you will need to figure out how to add your own single quotation to the attack string if you are trapped in a JS environment where your input is encircled by single quotes (which will often be filtered so you have to try and get around those filters). The next step is to plan an effective assault to either steal data, run a script, or accomplish a valuable task.
3. DOM Based XSS: The Document Object Model is a platform-neutral interface that establishes a logical framework for navigating and interacting with HTML and XML documents. By altering the browser's DOM environment to execute client-side code dangerously, hackers plan DOM-based XSS attacks. As harmful client-side scripts don't reach the server, DOM-based vulnerabilities are complex and difficult to patch. As they don't leave any traces in the server logs, this makes it challenging for automatic vulnerability scanners and a Web Application Firewall to find them.
4. BLIND CROSS-SITE SCRIPTING: Persistent XSS in the form of blind cross-site scripting. The attack typically takes place when the attacker's payload is saved on the server and reflected back to the victim from the backend application. For instance, an attacker can utilise feedback forms to submit a malicious payload, which will be executed whenever the backend user or administrator of the application opens the attacker's submitted form through the backend application. In a real-world setting, blind cross-site scripting is challenging to detect, yet XSS Hunter is one of the best tools for this.
Effects of an XSS Attack
Whether an XSS attack is reflected or saved, the outcome is always the same (or DOM Based). The payload's journey to the server is different. Do not believe that a "read-only" or "brochureware" site is immune to significant reflected XSS attacks. For the end user, XSS can result in a range of issues, from minor annoyances to full account breach. In the most serious XSS attacks, the user's session cookie is exposed, enabling an attacker to hijack the user's session and seize control of the account.
How to Assess Your Vulnerability
It might be challenging to find and fix XSS problems in a web application. The simplest method to detect bugs in a piece of code is to conduct a security assessment of it and look for any locations where input from an HTTP request can accidentally end up in the HTML output. Be aware that a malicious JavaScript might be transmitted using a variety of different HTML tags. Nessus, Nikto, and a few other programmes can help scan a website for these errors, but they can only examine a small portion of it. A website's vulnerability in one area increases the possibility that other issues exist.
Guidelines for Self-Protection
The OWASP XSS Prevention Cheat Sheet lists the most effective XSS defences. Moreover, you must disable HTTP TRACE functionality on all web servers. Even when document. Cookie is disabled or the client does not support it, an attacker can still steal cookie data by using JavaScript. This attack is launched when a user posts a malicious script to a forum, causing a link to be clicked by another user, triggering an asynchronous HTTP Trace call that gathers the user's cookie information from the server and sends it to another malicious server that gathers the cookie information to launch a session hijack attack. This can be easily avoided by disabling HTTP TRACE functionality on all web servers. The OWASP ESAPI project has created a collection of reusable security components in a number of languages, including routines for parameter validation and escaping to thwart XSS attacks and parameter tampering. The OWASP Web Goat Project training programme also includes courses on data encoding and cross-site scripting.
● The following JSP code snippet displays an individual ID, abbreviated id, to the user after reading it through an HTTP request.
If ID just contains the common alphanumeric characters, the code in this example runs successfully. If the value of Id contains meta-characters or source code, the web browser will run the code as it displays the HTTP response. This might not seem like much of a vulnerability at first. Later, why would input someone to a website that triggers to launch a harmful malware on their computer? The true risk is that an attacker will construct a malicious URL and then persuade people into viewing it via email or other social engineering methods. When victims click the link, they unintentionally reflect the malicious content back to their own computers via the vulnerably web application.
● The following JSP code segment searches a database for an employee with a specified ID and displays the name of that employee.
Similar to Example 1, this code works as intended when name's values are appropriate, but if they are not, it has no effect in preventing attacks. Similarly, the fact that the value of name is read from a database, whose contents appear to be handled by the programme, makes this code seem less hazardous. Yet, the database could be used as a delivery system for malicious content if the name value comes from user-supplied information. An attacker can run harmful commands in the user's web browser without performing sufficient input validation on all of the data contained in the database.
● Stored XSS exploits are particularly sneaky since the indirection brought on by the data store makes it more challenging to see the danger and raises the potential that the attack will impact numerous users. Websites that let users "sign a guestbook" served as the origin of XSS in this manner. Attackers would embed malicious JavaScript code in their guestbook entries, which would be executed by all future guests to the guestbook page.
● The examples show that code that includes unsubstantiated data in an HTTP response leads to XSS vulnerabilities. Three ways exist for an XSS attack to get to a target:
● Similar to Example 1, data is read straight from the HTTP request and mirrored back in the HTTP response. Reflected XSS vulnerabilities happen when an attacker tricks a user into sending harmful content to a weak web application, which is then mirrored back to the user and executed by the web browser. The most typical method of distributing harmful content is to add it as a variable to a URL that is shared publicly or sent directly to victims by email.
● Similar to Example 2, the application saves risky data in a database or another reliable data repository. After that, the application reads the hazardous data back in and includes it in dynamic content. When an attacker inserts harmful text into a data store, which is later read and integrated in dynamic content, a stored XSS vulnerability occurs. An location that is visible to lots of people or those who are highly interested is where an attacker should insert malicious stuff, in their opinion. Fascinating users frequently use the programme with elevated rights or interact with private information that is valuable to an attacker. If one of these users executes harmful content, the attacker might be able to carry out privileged operations on the user's behalf or obtain sensitive information.
● The risky material is initially read back into the application as trustworthy data and incorporated in dynamic content from a source outside the application, where the dangerous data is stored in a database or another data storage.
