I Started Learning postMessage Bugs

Added: 2026-05-19

[00:00:00]In this video, I'm going to start the process of learning post message bugs.

[00:00:04]This is a bug class I've wanted to get into for a while now. If you've known if you know who I am, if you've been following the channel, you know I've been doing a lot of work on the client side, getting to know the JavaScript files a lot better, actually starting to extract, beautify, and learn take params and stuff from there. So, I believe a next next step would be learning post message bug hunting. So, I have yes, we have pulled up. I actually I read this.

[00:00:27]I also watched this video here by Ammerse and I did some chat GBT stuff trying to learn more and created this slideshow. But first, if you don't know how I am, my name is Logan Sack. I've been at Bug Man Hunter for the last nine months now and releasing out my first valid bug on the Canadian government.

[00:00:40]However, I'm still in the progress of getting my first paid bug and that's pretty much going to be the number one focus until until I hit it. But first off, I just wanted to go through because I still don't quite understand Postmatches bugs. So, I'm just going to go through learning it a little bit first. So what first I did was I watched this video by Ammerse very good video I believe it's very underrated there not there aren't very many videos on the topic of postm bugs in the first place like if you scroll down you have critical thinking from post exploits from three years ago this a year ago maybe this is something I could watch why hackers love post messages came out a month ago probably have to watch that but there's genuinely just not very much out there when it comes to post message so very first thing I did is I watched that video and then I read this. So let me just give you guys like a quick overview. So introduction to post message. So basically it's anything with with the method window message is used by application to allow cross origin communication between different window objects. This method provides a way to securely circumvent the restrictions on the same origin policy. So you have the message target origin and then the transfer. So post message vulnerabilities is is essential to to ensure that post message is implemented properly. If not this could lead to security vulnerabilities such as cross-ite scripting, sensitive data exposure, information theft and others.

[00:02:03]So identifying the use of post messages.

[00:02:05]This is something where I've had a little bit of problems because I'm like okay if I see post meshes that means that could be something. Like for example this is a bug bounty target that I've been hunting on. And if you go here to inspect and we go to the network tab and let's just reload.

[00:02:23]There is a main file right here. This one. And let's go to the sources from that one.

[00:02:30]Let's take that to sources panel. Now if I go F and I go like post message, I see stuff.

[00:02:40]Wait, this might be the wrong one. But we're still seeing stuff. See how we see S.Post message. But that doesn't mean this is explo exploitable because we still need to find the add event listeners. Yeah, that's the most important thing is this. Ah, here we go.

[00:02:55]Here's like message.

[00:02:58]Okay, let's just get this real quick.

[00:03:04]Here we go. So, post message0 addeventlister.

[00:03:10]And you see how sometimes it will say stuff like if you go back here if it doesn't have let's go down this is the exploit chain. See how it's lacking the where where is it?

[00:03:25]Where it is? Uh it doesn't utilize this right here. Do not utilize a wild card target origin. Instead use expected target origin with post message. So I see here that I'm not seeing a target origin, but it doesn't automatically mean that this is vulnerable. Like for example, you're supposed to look for post measures in specific scenarios.

[00:03:46]Like for example, let's let's start me by me fully going through this. I'm not going to bore you guys by going through all of this. I've already read this, but I will go through this real quick.

[00:03:56]And genuinely, I'm trying to get a better understanding of this. I'm probably going to do some sports swigger labs and probably some other reading and actually go hunting for this in the wild.

[00:04:04]Okay, so post message bug hunting sheet cheat sheet plus study guide goal. Stop pro stop proving post messages exist and start prove impact which is exactly what I've been doing. I'll just like see it and then like okay does that mean it's vulnerable? I don't see the event origin or like the eval thing but it doesn't automatically mean it's a bug.

[00:04:26]So all right in window add eventlister message handler it starts with you have the attacker origin. So, okay, even this I'm still a little bit confused about this right here. The relationship between the Okay, one second. Okay, I'm back. I was hearing something weird in my house. But anyway, um so I don't quite understand the relationship between the attack origin message handler and sync. So, before I even go further into this, I'm just going to that like what's the relation? I don't I'm just going to going to look it up.

[00:05:02]So explain the relationship between attacker origin.

[00:05:18]Got the I handler message handler and sync action. Actually, I think I understand sync. This is like pretty much same with like cross-ite scripting where like if you can get the h if you can get like a script alert, but if it's not in a spot that it's actually going to execute, it doesn't matter. So, okay, think of every post message bug as a three-part chain. Attacker origin, message handler, sync slashaction. If any part of the chain is missing, the bug usually dies. Okay. Attacker origin.

[00:05:59]The attacker origin is a malicious message comes from example evil.com. The attacker controls a page like target window.post message type update profile name image search equal x on on error equal alert and then I would assume this means the origin is wild card.

