Sumeru Cyber Security
  • Sumeru Cyber Security
  • Workarounds for prevalent vulnerabilities
    • Version Disclosure
    • Host Header Attack
    • HttpOnly and Secure Flag
    • Security Headers
    • Clickjacking
    • Weak Password
    • Username Enumeration
    • jQuery Outdated
    • Cross-Origin Resource Sharing
    • AWS S3 Bucket Misconfiguration
    • Directory Listing
    • Laravel Debug Enabled
    • Autocomplete and Remember Password Enabled
    • Brute Force Attack
    • Cross Site Request Forgery
    • SQL Injection
    • PhpMyAdmin page Available Publicly
    • Implementation of BASIC Authentication
    • Cache Browsing
    • Insecure Direct Object Reference
    • Active mixed content over https
    • Improper forgot password implementation
    • ASP.NET Debug Enabled
    • Sensitive Data Sent in GET Request
    • Weak CAPTCHA Implementation
    • Csv Injection
    • Cross Site Scripting
    • Web Server Robot.txt Information Disclosure
    • SSL Related Issues
    • Local File Inclusion
    • Weak CAPTCHA Implementation
    • Automated Form Submission
    • Php.ini File Available Publicly
    • ITLP
    • Internal Path Disclosure
    • Insecure Direct Object Reference
    • Access Token Not Expiring After Logout
  • OWASP A09-Security Logging and Monitoring Failures
  • OWASP API09-Improper Inventory Management v1.0
Powered by GitBook
On this page
  • Introduction
  • How to Test
  • Reflected and Stored XSS
  • DOM Based XSS
  • How to Fix
  • PHP
  • ASP.NET
  • JSP
  • DOM Based XSS
  • References

Was this helpful?

  1. Workarounds for prevalent vulnerabilities

Cross Site Scripting

PreviousCsv InjectionNextWeb Server Robot.txt Information Disclosure

Last updated 5 years ago

Was this helpful?

Introduction

It is possible to store and execute malicious scripts into the application. This vulnerability presents a high risk to the business since it lets an attacker to steal the valid session credentials of an authenticated user in the application.

Types

  • Reflected XSS

  • Stored XSS

  • DOM Based XSS

How to Test

Reflected and Stored XSS

When given the malicious script inside the input field and click update to store the given information

Here we given the malicious script as a payload to get the cookie information as <script>alert(document.cookie)</script>

Given malicious script is stored permanently and cookie shown in this application like the below screenshot.

DOM Based XSS

When the attack is injected into the application during runtime in the client directly.

When a browser is rendering HTML and any other associated content like CSS, JavaScript, etc. it identifies various rendering contexts for the different kinds of input and follows different rules for each context. A rendering context is associated with the parsing of HTML tags and their attributes.

How to Fix

  • The application must implement server side validation for all user-entered inputs.

  • HTML tags should be rejected by HTML encoding process.

PHP

The HTML entities function in PHP is used to convert characters into corresponding HTML entities where applicable. It is used to encode user input on a website so that users cannot insert harmful HTML codes into a site.

To prevent the Stored XSS we have to use the htmlentities() when storing the data to the server

This htmlentities() function will encode the user input and stores the data like below

When we fetch the stored data it will be shown as what we have stored in the database like the above instead of executing the malicious scripts.

ASP.NET

In ASP.NET Server.HtmlEncode() function will encode the user input and stores the data.

when we fetch the stored data it will be shown as what we have stored in the database instead of executing the malicious scripts.

JSP

First we have to import the library “org.apache.commons.lang3.StringEscapeUtils;”

In JSP StringEscapeUtils.escapeHtml4() function will encode the user input and stores the data and when we fetch the stored data it will be shown as what we have stored in the database instead of executing the malicious scripts.

DOM Based XSS

To make HTML in the DOM safe, we recommend:

  • HTML encoding, and then

  • JavaScript encoding all untrusted input, as shown in these examples:

* element.innerHTML ="<%=Encoder.encodeForJS(Encoder.encodeForHTML(untrustedData))%>"; 
* element.outerHTML = "<%=Encoder.encodeForJS(Encoder.encodeForHTML(untrustedData))%>"; 
 *document.write("<%=Encoder.encodeForJS(Encoder.encodeForHTML(untrustedData))%>"); 
* document.writeln("<%=Encoder.encodeForJS(Encoder.encodeForHTML(untrustedData))%>"); 

References

Note: The Encoder.encodeForHTML() and Encoder.encodeForJS() are just notional encoders. Various options for actual encoders are listed later in this link

https://cheatsheetseries.owasp.org/cheatsheets/DOM_based_XSS_Prevention_Cheat_Sheet.html
https://www.geeksforgeeks.org/htmlentities-vs-htmlspecialchars-function-in-php/
https://docs.microsoft.com/en-us/previous-versions/iis/6.0-sdk/ms525347(v%3Dvs.90)
https://howtodoinjava.com/java/string/escape-html-encode-string/
https://happycoding.io/tutorials/java-server/sanitizing-user-input