PostMessage Vulnerabilities
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
PostMessage संदेश भेजने के लिए निम्नलिखित फ़ंक्शन का उपयोग करता है:
ध्यान दें कि targetOrigin एक '*' या एक URL हो सकता है जैसे https://company.com. दूसरे परिदृश्य में, संदेश केवल उस डोमेन पर भेजा जा सकता है (भले ही विंडो ऑब्जेक्ट का मूल अलग हो). यदि wildcard का उपयोग किया जाता है, तो संदेश किसी भी डोमेन पर भेजे जा सकते हैं, और यह विंडो ऑब्जेक्ट के मूल पर भेजे जाएंगे।
जैसा कि इस रिपोर्ट में बताया गया है, यदि आप एक पृष्ठ पाते हैं जिसे iframed किया जा सकता है (कोई X-Frame-Header
सुरक्षा नहीं) और जो संवेदनशील संदेश को postMessage के माध्यम से wildcard (*) का उपयोग करके भेज रहा है, तो आप iframe के origin को संशोधित कर सकते हैं और संवेदनशील संदेश को एक डोमेन पर लीक कर सकते हैं जो आपके द्वारा नियंत्रित है।
ध्यान दें कि यदि पृष्ठ को iframed किया जा सकता है लेकिन targetOrigin एक URL पर सेट है और wildcard पर नहीं, तो यह चाल काम नहीं करेगी।
addEventListener
वह फ़ंक्शन है जिसका उपयोग JS द्वारा उस फ़ंक्शन को घोषित करने के लिए किया जाता है जो postMessages
की उम्मीद कर रहा है।
इसके समान कोड का उपयोग किया जाएगा:
Note in this case how the पहली चीज that the code is doing is उत्पत्ति की जांच करना. This is terribly महत्वपूर्ण mainly if the page is going to do कुछ संवेदनशील with the received information (like changing a password). अगर यह उत्पत्ति की जांच नहीं करता है, तो हमलावर पीड़ितों को इस एंडपॉइंट्स पर मनमाना डेटा भेजने के लिए मजबूर कर सकते हैं and change the victims passwords (in this example).
In order to इवेंट लिस्नर्स in the current page you can:
खोजें the JS code for window.addEventListener
and $(window).on
(JQuery version)
निष्पादित करें in the developer tools console: getEventListeners(window)
जाएं Elements --> Event Listeners in the developer tools of the browser
Use a ब्राउज़र एक्सटेंशन like https://github.com/benso-io/posta or https://github.com/fransr/postMessage-tracker. This browser extensions will सभी संदेशों को इंटरसेप्ट and show them to you.
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:
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:
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:
Bypassing the escape:
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.
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 SOP with Iframes - 1It'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):
आप e.source
को null करने के लिए एक iframe बना सकते हैं जो postMessage भेजता है और तुरंत हटा दिया जाता है।
अधिक जानकारी के लिए पढ़ें:
Bypassing SOP with Iframes - 2इन हमलों को करने के लिए, आदर्श रूप से आप शिकार वेब पृष्ठ को एक iframe
के अंदर रख सकेंगे। लेकिन कुछ हेडर जैसे X-Frame-Header
उस व्यवहार को रोक सकते हैं।
उन परिदृश्यों में, आप अभी भी एक कम छिपे हुए हमले का उपयोग कर सकते हैं। आप कमजोर वेब एप्लिकेशन के लिए एक नया टैब खोल सकते हैं और इसके साथ संवाद कर सकते हैं:
नीचे दिए गए पृष्ठ में आप देख सकते हैं कि आप कैसे संवेदनशील postmessage डेटा को बच्चे के iframe में चुरा सकते हैं, डेटा भेजने से पहले मुख्य पृष्ठ को ब्लॉक करके और बच्चे में XSS का दुरुपयोग करके डेटा लीक करने से पहले:
Blocking main page to steal postmessageयदि आप बिना X-Frame-Header के एक वेबपृष्ठ को iframe कर सकते हैं जिसमें एक और iframe है, तो आप उस बच्चे के iframe का स्थान बदल सकते हैं, इसलिए यदि यह एक postmessage प्राप्त कर रहा है जो wildcard का उपयोग करके भेजा गया है, तो एक हमलावर उस iframe का origin एक पृष्ठ में बदल सकता है जो उसके द्वारा नियंत्रित है और संदेश चुरा सकता है:
Steal postmessage modifying iframe locationउन परिदृश्यों में जहां postMessage
के माध्यम से भेजा गया डेटा JS द्वारा निष्पादित होता है, आप पृष्ठ को iframe कर सकते हैं और प्रोटोटाइप प्रदूषण/XSS का दुरुपयोग कर सकते हैं, जो कि postMessage
के माध्यम से भेजा गया है।
postMessage के माध्यम से बहुत अच्छे से समझाए गए XSS के कुछ उदाहरण https://jlajara.gitlab.io/web/2020/07/17/Dom_XSS_PostMessage_2.html पर मिल सकते हैं।
iframe
के लिए postMessage
के माध्यम से प्रोटोटाइप प्रदूषण और फिर XSS का दुरुपयोग करने के लिए एक उदाहरण:
For अधिक जानकारी:
प्रोटोटाइप प्रदूषण के बारे में पृष्ठ का लिंक
XSS के बारे में पृष्ठ का लिंक
क्लाइंट साइड प्रोटोटाइप प्रदूषण से XSS के बारे में पृष्ठ का लिंक
अभ्यास के लिए: https://github.com/yavolo/eventlistener-xss-recon
AWS हैकिंग सीखें और अभ्यास करें:HackTricks Training AWS Red Team Expert (ARTE) GCP हैकिंग सीखें और अभ्यास करें: HackTricks Training GCP Red Team Expert (GRTE)