[00:06:22]So any origin I'm pretty sure and then this means the attacker is trying to send data into the target app. Important attacker origin is not the payload itself. It is the website/domain sending the payload.

[00:06:37]Okay.

[00:06:40]Wait, wait. But like I don't understand how this will get sent anywhere. Does it just send it everywhere? That that that just can't make sense though.

[00:06:50]I got to look into that more too. So when you test post message, the question is can evil.com send a message that target page accepts.

[00:07:00]If the target only accepts messages from trusted.target.com, then ille.com should be blocked. But if the handler has no origin check or has a weak check, the or the attacker origin becomes dangerous.

[00:07:13]Message handler. The message handler is a JavaScript code on the target page that receives the message.

[00:07:20]Example window add eventlister message function event console.log event or origin console.log event data. Okay. So I do know console.log is basically the equivalent of Python for print.

[00:07:36]So this handler receives event.org event.org origin event data event. source where the message came from. Event data the data sent by the attacker. The events source the window/frame that sent it.

[00:07:54]A safe handler should usually do something like this. So it'll do its little thing with like the window.ventlister message function event, but then there will be an if statement. So ifvent.org not equal to https trusted.target.com target.com return handle trusted message and dangerous handler looks like window.addeventlister message function event and then there is no if statement and it's just document.body and then you have the h enter.html HTML which I think is something else where I think that might be the sync maybe. Is that the sync?

[00:08:35]I believe that's the sync. Yeah. Handler event. Data. I'm pretty sure that's the sync.

[00:08:43]No, this is the sync. Sync is right here. Isn't that also sync? Okay. Um Okay. Yeah. So why? Because it accepts data from anywhere and uses it directly.

[00:08:55]The handler is the gatekeeper. It decides who sent this. Do I trust them?

[00:09:01]What data did they send?

[00:09:03]What am I going to do with it? Bad handlers either do not check event.org, check event.org weekly, do not validate event.data, trust message types blindly, pass attacker data into dangerous code.

[00:09:22]Okay. Um, sync slash action. The sync or action is where is what the app does with the received message. This is where impact happens. Okay, so it doesn't matter. Okay, so at least to my understanding, let's say you find for example, you find this the ad event listener and it also you have your attacker origin set up and there is no check. But even if all of that works, like you can send the message, but if the sync to action there is it's not going somewhere sensitive or something, then if you have no impact, it doesn't matter. So that's why it means where it's like all three parts of the chain need to be successful for this to actually be a bug. Otherwise, it's more like just a it's a gadget. It's a feature. And it might not be perfect security, but at the end of the day, nothing's being exploited. There's no impact. So what is why does it matter?

[00:10:17]So this this is where impact happens. So sync example DOM XSS window.adde eventlister message function and then document element by ID output enter.html equals event.data if attacker sends so this is some JavaScript. Okay.

[00:10:36]Then the sync is enter.html.

[00:10:39]Oh okay. Okay. I get I get so yeah so enter HTML this can execute JavaScript that can become DOMXS. So the chain is evil.com sends HTML payload and then target page message handler accepts it because it has the add event listener and it's actually not being checked. It doesn't have the origin check and that leads to handler puts it into inner html leading to XSS.

[00:11:12]So action example account change. Not every post message bug is XSS. Sometimes this the sync is privilege action example. Okay, I'm going to read some JavaScript. window add eventlister message function event if event.data.type type equal to change email fetch/ API/acount/ email method post body JSON.stringify email event.data email.

[00:11:41]Okay. So if there is no proper origin check attacker sends type change email email attacker evil.com then the chain is what I don't understand is like how does it wait no no no it sends it because this is open and there's no check but like I don't understand how you create the the attacker the attacker origin how would you create the attacker origin website so then the chain is evil.com sends change email message target message handler accepts it and then handler makes authenticated request victim account email change.

[00:12:20]Also, I don't understand how this is a bug. Isn't this like self XSS? Cuz like is this like a link you can send to another person?

[00:12:31]Wait, do you send like your um your attacker domain to the victim? Is this like a fishing thing? And then from there they click it, they get a I don't Okay, that's awesome. somebody even though like I'm a bug bount hunter I read that it's important to you need to think like a black hat you could say not because you're actually going to do anything bad but you just want to helps you to prove impact so that is often better than basic alert box because it has direct account impact the relationship in one sense the attacker origin sends untrusted data the message handler decides whether to trust and process it and the sync/action determines whether that trust mistake becomes a real vulnerability.

[00:13:13]Okay, I'm just going to um going to write that somewhere. Okay, I'm just going to put it right here.

[00:13:19]That's that's important. All right, have that down. Probably going to be it for that.

[00:13:25]Okay, so how to think while hunting.

[00:13:28]Use this checklist. Can attacker controlled origin send a message? Does the target page have a message handler?

[00:13:36]And can the attacker control origin send a message? Can't that always be true?

