Ep. 124: Double-ClickJacking ၏ စာသားမှတ်တမ်းအပြည့်အစုံ

really, it doesn't even matter that much with the way this technique works. But what we're gonna do is kind of this sleight of hand that's gonna happen. So imagine that you've visited a website that is the attacker controlled website or you've received an email that is sending you to a link right our phishing emails that come in. It's gonna send you to the link to the malicious website. 00:03:51.110 --> 00:04:50.019 And on that malicious website, there's some action that you're going to take. Right? So you're gonna maybe click a button or whatever. Right? It's gonna open another window or another tab. Doesn't really matter. It can be done either way. It could be a new window over top of the current browser window, or it could just be another tab that opens up. And when it opens up that other tab, you're not gonna really notice it because it'll it's gonna cover the current window that you're looking at or move you to the new tab. Right? So the focus is gonna change to that. But when you do that, that original page that you were on is going to change, and it's gonna get redirected to what the malicious page wants to actually get you to take action on. So maybe it's some sort of, API or OAuth authorization form that is some page that has basically a single click execution. 00:04:50.879 --> 00:05:45.879 So if you think about OAuth authorizations, you'll get that little screen that pops up. Hey. Do you want to allow this application to access this type of thing? And in this case, there'd be a single button, yes, authorize. Or maybe there's a cancel button on there as well. But an authorized button. One click, it authorizes it. We're good to go. So now imagine you've clicked on the initial page. A new page pops up over. And behind the scenes, this new OAuth page as an example now slides in to where that original page was, but you haven't noticed this yet because you're busy looking at the other page. You're on the other page, and it's gonna give you some sort of authentication request or CAPTCHA verification that says, hey. I need you to double click to prove that you're a human. 00:05:46.418 --> 00:05:50.120 Show me that you're not a bot, so double click on this button. 00:05:51.185 --> 00:06:02.485 And when you do that and now keep in mind, that button is gonna be placed in the same exact spot as the button on the page that just got loaded behind it. 00:06:03.199 --> 00:06:10.500 So that when that window closes, your mouse is now directly over the action that wants to be taken. 00:06:10.879 --> 00:06:17.475 So the authorization of the OAuth or whatever piece needs to be done here. 00:06:18.894 --> 00:07:06.939 You go in, you start the double click on the mouse down on this Melissa's page that popped up is going to now close the window of that page. So that captcha screen with the double click me is gonna disappear mid as you're doing the double click and so by the time you get to that second click you're now back on that original window or tab that now has that OAuth authorization, and you're gonna click the allow button on that page. So it really is kind of that slight of hand. I'm gonna present you something that's unrelated to anything that you might think you're doing. It's just some benign content. 00:07:07.560 --> 00:09:33.000 It's going to open a new window over top or a new tab right next to it. But you're not gonna realize that when it does that, it's going to change the content of that initial page to some action against some site that you have control over. And then when you take the double click action on the new page that popped up on mouse down, it's going to close that new page and you end up clicking the button on the page below it taking that action. And again this could be an OAuth authorization some sort of API authorization anything that's a single click operation that can be loaded basically kind of with a query string. Right? Because we lose any capability or the malicious user loses any capability to manipulate the pages once they make the request to that page because they've given up that control. We're not in a frame or anything like that. We've redirected our page to the actual site, so we lose all control after that. So that's kind of the high level of what's going on with double click jacking. It's this time gap take advantage of the speed so that we can swap out something right before you go to click it. I always think of it as that little bit of a slow motion, I can't stop it, but I see it happening type of thing. Because if you're a slow clicker, you might actually see the page that is swapped out. And you click that first one, and all of a sudden, you see the page disappear, but you're already in motion to clicking the second click. And it's like, no. And then sure enough, you click it. The authorization is done, and we're passed. So this is really kind of an interesting technique that we see coming out of this and there's really not a lot of good remediations for it. Like I said, the clickjacking remediations don't really help in this situation because it just doesn't work the same. With clickjacking, I can not allow cookies to be enabled if I'm being loaded into a frame of some sort. But here, it's literally just a legitimate request to redirect the page to the victim site. 00:09:34.019 --> 00:10:53.200 So there's nothing there for the browser to really know, oh, I shouldn't load this because it just looks like a regular page load. There's no frame. There's no anything else. So that makes it difficult for some of that other stuff to detect this. Even if you were thinking about content security policy or other things that exist out there, it really is difficult because it's just a normal the page loading in a browser window. There's nothing special there to really detect that. So what can we do to help resolve this? Well, as Paulos mentions, in some of his stuff, he's got an example script, and I'll share a link out to his site, a JavaScript side script that

