A Cross-Site Scripting (XSS) vulnerability was detected in the web application. Cross-Site Scripting occurs when dynamically generated web pages display user input, such as login information, that is not properly validated, allowing an attacker to embed malicious scripts into the generated page and then execute the script on the machine of any user that views the site. In this instance, the web application was vulnerable to an automatic payload, meaning the user simply has to visit a page to make the malicious scripts execute. If successful, Cross-Site Scripting vulnerabilities can be exploited to manipulate or steal cookies, create requests that can be mistaken for those of a valid user, compromise confidential information, or execute malicious code on end user systems. Recommendations include implementing secure programming techniques that ensure proper filtration of user-supplied data, and encoding all user supplied data to prevent inserted scripts being sent to end users in a format that can be executed.
Cross-Site Scripting(XSS) happens when user input from a web client is immediately included via server-side scripts in a dynamically generated web page. Reflected XSS is specifically considered critical when malicious payload can be embedded in a URL (e.g. in query strings of GET requests). An attacker can trick a victim, via phishing attack, to click on a link with vulnerable input which has been altered to include attack code and then sent to the legitimate server. The injected code is then reflected back to the user’s browser which executes it.
The implications of successful Cross-Site Scripting attacks are:
- Account hijacking — An attacker can hijack the user’s session before the session cookie expires and take actions with the privileges of the user who accessed the URL, such as issuing database queries and viewing the results.
- Worm propagation — With Ajax applications, XSS can propagate somewhat like a virus. The XSS payload can autonomously inject itself into pages, and easily re-inject the same host with more XSS, all of which can be done with no hard refresh. Thus, XSS can send multiple requests using complex HTTP methods to propagate itself invisibly to the user.
- Information theft — Via redirection and fake sites, attackers can connect users to a malicious server of the attacker’s choice and capture any information entered by the user.
- Denial of Service — Often by utilizing malformed display requests on sites that contain a Cross-Site Scripting vulnerability, attackers can cause a denial of service condition to occur by causing the host site to query itself repeatedly .
- Manipulation of user settings — Attackers can change user settings for nefarious purposes.
- Bypass Content-Security-Policy protection — Attackers can inject a malformed tag formation, known as dangling tag injection, which in some cases allows injected script to reuse valid nonce on the page and bypass script source restriction. Additionally dangling tag injection can be used to steal sensitive information embedded in HTML response if browser is able to make a request to the injected link.
- Base tag injection: Attacker can cause relative links on a page to load from a different domain by modifying the base URL for the page via base tag injection.
- Link prefetch injection: While unable to execute script, attackers can use link tag with rel=prefetch that will make browsers pre-fetch the specified link even though it is never rendered and rejected subsequently due to web application enforced cross-site policy (e.g. CSP protections).
- Edge side includes (ESI) Injection — ESI is a markup language used in various HTTP devices, such as reverse proxies and load balancers, that are positioned between client and server. An attacker can inject ESI markup to perform critical attacks such as cross-site scripting and HTTPOnly cookie protection bypass.
Cross-Site Scripting attacks can be avoided by carefully validating all input, and properly encoding all output. When validating user input, verify that it matches the strictest definition of valid input possible. For example, if a certain parameter is supposed to be a number, attempt to convert it to a numeric data type in your programming language.
ASP.NET: int.TryParse(Request.QueryString[“q”], out val);
The same applies to date and time values, or anything that can be converted to a stricter type before being used. When accepting other types of text input, make sure the value matches either a list of acceptable values (white-listing), or a strict regular expression. If at any point the value appears invalid, do not accept it. Also, do not attempt to return the value to the user in an error message.
Most server side scripting languages provide built in methods to convert the value of the input variable into correct, non-interpretable HTML. These should be used to sanitize all input before it is displayed to the client.
PHP: string htmlspecialchars (string string [, int quote_style])
ASP.NET: Server.HTMLEncode (strHTML String)
s = s.replace(/&/g,’&’).replace(/”/i,’"’).replace(/</i,’<’).replace(/>/i,’>’).replace(/’/i,’'’)
Ensure that you are always using the right approach at the right time. Validating user input should be done as soon as it is received. Encoding data for display should be done immediately before displaying it.
For Security Operations:
Server-side encoding, where all dynamic content is first sent through an encoding function where Scripting tags will be replaced with codes in the selected character set, can help to prevent Cross-Site Scripting attacks.
Many web application platforms and frameworks have some built-in support for preventing Cross-Site Scripting. Make sure that any built-in protection is enabled for your platform. In some cases, a misconfiguration could allow Cross-Site Scripting. In ASP.NET, if a page’s EnableViewStateMac property is set to False, the ASP.NET view state can be used as a vector for Cross-Site Scripting.
An IDS or IPS can also be used to detect or filter out XSS attacks. Below are a few regular expressions that will help detect Cross-Site Scripting.
Regex for a simple XSS attack:
The above regular expression would be added into a new Snort rule as follows:
alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:”NII Cross-Site Scripting attempt”; flow:to_server,established; pcre:”/((\%3C)|<)((\%2F)|\/)*[a-z0–9\%]+((\%3E)|>)/i”; classtype:Web-application-attack; sid:9000; rev:5;)
Paranoid regex for XSS attacks:
This signature simply looks for the opening HTML tag, and its hex equivalent, followed by one or more characters other than the new line, and then followed by the closing tag or its hex equivalent. This may end up giving a few false positives depending upon how your web application and web server are structured, but it is guaranteed to catch anything that even remotely resembles a Cross-Site Scripting attack.
Fixes for Cross-Site Scripting defects will ultimately require code based fixes. Read the the following links for more information about manually testing your application for Cross-Site Scripting.
Best book for Hacking and Penetration Testing
Penetration Testing: A Hands-On Introduction to Hacking — https://amzn.to/2YUvteh
The Hacker Playbook 3: Practical Guide To Penetration Testing — https://amzn.to/2KEDonb
Mastering Modern Web Penetration Testing — https://amzn.to/2Hct6IX
Kali Linux Web Penetration Testing Cookbook: Identify, exploit, and prevent web application vulnerabilities with Kali Linux 2018.x, 2nd Edition — https://amzn.to/31IjPQG