Tabnabbing

[00:00:00]
>> Steve Kinney: So one of the attacks, which is I have, I think, example code in here, but I don't think we're gonna talk about it too much because it's we're getting to the point of somewhat esoteric, but interesting is an attack called tabnabbing. And tabnabbing is like conceptually kind of super interesting, but also a little bit weird.

[00:00:21]
Where basically, like I said, it can be an iframe that you can send a post message to or it can be any window that you spawned. Right and this is why when we saw that Chrome tried to block that pop-up, it's effectively thinking about this. So what tabnabbing does is it effectively, if they can get the code into your site so there's got to be a lot of times some slightly nefarious code or if they are very clever with an iframe, they can make it look like your site for a second, which is basically they open a new tab with some other page.

[00:00:55]
It doesn't even really matter what it is, and then have like a window.setTimeout, to like swap it to like a very legit page. But that connection is still there they can still like, there's still a reference from the old page to the new page and it's basically trying to distract you for a second.

[00:01:12]
Again, this comes down to user manipulation, right? Distract you for a second and then swap the page where they still have a reference to their attacking codes, like in a setTimeout, or something like that, or setInterval, and doing stuff while you're navigating your page. The thing I sent you before about either the frame options, the CSP header or busting out of the frame will save you from those attacks as well, right?

[00:01:35]
So it's kind of a if you don't think you're gonna be framed. [LAUGH] It's not an intentional pun, I promise. Having some amount of settings in that case as well. If you choose to frame stuff so I have to do this thing in our app, and I don't actually know how I'm gonna do it yet.

[00:01:53]
But we have this idea that users want to be able to when they're looking at some of their workflows, I work around work on a workflow engines look at their workflows, they wanna have links that they embed in there, the link to their systems, right? So they can go see that ID, so on and so forth,right?

[00:02:09]
So theoretically, I have to load dynamic content into the page which does theoretically expose me to a wide range of these attacks, and I'm not sleeping well because of it. So our current plan is basically there's not only can you load an iframe, but you can load an iframe with this thing called sandbox set as a CSP header, which means nothing.

[00:02:27]
You can't even submit forms in there, right? And so my plan is basically take the content as markdown, strip out most things, allow no HTML, sanitize it one more time. And then basically load it as a completely sandbox iframe with only the links that will theoretically work. The other thing for the tabnabbing that will give you another layer of protection, and I'm just gonna write this in a scratch area over here is you had window top.

[00:02:59]
For a frame you have window dot opener for the child window that was opened that can talk back to the other one if all of your links
>> Steve Kinney: Have like there is no opener, right? The child window cannot communicate back to the window that's spawned it, right? So now, if someone does do this attack and opens up your site, or something along those lines, you've broken the link.

[00:03:29]
This strips the referrer tag so these are things you might consider we talked a lot about like stripping stuff out of HTML, but we might also consider adding stuff into our HTML.to break that kind of connection between frames and windows as well.