[00:13:43]Does the target page have a message handler? Does a handler check event.org origin correctly? Does event data reach a dangerous sync or privilege action?

[00:13:53]Can this produce real security impact?

[00:13:55]The harsh truth. Most post specialist findings fail at step four or five.

[00:14:00]Okay. Does event data reach a dangerous sync or privilege action? finding this window addit listener message handler means almost nothing by itself.

[00:14:11]So this is a hand the handler it's the function finding this wait I think so right what does handler what's the handler usually I still have questions okay but I'm just going to keep reiterating this and asking asking the questions so window addeventlist listener message function event documentbody html event html with no word in check is where your eyes light up. Mental model. Think of it like a delivery system. Attacker origin equals suspicious. Delivery driver.

[00:14:48]Message handler. Front desk security guard.

[00:14:52]Sync/action. What happens after the package is accepted? A save app says I only accept packages from this exact trusted sender. A vulnerable app says the package says target.com somewhere on it, so it must be trusted. Or worse, I accept every package and I immediately open it inside the admin office. That is a bug. All right, let me go ahead and write down put this checklist as well.

[00:15:15]Okay, then put Whoops. Checklist.

[00:15:20]Write down this as a checklist.

[00:15:23]Checklist. Okay, now I'm going to go back here.

[00:15:29]And now I get some more questions answered. First off, what is the what does the handler handler look like?

[00:15:35]Wait, no, no, actually. Yeah, start here. What does the hand deliver look like in JS?

[00:15:48]Is I'm actually there's just so little stuff out here on postmatch. It's really strange. Postmatch handler JS usually looks like code that listens for message event.

[00:15:59]Okay, so the handler is going to just be like the add event listener. be honest like that might be kind of like how come okay you know whatever it's my channel I'll ask the dumb questions I want to so window on message okay common real world shapes add event listener handler origin check if origin and not equal return weak origin check handler that returns event data Okay.

[00:16:34]Okay. Handler with JSON parsing JSON.

[00:16:41]Switches message type.

[00:16:45]Yeah. So many different ways and things going on here. Okay. The most part I just I got what I wanted.

[00:16:53]The mental pattern your mental pattern when reading JS look for this structure window add event listener message function event origin check that's first thing you want to look for is there origin check if event origin not equal to https trust.com return two data extraction const data equal event data three action based on data if data type equal to something and then four sync SL action. Your job is to answer who can send the message. What data can they send? Does this handler trust it?

[00:17:28]What dangerous thing happens after trust?

[00:17:34]Okay.

[00:17:35]And now last thing, how does attacker create what's it called? The attacker origin. the attacker origin which sends a post message.

[00:17:57]Do I need a domain?

[00:18:03]Then I still have one more question.

[00:18:07]So no, you do not need a real domain to start testing for learning and basic proof of concepts. Your attacker origin can be just local host stuff. That means your local machine is actually is acting as a attacker controlled website.

[00:18:20]Quit attack origin actually means scheme plus host plus port breakdown. Your local origin could be so when your local exploit exploit page sends a message. The target sees event.org equal to note event.org equal to evil.com. Basic attacker page create a file called exploit.html.

[00:18:43]Put this inside post message attacker page target.

[00:18:49]This is the thing we're targeting, right? With hand with page handler.

[00:18:54]Yeah. Okay. And then const iframe equal document.element by ID target iframe.onload um iframe.content.window.post message test html. It's good for JavaScript URL once again.

[00:19:11]So what's the difference between this? Is this different for a reason? Then serve it locally. Open exploit.html. Now your attacker origin is your page is sending a message into the target iframe. When you when you do need a real domain, you need a real a real or deployed domain.

[00:19:31]When target blocks local host, you need https. You need to prove realistic victim attack path. You need to bypass weak origin checks like include start.com. You need to host you need to host a page publicly for triage.

[00:19:46]For example, with vulnerable check is if includes and yeah, you can't use that because you need it to be something where it has target.com somewhere or evil-target.com.

[00:19:56]So cheap options for testing eventually get a cheap domain login sack testing.com and create subdomains like Yeah. Okay. Uh domains do not need to be fancy. just needs attack control. You can host exploit page, GitHub pages, cloudfare, yada yada. Exmp important difference local testing versus realistic exploit. Local test good for answering. Can I send a message? Does the handler receive it? Does event data reach the sync? Does payload execute?

[00:20:22]Local origin. Realistic exploit good for report evidence. Can a real attacker controlled website exploit this? Would a victim only need to visit my page? Okay, so the vis the victim does need to visit the attacker's page. How would the victim even get to the attacker's page? Does it work on HTTPS? Can triage reproduce it?

[00:20:45]Real attack origin. Real attacker or Ira attack? Pretty much the same thing again.

[00:20:53]Okay. Oh, okay. I get it. I get it. So, wait. No, I don't. No, I don't. Real attacker origin and then I frame base attack mage. uses when the target page can be framed. So, this is the vulnerable page. Yeah.

