Nice, I had to listen through some sections a couple of times to really get my head around what was going on but def an interesting technique - thanks for sharing
i watched it literally more that 20 times to understand it and the interesting thing is now that i got it i know it worth knowing it if it takes 100 times or even more to understand it.
Yeah and the backend should completely ignore the amount of injectable arbitrary code to trigger such complex self-xss. Might be easier to just setup a i.e. BeEF hook.
I didnt finished the video (1/3 of it rn) but the first technique with windows.open and CSRF login is the same as bitK technique with to turn self XSS in normal XSS 🤔
It is different and more complex than bitK technique but that's unecessary complex. Dont get me wrong, this is an awesome technique and this young man has just a crazy skill, better than most of hackers out there. Thank you for sharing this technique!!!
In 1/3 of the video, we're talking about the conventional way to exploit self-XSS which only affects confidentiality and not integrity plus you have to be on the same origin. With this technique, you can also affect integrity plus you only need to be on the same site, not same origin which means you can also exploit exotic subdomains without needing CORS.
@@BugBountyReportsExplained Yeah, you're right!! I just watched the second part, and I had to play it a second time to fully grasp the concept and its impact!
Yeah self xss is usually stored. This bug seems like it has a few requirements but still I'm going to search for a writeup when Im done watching for sure
@@BugBountyReportsExplained Yes, there is also the case where it's dom based self-xss (not reflected DOM-based). So basically you input something in the page and it executes (self-XSS), but it doesn't get stored for other users. This is pretty rare, but the self-XSS case I recently ran into, and that I had in mind when I started watching this video. I can provide an example if I didn't explain that well. Great content. Cheers!
Once the victim is logged into his own account and gets redirected to the XSS page (but where the session cookie is fixed with the attacker cookie and not the victim one), how can the self-XSS be escalated to a normal XSS in the victim context? I mean, the cookie that can be exfiltrated from that page is the attacker cookie
Could you please link an article that explains the co conventional self-xss exploitation method you explained? I didn't quite understand how you interact with the victim's user after logging in to the attacker's user. I read through a medium article trying to understand it, but your explanation seems to be different from the article.
Will you make any lab for this bug? I'm trying to figure out how i can make the lab. Still at some point I'm getting confused in these scenarios. mostly 2nd one looks interesting and i want to make lab for that.
Remember that from 1st September, the price of BBRE Premium will go up to $128/year. As usual, every existing member will stay on their current price so if you subscribe before the price rise, you will lock that $99/year forever. To subscribe, go to bbre.dev/premium
Nice, I had to listen through some sections a couple of times to really get my head around what was going on but def an interesting technique - thanks for sharing
i watched it literally more that 20 times to understand it and the interesting thing is now that i got it i know it worth knowing it if it takes 100 times or even more to understand it.
So the attack requires the vulnerable web app to be
1. Vulnerable to CSRF
2. To also have the Self XSS
If so, that is awesome
Yeah and the backend should completely ignore the amount of injectable arbitrary code to trigger such complex self-xss.
Might be easier to just setup a i.e. BeEF hook.
When you're at the level Matan is at, that how you stand out from other hackers - you're able to exploit edge cases others can't.
Only login csrf is enough If I understand
Cool, that’s a really interesting technique! Thanks for sharing.
I didnt finished the video (1/3 of it rn) but the first technique with windows.open and CSRF login is the same as bitK technique with to turn self XSS in normal XSS 🤔
It is different and more complex than bitK technique but that's unecessary complex.
Dont get me wrong, this is an awesome technique and this young man has just a crazy skill, better than most of hackers out there. Thank you for sharing this technique!!!
In 1/3 of the video, we're talking about the conventional way to exploit self-XSS which only affects confidentiality and not integrity plus you have to be on the same origin. With this technique, you can also affect integrity plus you only need to be on the same site, not same origin which means you can also exploit exotic subdomains without needing CORS.
@@BugBountyReportsExplained Yeah, you're right!! I just watched the second part, and I had to play it a second time to fully grasp the concept and its impact!
Clever! Just a small note: The techniques in this video implies that the payload is stored. Please feel free to correct me if I'm wrong on that.
Yes, if your payload is reflected from the URL, you don't need the victim to be logged in to your account
Yeah self xss is usually stored. This bug seems like it has a few requirements but still I'm going to search for a writeup when Im done watching for sure
@@BugBountyReportsExplained Yes, there is also the case where it's dom based self-xss (not reflected DOM-based). So basically you input something in the page and it executes (self-XSS), but it doesn't get stored for other users. This is pretty rare, but the self-XSS case I recently ran into, and that I had in mind when I started watching this video. I can provide an example if I didn't explain that well. Great content. Cheers!
So clever. Thanks for sharing
Once the victim is logged into his own account and gets redirected to the XSS page (but where the session cookie is fixed with the attacker cookie and not the victim one), how can the self-XSS be escalated to a normal XSS in the victim context? I mean, the cookie that can be exfiltrated from that page is the attacker cookie
Your barely ever exploit an xss by stealing session cookie because it's usually HttpOnly. But you can still read data and send requests as the victim
@@BugBountyReportsExplained ok now that's clear, thanks!
You can log in the victim as the attacker from a subdomain by setting a cookie scoped to the target domain and path. Just need an xss on a subdomain.
Yes, and in that case you can also skip a lot steps in the attack by just setting the attacker’s session cookies with a specific path using your XSS
Could you please link an article that explains the co conventional self-xss exploitation method you explained? I didn't quite understand how you interact with the victim's user after logging in to the attacker's user. I read through a medium article trying to understand it, but your explanation seems to be different from the article.
I described it some time ago on BBRE Premium: members.bugbountyexplained.com/little-known-technique-to-exploit-self-xss-with-a-serious-impact/
Will you make any lab for this bug? I'm trying to figure out how i can make the lab. Still at some point I'm getting confused in these scenarios. mostly 2nd one looks interesting and i want to make lab for that.
I'm not planning to. It's a client-side attack so you can fairly easily play with it in DevTools
Genius, He thinks like a hacker with 16 years experience, He must focus on browsers hacking .
which country he is from ?
Poland
Israel
Matan is from Israel
🧐
you should do a video of the techniques to exploit self xss
because i have a lot of P5 self xss
I think if you have a csrf there you can inject it to the victim acc
@@N4G_Arthur do you have any video or blog post explain that
reach out to Matan or me and we'll see what we can do
Plz Make a practical video😊@@BugBountyReportsExplained
@@m0zA369 lol that's literally what this video is about ^^
Deep down, I know the guy is good; but as a beginner i barely understand the logic here. Looking forward to upping my bug bounty game.
Thanks for sharing.
Remember that from 1st September, the price of BBRE Premium will go up to $128/year. As usual, every existing member will stay on their current price so if you subscribe before the price rise, you will lock that $99/year forever. To subscribe, go to bbre.dev/premium
Awesome 😎
U look like agent 47😅
Crazy!
dang it this awesome lolll
Please Do 1 hour podcast with him like you do with other guys.
I surely will