Web Security, v2

postMessage

Steve Kinney

Steve Kinney

Temporal
Web Security, v2

Check out a free preview of the full Web Security, v2 course

The "postMessage" Lesson is part of the full, Web Security, v2 course featured in this preview video. Here's what you'd learn in this lesson:

Steve discusses how an iframe can be injected with malicious code and how the code blindly accepts messages without checking their origin. He explains how to fix this vulnerability by whitelisting trusted domains and ensuring that messages are only accepted from those domains.

Preview
Close
Get $100 Off
Get $100 Off!

Transcript from the "postMessage" Lesson

[00:00:00]
>> Steve Kinney: There are other things that we can play around with, let's talk about kind of another interesting one. Again, this falls under the social engineering piece. And then we'll kind of pull out to the if you need it, here are some other options for you and just some other high-level techniques that we can kind of take a look at that are kind of more like bonus labs.

[00:00:23]
And areas to explore but I think worth calling out because they're important. We started with things that you need to think about every day and as we pull out, we're talking about weird attack vectors. And then finally, we'll talk about things you probably set up once in the very beginning.

[00:00:39]
Cuz if you don't set them up in the very beginning, you will be sad and need to do some maintenance later. So, well, that's kinda the way that we'll kinda bubble this up. But we have,
>> Steve Kinney: Actually, I think, yeah, yeah, we're gonna check out this one called support-chat, real quick, which is another two.

[00:01:11]
>> Steve Kinney: So support chat has some interesting features to it, that's ahead, 4008 and, yeah. Yeah, so if we look at just, it's actually interesting doing this, not in an incognito window, is going to show you the attack, because extensions are weird and they play around. But I think instead of moving into an incognito window, I'm going to choose to show you the slightly nefarious version.

[00:01:41]
Let's do that another tab too, which is local host I think.
>> Steve Kinney: These injected object objects are actually one of my browser extensions, sending a post message in to the frame, as well. And so this is basically something from the outside world is sending messages in. This is super easy to fix, cuz it's on both ends, but we need to kind of take a look at it.

[00:02:17]
So, we look at the code in this case. We've got,
>> Steve Kinney: It's just an iframe that if we look at it by itself, it's just a chat, it's great. And even but fully loaded, it had stuff being injected in there as well. But And if you look in the console, it's from, I think, my one password extension or whatever, this is outside code in this case.

[00:02:49]
So we've got that, and then let's see, this is in client.
>> Steve Kinney: So effectively, in this case, we are saying, hey, we've got this window event listener for message, and if a message comes in, add it in there, right. This is an easy fix, which is that right now it is just accepting messages that come in, right?

[00:03:15]
Which could be anything. And so, if I went to that malicious one again, now they've iframed it in almost in a compelling iframe, right? I put a shadow on it, so it looks totally real. We could say support and,
>> Steve Kinney: I don't like you, right? And it sends the message into the window, right?

[00:03:45]
And this might be a situation where we have a pop-up or an iframe just in the chat from a segment integration or something like that. And the message comes in, and we just blindly take it and apply it to the DOM, right? So, the receiving end this is easily fixed by just checking and kind of the way we felt about just allow listening what you will stand for.

[00:04:14]
So we can say, yeah, whatever the trusted domain, I think in this case, it's like 4108 and the other one is coming from 418. And so now, if we try to do that, and we say,
>> Steve Kinney: You can see, nothing happens, right? Cuz all these events that come in have an origin, right?

[00:04:42]
And if you don't check the origin on the way in from any of these messages, like anyone can wrap you in an iframe and trigger that. Including what I did in a non incognito window, like extensions, right? That will pass it on in. There is another side, which is, what if the opposite is true?

[00:05:01]
What if you don't want someone to put an iframe in you and receive messages that you're sending, right? You're worried about what if they swap out a very legit iframe for something nefarious and now they're receiving data and collecting it? Cuz then they control the code, it's almost the reverse of a CSRF, where you're sending messages to what you think is your iframe, and they're collecting them all, right?

[00:05:25]
Again, incredibly easy to do in this case, but problematic if you don't, right? Which is to give it an origin that it is allowed to send messages to. So in this case, the frame has to be on that allow list. And so we could say, in this case, that should be the 4108.

[00:05:44]
And now it will send them in, they won't go anywhere because they're blocking it here. But if I set this to a very different one, let's just say, like, 5555,
>> Steve Kinney: Right, and we try to send something.
>> Steve Kinney: It will block it, so again, both sides can protect each other from visibility and messages can actually work with pop up windows like theoretically, if it spawns it into a new tab.

[00:06:17]
There is effectively a link between those two windows.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now