[00:21:08]What's the ID supposed to be? I guess it's just Okay.

[00:21:13]And then target. Yeah. And then, but why is the URL evil.com? Isn't the URL this?

[00:21:23]If target has X frame options denied, content security policy frame ancestors none, then I frame testing may fail. The have some does not always kill a bug.

[00:21:32]You may test will pop up instead.

[00:21:37]Okay. This creates a new target window.

[00:21:39]Waits a few seconds and sends a message.

[00:21:42]Then inside JavaScript handler, target sees the page is hosted at login.com.

[00:21:48]Then target sees event dot ruthless ruthless part. Do not buy a domain yet just because you are learning post mess.

[00:21:56]That is premature. Start with local host. that only use a real domain when you find handler that actually has a plausible sync slaction. Your workflow should be fine handler, understand expected message format, test with logo host, confirm sync/action impact exist, do not skip step five.

[00:22:14]Do do not skip to steps five before step two.

[00:22:20]Okay, that is how beginners waste days making beautiful exploit pages for handlers that do nothing.

[00:22:26]Okay, so that leaves me with one problem. One question. How is this a bug? How is this a bug?

[00:22:40]Does victim need to go to attacker website?

[00:22:48]And if a victim went to attacker website, wouldn't that already be like bad?

[00:22:53]Yes. In most post measures exploit scenarios, the victim needs to visit attacker control page or interact with an attacker control pop-up embedded flow that is not automatically disqualifying.

[00:23:03]A lot of web bugs require victim interaction with like access CSRF, oath login, CSRF, open redirect chains, clickjacking, etc. The real question is if the victim visits the attacker page while logged in and the attacker cause something cause something security impacting to happen, this could still be a bug. A post magic bug is usually a client/ trust bug.

[00:23:27]The target page has JavaScript that says window.adde eventlister accepts a message performs action. The vulnerable version basically means I will accept infrastructure from any website.

[00:23:39]So the attacker hosts a page like even a com victim visits it. Attacker page opens opens or frames the real target.

[00:23:47]Then then the attacker page sends target window.post Post message type change email email attacker evo.com.

[00:23:56]Okay, that makes sense. So if the handler accepts that message and performs action, the victim's browser does the action while logged in. That is the bug. Okay, so victim does not need to paste code. The victim does not need to open dev tools. Victim does not need to manually send the message. They only need to visit the malicious page assuming the target can frame can be framed/opened and the handler is reachable. Example, not a bug. is probably not reportable. Window addeventlister message function event console.log event.d data exploit chain attacker sends a message target logs it into console. Nothing security relevant happens. Okay. So then this this is what you would call the sync I guess would be console.log. It's just it was just going to pop up in the console like nothing bad actually happened. So example real bugxs.

[00:24:46]So now it gets placed in document.body.

[00:24:48]body.inhtml.

[00:24:50]Inside HTML, you can do you can ex execute JavaScript. So therefore, from the attacker domain, you could input a malicious payload like image equal X on error alert document. And now we have exploit chain victim visits attacker.com. Tacker.com frames/opens target.com.

[00:25:11]A target attacker.com sends malicious HTML. target.com inserts it into inner html JavaScript executes on target.com.

[00:25:21]This is a bug because attack control JavaScript executes in the target origin. Okay. Impact can read page data.

[00:25:29]Perform actions as the user steals CSRF tokens access accessible modifying account settings interacting with same origin APIs. Example real bug account action target code.

[00:25:41]Sorry if I keep sniffing, but I'm a little I'm kind of sick right now. Okay.

[00:25:45]So, window addventlister message function event if event.data.type equals update web hook fetch and then that method post credentials include oh credials credentials include body json.stringify url event.data URL.

[00:26:05]Okay. So, attacker sends target window.post Post message type update web hook URL attacker.com/webhook exploit chain. So that would go in here, right?

[00:26:22]And then the web hook would become the attackers.

[00:26:26]Okay. So victim visits attacker.com.

[00:26:29]Attacker.com opens target.com/s settings. Message triggers authenticated fetch. Victim's web hook changes to attacker URL. This can be high impact if web hooks receive sensitive inv oh my goodness I'm tired invites no events events sensitive events payment notifications internal data off events etc when victim interaction makes it weak victim interaction makes the bug weaker than when the victim must click many things victim must already be a very specific page target page cannot be framed or open reliably The action requires visible confirmation. Yeah, that's going to be bad. No one's going to say yes, let me be hacked. The payload only works in the attacker's own account. Yeah, that's that's just like selfex, not not a bug. The impact is just alert one with no sensitive context. For bug bounty, you need realistic attack path. Victim clicks one link while logged in, exploit happens.

[00:27:30]That is much stronger than victim must log in, navigate to settings, open dev tools, paste code, and then click submit. Second one is garbage. Key difference from normal CSRF client side request forgering abuses the server accepting a forged request.