can potentially help. And, basically, the idea behind it is if you've got a page that has a sensitive one click function on it, you could probably put this on any page, to be honest. If you've got a page like that, then you have this JavaScript you can load in and basically disables those key buttons on initial page load and then reenables them when it shows that a human is interacting with the page. So, for example, if I just go load the page and I don't do nothing, I don't touch anything, I don't move the mouse, anything like that, you'd see that the button would be disabled. 00:10:53.820 --> 00:12:20.799 And it wouldn't be until I actually do a mouse move or something that a human would do that it would then enable the buttons on the screen. In the case of this double click jacking, because you're not moving the mouse or anything and it's happening fast, the double click, if you were to load the page behind the scene, and then in which case, the button would be disabled. And then you go through, do the double click on the other page. When the other page disappears and you do the initial click on that button, it will be disabled. And so it won't work. Now maybe that'll enable the page or enable the button for you, but you're already done with your clicks. So it's okay. You've had enough time to see that, oh, wait. This is not the page I should be clicking on, and it stops it. Now that's a I mean, a a good idea to be able to do that. I tried actually putting this together. I struggled a little bit trying to get it to work. It was really weird. I had some different outcomes depending on where I was running my code. So I had a very simple website that I was putting together and running it locally. It was working okay. Like, it was blocking it. I go post it out on my web server, and then all of a sudden, it wasn't doing it. And for some reason, as soon as the page became active, it would enable my buttons. 00:12:21.485 --> 00:12:24.865 So there was some weirdness with it. I actually made a few modifications. 00:12:25.725 --> 00:13:20.794 I put in almost like a little timer so that way it would stop it. Because what was happening for me was that as soon as the new that window that popped up closed and the focus came back to my original page, it would run the mouse click or mouse move, and it would enable my button. So it was still allowing it to happen. So I ended up modifying a little bit, and I put a time out on there of, like, one or two seconds to be able to slow that down. So that way when my initial page became focus again, it would still take two seconds for that button to enable, and that was enough to be pretty consistent on keeping it working. And the whole goal with the JavaScript behind here is that a regular user wouldn't notice this issue Because even if a regular user loaded the page, it's they're gonna move the mouse around. 00:13:20.794 --> 00:13:38.769 They're gonna do something before they get to the point where they're gonna click a button. So even if your page starts disabled in that sense, you're gonna move the mouse to get to something on the page, and that is gonna enable everything. And you really wouldn't notice. It's not gonna cause any friction for a regular user using the page. 00:13:39.389 --> 00:14:50.014 So you could take a look at that and see again, he's got some code on there on his site that shows what he was doing and see how that works. I I I struggled a little bit with it, and I'm not sure again, I had two different pages and one worked, one didn't. And they seem to be kind of doing the exact same thing. So I'm not sure why there were some issues there, but that probably is my user error. But that's one way that we can look to help reduce the risk of this is by putting some sort of client side script on there to disable buttons by default and then enable them when we detect that an actual user is doing this. There's really not a lot of other things that we can do at this point, really, honestly, because it's just a regular page load. We can't tell that this was loaded this way versus another way. I mean, maybe at a deeper level at the browser, we could do that. And there is the recommendation, you know, of maybe, like, having some sort of header that we could set kinda like CSP or something else that maybe could detect, like, rapid changes in the applications during clicking. 00:14:51.208 --> 00:15:11.365 I don't know really what that would look like, but I think it would be interesting to find out. I'd love to hear more about what that would look like to be able to set some sort of head or have some global way to be able to protect against this. Because, obviously, we really wanna try to find things that protect at the base foundational level and not something that we have to go do on every single page. 00:15:12.784 --> 00:16:49.610 So is this something that we need to stop everything we're doing and and find all the areas and and fix every page on our website? I don't know. I think most of the pages that we have probably do not work as simple as this, that a page just gets loaded through a simple get request that's gonna have everything needed to be able to change it without being able to change any of the data on the page. I think that's why we call out things like the OAuth authorization type of request because those are kind of simple. They're, you know, a single button click. So I think it's really for the organization and for developers out there and product owners thinking about where do you have that type of interaction, at least at this point, not that it would hurt to have maybe a global JavaScript that can disable everything on all pages. But if you're looking specifically, going through and trying to find out what are those sensitive pages that could load in this manner and be able to execute via just a single click to be able to pick those out. That's kind of where we come in with our threat modeling and those different areas to

