And I got a bounty for it. Got $1,000 bounty on my first bug, first bounty. So I was like, oh, this is, it's easy. I found with time that showing impact will result in better bounties and also better bounties means higher, impact. While still working full-time. I decided to apply as a triager at HackerOne. And fortunately, I got the job. I think I was always good technically, but OSCP gave me that mindset, like that hacker mindset that I did not have.
sometimes the, you won't get in your error messages, but that the A team react differently depending on your input. Hello JR0ch. Thank you so much for joining me today for, the podcast. For those listeners who don't know you yet, can you please introduce yourself and tell us a little bit about your background? Sure. so my name is Jasmin Landry. It's a French Canadian name.
I'm known as, JR0ch17 on internet currently, full-time bug bounty hunter but I started my career in it, in 2012, so almost 15 years now. Yeah, that's a lot. my first couple of years in my career I worked as a system administrator, so I worked a lot with Linux, networking for routing and switching, using like products like Cisco, windows as well, middle servers. I did lots of certifications as well. I was certified with Cisco, Microsoft, so VMware as well, which was big 10 years ago.
Not as much now. And I did that for like roughly four or five years. And after a while I was, I wouldn't say bored, but I wanted more challenges. I wanted like something more challenging. and security was also something that was, I was interested in. at school I had classes on security, but it was like really like basics. and I wanted to, I guess work in security, but I wanted to do more than just basic stuff. and obviously hacking or penting was something that I always wanted to do.
when I learned that we could do it as a adult was like, I wanna do that one day. It was my career goal. Yeah, I think so. I think a lot were like this. Yes, that's true. So I worked my way. To get there. so while I was working full-time assist admin, I spent my evenings, learning, reading as much as I could. I read many books on hacking, and did a few certifications such as OSCP, which to me was like the, game changer personally.
I think I'm always good technically, but USCP gave me that mindset, like that hacker mindset that I did not have. Yeah. Because as a regular person you would just do what the app tells you to do. But the was CP helped me get the hacker mindset of can I do something else that you cannot, that I should not be able to do? Yeah. and yeah, so I did the recipes.
P. and then after roughly six months after I got my first job in, in, information security or cybersecurity, I did stuff that were considered junior. but I got my foot in, so I was like, okay, yeah, now I can focus on. Was it more towards the networking since you've already had the experience with this? it did help like. Landing a job insecurity, but I did also did like it, but I found it, that it was not a passion. Yeah. While cybersecurity, it was more of a passion.
Yeah. like I remember what I was studying, I, had to like, okay, go to bed late while networking. While I was studying networking. I was, did not have that passion. Yeah, I see. I, it was fun, but not like, cybersecurity or hacking in general. and I got my job. I had colleagues who were pen testers. I was not yet, I was just like a junior analyst. I did help them on, some like automation task, or not ion, but like running ES scans and stuff like that.
and around that time, one of my colleagues did a bit of bug bounty. he wasn't really good, but he was talking to me about it. He was like, oh, you should. Yeah, she used Should try it. Yeah. I was like, okay, I'll try it. I registered on both Buck Grout and Hacker One. tried, did not really succeed. so what year was that? 2017. 2017. Okay. Yeah. I did find one bug, which was like, luck. on the Microsoft, application, I just put in like a payload, and months later I noticed that it, worked.
It was like a reflected excess. Yeah. And I got a bounty for it, like one K Bounty on my first bug, first bounty. So I was like, oh, this is. It's easy, you, you, learn through this scam as well. Yeah. Yeah. So this was like in February, 2017. Yeah. so I literally got my first job I took in January, so a month earlier. So I started doing bug mounty, one month later. And then for the next couple of months I. Not no bugs, no bounties, ab, absolutely nothing.
So I was like, okay, I need to take a step back, improve my skills and more knowledge on, on, on the topics. so I did continue learning. I remember having, the hack one activity page open on my browser every day. So every day I looked at what was reported, what was disclosed. Yeah, read it. I looked at, Twitter back then X now, what people were talking about where there were, maybe they disclosing bugs, or, pub making public their, research or writeups. So I read a lot.
I read some more books on web application. do you remember the names of the books? Yes. it was, I. Web Application Hacker's Handbook. Yeah, that, I think I read that one. Yeah. Like 900 page book. Yeah. Yeah. It's a big one. I think I read that one twice actually. Because I think the first time they read it was like, okay, I understand. The second time was okay, now I get it. You only have that. Okay, I get it.
Now it's, this is the thing when you, this is like the time when you think you're ready. so fast forward from February to August, in August I found my, second bug, second Bounty, another X excess s This one was a bit more complicated, so I was happy that I was the first one on it. 'cause I put in and put in the effort. So if it would've been a dupe, I probably would've been like discouraged, Yeah. so I was first one on and got a, Bounty, and then the month after.
Started finding more bugs and I was not really, I wouldn't say like a good bug bunny, hunter, but I started finding stuff, had some Ds obviously. so I was like getting confidence, but I still felt I was not where I wanted to be. I feel like I could improve myself even more, if I had the chance to like, learn more. Yeah. while still working full time, I decided to apply as a triager at Hacker One. unfortunately, I, got the job, back then in, I. Yes. I think this was December, 2017.
I worked at Hacker One as a triager for about a year, working 10 to 15 hours a week on top of my full-time. Oh, so it was like a part-time? Yeah, part-time. Okay. Interesting. Yeah. by triaging reports I learned, that Hacker one does get a, lots of reports, not always good. some really good, yeah, a lot, of bad. we all know that. but I was able to, I guess learn, I would say learn how others work. 'cause when, we write a report, we don't always write like how we got to that point.
We just explain the bug. Yeah. But it still showed me like, okay, I didn't know, I dunno, post measure that existed. So now I knew what that existed, that it was vulnerable in some cases. So I was able to look into it, learn more about it. Yeah. And then the un exploit it. After a year of triaging, obviously it's a job that's not easy. so I figured, okay, I wanna spend those 10, 15 hours of triaging and do hunting instead. So I started doing a bit more bug balance in 2018. had a good year.
like again, also having a full-time job. Full-time job. So I probably did 20 hours a week back then. I was like in my early mid twenties, had lots of energy and I was able to hack, late evenings. So I had a good year. I had met, Gilbert, founder of, Hacker One, and, Peter Yaki, who we worked at Shopify back then. so I had attended my first LHE, life hacking event with Shopify, was actually. In Montreal, ironically. Oh yeah. so I got my first electric experience over there.
I remember finding a few books, but they were all closed as I think informative because Shopify nine needs not only needs to target. Oh yeah. especially as a beginner, it'll be even harder. but again, I learned a lot while working with, others, collaborating with other people. the show tell obviously was insane. I remember those. Yeah, it magical. Yeah. The tells are, like critical to it was critical to my learning anyways.
Yeah. Yeah. And then, while with time got invited to Morally cheese and stuff, and while I was working at Hacker One, obviously had access to a lot of programs. So like, when I was not able to hack on those programs, 'cause obviously you would cheating, so I hacked a lot on background. my first couple of years, made my way in the top, I think 40 at one point all time on buck route. and then switched to hack one.
'cause I think they were doing a bit more events and my friends were attending a lot, of them, so I figured out, yeah, one out attend those too. So did of, of life hacking events, bug mati, part-time as well. and then a couple of years ago during the covid, I was a bit tired of, my, my job. I wouldn't say tired, but I eventually scaled up. I was not a junior analyst. I became a pen tester as senior business as a matter of fact.
so I was hacking 40 hours a week and then doing Ty 20 hours roughly a week. Yeah. So it was a lot. Yeah. so I was like, okay. Oh, my brain is tired. so I took another job, which was not related to pen testing, just like a, an AppSec, job as a consultant for a six month contract. okay. I could calm down my hacking stuff. I. take a breather and then still do bug bounty. But like after a while when I did pen testing, 40 hours and bug on the evenings, I was like, I'm not, wasn't motivated.
Yeah. So I wanted like that motivation back because I was really enjoyed doing bug bounty like in the past few years. so I took that job, I did it for six months and then after the contract I was like, okay, should I do ba full time? Should I take another job? I was like, really, debating. And it was roughly a year after I had my, my, my son and as a father, like during bubble full time is a risk. 'cause we all know that. Yeah. It's not like stable income, Yeah.
It's, we don't decide when we get paid. with a regular job, you get paid every two weeks no matter what. So Okay. I'll, I won't take the risk, but I. It wasn't online, so I took a, job as in a startup in Montreal, as head of IT security. So I was leading the whole IT department and security department, and the department was me. I was alone. I was the very first employee in security over there in it. I was a startup, that was founded like 10 years earlier.
So it was like a sas It was a long startup. Yeah, it was like a SaaS product, which had barely any security. So even the employee side of things, like there were no like basic stuff, like INCH varies on their laptops and EDR, there's nothing. Yeah. So I was like, okay, this is not what I. Was thinking of doing, but like the challenge is so interesting that I think I'll take the job.
So I took the job, and eventually hired, more people, eventually put in like the basics in place, just to get like the regulars because like, a regular company would have as security, products or, whatnot. and then a year later, we got acquired by nasdaq, which was quite interesting. 'cause I learned that the acquisition would not have happened because of my work. if it had happened like a year earlier, security would've been like, NF on the audit for due diligence.
But when NASDAQ did the audit on the startup, they, we got an a plus on security. I was like, man, this is really cool. Yeah. So I felt like really cool. Yeah. Like even when, you had like the meeting internally where, the founders were like saying that, we're gonna get inquired by nasdaq. I got a shout out saying, look, you can't thank, Ja Manus without him, this won't be happening. Yeah. So that was pretty cool.
and then while joining nasdaq, with the, title that I had at the previous company, with the work that I was doing, I got I guess hired as a senior director in, at nasdaq, in information security. so obviously Nasdaq is, was way bigger than, what I was doing, that had lost more departments, lot more people in security. so I stayed at NASDAQ for roughly two years. and then, again, still doing bug bounty as a hobby, part-time.
now as a, family I could even do less bug bounty, but still did like maybe 10 hours a week on average, sometimes more, sometimes less. And then, back in Vegas this past summer, for the Life Hacker One event, life hacking event with Hacker One, I took two weeks off to do, just focus on the event itself. So that came just Took some time for myself and then hack. Just have fun. Yeah. Yeah. And had a time in my life, I really enjoyed it. So I was like, okay, should I leave now?
Actually bug my full time? I was like, I can't think about it. and this is like in, in August, right? The live hacking in, Vegas, in September I get my resignation. So I was like, okay, man, I think it's time. I'll, give it a shot. Yeah. yeah, so I left Nasdaq in end of September, First week of August. Of October, I was full-time by Monte. Obviously I took some time off, for myself. So 2024 was, the rest of 2024 was a bit quiet.
did, a bit of hacking, did a bit like recon building just to get some, passive income going. 'cause I am like a deep dive hacker. so I recons like not my thing at all. Yeah. so I did a bit of, building, bit of hacking, a bit of hacker one pen testing as well, just to get back into it. And then starting in 2025, I really doing like a full-time hunting. And it's been doing, it's been going really well. Yeah. I saw your profile. yeah, I'm happy about that decision. Yeah. I get to work, work for me.
It's, not work. I'm just having fun hacking, but I do work a lot less than I did. Yeah. I've been playing, obviously as a Canadian I play hockey, I've been playing hockey a lot more, even during the work days. Yeah. I've been playing golf a lot more as well. golf is also another passion that I've been building in the past year or so. so in the end, I work less and make more money and have like more like free time for myself. Yeah, that's great. For my family.
So my son just goes to school now, so let's say he has a day off of school. While it's not a panic at home, I can just stay with them, and we can go out, we can go to the park and do anything we want. Yeah. That's awesome. It's not a big, yeah. So if I need to take some time off, I just take it. I don't need to ask for approval or whatnot, so I find that it's a lot less stress. Yeah. Even though we get, even though they'll get a stable income, but in the end. The income is bigger, right?
Yeah. with bug, for me personally, so I really less stressed. and I've been really enjoying it. Yeah. So I don't regret it, one bit. Yeah, Unfortunately for na, that, but yeah. Yeah. No, that's great because, and also it's, there's a thing that 'cause obviously a, podcast about backbone. It's a podcast about making money, but I really like this, these beats where somebody says something about the worklife balance, spending time with the family. 'cause I think this.
At the end of the day, the, this is more important in your life than it is additional $2,000, additional five, $10,000. And yeah, it's just invaluable. It is. Yeah. And the time will, we will never get back, so. I'm really happy to, I, sometimes I try to smuggle in the podcast like this, but it's really hard, so I'm really glad to hear this from you. Awesome. Yeah. And like stuff like really basic, like taking naps. Yeah. Like with a full-time job, nine to five, you can't really take naps.
Yeah. And like when I feel tired. I'll take a one hour an nap, I'm getting old, have rest, because I feel like sleep is really something that I lack in the past couple of years. 'cause yeah, I was working full-time, doing my bouncy on evenings once in a while, so I feel like I need to catch up a bit. Yeah. I think maybe the way I have, a few white hairs in my beer now. Maybe I lack of sleep. So I'm trying to like, really work on my, my, my health.
Yeah. worklife balance, make sure like I'm really happy and healthy. And for now I think Bug Monte is perfect for, me right now, Yeah. Yeah. It's, so you've, you've mentioned a few different ways of learning. You've mentioned books, you've mentioned just hunting you, you've been employed as a pan tester. You've mentioned some certificates. Which of these things, these methods of learning, you would say, are the most efficient in context of strictly bag bounty? I think it's really having your.
Like deep diving and, working with it. I'm like a, learner where having someone teach me, is I won't learn as much as I as reading. Yeah. For some reason when I read, I learn Yeah. Faster and easier. but having like really like testing stuff, is I think is the way to that. The way to go. Yeah. along with reading for example, when at one point you will get stuck on something, so you will have to look it up, which is equivalent to reading in the end.
Yeah. so that's how I. Work, in terms of, learning. let's say I wanna learn something new, I will try to do it or whatever it is, manually and then read a bit on it and go back to it and, so for me personally, that's the, that's my way of learning. Yeah. Yeah. I, see. And I think the, it's easy to, get lost in different methods. 'cause they are very satisfying. Getting a certificate, having a task done is very satisfying. But I think just getting your hands dirty, right? it's the thing.
I think so do. Yeah, for sure. so as mentioned, I saw your hacker profile recently. It looks really good with a reputation of, with an impact of over 37 in the last 90 days. Yes. Which is huge. It basically means you, you have only Cris almost. Yeah. Almost. So what's the, secret? What's what happens recently? I don't know. I remember like sitting and golf for myself I think, for a long time. if you look at my overall impact all time. It used to be like around 20 something.
I was like, I want increase that. Yeah. 'cause it's always fun. Half really and a half. Yeah. So I think now my impact, what is it all time? 25.95 all time. That's good. It used to be like 20 ish. Yeah. So it's I want to get, I want to increase that to 25. So like my average would be like equivalent of a high. Yeah, so in the past year or so, I focused mainly on highs and credits. if I found a low, I would try to change it with something else instead of reporting it as is something for mediums.
I did submit a few mediums, but I think mostly highs and credits and even like for mediums, let's say reflected excess success. I don't think I reported one Xs, which was medium. I've always increased it to high and even some cases it's critical. Yeah, yeah. By basically taking over the account. Yes, exactly. and I found I, won't say it's, a new technique, but like it's just thinking of how to. use the XS to show impact.
so I, won't say, I won't say I've submitted only x success, obviously not, and actually barely any success, maybe like 10 maximum, throughout the year. But I did focus on high criticals, on, I did focus on how to maybe better show impact. for example, again, exercise as an example. I used to just do an alert. Yeah. But I found with time that showing impact will result in better bounties and also better bounties means higher, impact.
Yeah. So in the end, showing impact on all of my reports, showing, I would say focusing on certain stuff. 'cause I focus on everything. but lots of service side issues. And I try to chain issues, show impact, look for stuff that is a bit hidden. Yeah. and in the end, I reported lots of. Bugs that were high and, critical, which increased my impact. Yeah. And now it's just like habit.
So let's say in the ni 90 days lecture, it's 37, but now it's like the way I work, I look for, stuff that everybody looks for, I think. But I try to, show impact a bit more than I used to. Yeah. So what are your most common commonly reported back classes? probably SSRF, as you guys saw, or not yet. I have, I reported an interesting one. so we, we published it on, YouTube two weeks ago. The writeup with it together. So if you haven't watched it, make sure you, do.
'cause it's an amazing SSR with a huge impact. And it's also. some techniques of both the exploitation and detection that are probably universal across more targets. so definitely worth that. yes. Sorry. For sure. one of my, go-to one, those, one of the bug classes I like to look for personally, on all, kind of applications. But I will not ignore address stuff like, either service at our client side, whether it's XS or C srf. Yeah. past reversal, both client and service side.
c injection, ecstasy. I'll look for everything. Yeah. Depending on what I see. I'll look at it, but I tend to find more service side stuff. my, like my client side skills are limited a bit. so I will, rarely find anything related to the dom. do success. I probably won't even look for it. Yeah. but I, use like the JavaScript to find end points to look for service side stuff, for example. Yeah. So I tend to find more service side bugs, a bit client side. so yeah, a bit of a generalist I'd say.
Yeah. When I was preparing for the interview I saw so, a big variety of different bug you report and also bags that I ignore and I never look for them and I, so that's, oh yeah. That's why I wanted to interview for example, server, site template injection. It's, 'cause for me the, problem of it is that in theory it can be everywhere. I dunno, and I don't like. Putting the payloads everywhere if I don't have some clue that the back can be there. So what is your approach?
Do you just have the, SSTI payloads everywhere or do you look for some kind of clues that it can be there? a mix of both. So I used to be, like you were, I would not necessarily put payloads everywhere. at one point I was like working on an app. I had found absolutely nothing. Yeah. And at one point I put my pillow everywhere and eventually. It worked. Yeah. Okay. Maybe I should put it everywhere. So I started doing that. But the, so sorry to interrupt.
Which, S-S-T-I-P do you put, do you have that's the thing, a polyglot for all language? not really. It depends on the app. Okay. Because certain applications, depending on language that is used, the template engine will have its own syntax. Yeah. So let's say, Python engine will be different than on Java. Yeah. From pH p Ruby, it looks all different. So I try to focus on, what could be used in the backend.
Yeah. for client side, I do have like more of a poly cloud 'cause I have a angular JS view, which has a similar syntax in terms of templates. but for service side, I try to be more specific. Yeah. also to bypass the wall. 'cause a lot of cases they're, they blocked like curly brackets and whatnot. If you're a bit more specific, sometimes you can work around bypassing off. yeah. So yeah. Technique now, specific, but I've put it everywhere.
'cause I've had cases where, it worked and I was not expecting it. Does everything also mean like a default headers, like user agent, I don't know, host header or is it just inputs? Just inputs, yeah. Yeah. And maybe you should try headers as you're bringing a good point, but, yeah, just inputs.
Yeah. For me, I, dunno, I feel stupid for not testing so many things, but, one thing I noticed, is some, a lot of the applications, the way that build these days is your input will is like on the application, but it will be brought. Elsewhere. Yeah. and those, sometimes those, elsewhere will be vulnerable. So your payload may trigger on that one. Yeah. So like a second order injection in this case, Yeah.
I I had a few cases like that, with Ansible, where I put in my payload, like in my, my, in my email address. Yeah. And it eventually worked like in a totally different application. I put my, in my payload, like I think seven times seven, like the typical Yeah. Testing thing. and then my email address, it was like JRO plus 49. I was like, whoa. And it was like totally different code, different everything. It's yeah, something's happening on the way there or over there.
So yeah, I've been just trying to put it everywhere if I can. 'cause you never know where you, your input will, will end up. Yeah. Do you have some kind. I dunno, a word list that you always put in the, pillow. Do you manually type it into each input? What's the, like, how exactly do you, do it? just like a match and replace rule. Okay. so I have a interesting, let's say I would put SSTI and in the pillow it would be like my public lot for client side or that's smart. Or another, keyword.
Yeah. for server side stuff, I use lots of, matching replace rules. Just bypass like client side restrictions and whatnot. Yeah. That's super nice. I never thought about this. I use uman, it's called Okay. But I don't use it enough, I think, and it does not always work. Especially if you have some kind of weird input or whatever. Okay. Yeah. So that's, yeah, I'm definitely going to, use this from now on. Awesome. Another, the backlash I never find, 'cause I never test for it at school injection.
Yeah. You have, I saw a Twitter picture from last year from 2024. Yeah, you had some. So it's still around. I found four more in 20, 25. So centuries. Yes, it still exists for sure. I think like in the end. First SQL injection. Yeah. Even if you have your database like in, AWS, like I've forgotten the name. but anyways, or like in Azure, it's still in the end the code that is vulnerable. Yeah. So the developers still code, vulnerable code. you'll still find some.
and so yeah, so the ones that I found this year were really simple. Like I just added like a single quote and see how it reacted. It gave me an error message showing that it's probably vulnerable. and indeed it was, and it's nothing that really complicated. yeah, sometimes there are, they are complicated, but the ones that I found, in, this year, 2025, it's just like single code, send it to ESCO map and the rest is done. Yeah, I think so. It's literally minutes of, testing and Yeah.
Yeah. I think the exploitation part is the. The more doable one, I think. Detect the more difficult to, detect. Detect it. So I have a few methods of, like testing, but something that is hard is identifying the database that is used. Yeah. sometimes like the, you won't get any error messages, but you'll see that the application reacts differently depending on your input. so that, that is usually hard to identify. Some cases like it, the application is built on Ruby, on Rails.
A lot of times it works best with Postgres. So you can guess that it's Postgres or PP, it'll probably be minus but you never know. You can be anything. same thing for apps. Built on C or Microsoft products will most likely be, MSS grill. Yeah. But again, you never know it can be anything. Right? Yeah. so this is usually something that's quite hard. we had a technique doesn't always work, but sometimes it does, for identifying what is used in the backend.
And it's really simple just looking at like job applications or job offers. Sometimes they, list oh, we're looking for a, database administrator. Yeah, this is what we're using, so okay, this, they use that. So maybe it's, that's, what it's used in the backend. so sometimes that's just a simple thing, need that, that can work. but, so yeah, there's, they still exists in 2025.
Yeah. I saw, I saw in one of your, I think it was an article on background that sometimes for Rico you browse job applications. And I was like, yeah, what information do you find? Job applications and Yeah, that makes sense. Yes. I find that it's interesting 'cause. And, when you look at application itself, you'll see like language, like quick plugins, like you were built with, and with error messages.
You can see a bit what's used in the backend, but you, it won't go in detail as much as like a job application. Yeah. I find that some companies have started like hiding that a bit, but some others, like they'll show like, oh, elastic search, MongoDB. they, so everything what developers need to know, and this is a good indicator of what is potentially used in the background around that product. Yeah. like I said, like your input can go from one app to the other.
let's say, it can go from the app to Elastic search, or maybe your data is stored MongoDB and then a job fetches the data from MongoDB and puts it in a admin dashboard. Like you never know, right? Yeah. so knowing what is used. In the product or around, I think it's like an indicator or not an indicator, but like it helps in terms of recon For me personally. Yeah. Of what it could, test for.
Also, one thing I saw in, one of the interview, in, in the same blog post background was that you think what infrastructure as a code used, tools are used. And my question is, first, how do we even determine this? And the second is, if you know what tools are used, how do you use this information? Yeah. So this is like really context dependent. so in. When I wrote that article with background, it's 'cause I recently found an SSTI, with Terraform where my input landed in, a Terraform file.
Okay. So it, so Terraform evaluated my input. Okay. It's a very specific functionality, isn't it? Yeah, it was, and in the end I could see that it validated because it rendered it back to the application. Yeah. and with testing at, the time I had no idea it was Terraform. Yeah. So I knew something was happening, but not sure what. So with testing and all, I figured okay, maybe it's a Terraform 'cause I worked with it in the past while I was working in, AppSec. Yeah. I was like, is it that?
So I tested it and indeed it was, yeah. Was this, some kind of functionality, which was it like, testing a cloud provider which allowed you to deploy somehow something like this? yes. okay. Not. A cloud provider, but you could deploy, like products, like you could deploy like WordPress and stuff like that. Yeah. Yeah. I see. So you so contact dependent. Yeah. So you won't probably, won't see that like in regular applications.
But again, if it's something that you can deploy stuff or maybe sometimes not, it really depends. Yeah. but something that I only find once with Yeah. I see. I found this so it exists. So maybe others target. Yeah. And these targets are very interesting, right? Anything built for developer developers is very interesting, at least from my experience. exactly. Yeah. Because the functionality is very complex. The what happens under the hood often, like executes comments, creates clusters. Exactly.
True. This is very complex. This is very hard to get. True. And they may not think about the security impact or maybe you have some kind of separation, so they don't, we don't need security. 'cause you have your own instance and then you have. A client side bug. Which allows us to do anything and Exactly from my, yeah. these targets are very interesting. That's true.
one other bag class that, that I saw your report and I also, sometimes I do test for it, but rarely, probably not often enough is XXC. Because this is very specific, I guess this is not a case where you spam the payloads 'cause you need like the XL XML parer to, do it. But do you have some experience of maybe cases where it wasn't so obvious XML is par, but you through some trick you made it parts xml? not really I'll when I test for XXC is 'cause I saw something XML related.
Yeah. But what I did have luck with is look at features that people did not think X ml was used. Yeah. Yeah. I had one case, Two years ago, I think, where. what was it again? I'm trying to remember here. but yeah, you could convert, like a doc file or a PDF to, another file type. Yeah. And one of the options was, XCL F file. What, yeah, what exactly? It proves a point. So I looked at what is an X lift file, so X-L-I-F-F. Okay. And by looking into it, it was X and L. Okay.
So I just put a regular existing payload and it worked. how did you get to, to, how did you discover a file like this exists? type, I mean, in the options on the UI itself. On application, you could do like a doc Excel. Yeah. PowerPoint, regular T xt, HTML. And in the bottom there was X lift. Yeah. So probably people tested for DOC and PowerPoint, Excel. 'cause it's a known technique where you can, it's a, it's a. XML document in end. Yeah. That just compressed or zip whatever.
So people probably tested for that, but have they tested, I mean they also probably tested from HTML to other stuff, but have they tested for X lift? And you said what? So yeah, you, yeah, exactly. So have no idea. I was like, probably not, Yeah. So I tested it and it worked. I was the first one and it got a bounce for it. And yeah. So I look for stuff where maybe people will not look or think the XL is used.
Yeah. I had another case on that same application, in regards to, site map parsing just a bit more of a known technique where site map is, an XML file. Yeah. So I had one case like that where you can give it like a remote, site map file and it'll parse it. and then XML XXC. Yeah. apart from that, like it's. I won't necessarily put like accessy, pay payloads blindly. I'm just trying to find a function that functionality or like other, other XML related specs.
I've had luck with that as well, where it's like format that is X ML based and you can put SY in there 'cause it doesn't expect it. the parer won't expect it, but it'll still parse it in some, cases. so yeah. How, what do you mean other XML specs? what does it mean? So one that I found recently, I'm not sure if I can disclose, the spec name, I guess it spec name. It can be anything. Yeah. It's called CXML. Okay. I forgot what CX ML is. We can look it up real quick.
commerce extensible markup language. Okay. And this is like one example, but there were others that I found in the past, which, it was completely different, spec related to, I think like translation stuff. Okay. and it was like, XML based spec. so I just looked at the docs online, see how it worked. and then in the end, maybe you can get an EC to see with that. 'cause in the end it is xml.
So maybe the pars in the backend will parse it even though it doesn't look like, not that look doesn't look like XXC. It's maybe a feature that others don't think it. There is XML parsing. It's not as obvious for not as obvious. Yeah, exactly. I see. Yeah. Yeah. Although now I thought about this probably spamming the payload. Once every hundred targets it will probably work as well. Maybe. Yeah. Potentially. Yes. Yeah. It's, crazy how many things we, probably miss as hunters in general, right.
For like weird, things that happen that you can never guess blindly. True. yeah. And one thing as well that has, has happened in the past, recently is external, these don't work, but internal ones do. What's an internal entity? internal DTD internal document. Oh, yeah, I forgot what d it stands for document type definition, I think. so internal dt. So instead of pointing to like your own DTD file Yeah. You have to point to an internal one.
so I've had a few cases where external word is allowed, but internal ones did work. So we have to test for both. Yeah. 'cause I guess there's one that's defaulting, UB. That's like always Yeah. Depending on the os. Yeah. You'll have always these files available. Yeah. Yeah. 'cause it sounds pretty, because the thing is you don't fetch the DTD from your server. You need to know a local DTD, which sounds like something that's really hard to know. The black box test. Right.
But there are a few that are. In, I guess it was Debian that is always in the same directory. And if you can use the file protocol, it's not like a guesswork, it's a Exactly. Yeah. and there are, I have a GitHub repo, not, not mine, but like I start a GitHub repo that has a bunch of payloads containing, internal dds. Yeah, that's pretty interesting. So I usually just use that list, test it out. 'cause in the end you're a black box. So you don't know what OS is used in the backend.
Yeah, I think I, or not the backend, yeah. I think I remember using these Ripple once as well for, something. Yeah. So for HTCI keep in mind of texting for internal disease as well. 'cause yeah, I found that not a lot of times, but sometimes, like I said, by default, I think now more, nowadays, by default they disabled external disease. But maybe forget about internal ones. Yeah. Yeah. That's a good one. Good. These are, the bug that were, that are painful for me.
'cause I, know I miss them because I just don't test for them. I don't know why, but, yeah. Another bag that I do actually test for it, but I, I. I want to test more. 'cause I see the potential secondary past reversal. Yes. How, is your experience with them? One of my favorite bug, I test it for on every app that I, use.
Yeah. If I see that it's probably happening, I, it's not something that I found often, but I do looking forward and then I think, it can be like a really impactful bug if you're able to show impact. Yeah. it's funny 'cause when I was, when I started looking for that, it's roughly the same time around, when Sam Curry published his research about it. And I actually, the him, have you seen this before? 'cause I know this, it's his type of thing. So he's oh, I'm actually doing a, research on it.
I published it like in the, week or something. It was like really late. Yeah. Around the same time I say, oh, cool, I'll just look it up. and yeah, like I said, it's, common. It's not something that I've found too many times, but I think it's sometimes, a lot of times it's hard to, I mean it won't be verbose, a lot. It'll show that maybe it's happening, maybe not. Yeah. Depending on the error message. and there's a lot, lots of guessing work as well needed if it's a bit blind.
Yeah. Do you fast all the path parameters or all, the parameters or what? I go a bit logically. Okay. 'cause some parameters, for example, let's say it's like a, an JSO body of a, post request. If the parameter is like id, then let's say it's like a digit, then maybe in the backend it, there will be like a call, let's say a PIV one slash object name. Than the ig. Yeah. So maybe this is a good parameter test.
Yeah. If it's, let's say like a parameter just looks more like a metric related, for example, it'll have like your Chrome version for example, then probably not. Yeah. I try to go a bit more logically. but I, would test every, that I, let's say, I'm not sure. It's like really specific to the application. And I would test maybe all parameters to check. 'cause you never know, right? Yeah. so yeah, that would be my approach.
Yeah. 'cause yeah, it makes sense to basically test every parameter that can be in the path later. That test would make sense to test. So most of the time it's gonna be IDs, Maybe a type. And, regarding to that, I discovered a new, I won't say new technique, but something relates to secondary pat reversal, with GraphQL. I'm gonna. Talk about it, at a future conference. But, I think we need to keep in mind that it's not always just like an a PIA rest, API in the backend. Could be something else.
Yeah. yeah, I think it'll be a fun, yeah, the, the backends can be really, complex. I wait for the full talk. but yeah, we, sell many times that what happens on the backend can be crazy and, that, we don't expect can happen. yeah, it's nice when, you fast for the, secondary pass. 'cause I guess for template injection, usually you need like one payload. Maybe two free or, for different engine, depending on the technology for secondary erso. how many payloads do you test?
'cause I guess you need different depths. I need, you need different, iterations of, your own coding. So how long is your, word is for fuzzing? I actually rarely fuzz. I do it like. Manually. Okay. Just see how he reacts. Okay. my typical go-to is like traverse back one path and comment out the rest. So I put like a question mark or hashtag Yeah. vault with all coding without depending on, on, on what's going on.
'cause a lot of times if you're not giving it, what is what it's expecting, it'll give you an error message. Yeah. so if you just comment out. The rest of the, UL maybe there are hardcoded parameters that you're not seeing, in the code and that in the error message it'll tell you, oh, you're missing X parameter. Yeah. So that way you have an idea that, okay, maybe there is like a de patcher vessel here.
or just like the path itself, it's if by going back one it may say oh, object X or whatever's going on is not there. Yeah. So it gives you an idea of something is happening in the backend. Yeah. Now you mentioned actually, 'cause I do have, I do use a longer, list, but when I test manual, I would start with going back and going forward. Right now, I think actually you, you say it maybe putting in a question mark. Is more likely to give us a useful error rather than anything else. Question mark.
Maybe the, full UL is like your input than other path in the end, right? Yeah. So if you put a question mark, it'll remove everything else. Yeah. So it'll give an error message indicating what is happening. if you just put like a, let's say double slash or whatever without removing the rest, it'll just say maybe knock out. Yeah. Compared to if you put a question mark, it may be more ose. Yeah. Yeah. Yeah. That's interesting.
And also, if there's some kind of filter for the dot slash, which I think is rare, but probably can happen You are not gonna have problems with this. True. Yeah. Yeah. Especially if the input is in the body. obviously it depends on the valve. Let's say Akamai is really annoying with the l slash Yeah, but other, but usually like you can get away with it just with the regular, yeah. Yeah. It's the body. It's not a problem, but it, sometimes you need to encode it.
really depends on, the context of the, application. Yeah. Yeah. So we mentioned GraphQL. I know the research is coming later, but, in general, what's, your methodology for, testing GraphQL? I guess you. So you, start by checking the introspection is enabled. Yes. That's usually my, first thing that I do. I find that it's disabled most of the time, unfortunately. Unfortunately. so what I do typically first is try to find the queries themselves in the JavaScript files.
a lot of times they'll be there, so just look for like query space and Yeah. Yeah. It's easy to prep for. Exactly. or just like the operations name and try to, find, those, queries or mutation that way I. let's say I do have a query, I valid query and networks. I try to add more parameters to it, see if I can get those in response or disclose more information that I would not be able to access. secondary patch. Russell's also, one that I've had success with in GraphQL queries OR mutations.
Okay. yeah, so, you would use the DO slash or whatever the character in like a variable As the variable? Okay. Yeah, yeah, typical stuff like DOS, like non GRA techniques. Yeah. I call hacking techniques. Yeah. Yeah. How successful are you with reporting the denial of service bugs? Not successful. When, they are mentioned as our scope. not successful 'cause everybody probably tests for it. Yeah. I actually started like not testing for it 'cause I found that in impact's not always there either.
'cause a lot of times it'll just do os GraphQL service. Yeah. Everything else works. And then, sometimes impacts there, sometimes not. Depends on, application, but I just started looking for other, stuff. Yeah. Yeah. And also if you're testing the target, which you showed the writeup from LA recently, which has separate instances. Sometimes you, can only dose if it's a post authentication, sometimes you can only dose your own instance. Exactly.
Yeah. If, that's a dose and you have to be a user of the organization which you're dosing Yeah. The impact is really low. Exactly. Yeah. And yeah, and I had this case recently, I reported the denial of service. 'cause the response time was really long. And turned out that I could, even though my instance was, was, having a long, response time, the other instance was unaffected.
Okay. So even though it was like a very similar case to what it, what you described, like the domain was similar, so I assumed some resources are shared as well. it still was separated enough that the dose just didn't affect on the users, so it was, pretty useless. One thing as well that I just remembered, that I test for, a lot of times the query augmentation will be in the body request, but if you put it as, a get request, sometimes it'll work. So that can help in terms of CSRF or whatnot.
Yeah. Yeah. Sometimes it works and usually if it works, it also allows mutations, doesn't it? I don't, know. Maybe I. I haven't, I think last time that I found it, it was only queries, no, it was mutation. 'cause I reported as a CSR, so I did an action. Yeah. Yeah. I said about the question, I realized it doesn't really make sense. How about OI on the Critical Thinking podcast, you mentioned, a very interesting back in purify. Can you please remind, us or, tell the users that didn't listen?
what was the bug? Yeah, sure. so it was a case, where Dump Purify was used along with, obviously Chrome, and Dump Purify did block the metal tag, but for some reason it still, existed in the dom, I guess in Chrome. Yeah. Yeah. The bug itself was, I was able to leak, an nawa token by putting the meta tag, which, what was it? The refer policy so that the token would be sent through, I think an image, I think I put an image, payload image tag, yeah. as of my HML injection payload.
so that way the cookies would be sent to the URL along with the token. and from what I heard recently, just last month, that technique still works. So it still applies, probably today. I guess Chrome or number four, number five has having not fixed it, so Yeah, because the bug is the. When your HTML on the client side is being parsed, maybe you have, a, very restrictive, list of allowed tags and usually meta tag will not be allowed. Usually.
Yeah. But, still, after parsing it, it is applied to the website. So even though. Don't purify the HT m other returns. Strips it in. Yeah, strips it. It's still in the website, right? Yeah. Yeah. That's a very cool bag. I stumbled on it like a bit by chance because I was literally just trying any payloads thought of meta of metatech 'cause it did apply to my scenario. Yeah. and I later learned through critical thinking of how to look for the allow listed tags and dumper five.
So I did not do that last time, which we literal just like trying some, strike some stuff. Yeah. and yeah, like I said, ended up working and then still works to this day. So even this dumper five blocks it. Yeah. It still for some reason applies in the dam yeah. Yeah. So if you have do purify on the client side and you have something sensitive, you can put in the URL, use this 'cause it still works. So Yeah, it's a very interesting bug. I'm trying to think if I have some target using it. Maybe.
'cause dify is used often a lot more. Yeah. Than it used to be like just two or three years ago. Felix now is everywhere. Yeah. I think it became the standard. I think so, yes. Which we should be happy about. At the end of the day, we wouldn't think to be success, but as backhanders, we, not which, means they do a good job of Right, exactly. Of being hard to bypass. That's true. speaking of, of oath, so if we have, this bag which allows us to, to leak the URL, but for, this to.
To be a value attack, we have, we should put an unused code in the URL, right? So what are some methods we, can do it with? so when I test for aot, I find it like so many attack scenarios and techniques. So I usually just open up, France Roses, like dirty dancing article, which is great. Yeah, it's awesome. Just trying to think of okay, I should maybe try this and that. I also look at the, I think there's a guide for oas. hacking, like created from Oasp, I believe. sorry. Oasp awa hacking guy.
yeah, so look at that for like ideas. but a lot of time I just look for the basic stuff. can I send the code to, an attacker server, attacker own server to do a direct UI parameter? is the state validated? what else am I, what am I missing in terms of, the, basic regular stuff? Yeah. Yeah. I af I remember after the article from France, I started testing it on every flow. But I, got to a point where usually it's, if there's a, the outflow, it's fairly easy to break it.
And to, land with the code on the page. the harder part is to leave the URL. Yes. Yeah. usually it means needing an exercise or the value mentioned, or the one he described was some kind exercise, but on the sandbox domain. But it is allowed to, leak the, URL, but it's usually quite difficult to do, unfortunately.
Yes. Yeah. And then like you said, so you need an success, but you always had success, so you don't often, you don't always need to exploit that part to do something bad, Yeah, you can you can probably use it as a gadget to show the impact of their success if you cannot address it, change the email, stuff like this. Yes. actually reminded me of something. One thing that did work recently is something that Dorian sek, published recently.
Yeah. I think also Justin spoke about it in critical thinking. I think they called it client side. No, client application. Fusion Client application. Oh, I know what you mean. Client id, yeah. Confusion. Something like that. Yeah. Yeah. actually I think I pulled it up here. I wanted, I remembered I wanna talk about it. Yeah. The blog post from about is very good. Yeah. I actually don't, so yeah. you can create like your own, if you can, depending on the context.
Yeah. Use like different client id. Sometimes they won't validate the client Id. But once it's time for the application to validate the token, it'll notice that it's not, for the client. And, so the token will not be consumed. So you can try to steal it in another way or not. But there are ways by manipulating the client ID where you can get access to the token or, Yeah. Lots of testing to be done with, with a lot. and also I remember one bag and I tracked the origin of why it was possible.
'cause it was possible to use, like my client authenticate to somebody's instance, right? Yeah. it was using kognito. Okay. And I tracked back that in the AWS documentation there was, or still is, I haven't checked, a code snippet to, to validate the, token in that case. And this code did not have, because basically what you need to do in, In that case, it's to validate the issuer. If it's the one you are, you're trying to authenticate user against.
And basically the code in the dogs didn't have this validation of the issuer. But the dog said, this code does not have the validation of the issuer, but for the production, code, you should do it yourself. Oh really? But of course, the developer would copy the code and use it as this. So, we'd work like this. I think they did fix this part in documentation, but it was very kind. Yes. I also remember one AAT bug from WAN to Africa, who it was, recently.
I remember it was, I wasn't answering that 'cause I had something that I had tested for, in the outflow, the product, the. Application, there were like custom parameters that were added in the OT flow. Yeah. And I was like, it's probably just like metrics stuff, like for them to know who connected from where. it turns out that by manipulating those, parameters, you could just put any redirect UI and the token would be directed redirected over there.
So since the custom parameter had like arbitrary data, it like did dirty dancing and messed up everything. Yeah. so yeah, it was one case where I was like, oh, I should have thought about that. Wait, so another parameter was used as the redirect, right? No, like another parameter was part of the oat flow. Yeah. It contain I forgot what it was. but just like something that. It's not necessarily part of the AWA spec and the regular AWA flow. Just like an arbitrary like yeah.
Parameter specific to the application. Yeah. I see. And by manual manipulating it, you could put in any value as you redirect your I parameter, you can redirect it. It could redirect the code anywhere. Yeah. Yeah, That seems, yeah. I always love to see the, custom parameters or when the state is like adjacent and contains Yeah, true. I love to see this, but when there's like the, pk CE thing with a challenge Yeah. you just remove those parameters.
Sometimes it works, Yeah, yeah, how successful have you been recently with the typical ovary direct URI takeovers where the redirect URI just isn't validated properly? it's been a while. I think last one was through like a pastoral vessel in the redirect U eye. Yeah. So it stays on the same application and same origin, but you need ans or something or like a direction with the metal tag, whatever, another technique to leak. Yeah. or redirect. Or the redirect. Yeah. but it's been a while.
I found I think a few last year, but I don't think I found one yet in 2025. In regards to OT or, yeah, it's hard. The programs are starting to configure it a bit more properly, but I think there's always some, weird bug thing around in ot, so Yeah. Yeah, of course there is. And you have some hidden parameters it lead to that are just forgotten and the validation is exactly not there. You know what bug actually reminds, it reminds me of one bug actually, and it's quite interesting.
and part of the AWA flow, like I manipulated the scope part. Yeah. And I added myself a privilege that I usually do not have. Yeah. And in the end it was redirected to. Arbitrary host that did not even know existed. Yeah. Because of a different scope. And it gave me like, you're not allowed to access that permission. Yeah. But it was, the token was sent in the URL and the other host, so I just found another excess on that other host and then was able to leak the token in the whole flow.
Flow. Yeah. That's interesting. Yeah. It was the one was weird. Yeah, because why would it redirect to a completely different host? doesn't make sense. Yeah. What was the other host? Was it like a. Server. It was like server or something like this. Some kind of SSO server, But it was not used. It was like used for another product. Yeah, I see. Completely. Yeah. That, that's cool. and usually it was like in the login or like some kind of sso, but usually like in login application.
Yeah. But that one was sent to completely different one, which was not even used as like a what for my obligation. Yeah. Yeah. I see. Do you often test for, let's say lower severity of related bug where, for example, I. When you go through the authentication flow with some restricted set of scopes, and then you want to redo the authentication flow, but with more scopes, it should reprompt the user to confirm the new scopes. So if, there's no reconfirmation, it's like a lower medium level bag.
there are a, few different ones as well. I know Johan is sometimes looking for, bags like this. Do you also spend time on this or. Because you of your resolution to look for high increases you ignore. Yeah. Not really. Maybe I should, maybe you could lead to like more, more bugs and more interesting bugs that can maybe change with other stuff. but yeah, I usually just try to link the code somehow. Yeah. Yeah. Because it directly to a TO which is my goal for oau. Yeah, for heis and kids.
That's, the only goal. Yeah. Because the other, why do I have started recently to hunt? 'cause I, hunt on the target that paid really well for mediums. so I also hunted for these attack scenarios that are a little bit more difficult to exploit. 'cause the attack scenarios, like the app is the attacker. So it has more privileges than it should and it's clearly a back. Right. But the tax ary is not there.
But on a good target that pays, like for the, this target paid I up to 1000 lows and up to 8,000 mediums. Okay. Yeah. That's worth it. That's, worth it. Yeah. Awesome. And I think there's a lot of, bags like this, but it's quite difficult to test or it's a bit annoying. Yeah. But yeah, sometimes it is worth it. Okay. Last, question, 'cause you said that you are more like a deep dive guy, more like a manual hacker. But you did build some automation. Yep. So what does the automation do?
it's pretty, I wouldn't say simple. Like I don't do like any nuclei hacking or, scanning. 'cause I feel like everybody's already doing it. So it would be a waste of resources. Yeah. And time to do it. So I have put like an infrastructure in place where. I get alerted when a new app, has been put online on, internet. Okay. By, from the DNS sources. Yeah. D Ns. Yeah. So it sometimes it resolves actually a lot of time. It doesn't resolve. But at least I know when it's there.
Yeah. And I put like a bot in place that would constantly test the resolution. no, sorry, lemme start again. So I have a, a tool in place where, it alerts me of new assets. whether they're on internet or not. Sometimes it resolves, sometimes it doesn't. Yeah. If it does resolve, I'll do with HT PX on it, see if HP is running, if it doesn't, just store it in the file. And then, the bot that I built will constantly do resolution, constantly. Once I think every week that I did it.
Yeah. To see if it does resolve and if it does. Then do HPS. Okay. Interesting. Yeah. Do you some somehow note all the domains that resolve to internal IP addresses to use it later for, I do store it. Yeah. but I don't go back to it, much. I go back to it when I do need it for R Okay. Yeah, yeah, 'cause I thought it's, it useful to, let's say we have, loads of IP addresses resolved from a wildcard domain, let's say. It's useful to just save all the internal ones.
Yeah. And once you have the SSRF, that's, the ones that you use. Exactly, yes. So that's what you do. Yeah. Nice. Yeah. It's, I thought about it, didn't do it. Yeah. I think in the end, it's like I kinda changed my, technique a bit. Yeah. so I used to just like open burp. Hack. Yeah. And that's it. Now I've been like gathering a bit more data, taking a lot more notes. My notes are, a lot more structured.
Oh, and I do note like internal domains and yeah, take note of everything that I see that can be, can lead to a bug. So I think I probably missed some bugs in the past where I was like, oh, I remember that, but where was it? I don't know. But by taking notes, yeah, sometimes it's easier to, go back. How do you organize the notes? I have a, let's say a hack on, one application. 'cause I'm a deep dive, so I don't really do recon or not much. Anyway.
I have like technologies used, like my recon in terms of hacking on an app. I like, not like ESE scanning, just like recon on the apps system. So I'll note that technologies used, I'll note the, API endpoints, the reverse proxy APIs sometimes slash I don't know, water will have a different backend than another. Another one. Yeah. So I know which one leads to another end, another, backend. sometimes like slash Water will have an known JS app, but slash Glass will have, a Java app.
So I take note all of, this. take note of GraphQL endpoints, things that I notice that are like interesting or weird sometimes just something as simple as like a metrics like sex. slash metrics endpoints, are pretty usefully. Usually we report them as a little bit like informative, but it can help in other stuff. So I take note of that. I take note of like lows and mediums that I will not report. Yeah. Report, yeah. But can be trained with something else.
I take note of what I see is interesting and what to test. kinda like a bit of threat modeling. okay, this app, this has this, a bit of, a bit of logic behind what to test. and, actually could probably take a look here. Forgetting something so you, things for, to you save for later. internal domains, right? Obviously lows, mediums and that, you can potentially change with something. Yes. What else are like the typical things you save for later?
stuff that I find that are probably vulnerable but have a hard time exploiting. Okay. or that they disclose information, which can probably help in another place. For example, I had one case where, when I uploaded a file for some reason, once in a while it said, ok, find file in this path. This was the internal path. Okay. Yeah. So I could, know where it was being uploaded, and maybe I could pa do like a petro Russell and upload it elsewhere or whatnot. So information like that.
I also store, custom headers. I've had luck recently with like custom headers that the company's, Use, success in what sense? In the sense of putting one header in and different request that normally did not have that header? yeah, sometimes yes. Okay. I see. I saw different behavior. and one trick as well that I think France, obviously France knows everything, right? it's looking at the access control allowed headers, I think. Yeah. In response, yeah.
Sometimes you have like custom headers in there and putting them in the requests. We'll have an adjusting behavior. so I had a few cases like that, which like interesting. I was not always able to exploit it, but like I know something is happening. They're doing something with that header. I didn't look at this part. the headers that are disclosed in the access control allow allowed headers. Yeah. Sometimes you have a bunch of them.
So if you put one by one or all of them in your request and put like any value, sometimes the application will reply like with something interesting. Okay. Yeah. Okay, I see. Interesting. and also cases where, the app used like, custom headers for admins and by putting like that header. In the request and putting like a, let's say it was like a X dash user ID in the request. I could put another id, it got me access to another user's. Yeah. So like that, yeah. That's cool.
So that should not work, but works after. speaking of things that should not work, but they work or they worked, after the recent next JS bug. Oh yeah. I'm tempted to just take a look at the source code of each web framework. Just create for. All the headers that I thought about that too. Yeah. I actually thought about it. About it too. Yeah. Because I'm sure something weird happens. There must be something else. Yeah. There must be something else.
It's not the first time that guy in, in particular has found next J bugs specific to, headers. I think he had found two or three regarding to cash poisoning. Yeah. And now an authorization bypass with headers. And I think I found a future where it led to some interesting stuff. So I think headers are definitely, an interesting, attack surface. Yeah. Yeah, for sure.
we'll end our interview here, but before we do, tell me what are your plans for 2025 as this is your first full year as a full-time background hunter, what are your goals for this year? I have my, financial goals and sort background. I'm on pace to pass that. Yeah. I think by a lot, if I can continue hacking and finding more bugs. Yeah. I'm hoping to get invited to a few, more life hacking events. 'cause those usually like boost, a bit. yeah. And, hoping to take more vacation as well.
I actually go on vacation a couple of weeks. I'm hoping, to be able to, schedule some, more, later this summer, maybe in the fall as well. We'll see. just, have fun, play more golf, play more hockey, and, have fun doing multi full time or part-time, but like full-time, part-time was full-time. Yeah. Awesome. I wish you a lot of good luck with this and thank you so much for the interview. Thanks for having me.