[00:27:48]Post mesh abuses abuse usually exploits the front end accepting a forged instruction.

[00:27:54]Accepting a forged instruction, then the front end performs the action. CSRF attacker.com sends request directly to target.com.

[00:28:03]Post message bug. Attacker.com sends message to target page. TargetJS sends request to target.js. Sends request to target.com.

[00:28:14]The second version can bypass some CSRF protections because the request is made by the real apps JavaScript potentially with expected headers, tokens or request format. This is why it can matter. Your report has to prove this. A strong post message report should show vulnerable handler code missing/weak origin event.org origin validation attack control and message realistic victim delivery iframe or popup security impact xss sensitive data leak account change token injection web hook change ooth abuse etc. weak report and controlled origin can send a crafted post message to settings/inttegrations because the handler does not validate event.org origin accepts type update web hook and forms an authenticated request to update the victim's web hook URL. A victim only needs to visit the attacker control page while while logged in.

[00:29:09]Okay, this is a strong report. That was a weak report. This page has post me and no origin check. Yeah, that you need to prove the impact like show it. Bottom line, yes, the victim usually needs to visit the attacker website. This is still a bug only if the attacker control message causes real impact inside the target origin or victim account. The chain you need is victim visits attacker page. Attacker sends post message target handler trusted dangerous sync/action runs. Security impact happens. No sync action, no bug. No realistic victim path weak bug. No impact. Do not report.

[00:29:45]Okay, so now I'd say I have a better understanding of at least the theory behind it and some of the key terms like the attacker origin, the handler source action, well sync slaction.

[00:29:57]So now let me go ahead and read this. I just wanna I This is kind of a long video. Might be kind of boring to be honest. But at least this is me going through learning something new and I think this is important for me to post on my channel cuz I I want to see like look back on Logan Sack. What what was he doing when he was um up and coming, you know? So all right, we kind of already read this attacker origin message handler sync/action. So mental model five-part chain a report lives or dies on this chain one weak link keep digging sender no one sender can attacker open iframe slashpop it up message can attacker control event data receiver which page listens trust check origin plus source plus schema validation sync/ action xs leak redirect or state change so this right here which page listens That's where we're going to get the uh event listener. No, add event listener.

[00:31:02]And then it does matter like the trust check. And then you still need to think about like can we bypass will the message actually get sent and it will actually be inputed inside. But then we still need to think about even if it gets put inside is this a dangerous sync because if not if there's a sync this is a sync with no impact doesn't matter. So cheat sheet rule untrusted origin trusted handler dangerous sync action realistic victim path real impact.

[00:31:30]Okay so fast vict fast recon find the listeners first your JS recon should flag handlers before you open burp. Yeah I've been working on some JavaScript um scripts as of late if you want to get them. They're uh they're coming out very soon. I'd say this Friday for people who are in my list, go to loans.com link in the description and um quick grip over beautifyjs.

[00:31:59]You just add some post message stuff and then browser checks. Oh yeah. Yeah. Look at this. I'm going to show you this real quick.

[00:32:07]So get event listeners window message.

[00:32:10]Be honest, I don't understand what that does. Let's go here. See console.

[00:32:16]I click it. See, it it shows something.

[00:32:19]I have no idea what this this means, though. What does that stuff mean?

[00:32:24]Let's just finish reading this first. Do not stop at found post message. Your target is handler plus missing/bad trust check plus dangerous behavior. Okay, so you have that. You also have dev tools event listeners message source sources search sources for event.data/ data/ origin trace from listener to sync action. Okay, but what does that mean? What does this stuff mean? Okay, I have a hard time I'm seeing it. The windows open, but okay.

[00:32:52]Uh crap. What does this mean?

[00:32:58]What does this mean?

[00:33:04]Let me just make sure it gets it correctly. Let me just Can I just Hey, there you go.

[00:33:17]Cuz I genuinely have no idea what the heck I'm looking at. What does once false passive false type message even mean? I have no clue. This means your current page has two JavaScript post message handlers registered on window dot you ran get eventlister window dossage and chrome returned length two. So the page is listening for incoming post message events in two separate places what each field means.

[00:33:44]So first one type message use capture false listener f this is actually JavaScript function that runs when the page receives a message. This is the important part. For example, somewhere in the app, there is code like window event listener message event. Is there I'm telling you I feel like I looked I didn't see this. Let me check.

[00:34:11]I should have everything pulled up here.

[00:34:14]If it's going to be here, is it wouldn't it be in here? See, we're seeing zero.

[00:34:18]Like, what is it?

[00:34:21]We have this like window. Event lists are test passive.

[00:34:29]I'm not really seeing like it's always talking about you see stuff like function event. I don't see any function event.

[00:34:40]Um what is it seeing?

[00:34:49]Let's test.

