Website security principles have had a thorough overhaul over the past few years, primarily due to easy access to malicious tools. Starting from DDoS attacks to remote code execution, a full-fledged web application security platform will need to check the standout culprits like cross-site scripting. While the attacks are from the client side on most occasions, they can be configured to work remotely against the most secure platforms too.
What is Cross-Site Scripting?
Cross-site scripting, denoted by XSS, is a code injection attack on the client-side. The attacker intends to run harmful scripts in the victim's web browser by embedding malicious code in a simple web page or online application. The actual attack occurs when the victim hits the malicious code-infected web page or online application. The web page or web application serves as a vehicle for the malicious script to be sent to the user's browser.
The primary goal of this attack is to steal the identifying data of the other user - cookies, session tokens, and additional information. In most circumstances, this technique is used to steal the victim's cookies. Cookies, as you all know, assist you in automatically logging in. As a result, you may log in with the other identities using stolen cookies. That's one of the reasons why this attack is regarded as one of the most dangerous. It may be done using a variety of client-side programming languages.
Now that you have a general idea about cross-site scripting attacks, you will understand how these attacks work and their general flow.
Working of Cross-Site Scripting
Typically, the way a user interacts with a website is shown in the image below.
- User enters the website URL in the web browser.
- Browser asks the relevant information from a server hosting the website.
- Server sends the data back to the web-browser, where the user can retrieve the data.
When an attacker injects their code into a web page, usually by exploiting a weakness in the website's software, they may inject their script, which is run by the victim's browser. The dual connectivity of the web-browser, allows the hacker to attack either the server or end-user.
Another common application of cross-site scripting attacks is when the vulnerability is present on most of a website's publicly accessible pages. In this situation, hackers can inject their code to target website users by inserting their advertisements, phishing prompts, or other harmful information.
With the working of XSS attacks covered, you will over the different types of XSS attacks employed by hackers.
Categories of Attacks
- Reflective: In this scenario, the attacker's payload must be included in the request submitted to the webserver. Attackers use malicious URLs, phishing scams, and other social engineering tactics to trick the victim into sending a request to the server.
- Persistent: An attacker uses persistent (stored) XSS to inject malicious material (payload), most commonly JavaScript code, into the victim software. Should there be no input validation, the malicious code will be permanently saved (persisted) by the target program, such as a database.
- DOM-Based: This attack occurs when a web application's client-side script sends user-supplied data to the DOM. The web app reads the DOM and sends it to the browser. When the DOM data is read back, the payload is executed.
While there are multiple variants of these XSS attacks, security professionals recommend several preventive measures to combat them. So, go over some of these steps.
Preventive Measures
- Third-Party Frameworks: You may analyze your web app for Cross-Site Scripting and other serious vulnerabilities using automated security suites such as Crashtest and Acunetix before each release.
- Sanitizing Code: Sanitizing user input removes potentially executable characters from data. Instead, it converts unwanted user input into a usable format and guarantees that the data received cannot be construed as executable code.
- Escape Rules: Rather than attempting to establish whether data is user-provided and therefore potentially compromised, you must take precautions and escape data regardless of whether it is user-provided.
- Encoding JavaScript: Because the context into which you're writing defines the type of encoding you need to employ, encoding should be performed just before writing user-controllable data to a page.
- Implementing CSP: A content security policy (CSP) can specify which functions a website is permitted to carry out. This may be the most robust approach available to you because it may prevent XSS attacks or considerably minimize their likelihood.
- Using HTTPOnly Flag: If a web browser that supports HttpOnly discovers a cookie with the HttpOnly flag and client-side script code tries to retrieve the cookie, the browser returns an empty string. This prevents the malicious (typically XSS) code from delivering data to the attacker's website, causing the attack to fail.
With so many new facets in this tutorial, a live demonstration of how XSS attacks work will be beneficial. Now, look at the set of XSS challenges in our next section.
Demonstration of Cross-Site Scripting Attacks
You will solve a set of challenges dealing with multiple levels of XSS attacks. There are six levels in total. The website where one can start these attacks is XSS Game.
Level 1:
In this challenge, user input is immediately incorporated into the page without adequate escaping. You need to interact with the vulnerable program below to have it run JavaScript. For example, you may change the vulnerable window's URL bar or conduct actions within.
Because they are non-persistent XSS attacks, we must conduct a reflected XSS into the web-application, and the payload must be contained in the URL to be successful.
Payload: <script>alert('Level 1 Complete')</script>
Level 2:
Any text I submit appears to be a blockquote in the page source. So the same <script> tag from Level 1 should function here, but it doesn't. InnerHTML adds the created HTML fragment to the message. So, no script tags will be executed when the browser parses this HTML fragment (HTML variable in the preceding code).
The solution here is to use events. Events will adequately execute the defined JavaScript snippet.
Payload: <img src=X onerror="alert('Level 2 Complete')">
The above injection attempts to load an image that does not exist, causing an OnError event. OnError will run our alert function.
Level 3:
When a tab is clicked, the URL fragment shows the tab number. The value after the #tag governs the page's functionality. Therefore, it is an input. Consequently, you only need to create a payload that changes the <img> tag to run Javascript. In this case, you will utilize the existing image element and modify the src to something that doesn't exist, causing it to run an OnError event with the URL.
Payload: xxs.jpg' onerror='alert("Level 3 done")'/>
Level 4:
Because the website has a timer, putting numbers in the box starts a countdown, and when it ends, the program informs you. The value supplied in the textbox is sent to the server through the URL timer parameter.
In the OnLoad event of timer.html, the startTimer() function is invoked. However, the timer argument is provided directly to startTimer(). The Web-Application must do a pop-up alert() that escapes the startTimer function's content without disturbing the JavaScript code. The argument value is sent straight to startTimer() without filtering. Therefore, you can try to shoehorn an alert() function with the startTimer() function into the onload event.
Payload: ');alert('Level 4 Complete
Level 5:
You can inspect the page source. The "Next" link's href attribute value is "confirm," which matches the "next" URL query string. Using the "next" query parameter, you may add Javascript code to the href property of the "Next" link. Finally, the script activates when the user clicks the link.
Payload: javascript:alert('Level 5 Complete')
Level 6:
The flaw is in the code that handles the value following the # tag. Line 45 takes the value following the # tag as the gadget name. In line 48, this value is supplied directly to the includeGadget() function.
The includeGadget() function creates a <script> tag [line 18] and uses the URL (gadgetName) argument as src attribute of the script tag [line 28]. So you have total control over the HTML element of the script.
Payload: https://xss-game.appspot.com/level6/frame#data:application/javascript,alert('Level 6 complete')
Finally, you completed all six levels of our XSS challenge.
Conclusion
In this tutorial, you learned how cross-site scripting can prey on website vulnerabilities, its various categories, and some preventive measures that can help administrators protect their server software from being exploited. However, battling cross-site scripting is a single task in the ocean of skills an ethical hacker must master.
Simplilearn offers a Post Graduate Program in Cyber Security that covers all areas necessary to be learned by new and experienced ethical hackers alike. You covered topics like network sniffing, enumeration, and vulnerability analysis to prepare students for interviews and future corporate jobs. The IT industry is clamoring for competent cybersecurity personnel; therefore, now is the time to start learning about ethical hacking.
Do you have any questions about cross-site scripting attacks? Please leave your ideas and questions in the comment space below, and we will respond to them with solutions.