identify the highest risk spots of our applications to be able to see this and be able to catch it and add this protection. So I would start there in looking to see where you have that. I'm curious to see this year with a new finding like this coming out. Is this going to be the new hotness that we see on all our pen test reports this year? 00:16:49.828 --> 00:17:12.365 Anybody that has their annual web app pen test come around, is this gonna be the new low hanging fruit that all the pen test reports are gonna contain? I have a sneaky suspicion we'll probably see quite a bit of it. The thing I would just make caution of is that if you're the one on the receiving end of these reports, think about where this is actually happening. 00:17:12.720 --> 00:17:45.519 Look at it and see. Is this a high concern for me in this area or this really can't be caused? You know, what is the real risk around this happening? Not saying don't look to fix it because we wanna fill these holes, but we may get a lot of these where it's just like every single page. Oh, your buttons don't disable on initial load. This is potential for double click jacking. Let's make sure that it's actually gonna be a risk here. And it's not, oh, well, that page yeah. Sure. We could call it, but you're there's no anybody would know this. 00:17:45.519 --> 00:18:14.700 You're not gonna be able to get to this. The risk is pretty low. This isn't critical versus a page where you could authorize an OAuth client or something else, that would be super critical, and we wanna resolve that ASAP. So just be smart with how you triage the findings when they come in, just like we do with every other finding that comes in. We wanna make sure that we understand the risk. We wanna understand, can it be exploited? What happens if it is exploited? 00:18:15.720 --> 00:19:47.505 And let's look to see how we can resolve this. These are sometimes a little bit trickier when there's not a true straightforward resolution. As I said, I mean, I tried the JavaScript, and it got me, like, most the way I had to tweak it a little bit. Maybe others will have to tweak it a little bit too. I guess to that point, don't just grab something and just assume it's gonna work. Do the testing on it. Validate that it's working in your test cases. And if you do need to make a little bit of modification to get it functioning in your area, you know, to make those modifications. We can do that. It's great that we have this initial script to get it started, and, hopefully, it works straight out of the box for you. But if not, it's the best starting point. I don't know as I would have had a good starting point to figure out how to go in and stop that from a JavaScript perspective. So you really have to appreciate the information that's shared when something like this comes out. I think Paul has did a great job really outlining what the issue was and also, you know, some ideas of, hey. How could we go ahead and solve this? And in the security world, especially when you're finding things like that, the ability to be able to analyze and say, hey. Here's how we could go about resolving this, not just coming at us with a problem, but, hey. Here's a problem, and here's a potential solution, is invaluable when we talk about security and the stuff that we get out of there. So that's kind of my initial take on double click jacking. 00:19:47.565 --> 00:20:00.779 It it's pretty interesting. I thought it was interesting when it first came out. I know it came out a little bit more than a month ago, but I wanna take a little bit of time. I don't wanna be out there with everybody else dropping the same information at the same time. Let's spread it out a little bit. 00:20:01.240 --> 00:20:33.829 And, if you have any thoughts on it, any questions, any ideas about how that could happen, feel free to share it. This is what the community is all about. So, yeah, an interesting new technique. We're not seeing as many of these these days. So, it is kind of a little bit fresh to see something new popping out for us to look at and something to talk about and something that's interesting and challenges a lot of things that we've been doing. So I appreciate everybody for listening, and I'll catch you on the next episode. 00:20:39.890 --> 00:20:55.259 You have been listening to the DevelopSec podcast with James Jardine. To find out more about how we can help you with application security, follow us on Twitter at DevelopSec, or check out our website at www.developsec.com.