[00:34:53]I guess I need to um Oh, what's this?

[00:34:55]Pop state.

[00:34:57]Remove event listener pop state. What's this? I don't Okay, I'mma ask. I'mma ask.

[00:35:03]Chrome is showing you that function as I need to figure out what the f function is. I need to minify this code or whatever it is. So actually look inside it. Second one is probably minified code. Yeah, T is probably the message event. So zero equals anomous message handler one name/minified message handler called RT once false the handler does not remove itself after writing once it keeps it will keep listening for messages passive false not very important here passive matters more for scroll/ouch events for message events is usually irrelevant type messages confirms that the event type is post message receive event it means the page listens for message events yeah also not very important for post message hunting. It means the listener is not using capture phase behavior.

[00:35:51]Well, they use capture. What does what this does not mean does not mean you found a bug. It only means the page can receive.

[00:35:59]No, it can receive post messages. That is step one. A bug requires a chain. Right now you concerned message handler exists. That's not enough. You need to what what you now what you need to do next click the listener F or listener RT in dev tools. Chrome should jump you to the source code for that handler. You're looking for things like event.org origin event. Events source or minified equivalents. Okay, let's see. Let me go back to the console.

[00:36:34]Why is it why is my computer so dark, bro? I open up my window. Uh, let's go to which one are you looking for? The on message one.

[00:36:46]I don't even know which one we're looking at.

[00:36:51]Um, yeah. This is going to this about get ugly really fast.

[00:36:58]One second. Okay. Uh, I I I'll be honest. I don't know what I'm looking at. I have no idea what what the heck I'm looking at.

[00:37:13]Bro, I don't know what I'm Okay, just start opening stuff up.

[00:37:22]Yeah. Uh, I don't know what I'm looking at.

[00:37:28]Let me just look for it in here. What if I just like search for it in the source code?

[00:37:33]Sources.

[00:37:36]Actually, I want to ask you about this one, too.

[00:37:40]What is this?

[00:37:46]Uh, is that meaningful?

[00:37:51]Second handler. This is probably your event objects. So, inside the function look for pretty much the same thing.

[00:37:56]What wouldn't be interesting? No origin check. I'm not seeing origin check, but like um we have syncs and stuff. It's just like I don't know.

[00:38:06]I don't know what you should do right now in console run this. I can run console stuff then run if Chrome allows it.

[00:38:17]Excuse me. Uh it will print the actual hand. Okay, let's see. Uh what's this looking like?

[00:38:23]Let me not let me just like I'm not it's not does the clear function work? No.

[00:38:29]Okay, let me just Okay, so function native code. What the heck does that mean?

[00:38:42]Then run this one.

[00:38:46]Okay.

[00:38:50]Ah, yeah. I don't know if that's important or not. I have no idea. I mean, like it showed something. That's that means something, right?

[00:39:02]Um, okay. I'll get rid of this for now.

[00:39:04]Let me just like move this over so I don't forget about it.

[00:39:08]Over here.

[00:39:10]Um, example. Just name it whatever.

[00:39:14]What the heck is that? Why is it like that? I don't know. Okay. Um, go back.

[00:39:20]Remove.

[00:39:22]Then inspect. Does it check origin?

[00:39:26]Does it Does it touch DOM?

[00:39:30]Your screenshot also shows download the VU dev tools extension.

[00:39:35]So one of these handlers may be for from VU related code that often ends up being noise unless it interacts with app specific behavior. Okay, so we do have this. Let me just copy and then just paste. What does it have to what does it think about this? To be honest, I have no idea. I don't know.

[00:40:02]Okay, this is almost certainly meta/pixel IWL code, not the target app's custom business logic. What does that mean?

[00:40:10]Does that mean I'm looking at the wrong thing?

[00:40:14]Like, no. No. Right. I mean, it says main. I mean, it says main. It has to be for the right app, right?

[00:40:20]I mean, yeah. Right. Right.

[00:40:25]I did. Well, likely means something like Facebook's integrated web learning codeless events to set up behavior. This is probably loaded from tracking/ pixel script cleanup version your minified handler Facebook bootstrap.

[00:40:45]What it is what is it doing? What it is doing? Your handler receives a message event here message origin and extracts these fields from the message.

[00:40:57]The two accepted messages message types are Facebook IWL bootstrap Facebook IWL confirm domain that is your biggest clue. This is face this is Facebook/ metat tracking tooling not core app functionality. Is there an origin check?

[00:41:12]Yes. This part is the origin source/v validation var b equal.est t.org origin t.org origin. Okay.

[00:41:22]And then the equal e. Okay. It is saying the message is trusted if t.org origin matches reax or t.org m matches reax f or message source match expected window/source condition. The actual important thing now is knowing what the underscore and f are. They are probably reaxes for trusted Facebook origins like facebook.com, facebook.net, meta.com.

