February 24, 2025 • 21 mins
In this episode, I go over what Double-ClickJacking is and what you can potentially do about it to reduce the risk to your applications.
Will this be the new finding on everyone's pen tests this year?
Paulos Yibelo first described Double-ClickJacking and you can read more from him at his post referenced below.
References:
Paulos Yibelo Blog: https://www.paulosyibelo.com/2024/12/doubleclickjacking-what.html
For more info go to https://www.developsec.com or follow us on X (@developsec).
The DevelopSec podcast is brought to you by Jardine Software Inc.
Mark as Played
Transcript
Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
(00:04):
In this episode, James talks about double click jacking and what youneed to know to protect your applications.
Tackling the challenge to integrate security into the development process?
Looking for insights, answers, and practical solutions to avoid gettingoverwhelmed? Welcome to the DevelopSec podcast, where our
(00:30):
focus is your success in securing and improving developmentprocesses. And here is your
host, James Jardine. Hi, everyone.
Welcome to this episode of the DevelopSec podcast. I amyour host, James Jardine. And today, I want to talk about
double click jacking. It's kind of a newerattack technique that came out a little over a
(00:55):
month ago. It came out the January,actually coined by Paulos Yebello. Hopefully, I'm
kinda saying that correctly. I'll put a link to the post that heput up talking about this new attack vector, and I wanna
take a little bit of time to go through some of this to explain itto some people. It's not to be confused with
(01:18):
clickjacking, which, actually, I went back to see ifI had a post about clickjacking, and, unfortunately, I
did not. So I'll look to record a podcast about clickjackingas well just so that way we can reference that so you can see the
difference. But just to start off, if you've heard ofclickjacking before, or maybe you haven't,
(01:40):
basically, I'll give you the high level. Clickjacking is really morearound using frames, iframes
that are invisible and layering them over an existingwebsite so that when you go to click a
link on the page that you can visually see,what you don't realize is you're actually clicking an invisible button over
(02:02):
top of that. That's going to function.
And then you're actually it's jacking the click that youdid that you thought was going to one button was actually
going to another button on another site. So that's kind of the highlevel of clickjacking. It obviously gets much more deeper than that. I'll
do a a longer episode talking about that in the future,but that's kind of where we go with that. And with clickjacking, we have some
(02:30):
different remediations and controls that we canput in place to help protect against that. And
when we start talking about double click jacking, we'll see thatthose controls really don't transfer because double click
jacking really happens in a whole different way than what we sawwith click jacking. So with double click
(02:52):
jacking, the whole idea behind this is thatwe're taking advantage of the time gap
between when a user first starts to click. Sothat mouse down on the first click of a
button or a link or anything like that. Thetime between that first click happens and the
(03:14):
last mouse up of the double click that occursthere, Right? There's a little bit of a time gap. And for everybody, it's a
little bit different. Some people double click really fast. Some people double clickreally slow. And 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 ofhand that's gonna happen. So imagine that
(03:36):
you've visited a website that is theattacker controlled website or you've received an email
that is sending you to a link right our phishing emails that come in. It'sgonna send you to the link to the malicious website.
And on that malicious website, there's some action thatyou're going to take. Right? So you're gonna maybe click a button or
(03:58):
whatever. Right? It's gonna open another window oranother 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 beanother tab that opens up. And when
it opens up that other tab, you're not gonna reallynotice it because it'll it's gonna cover the current window that you're
(04:20):
looking at or move you to the new tab. Right? So the focus is gonnachange 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 somesort of, API or OAuth
(04:43):
authorization form that is somepage that has basically a single click execution.
So if you think about OAuth authorizations, you'llget that little screen that pops up. Hey. Do you want to allow this application
to access this type of thing? And in thiscase, there'd be a single button, yes, authorize. Or maybe there's a
(05:05):
cancel button on there as well. But an authorized button. Oneclick, it authorizes it. We're good to go. So now
imagine you've clicked on the initial page. A new pagepops up over. And behind the scenes,
this new OAuth page as anexample now slides in to where that original
(05:27):
page was, but you haven't noticed this yet because you're busy looking at the otherpage. You're on the other page, and it's gonna give you some
sort of authentication request orCAPTCHA verification that says, hey. I need you to
double click to prove that you're a human.
Show me that you're not a bot, so double click on this button.
(05:51):
And when you do that and now keep in mind, thatbutton is gonna be placed in the same exact spot as the
button on the page that just got loaded behind it.
So that when that window closes, your mouse is nowdirectly over the action that wants to be taken.
So the authorization of the OAuth orwhatever piece needs to be done here.
(06:18):
You go in, you start the double click on the mouse downon this Melissa's page that popped up is
going to now close the window of thatpage. So that captcha screen with the double
click me is gonna disappearmid as you're doing the double click
(06:41):
and so by the time you get to that second clickyou're now back on that original
window or tab that now has that OAuthauthorization, and you're gonna click the allow
button on that page. So it really is kind of that slightof hand. I'm gonna present you something that's unrelated to anything
(07:03):
that you might think you're doing. It's just some benign content.
It's going to open a new window over top or a newtab 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 tosome action against some site that you have control over. And
then when you take the double click action on the new page thatpopped up on mouse down, it's going to close that new
(07:30):
page and you end up clicking the button on thepage below it taking that action. And again
this could be an OAuth authorization some sort of API authorizationanything that's a single click operation
that can be loaded basically kind of with a query string. Right? Becausewe lose any capability or the malicious
(07:54):
user loses any capability to manipulate the pagesonce 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'veredirected our page to the actual site, so we
lose all control after that. So that's kindof the high level of what's going on with double click jacking. It's
(08:16):
this time gap take advantage of thespeed so that we can swap out
something right before you go to click it. I always think of it asthat little bit of a slow
motion, I can't stop it, but Isee it happening type of thing. Because if you're a slow
(08:38):
clicker, you might actually see the page thatis 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 thesecond click. And it's like, no. And then
sure enough, you click it. The authorization is done, and we'repassed. So this is really kind of an interesting
(08:59):
technique that we see coming out of this andthere's really not a lot of good
remediations for it. Like I said, the clickjackingremediations don't really help in this situation
because it just doesn't work the same. With clickjacking, I cannot allow cookies to be enabled if I'm being loaded into
(09:22):
a frame of some sort. But here, it'sliterally just a legitimate request to redirect the
page to the victim site.
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 forsome of that other stuff to detect this. Even if you were thinking about
(09:49):
content security policy or other things that exist outthere, it really is difficult because it's just
a normal the page loading in a browser window. There's nothingspecial 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
(10:12):
out to his site, a JavaScript side scriptthat 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, youcould 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 andbasically disables those key buttons on initial page
(10:35):
load and then reenables them whenit shows that a human is interacting with the
page. So, for example, if I just go load the pageand 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.
And it wouldn't be until I actually do a mouse move or something that ahuman would do that it would then enable the buttons on the
(11:01):
screen. In the case of this doubleclick jacking, because you're not moving the mouse or anything and it's happening
fast, the double click, if you were to load thepage behind the scene, and then in
which case, the button would be disabled. And then you gothrough, do the double click on the other page. When the other page
(11:22):
disappears and you do the initial click on thatbutton, it will be disabled. And so it won't
work. Now maybe that'll enable the page or enable the buttonfor 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 pageI should be clicking on, and it stops it. Now that's
(11:43):
a I mean, a a good idea to be able to do that. I triedactually putting this together. I struggled a little bit
trying to get it to work. It was really weird. I had somedifferent outcomes depending on where I was running my
code. So I had a very simple website that I wasputting together and running it locally. It was working
(12:05):
okay. Like, it was blocking it. I go post it out on my webserver, and then all of a sudden, it wasn't doing it. And for some
reason, as soon as the pagebecame active, it would enable my buttons.
So there was some weirdness with it. I actually made a few modifications.
I put in almost like a little timer so that way it would stopit. Because what was happening for me was that as soon as
(12:33):
the new that window that popped up closed and thefocus came back to my original page, it would
run the mouse click or mouse move, and it wouldenable 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
(12:54):
down. So that way when my initial page became focusagain, it would still take two seconds for
that button to enable, and that was enough to be pretty consistent onkeeping it working. And the whole goal with the
JavaScript behind here is that a regular user wouldn't notice thisissue Because even if a regular user loaded the
(13:17):
page, it's they're gonna move the mouse around.
They're gonna do something before they get to the point where they're gonna click abutton. So even if your page starts disabled
in that sense, you're gonna move the mouse to get to something on thepage, 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.
(13:39):
So you could take a look at that and see again, he's got somecode on there on his site that shows what he was doing and
see how that works. I I I struggled alittle 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 theexact same thing. So I'm not sure why there were some issues there, but
(14:01):
that probably is my user error. But that's one way that we can lookto help reduce the risk of this
is by putting some sort of client side script on there to disable buttons bydefault and then enable them when we detect that an actual user is doing
this. There's really not a lot of otherthings that we can do at this point, really, honestly,
(14:23):
because it's just a regular page load. We can't tell thatthis was loaded this way versus another way. I mean, maybe at a deeper
level at the browser, we could do that. And there is therecommendation, you know, of maybe, like, having some sort of header
that we could set kinda like CSP or something else that maybecould detect, like, rapid changes
(14:46):
in the applications during clicking.
I don't know really what that would look like, but I think it would beinteresting 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 wayto be able to protect against this. Because, obviously, we really wanna try to
find things that protect at the base foundational leveland not something that we have to go do on every single page.
(15:12):
So is this something that we need to stop everything we'redoing and and find all the areas and and fix every page on our
website? I don't know. I thinkmost of the pages that we have probably do not
work as simple as this, that a page just getsloaded through a simple get
(15:35):
request that's gonna have everything needed to be able to change it without being ableto change any of the data on the page. I think that's why we call
out things like the OAuth authorization typeof request because those are kind of simple. They're,
you know, a single button click. So I think it'sreally for the organization and for developers out
(15:57):
there and product owners thinking about where do you have that type ofinteraction, at least at this point, not that it would hurt to
have maybe a global JavaScript that can disableeverything on all pages. But if you're looking specifically,
going through and trying to find out what are those sensitive pages thatcould load in this manner and be able to execute
(16:19):
via just a single click to be able to pick those out. That's kind ofwhere we come in with our threat modeling and those different areas to
identify the highest risk spots of our applicationsto be able to see this and be able to catch it and
add this protection. So I would start there in looking tosee where you have that. I'm curious to see this year
(16:42):
with a new finding like this coming out. Is this going tobe the new hotness that we see on all our pen test reports this year?
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'llprobably see quite a bit of it. The thing I would just
(17:04):
make caution of is that if you're the one on the receiving end of thesereports, think about where this is actually happening.
Look at it and see. Is this a high concern for me in this areaor this really can't be caused? You know, what is the
real risk around this happening? Not sayingdon't look to fix it because we wanna fill these holes, but we
(17:27):
may get a lot of these where it's just like every single page. Oh, yourbuttons don't disable on initial load. This is potential
for double click jacking. Let's make sure that it's actuallygonna 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.
You're not gonna be able to get to this. The risk is pretty low. Thisisn't critical versus a page where you could authorize an
(17:53):
OAuth client or something else, that would besuper critical, and we wanna resolve that ASAP. So
just be smart with how you triage the findings when theycome 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 beexploited? What happens if it is exploited?
(18:15):
And let's look to see how we can resolve this. These aresometimes 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 bittoo. I guess to that point, don't just grab something and
(18:36):
just assume it's gonna work. Do the testing on it. Validate that it's working inyour test cases. And if you do need to make a little bit of modification
to get it functioning in your area, you know, to makethose modifications. We can do that. It's great
that we have this initial script to get itstarted, and, hopefully, it works straight out of the box for you. But
(18:59):
if not, it's the best starting point. I don't know as I wouldhave had a good starting point to figure out how to go in and stop
that from a JavaScript perspective. So you really have toappreciate the information that's shared when something like this comes
out. I think Paul has did a great job really outlining what the issuewas and also, you know, some ideas of, hey. How could we go
(19:21):
ahead and solve this? And in the security world, especiallywhen 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 justcoming at us with a problem, but, hey. Here's a problem, and here's a
potential solution, is invaluable when we talk aboutsecurity and the stuff that we get out of there. So that's kind of
(19:43):
my initial take on double click jacking.
It it's pretty interesting. I thought it was interesting when it first came out. Iknow 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 elsedropping the same information at the same time. Let's spread it out a little bit.
And, if you have any thoughts on it, any questions, anyideas about how that could happen, feel free to share it. This
(20:08):
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 ofa little bit fresh to see something new popping out for us to look
at and something to talk about and something that'sinteresting and challenges a lot of things that we've been doing. So I appreciate
(20:30):
everybody for listening, and I'll catch you on the next episode.
You have been listening to the DevelopSec podcast with JamesJardine. 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
(20:52):
www.developsec.com.
In this episode, James talks about double click jacking and what youneed to know to protect your applications.
Tackling the challenge to integrate security into the development process?
Looking for insights, answers, and practical solutions to avoid gettingoverwhelmed? Welcome to the DevelopSec podcast, where our
(00:30):
focus is your success in securing and improving developmentprocesses. And here is your
host, James Jardine. Hi, everyone.
Welcome to this episode of the DevelopSec podcast. I amyour host, James Jardine. And today, I want to talk about
double click jacking. It's kind of a newerattack technique that came out a little over a
(00:55):
month ago. It came out the January,actually coined by Paulos Yebello. Hopefully, I'm
kinda saying that correctly. I'll put a link to the post that heput up talking about this new attack vector, and I wanna
take a little bit of time to go through some of this to explain itto some people. It's not to be confused with
(01:18):
clickjacking, which, actually, I went back to see ifI had a post about clickjacking, and, unfortunately, I
did not. So I'll look to record a podcast about clickjackingas well just so that way we can reference that so you can see the
difference. But just to start off, if you've heard ofclickjacking before, or maybe you haven't,
(01:40):
basically, I'll give you the high level. Clickjacking is really morearound using frames, iframes
that are invisible and layering them over an existingwebsite so that when you go to click a
link on the page that you can visually see,what you don't realize is you're actually clicking an invisible button over
(02:02):
top of that. That's going to function.
And then you're actually it's jacking the click that youdid that you thought was going to one button was actually
going to another button on another site. So that's kind of the highlevel of clickjacking. It obviously gets much more deeper than that. I'll
do a a longer episode talking about that in the future,but that's kind of where we go with that. And with clickjacking, we have some
(02:30):
different remediations and controls that we canput in place to help protect against that. And
when we start talking about double click jacking, we'll see thatthose controls really don't transfer because double click
jacking really happens in a whole different way than what we sawwith click jacking. So with double click
(02:52):
jacking, the whole idea behind this is thatwe're taking advantage of the time gap
between when a user first starts to click. Sothat mouse down on the first click of a
button or a link or anything like that. Thetime between that first click happens and the
(03:14):
last mouse up of the double click that occursthere, Right? There's a little bit of a time gap. And for everybody, it's a
little bit different. Some people double click really fast. Some people double clickreally slow. And 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 ofhand that's gonna happen. So imagine that
(03:36):
you've visited a website that is theattacker controlled website or you've received an email
that is sending you to a link right our phishing emails that come in. It'sgonna send you to the link to the malicious website.
And on that malicious website, there's some action thatyou're going to take. Right? So you're gonna maybe click a button or
(03:58):
whatever. Right? It's gonna open another window oranother 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 beanother tab that opens up. And when
it opens up that other tab, you're not gonna reallynotice it because it'll it's gonna cover the current window that you're
(04:20):
looking at or move you to the new tab. Right? So the focus is gonnachange 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 somesort of, API or OAuth
(04:43):
authorization form that is somepage that has basically a single click execution.
So if you think about OAuth authorizations, you'llget that little screen that pops up. Hey. Do you want to allow this application
to access this type of thing? And in thiscase, there'd be a single button, yes, authorize. Or maybe there's a
(05:05):
cancel button on there as well. But an authorized button. Oneclick, it authorizes it. We're good to go. So now
imagine you've clicked on the initial page. A new pagepops up over. And behind the scenes,
this new OAuth page as anexample now slides in to where that original
(05:27):
page was, but you haven't noticed this yet because you're busy looking at the otherpage. You're on the other page, and it's gonna give you some
sort of authentication request orCAPTCHA verification that says, hey. I need you to
double click to prove that you're a human.
Show me that you're not a bot, so double click on this button.
(05:51):
And when you do that and now keep in mind, thatbutton is gonna be placed in the same exact spot as the
button on the page that just got loaded behind it.
So that when that window closes, your mouse is nowdirectly over the action that wants to be taken.
So the authorization of the OAuth orwhatever piece needs to be done here.
(06:18):
You go in, you start the double click on the mouse downon this Melissa's page that popped up is
going to now close the window of thatpage. So that captcha screen with the double
click me is gonna disappearmid as you're doing the double click
(06:41):
and so by the time you get to that second clickyou're now back on that original
window or tab that now has that OAuthauthorization, and you're gonna click the allow
button on that page. So it really is kind of that slightof hand. I'm gonna present you something that's unrelated to anything
(07:03):
that you might think you're doing. It's just some benign content.
It's going to open a new window over top or a newtab 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 tosome action against some site that you have control over. And
then when you take the double click action on the new page thatpopped up on mouse down, it's going to close that new
(07:30):
page and you end up clicking the button on thepage below it taking that action. And again
this could be an OAuth authorization some sort of API authorizationanything that's a single click operation
that can be loaded basically kind of with a query string. Right? Becausewe lose any capability or the malicious
(07:54):
user loses any capability to manipulate the pagesonce 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'veredirected our page to the actual site, so we
lose all control after that. So that's kindof the high level of what's going on with double click jacking. It's
(08:16):
this time gap take advantage of thespeed so that we can swap out
something right before you go to click it. I always think of it asthat little bit of a slow
motion, I can't stop it, but Isee it happening type of thing. Because if you're a slow
(08:38):
clicker, you might actually see the page thatis 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 thesecond click. And it's like, no. And then
sure enough, you click it. The authorization is done, and we'repassed. So this is really kind of an interesting
(08:59):
technique that we see coming out of this andthere's really not a lot of good
remediations for it. Like I said, the clickjackingremediations don't really help in this situation
because it just doesn't work the same. With clickjacking, I cannot allow cookies to be enabled if I'm being loaded into
(09:22):
a frame of some sort. But here, it'sliterally just a legitimate request to redirect the
page to the victim site.
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 forsome of that other stuff to detect this. Even if you were thinking about
(09:49):
content security policy or other things that exist outthere, it really is difficult because it's just
a normal the page loading in a browser window. There's nothingspecial 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
(10:12):
out to his site, a JavaScript side scriptthat 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, youcould 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 andbasically disables those key buttons on initial page
(10:35):
load and then reenables them whenit shows that a human is interacting with the
page. So, for example, if I just go load the pageand 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.
And it wouldn't be until I actually do a mouse move or something that ahuman would do that it would then enable the buttons on the
(11:01):
screen. In the case of this doubleclick jacking, because you're not moving the mouse or anything and it's happening
fast, the double click, if you were to load thepage behind the scene, and then in
which case, the button would be disabled. And then you gothrough, do the double click on the other page. When the other page
(11:22):
disappears and you do the initial click on thatbutton, it will be disabled. And so it won't
work. Now maybe that'll enable the page or enable the buttonfor 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 pageI should be clicking on, and it stops it. Now that's
(11:43):
a I mean, a a good idea to be able to do that. I triedactually putting this together. I struggled a little bit
trying to get it to work. It was really weird. I had somedifferent outcomes depending on where I was running my
code. So I had a very simple website that I wasputting together and running it locally. It was working
(12:05):
okay. Like, it was blocking it. I go post it out on my webserver, and then all of a sudden, it wasn't doing it. And for some
reason, as soon as the pagebecame active, it would enable my buttons.
So there was some weirdness with it. I actually made a few modifications.
I put in almost like a little timer so that way it would stopit. Because what was happening for me was that as soon as
(12:33):
the new that window that popped up closed and thefocus came back to my original page, it would
run the mouse click or mouse move, and it wouldenable 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
(12:54):
down. So that way when my initial page became focusagain, it would still take two seconds for
that button to enable, and that was enough to be pretty consistent onkeeping it working. And the whole goal with the
JavaScript behind here is that a regular user wouldn't notice thisissue Because even if a regular user loaded the
(13:17):
page, it's they're gonna move the mouse around.
They're gonna do something before they get to the point where they're gonna click abutton. So even if your page starts disabled
in that sense, you're gonna move the mouse to get to something on thepage, 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.
(13:39):
So you could take a look at that and see again, he's got somecode on there on his site that shows what he was doing and
see how that works. I I I struggled alittle 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 theexact same thing. So I'm not sure why there were some issues there, but
(14:01):
that probably is my user error. But that's one way that we can lookto help reduce the risk of this
is by putting some sort of client side script on there to disable buttons bydefault and then enable them when we detect that an actual user is doing
this. There's really not a lot of otherthings that we can do at this point, really, honestly,
(14:23):
because it's just a regular page load. We can't tell thatthis was loaded this way versus another way. I mean, maybe at a deeper
level at the browser, we could do that. And there is therecommendation, you know, of maybe, like, having some sort of header
that we could set kinda like CSP or something else that maybecould detect, like, rapid changes
(14:46):
in the applications during clicking.
I don't know really what that would look like, but I think it would beinteresting 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 wayto be able to protect against this. Because, obviously, we really wanna try to
find things that protect at the base foundational leveland not something that we have to go do on every single page.
(15:12):
So is this something that we need to stop everything we'redoing and and find all the areas and and fix every page on our
website? I don't know. I thinkmost of the pages that we have probably do not
work as simple as this, that a page just getsloaded through a simple get
(15:35):
request that's gonna have everything needed to be able to change it without being ableto change any of the data on the page. I think that's why we call
out things like the OAuth authorization typeof request because those are kind of simple. They're,
you know, a single button click. So I think it'sreally for the organization and for developers out
(15:57):
there and product owners thinking about where do you have that type ofinteraction, at least at this point, not that it would hurt to
have maybe a global JavaScript that can disableeverything on all pages. But if you're looking specifically,
going through and trying to find out what are those sensitive pages thatcould load in this manner and be able to execute
(16:19):
via just a single click to be able to pick those out. That's kind ofwhere we come in with our threat modeling and those different areas to
identify the highest risk spots of our applicationsto be able to see this and be able to catch it and
add this protection. So I would start there in looking tosee where you have that. I'm curious to see this year
(16:42):
with a new finding like this coming out. Is this going tobe the new hotness that we see on all our pen test reports this year?
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'llprobably see quite a bit of it. The thing I would just
(17:04):
make caution of is that if you're the one on the receiving end of thesereports, think about where this is actually happening.
Look at it and see. Is this a high concern for me in this areaor this really can't be caused? You know, what is the
real risk around this happening? Not sayingdon't look to fix it because we wanna fill these holes, but we
(17:27):
may get a lot of these where it's just like every single page. Oh, yourbuttons don't disable on initial load. This is potential
for double click jacking. Let's make sure that it's actuallygonna 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.
You're not gonna be able to get to this. The risk is pretty low. Thisisn't critical versus a page where you could authorize an
(17:53):
OAuth client or something else, that would besuper critical, and we wanna resolve that ASAP. So
just be smart with how you triage the findings when theycome 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 beexploited? What happens if it is exploited?
(18:15):
And let's look to see how we can resolve this. These aresometimes 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 bittoo. I guess to that point, don't just grab something and
(18:36):
just assume it's gonna work. Do the testing on it. Validate that it's working inyour test cases. And if you do need to make a little bit of modification
to get it functioning in your area, you know, to makethose modifications. We can do that. It's great
that we have this initial script to get itstarted, and, hopefully, it works straight out of the box for you. But
(18:59):
if not, it's the best starting point. I don't know as I wouldhave had a good starting point to figure out how to go in and stop
that from a JavaScript perspective. So you really have toappreciate the information that's shared when something like this comes
out. I think Paul has did a great job really outlining what the issuewas and also, you know, some ideas of, hey. How could we go
(19:21):
ahead and solve this? And in the security world, especiallywhen 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 justcoming at us with a problem, but, hey. Here's a problem, and here's a
potential solution, is invaluable when we talk aboutsecurity and the stuff that we get out of there. So that's kind of
(19:43):
my initial take on double click jacking.
It it's pretty interesting. I thought it was interesting when it first came out. Iknow 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 elsedropping the same information at the same time. Let's spread it out a little bit.
And, if you have any thoughts on it, any questions, anyideas about how that could happen, feel free to share it. This
(20:08):
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 ofa little bit fresh to see something new popping out for us to look
at and something to talk about and something that'sinteresting and challenges a lot of things that we've been doing. So I appreciate
(20:30):
everybody for listening, and I'll catch you on the next episode.
You have been listening to the DevelopSec podcast with JamesJardine. 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
(20:52):
www.developsec.com.
Popular Podcasts
Stuff You Should Know
If you've ever wanted to know about champagne, satanism, the Stonewall Uprising, chaos theory, LSD, El Nino, true crime and Rosa Parks, then look no further. Josh and Chuck have you covered.
Betrayal Season 5
Saskia Inwood woke up one morning, knowing her life would never be the same. The night before, she learned the unimaginable – that the husband she knew in the light of day was a different person after dark. This season unpacks Saskia’s discovery of her husband’s secret life and her fight to bring him to justice. Along the way, we expose a crime that is just coming to light. This is also a story about the myth of the “perfect victim:” who gets believed, who gets doubted, and why. We follow Saskia as she works to reclaim her body, her voice, and her life. If you would like to reach out to the Betrayal Team, email us at betrayalpod@gmail.com. Follow us on Instagram @betrayalpod and @glasspodcasts. Please join our Substack for additional exclusive content, curated book recommendations, and community discussions. Sign up FREE by clicking this link Beyond Betrayal Substack. Join our community dedicated to truth, resilience, and healing. Your voice matters! Be a part of our Betrayal journey on Substack.
Dateline NBC
Current and classic episodes, featuring compelling true-crime mysteries, powerful documentaries and in-depth investigations. Follow now to get the latest episodes of Dateline NBC completely free, or subscribe to Dateline Premium for ad-free listening and exclusive bonus content: DatelinePremium.com