CrossSite Scripting (XSS) - Security Check

In this post, we are going to explain in detail what exactly is CrossSite Scripting or XSS and why it is so important to remove any such vulnerability to your application.

Definition: 

XSS:

Cross-site scripting or XSS is a technique where untrusted code is injected into web pages viewed by others. A payload containing the untrusted code is sent to the web application as user input, which is then received by an unsuspecting user and executed. Cross-site scripting vulnerabilities typically allow an attacker to impersonate an affected user. If the affected user has privileged access to the application, the attacker could gain complete control over all application functions and data.

Types of XSS:

The most common cause of XSS vulnerability is the ignorance of strict checks, testing, and validation of user input or dynamic content before saving to the server while building the application, allowing client-side JavaScript to be injected in a manner that will enable it to execute. There are three primary flavors of XSS

1. Reflected XSS: This kind of scripting is non-persistent, which means when the injected malicious script results show up or are immediately reflected by the user
   Example:
   

   The second XSS vulnerability was found in the Help menu located 
   at https://commandcenter.com/help/ddhelp/
   ddhimpl/js/html/ddhelp.htm

   On this page, the ""Search"" functionality is vulnerable to XSS.
   Searching the following term would cause the script in the 
   ""on focus"" attribute is to be executed repeatedly until the user 
   leaves the page.
   ===============================================================
   "" onfocus=alert(document.cookie) autofocus
   ===============================================================
   
   
   
   

2. Stored XSS: This is persistent scripting which occurs when the data provided by the attack is stored on the server without adequate sanitization and then the malicious data is displayed on the web page to all users.
   Example:
   
   Adding information in a form input box - an attacker can type a malicious HTML in the box which should have contained the user's address
   ===============================================================
   Address: 123 Strreet <iframe onload=alert(document.domain)></iframe>TX,US
   ===============================================================
   
   
   
   
3. DOM-Based XSS:  This as the name implies the attack is at the client-side web browser generally done by containing client-side JavaScript that handles data from untrusted sources in an unsafe manner, typically writing data back to the DOM.
   Example:
   An application uses javascript in the dom to read from one input field and display value to another field
   ===============================================================
   var name = document.getElementById('Name').value;
   name = name + "exploit"
   results.innerHTML = 'Your name submited as: ' + name;
   ===============================================================
   

How to know your application is XSS or CSRF vulnerable:

Testing your application for XSS and CSRF is an essential need of any development process. The simplest way to verify for CrossSite scripting can be described as follows:

• Input coming into web applications is not validated before saving or processing.
• Output to the browser is not HTML encoded.

METHODOLOGY 

The assessment consisted of several phases, each detailed below along with the methodology, associated findings, and subsequent recommendations. GIS Vulnerability Management utilizes Penetration Testing Methodologies as the standard basis for penetration testing execution. 

The standard can be found here: https://owasp.org/www-project-web-security-testing-guide/latest/3-The_OWASP_Testing_Framework/1- Penetration_Testing_Methodologies

Tools utilized are covered in the Penetration Testing Execution can be found here: https://owasp.org/www-project-web-security-testing-guide/v41/6-Appendix/A-Testing_Tools_Resource

VULNERABILITY ANALYSIS 

Vulnerability identification and analysis is the process of discovering flaws in the hosted application. These issues could be anywhere from the application design to service misconfiguration and network misconfiguration as well.

MANUAL VERIFICATION 

Automated scanning tools often fail to report some vulnerabilities. A testing methodology that solely relies on automated scan results can give a false sense of security. For vulnerabilities discovered through automated scanning, manual verification ensures report findings are accurate and that the vulnerabilities reported are an accurate representation of the environment.

• Do manual entries of HTML, and Javascript codes into input boxes and makes the save. If the server saves the malicious content successfully then the application is vulnerable.
  
  
  
• Use Burp or Postman tool to test API endpoints with malicious content. For example Enter the malicious content (script) that needs to be uploaded on the server by modifying the “Value” parameter while forwarding the request, i.e., “<iframe onload=alert(document.domain)></iframe>” in the parameter;
  
  
  
• Enter the malicious content (script) that needs to be uploaded to the server by modifying the “Value” parameter while forwarding the request (there is no sanitization on the server side)., i.e., “<s>HTML-injection-Test</s>” in the parameter;
  
  

Implications / Consequences of not Fixing the Issue:

As a consequence, the malicious data will appear to be part of the website and run within the user’s 

browser under the privileges of the web application.

This vulnerability can be used to conduct a number of browser-based attacks including:

• Hijacking another user’s browser 

• Capturing sensitive information viewed by application users 

• Pseudo defacement of the application 

• Port scanning of internal hosts (“internal” in relation to the users of the web application) 

• Directed delivery of browser-based exploits 

• Other malicious activities

Suggested Countermeasures:

Using frameworks that automatically escape XSS by design, such as the latest Ruby on Rails, React JS.

•  Escaping untrusted HTTP request data based on the context in the HTML output (body, attribute, JavaScript, CSS, or URL) will resolve Reflected and Stored XSS vulnerabilities.
  
  
• Applying context-sensitive encoding when modifying the browser document on the client side acts against DOM XSS.
  
  
• Enabling a Content Security Policy (CSP) as a defense-in-depth mitigating control against XSS. It is effective if no other vulnerabilities exist that would allow placing malicious code via local file includes (e.g. path traversal overwrites or vulnerable libraries from permitted content delivery networks).
  
  
• Validating and Sanitizing every input entered by the user before saving should always be considered of prime importance during building the application.
  
  
• Check the impact of test input. Testers should analyze the results of the selected inputs and determine whether the discovered vulnerabilities impact the security of the application.

Conclusion:

CrossSite Scripting or XSS is avoidable vulnerability if design, implementation and testing of the application is done considering all factors of penetration testing.