[00:41:47]But you should not assume you need to click around and the source and find the definitions in F. Search in the same JS file for F equal or pretty print the file and search for yeah that's probably going to be apply. So then scroll upward until you find this is likely is this likely exploitable? Probably not. Reasons it checks origin/source. It only accepts Facebook specific message types. It validates validates pixel ID with you dash dot dot dot dot dot not actions are Facebook pixel/bootstrap actions not target account actions responses are sent back to t.source source not inserted not inserted into DOM no obvious dangerous sync like enter HTML eval location no fetch to target API or account mutation so right now this looks like a tracking script noise what would make it interesting only keep digging if one of these is true the origin reax is weak accepts attack control domains graph token can be leaked or abused does something dangerous with tag control data message causes sensitive target site behavior not just Facebook pixel setup dangerous functions here are all ones that I don't know you need to jump to their definitions and search for them then check current verdict do not report this right now you found Facebook/ssage pixel post message handler with some ordinance/source validation that handles Facebook IWL bootstrap messages that is not a bug your next move is this return native code So probably browser.

[00:43:30]So it is probably browser framework internal noise. This one is probably third party pixel noise. The list answer this is almost certainly not where the bounty is. Move on unless you can prove the underscore or f except t control origins.

[00:43:46]All right. All right. So at least I have better understanding of what the heck this stuff is going is doing and what's going on here. So understand like explain this to me. Let's just have him explain that to me first before I move on. Explain this. I also see this in the code. Explain that.

[00:44:04]Now I can't forget the uh these things.

[00:44:09]Um something else I found in the JS. I'm not going to lie, I found I actually find JS quite interesting.

[00:44:26]Okay, this is not post measure. This is browser history manipulation. You found code using the history API.

[00:44:32]What it means? Window history replace state. This changes the current browser history entry without reloading page example.

[00:44:41]This ch this changes the visible URL to settings/profile without full page reload. Very common in react sba single page application routing. The listeners this listens for browser navigation events. Usually the user clicks excuse me is it usually this is usually just means the app is managing browsing application is normal SBA behavior when this becomes interesting. Okay, now we can't trace everything. Okay, let me just get back to reading. I still haven't even read this like oh my goodness there's just there's a lot.

[00:45:15]Okay, back into slideshow. Keep learning.

[00:45:18]So then we have dev tools event listeners message search sources for event.d data. So often times like right now the code is minified. So we're not even going to be able to find things like event. It's going to be like t dod data or like fd data. So a good thing to do would be like to extract the horror files and beautify the JS and then go from there and actually take a deeper look into the code which I plan on doing. I definitely will do it because I really do believe JavaScript is really good for a bug hunter to be reading that stuff. But so do not stop at found post message. The target is handler plus missing bad trust check plus dangerous behavior. Okay. Cheat sheet source and sync triage. This message is only interesting when it controls something dangerous.

[00:46:05]So source event data parser JSON object string sync DOM URL API impact XS leak action high value syncs we have things like inner HTML outer HTML I'm not going to read all that stuff but you can see it right here and then low value by itself console.log because it's just going to like print. So even if it does print, let's say you type like script alert one, if it's just in console lo print exactly that it's not actually going to execute at least pretty sure.

[00:46:33]But if it was inside like event data and then enter html then this is like HTML stuff and will it will execute JavaScript at least to my understanding that's how it would work. So post message use only for analytics pings strict event.org Origin exact trusted origin message data not used anywhere meaningful.

[00:46:54]Excuse me. Origin validation good versus trash. Bad. This is bad stuff. This is better.

[00:47:03]Both bypasses come from sloppy string matching. Okay. Better const allow new set if allowed has origin return exact origin are properly by parsed allow list. Anything else deserves pressure testing. Okay. But thing is like you can't test everything because you kind of want to I feel like you want to skip around not in the sense that you want to skip steps which like first you're like can't is post message possible and then you go in instead of investing like if let's say okay so let's say post message you learn post message is possible now you're trying to see like wait maybe you don't even want to start there maybe you want to start at the fifth step which is um where's what's fifth step the impact or the sync. I guess either one. Either sync or impact. And that's I guess that's where you want to start cuz if you if there's no impact or no sync, there's no point trying to see if there post me is even a thing. I believe because I feel you just be wasting your time, I think. Okay. So, all right. On the next one. So, exploit harness iframe plus pop-up delivery. Use simple lo local pages. Fancy tooling. uh is not the bottleneck. We just have stuff like this onload HTML script. Then pop-up, same thing. Just these are just codes for exploits. If framing is blocked, use pop-up. If pop-up is blocked, test handler behavior manually and document the limitation. And then bug class one, DOMXS from web messages.

[00:48:35]Cleanest bug class also the easiest to overclean. Okay. Window.eventlister.

[00:48:40]Yeah, we've talked about this quite a bit. and then like output html there's no origin check and then just e data html post message it's going to be like HTML and then you're just going to have the script and then it's just going to send so valid attacker message controls HTML/JS sync and execute and executes it in victim context weak alert only works on your own page or needs impossible setup stronger show account/ session impact not just an alert but class two data leaks through target origin wild card is only bad when system data can be reach can reach the wrong window. So target app sends token post message attacker window look for data like access token refresh token other tokens emails whatever and then proof of standard become the receiver. Okay, so this is kind of like a reverse you could say. Instead of the usual attacker will send message now it's like target app is sending tokens to attacker window. So become the receiver capture message data show why that data matters keep testing inside scope. Okay so I could go on like how does this work? Start googling that as well chat ging it but like this video is already super long. It's almost 50 minutes long like crazy. But I'll probably just another time. Probably not even on Oh crap. Probably not make that a video. But you get the point. Where where are we here?

[00:50:10]But class three message triggers state change. So this is where settings/count logage logic hunters can win. They have this stuff right here. If web hook update fetch, do your thing like that.

[00:50:24]And then oh gosh. Whoops. That's not good. Move that up. Can we move that up?

[00:50:29]I think so. Right. Just move that down.

[00:50:32]Okay.

[00:50:35]And high impact actions. Change email phone at web hook. Okay. So then your best reports will not say post message bug. They will say attacker can force a victim to change X.

[00:50:46]Okay. Yeah. And then like you just make the the exploit one pretty much. That's reportability filter. This slide saves you from spitting noise. Usually reportable DOMX success from untrusted messages sensitive token/ user data leak state changing action from attacker origin origin bypass real sync/action realistic victim delivery path usually not enough they use post message target origin um wild card with no sense of data missing origin check but no sync/conole only behavior requires victim to paste JS or disable browser protections that's when we're getting into like if you have to have them disable able browser protections. That's getting into like some solution engineering stuff. Okay.

[00:51:31]One page testing checklist. Use this before you open a report. Can attacker open iframe slash opens iframe/popup the receiver?

[00:51:43]Message. What exact JSON/string shape does handler expect? Trust is origin/source checked correctly?

[00:51:51]Validation. Is schema/type sanitized or blindly trusted? sync DOM sync URL sync API action or data leak impact what can victim lose slashchange slashexpose repro reproduce what's what's repro can you deliver a simple exploit page all right so now this is going to be my 14-day study guide plan to be honest I move pretty quickly finishes faster than that but you know not trying to brag but it bor kind of fast all right three Oh, 3 hours per day. Oh gosh. Maybe not.

[00:52:27]Okay. Output beats passive reading. So, days one to two basic basics plus labs.

[00:52:32]Read post message docs. Complete beginner web message DOM labs. Day days 3 to five source review. Add grip mode.

[00:52:40]Find 20 handlers across realjs. Classify them. Days 6 to 8 exploit building.

[00:52:45]Write iframes/ pop-up harnesses. Test origin bypasses and message shapes. Days 9 to 11 impact hunting. Focus on OOTH settings integrations. Check out dashboards days 12 to 14. Report reporting standard. Turn best findings into full report draft even if not submittable. Daily daily deliverable.

[00:53:06]One handler trace one exploit attempt.

[00:53:08]One note on why it is or not exploitable.

[00:53:12]Field notes template copies this into notion for every handler. You can just read that. I'm not going to. Just going to take a mental image. Okay. Ruthless standard. No sing equal no report. No victim path equal weak report. No impact keep testing. No clear repro equal triage pain. I think it's like you don't have the exploit server set up and so they would have to make themselves and that's a lot of work. Your first real hunting assignment do not start broad. Pick one app area and go deep.

[00:53:43]Pick target area O settings integrations. Capture hard extract beautifyJS. I have script for that. uh link in description to login.com so you can sign up for that and then find handlers classify 10 plus exploit top three pro or kill do not bounce between programs spend one full week on one targets client side messaging surface the win is not learning post message the win is building a repeatable handler phrasing workflow you can reuse on every bug bounty program okay so we have gone through that we did a lot of work going through ask questions to ch I have read this. I'm not reading this again.

[00:54:22]If you guys want to read this, it's right here. Yes, we hack. Maybe it'll be linked in the description. I'm not sure if I remember. Yeah. And then also, don't forget to check out this this video by client side01 post message bugs. Very good. I highly recommend it. So, that's going to be it for this video. I just wanted to start learning post message and I was like, I'm already going to be on my computer doing this. might as well record me actually learning something because I feel like it's been too long since I've done that. And if you like the video, like, subscribe. Also, if you want to sign up for my email list where I send best booking techniques from real writeups I read in my own hunting sessions, maybe like in the future when I get better at this, I'll send something about post message bucks. Then link will be in description. Uh, go to Logan Sax and add your email and I'll send it out to you. I send out an email every week. And that's going to be it.

[00:55:13]All out.