Empowering Junior Testers: Strategies For Uncovering Critical Vulns In Web Applications

hi everyone thanks for coming welcome to Red TR and welcome to my talk on empowering Junior testers strategies for uncovering critical vulnerabilities web applications so before I begin I'm going to keep looking over here first of all because it's where my notes are so I apologize if that looks strange with camera away on us um a little bit of motivation first for why I even I'm here today why I want to talk about this particular topic throughout my career as my journ becoming a penetration tester I have always struggled massively with imposter syndrome I started in the University of Plymouth and quickly found a job at aage 24 as a cybercity engineer and I quickly found out that pentesting

even existed as a role and I was pretty excited to get started with that but I felt like I would never ever ever be qualified to do that kind of role eventually after a bit of training and self-development I did find myself doing application security pesting at4 and then I found out that all of my colleagues were really really good and I just started and that was terrible and eventually the company let me actually test Real World customer applications and I thought yes I finally proved to myself I can do this and then I realized that everyone else around me was reporting these huge Crystal findings and I was reporting user ination by passor reset for the 60th time today so

I decided that if I wanted to really be a pentester and prove to myself that I would be good at this job I did find some critical vulnerability something to really prove to myself more than anyone else that I have what it took and looking back on my my journey as a junior pentester I think I've realized that lots of people feel this way and it's not a unique experience to me maybe this journey to finding your first critical hner ability is actually Acquired and that by doing so you're quickly be a to prove to yourself that you have what takes and constantly find amazing findings just like my colleagues and I so off the back of that I thought

I'd talk a little bit about my experience as Junior tester take away from lessons learned from those tests that I did back in those days and then hopefully up the back of that fall some strategies that you guys can take away into your own testing and find some critical vulnerabilities so a little bit about me clouth University graduated 2020 straight into a 24 been ever since um cybercity engineer initially ended up doing applications stre pen testing and I'm now senior which is good fun but I'm still slightly worried about it and the hos syndrome is still there so hey onwards we're going to cover a couple of case studies today these are real case studies on real customers I can't name

um from my first two years as pentester then we're going to summarize some lessons learn out of that and hopefully we'll take away some strategies at the end we'll summarize so let's get on with the first case study a lesson in trying stupid stuff the application itself looks a little something like this and this was a customers instance of an API management tool basically developers could log into this application and from that they could read API documentation they could read um API keys that were stored in the application and they could interact with these apis via some kind of web console so it looked like a PR interesting Target because it had lots of critical sensitive data however as a

junior Tester the only kind of out I was allowed to test were things that had already passed through some much more experienced testers hands so they wouldn't miss anything and I would be left with an application and maybe I could report enumeration by passive reset again and I'd be moving on to the next app but I didn't want that to happen in this case in this case there was actually an endpoint that seemed interesting and that endpoint looked a little something like this this is clearly meant to return your profile deta details as a user and this was interesting to me because normally an application simply check your session cookie or something like that and say

here are your details but instead the application was passing in the big red box here some kind of horribly complicated user ID and I thought hey that's weird maybe if I take the user ID from a different user and put that in the URL I'll get some kind of insecure direct op reference and read some data I shouldn't have that didn't work 4 or3 forbidden straight away whatever I was very upset about that and just before I was about to move on from the test and complain to all my colleagues about how I can find medium risk on abilities I had one really silly idea I thought hey maybe I run brand minet here see what

happens for those of you who don't know brand minet is a tool from ports sger that basically guesses up to 65,000 different parameter names in a single request and if any of those uh parameters C the application respond differently it will give you a little issue that you can go and investigate and that's exactly what happened A New Hope a secret input in the URL called uid which immediately sounded kind a spicy so BR Miner was basically adding a second uid to the uh creery component of the quest and then adding some garbage data and the application responded with some interesting things first of all four or4 error and normally it would just be your profile details and an

error that specified user not so the question is does this new uid override our existing uid in the URL because we're actually still providing my valid user details in this request so I took another user ID and put it in that uid and kept my thees request exactly the same and I quickly got back the response containing a different users details so this is my first clue that I have some kind of Access Control Bypass on my hat this special uuid frer that was hidden the param L I found is overriding the uid in url however if any of you have done any kind of testing before you'll know that this kind of user ID is not exactly

predictable I as an attacker can't guess that and then Harvest all the information for all the other users on the application because it's way too complicated the user ID of that length is going to take hundreds of thousands if not billions of requests so at most I have really high access complexity access control issue which is maybe a low medium risk not a however I kind of wanted to solve that limitation I thought maybe just maybe there's a user added to this application that doesn't have some kind of complex user ID there's no reason for me to think this it's a really stupid idea but I thought maybe there's like a default admin or a default user who just has a u

ID I don't know maybe one oh there is a user ID with one the administrative user has your ID so now I have a real access control issue with a predictable exploit I can just add question mark uid equals 1 that is actually the entire explo the rest of the presentation by the way to any end point and suddenly I'm an administrator in some sense now I thought okay all I'm getting so far is the app Emil that's not very fun but maybe I can use it somewhere else the obvious choice for me at that time was update user right maybe I can change the email and lock them out of the account that didn't work the accounts were were

links to Office 365 um and the email was basically a placeholder more like a username or think it did nothing else just changed some text on their profile which is bad but not in any way I could also change their password but only if I knew their existing password which is as access control issue that you can almost never exploit so I thought anywhere else in the application no because those apis that I can interact with all had other unpredictable IDs that I couldn't use so I sat there for a bit made myself very sad and thought well maybe I can report a slightly better access control issue now I can edit some data and be some

data Maybe This is looking at kind of medium at 6.5 on cpss or something like that not the end of the world better than my usual finds at that point but then just before I report the vulnerability I had another idea or rather actually I just remembered something didn't I get some API documentation with this yes I did the API documentation contained a generate single sign on URL that was completely unlink from the rest of the application for those of you who don't know a sing sign on URL is basically a one-time login token that you can paste into a browser and it allows you to log in as the user without knowing their password

that might sound a bit insecure but it's usually so that on your laptop you can generate this link send it to your phone and then you can log in without having to type a tiny keyboard or something like that and obviously it's only meant to generate a single sign on URL for your own user but I have the power of question mark uid equals 1 so I added uid equals 1 to the Genera sign on URL and ended up with a single sign on token for some kind of user which I was hoping was the adventive user when I pasted that into browser I ended up on this page which doesn't look like much but

this admin user had access to every single us on the application with full rebr delete grate abilities or frud operations I should say I had access to every single API sted in the application including interacting with those apis and their API keys and finally in the horribly drawn Red Box on the left I had access to the application's content management system so I could edit any page I could delete any page I could add my own Pages host malicious content I basically at this point owned the entire application which is pretty critical so I brought that to the customer and I was very happy with myself though actually I still had a few more mistakes to make

along this journey which led to a series of very fortunate EVS in December of 2022 I reported this which is actually my first ever critical finding to the customer and I was really pleased to myself I've proven to myself I had What it Took even if it was ridiculously simple and provir basically guess work I got there in January of 2023 the customer reaches out to me and says we can't fix this we're going to contact the third party vendor which is pretty normal um customers often blame third party vendors for no reason and um I thought is pretty normal anyway about a week later I get an email from the third party vendor that basically said yeah

that's actually really is our fault we're sorry and that third party vendor turned out to be Microsoft turned out to be the cloud engineering team ATO and they said by the way we run a bug boun program if you're interested in reporting it there and maybe seeing if it works which pass at which point I realized the application I was testing was a customers instance of azir's API management software which means I had a good shot that may be my first bug Bounty along the way so in the middle of January I recreated the issue exactly as I did in the customers environment in a default instance of his Z and it was exactly the same way unbelievably s

reported it to Microsoft and in February following month they reported it by obviously removing support for the ID parameter if you bypass this you know amazing let me know how you did it I tried I failed at the end of January though I received the best email I've ever received in my career to date which was basically by adding U ID equals one to the end of the generated single sign on URL Microsoft are going to give you $10,000 which I almost missed because I didn't notice that I was testing ISU and not the customers application but lesson learned so off the back of this I have my first critical vulnerability an amount of money that I did not deserve

and some lessons to learn when I first entered this finding to the application security team at 24 the only lesson I can really come up with as a j tester was run it's pretty good maybe guess but looking back on it now I think there are several really important lessons we can take away from this first first and foremost being try that stupid idea I cannot stress this enough people skip the obvious stuff especially about testing maybe because it's all slightly obvious about testing I don't know but try that stupid idea you'd be surprised how often it actually works always refer back to your Discovery pH I know everyone always hars on about reading your AI documentation and I had read it

before the test I had learned that Endo existed but I forgot about it and I thought API documentation I'm not going to read that a second time but because I did I found the pathway to the goodex point so always refer back to the data you have especially before you're going to report an access to Control Bypass you need to full Tax Service don't see steps always ask yourself questions and iterate throughout the slides hopefully you can see my insane thought process of just guessing stupid things and then seeing if they work if you ask yourself silly questions and then just iterate The Next Step you'll find that you don't miss this break it down to logical steps

if you find the user ID that you think might be an idol see if it is okay if it isn't no problem maybe there's a user ID that's less complicated maybe your ID one equals Works in that case it does always iterate on a question until you're completely out of ideas including the studid on and finally always push for Maximum Impact show the customer how much this damage this pability D can do in their environment by pushing as hard as you can to push a finding from a small access control issue to a $10,000 B somehow right that's it for case number one case stud number two

let's try embracing some complexity it's not going to hurt too much but we'll see a little bit of a disclaimer this is a particularly complex topic called request mugling if you've never heard of it you may not understand what's going on for the next 20 minutes but that wor that's kind of the point I just want to highlight everyone that if you have no idea what's going on for the next few minutes we're still going to come back and learn some lessons and all I wanted to takeway is not to underestimate complex topics now at the time of this vulnerability that's exactly what we were doing at that was4 some new research had basically come out about

hb2 of best smuggling and we were really excited about that looking at that and going yeah let's go find of vulnerabilities about that and made all s for p to be 1.1 PR smuggling is old now it's not cool um vendors will have fixed it there's nothing to find you know whatever but since I wanted to find things that no one else was Finding and I wanted to find critical vulnerabilities to add some confidence to myself I kept looking for request htp1 on every single app I had as hard as I could and it failed for months but then I came across this application which was a login page because the customer didn't provide accounts before

the pentest started which never happens of course so after testing the username and password fields and finding the application wasn't vulnerable to anything I quickly found a version parameter which reflected some content but wasn't vulnerable to Cress scripting or template injection or anything fun so I was going to email the customer and say can I have some account please I can't test application but a tool called HTTP request Smuggler suddenly came back with ping saying hey maybe request smuggling and this is another tool from for by the way this as exciting as it sounds uh actually filled me with Dread because I knew quite a lot about hp2 request Ming but nothing about hp1 and I thought it

was going to be really complicated and I have no idea what I'm doing someone for help I have no you know I've only got a few days on this test I surely can't handle this right now who am I going to speak to and then I thought you know what screw it HP smuggling can be super critical I'm just going to learn it as I go what's the worst that can happen how can we confirm that we have press smuggling well this is where it gets a bit technical so in this particular case of profession mugling the front end and backend server um existed first of all for just the kind of architecture of the

application and if I send a request that looks a little bit like this on the left hand side the front end server you can see it's a HTP 1.0 request it contains a transfer encoding chunked and a Content length header these two headers basically represent the message lengths of requests heading to the service two different ways the transfer encoding should always be prioritized so the frontend server prioritizes the transfer encoding header and everything in yellow gets sent to the Mac end server so far so good the back end server however is a bit more strict with its request PK it says this request is 1.0 in 1.0 the transfer encoding chunks method didn't exist I'm going to ignore it fair enough

that's RFC comp when you do that however I've maliciously set the content length to four which ends just after the 43 the red 43 and then two new lines meaning four bites which leaves behind in the response or the request CU sorry something that looks suspiciously like a new HTTP request or a request prefix as we're going to refer to it and now we end up in this situation with the backend server is still in the content L it's responded to the previous request because it's read in data that it thought was there and it's left some data on the socket technical perspective and the content length is set 15 which is larger than xal y and the new zero

basically the backend server say hey where the rest is my data where is the rest of my data so when a new request comes along say a request from mool from some victim user rather than responding to that on its own that actually gets appended to our request prefix's body and interpreted as the same request by the backend server so the backend server then responds with the 404 and the person who sent this additional my profile request is confused if you're all still confused don't worry it gets much worse uh the next slide is a view from Bert repeater I'm going to send the exact explo I was just sending and you can see initially the application

responds with a 302 found and then randomly it starts going 44 which all that proves is that in my application you can see how it's excited because I'm waving my mouse around all that really proves is the application is actually responding to our prefixes they're kind of in front of the request in the que and that means that we can manipulate other people's request however because request smuggling is annoying this Behavior does not confirm request smuggling entirely you can see that in documentation that I form which is all forer the attack request and the normal request should be sent to the server using different network connections in this case the normal request by the way is just the

request that comes next in the que the attack request is the one that sends all complex data messages and stuff like that so there's a good reason for this and that's because front end and back ends have lots of different architectes the most common or what we usually see well actually not the most common but one of the options you can have is that every connection to the front end has its own connection to the back in which means that your request prefixes can only affect your own connection not very useful it's called a self desnc uh death Ram has an amazing talk on this by the way you go check it out there a little

link there which you can't see but I'll share the slides or something the second one is IP based desync where for performance reasons anyone on the same public IP says the same connection between the front end and the back end now my request prefixes end up on these cues meaning that they can actually affect other users on the same network or on the same um BPM for example and finally we have a completely open desync where the front end and back end prefer performance so much that rather than creating any new connections they just have one massive key live connection where all data from all over the Internet that tries to access the application goes the same height between

the front end and back end this is called keep connection and this is the scenario we had this is most critical because it means my request prefixes can hit anyone on the internet so with that in mind let's move on to actually building an exploit with press moding there's a big list from PS fig that you can try here and I tried bypassing front L security controls but the application didn't have any because of the login page I also uh tried reflecting exporting cross scripting findings and making them more impactful using smuggling but I couldn't do that because my reflected content wasn't one process scripting and I also tried making an open redirect happen which is

about the most dull you can make a finding in app open redirects everywhere I didn't want to report it as an open redirect so I ended up focusing in on capturing other users' requests which sounded pretty damn critical however after I dove into the documentation I quickly reached a blocker which is that to Capt other uses of requests you need a place to store them you need like a section on the application so when you refresh the page you get that data back now I did have that version parameter on the login page that reflected content but that really wasn't persistent storage as soon as you refresh the page it goes away so just before I was about to report this as an

onsite redirect to an open redirect using request muggling which is cool Pro of concept if you're technical but dull in terms of impact customer I decided screw it I'm going to do some research and make the I was not having it I'm sad that it's not working I that sorry so after four days of research this is a true story four days of research I finally came across a talk from Martin dard who now works at forer on response smuggling and in his uh research he had found that he could make request hijacking possible without assistant storage and with just reflected content and I thought hey I've got reflected content maybe I can do this but it also required something

called desynchronization which it turned out was actually another word for response Cube desynchronization now that sounds very confusing and it is we'll cover it in a second I actually knew a little bit about this because it had been released in the hp2 uh request modeling research and I thought hey that's pretty cool but I had assumed it only worked in http2 and not http1 however if you read the course the documentation very carefully it actually tells you that it's possible in both versions so I could have saved myself 4 days by just reading that page slightly better but hey let's see if we can make response to poisoning happen so that we can capture requests we have a

reflection Gadget now let's prove response CU poison so this is where my animations come into play I apologize they're all terrible I'm a pentester not an animator but it does explain it better than hat to be so so pretty the attacker sends a request to the frontend server and the front end server sends this time instead of a request prefix we're going to send one whole request and the reason call this is that we're hoping the backend will basically generate two responses to our SM request generating an extra response which causes something like this back and server sees two distinct requests these are whole requests and we'll see a bit more about that later so

generates two responses from a single request okay when these responses make it to the front- end server they're now in a que so well the front end just knows that one person sent a request so I'm going to respond to that one request with the next response in the queue so the attacker receives their response and now I have this yellow ball left over what happens to that it's okay don't guess let's look at a proof of concept of exploitation makes it a bit easier first the attacker sends the exploit to the front end server the front end server receives two responses from the backend server so since the attacker just sent a request the attacker

receives the attacker's response leaving the attacker's smuggled response the extra response generated in the front end Cube hopefully the victim comes across next and sends a request to the front end server their response is generated by the back end and added to the queue from the front end server so now when the victim's request is being handled by the front end server they receive the wrong response the attacker smug response the extra response okay pretty bad of course as an attacker if I time it right and send one more request I now receive the victim's response this is terrible news for HD applications because it basically means that you've caused a chain of Destruction where everyone starts

receiving the wrong responses in the application and you'll leak sensitive data all over the place to anyone on the internet trying to reach the application however there was a big limitation first of all you need a very high volume of traffic to make this work you need all the connections to be as consumed and for things to kind of go mad and I was in a preproduction environment by the way don't ever do this on the production environment customers will get very angry when you start dis synchronizing client data around um because it's so inconsistent you also don't know what kind of sensitive data you're going to get back if you want to capture a session token you need the

victim to be logging in as you trigger response to poisoning and hope that you're the one to get their log request and then it just end up magically logged in as the user which is cool but really unreliable unless you're want already have excite so I was going to combine this with our reflection Gadget as Martin said in his talk to make this more consistent so now we have a reflection Gadget and we've proven that response to poisoning actually works on the application and it did you just send one full request rather than request prefix and that behavior just all happens now that we have this we can look at the final expb I'm sure this all

makes total sense to do right it's okay I'm going to break this down again with some horribly drawn boxes the final xlo request uses two smuggled requests the first is the response to poisoning request which is going to trigger the same behavior just saw and the second is our reflection gadget on the login page and that is a request prefix that's why The Orange Box goes at the end of the request it's going to wait for more data so the blue box looks something like this it's a HTTP 1.0 request with the content link of four and a transfer coding set this will cause back and in front to disagree about this request being one request or three the response

C poisoning request is a Javascript file and it's one whole request and you can see that because the content length is set to three and the body is set to xal Y which is three Vibes of data right this will instantly generate a response on the back end through a big Javascript file and calls the response CU desynchronization finally we have the reflection Gadget which is a post to the login page and it has a massive content length of 10,000 which will hopefully be enough to make the backend wait for enough data from the victim's request that it gets appended to our version parameter reflected in the login page and then because of the response

desynchronization we'll have captured the victim's request y make sense no well don't worry the flow of this is even more complicated and has even more pretty boxes okay so again I'm not an animator I apologize for this the attacker is going to send their explo first this be just the front end serve as noral and then goes to the back end survey right after this happens the victim sends their request then the back end miss the Prest lengths and splits it into three distinct quests because the reflection Gadget is a prefix and is waiting for more data to arrive the victim's request actually gets appended to it see that it's one box now and just after that the

attacker has to send their followup request that gets added to the back end and then the back end can start responding to these requests the attacker sent no request first so the attacker response gets rooted to the attacker the victim's request was hopefully next so they get the random JavaScript CL that we smuggled to the back end they're like what the hell and the attacker who hopefully came in just at the right time finally receives what was meant to be the victim's response it is actually the reflection Gadget containing the victims request resulting in requested hty this is as simple as I can make it if it's still confusing don't worry you'll see how it looks on the next

slide again this is pretty unreliable it's very timing based the attacker requests have to have a victim request right in between and the timing is very sensitive so to make it a bit more reliable we're going to ramp it straight up to light speed using a tool called Telo Intruder again from volksen this is a very simple tool it takes a Hy to request of any format and spam it at the application as fast as it possibly can that's it it's a big gray box every new line in this gray box is HTP press export being sent to the application and that's what we're going to see I'm going to talk over this but if you just like watching terb do thing

just watch and try to breathe the tiny text I'm going to hit attack and then you're going to start seeing turbo Intruder spam the application with our exploit in a second I'm going to Halt this request and then look for 200 responses which are going to basically contain captured requests hopefully the first one I'm going to check here a little bit ahead of myself is actually going to contain our own request because the timing wasn't right we just captured our own request and you can see that here a search for exploit and the request body contains our export request failed but the next request I check does definitely contain the victim request and I can

tell this because it contains their access token which is what I use to authenticate as the victim so at this point the victim has just interacted with the application like as in visited the site or clicked a link and now I have stolen their session and I can completely take over their account pretty critical now one of the benefits of this kind of exploitation is that it's internet wide right I know it's an open desync so it will affect anyone trying to access application at this time that I was running the exploit including my colleagues I quickly noticed I was capturing access tokens for people that weren't me including my colleague or who said yes that is my access token he

didn't know I was doing this by the way I just sent him his access token and said is this yours I said um yes the point I'm trying to highlight here is that this affects anyone accessing the application simultaneously so if I just run this exploit for a day I will eventually capture the session to for every single user accessing the application from wherever they are on the internet okay resulting in an application wide account take over vulnerability that requires well user interaction in the sense they're using the application but basically no user interaction possibly the most physical finding I have to date by the way um so yeah a pretty powerful exploit very complicated some lessons off the back of

this run request mod maybe it's pretty good Big Stuff um it's only going to tell you that you have between a dis synchronization between the front and back end server so it will give you some Clues and then you can figure out rest on your own which as you can see is a little bit complicated it changes from time to time but um once you get the hang of it it's still pretty complicated question your assumptions and read the documentation carefully for a second time I almost missed out on a huge vulnerability four days of research could have been taken down to 5 minutes if I just realized that response to wor possible on hp2 connections and hp1

connections when you read documentation if you're really lazy like me control F search for security or notes and there'll be the bits that you didn't read and they tell you how to break applications search learn and improve don't rely on One Source my most of my exploits come from PS figure and things like that um and when they do there's still things that Miss from there so obviously use multiple sources but also even when you think you know loads of things about a topic still go away and do some research on the you could be surprised what you found I took me four days but eventually I found an exp that made this finding absolutely bonus in

termity always push for Maximum Impact it's actually okay to spend four days doing research I didn't get told off for doing that I didn't even get told off for not reading documentation in the first place okay if you're spending half your time pentesting using Google uh you're doing it right good job okay it's not a problem to be Googling all the time uh embrace it always push Max impact and finally Embrace complexity it really isn't going anywhere I now have a much better understanding of Hy to be profing and it still scares me and even though I have a good handle on that that kind of vulnerability I still don't know how to do a race condition I know what

the new tech looks like but I no idea where to find them or look for them or exploit them complexity complexity isn't going anywhere embrace it now and for the rest of your career you be wondering why is this still really difficult it just is is hard embrace it that's it for case studies let's try and quickly go through some strategies right so first of all strategy number one let automation complement your testing don't be afraid of it when I first started out post I was both told and myself felt the automation was very scary not reliable and um that I shouldn't use it because I crash applications and you definitely can if you run farx Buster on an

application which is just looking for URLs you can crash really really applications instantly but don't be afraid of it if you need to rate limit it if you learn it understand it use the Reliable Tools if you have to build it yourself because you're so distrusting other people go ahead and do that but do not ignore it you will be left behind okay we need automation these days especially for the size of the applications I have to test within five days these we these days it's ridiculous embrace it abandon scanning for vulnerabilities unfortunately we're way past the point of n return on vulnerability scanners being 100% accurate they're fine these days okay we've got some really good ones but

they're not going to spit out criticals every time they might occasionally split out a cross scripting vulnerability or a es injection vulnerability both of which are great 1% of the time you going to get one of those you can feel good about scam but if you abandon the idea of it actually spitting out probabilities and instead allow it to find Clues and bread coms that you as a human can put together and build an vulnerability you're going to have a much better uh success rate uh seriously use vulnerability scanners they are the best buzzers on the market and they can apply logic and you can just learn from their results and focus your testing on the weak areas that

vulnerability scaning can tell you about but not exploit by itself embrace the firsty potential pretty similar I see lots of people open fuff on their terminal and then start buzzing applications one parameter at a time and it takes them months to test an application use a vulnerability scanner on just that parameter it will test more payloads than you could ever have AAG and it has logic behind it that says if this doesn't work it's not vable that I'm going to move on once you have some Clues then you canol m and finally make testing stupid ideas quick and easy by running tools like Baran man and HP request mugler you can look for things that no one else is

looking for no one else is thinking I wonder if there's a hidden parameter here that bypasses accd controls why would you that's completely nonsensical why would the developers leave that in I don't know ask Microsoft but if you make it Easy by automating those tests you can just run them and then forget about them and if you get hit congratulations you're going to get a maybe there's no guarantees strategy number two try that stupid idea nothing is too obvious something I tell our new unit testers is if you find yourself thinking that's too obvious everyone's tried that try it anyway because everyone skips the B stuff and you'll be surprised how many fames I've gotten by just trying stupid

stuff and not thinking that's too obvious literally C yourself think that's obvious and go no I'm going to say anyway and You' be surprised how often that actually works Embrace simple thinking all I'm mean here is don't over complicate things break it down into the most logical steps you can if we're learning request smuggling take it one step at a time um and if you're learning to um break an ID because it's too complicated again take it one step at a time does a different user's ID work yes no does user ID one work yes no at least you checked right break it down and introduce stupid ideas into methodology if you don't check with

this stuff you're never going to find it so use automation put it at the beginning of your methodology check for it really early on and then forget about it and the one time it works you're going to be really happy strategy number three step back and reflect question your assumptions even if it means stating them out loud and I do this quite a lot question your assumptions again this comes back to my um mistake on hp2 versus hp1 and response poisoning but just your assumptions read the documentation a second time obviously perhaps but this time I want you to read it as an exlo development guide read it before you start testing the app so you

know what the app does and then half row through your testt when you've got a bunch of things that maybe you can work with reread the documentation and it will teach you how to break it that's what documentation is for if all else fails talk to the rubber duck if that doesn't make any sense you should look up rubber duck debugging basically talk to an inanimate object or a person who doesn't understand your issue they have to say nothing they can just be having a cup of tea it can be a parent the friend the grandma doesn't matter and just explain the issue as logically as you can out loud and you'll quickly realize you're an idiot and that you've made

some mistake with logic or assumptions and you'll be a to debug the issue you're probably going to see this a few times but check out the website it's awesome and they have links for that you Etc strategy number four Embrace complexity imposter syndrome is never going away has it gone away for me I don't know anyone who has ever managed to beat it in my team everyone still feels this way just embrace it and you'll feel much better about yourself if you're feeling totally out of your depth you're probably just about in the right place to learn that new technique that you're terrified of it worked for me with a press smuggling and it has

worked since then as well just Embrace that rock in your stomach to make if I'm not good enough and have all of it test the hard to test features complexity can come from the application just being very mean if it delays all your requests or there's web application viable or um there's loads of dynamic value you have to update set up a scanner that can use those things with some kind of session Rule and test the features that everyone else is too lazy to test with r pen testers and I think we're all really lazy so just test the hard to test features and You' be surprised that the critical vulnerabilities that you're hiding behind those students are just a

bit too difficult to scan and finally always push for Maximum Impact critical vulnerabilities are not found they are forged think about what is possible in the application how to exploit it will come naturally later off the back of that if you chain chain more things and then think about what else you can chain all those medium recommendations that you make to customers often can be chained together into pH abilities if you report proect scripting and a cookie missing P to be early or a cookie or a session token stored in local storage again one more time without also reporting that the cross scripting can be abused to steal that token I will lose my mind so always change your

vulnerabilities together a reflection on the login page that is not vulnerable to anything is useless it's not even worth reporting to the customer 99% of the time but if you have regress modling it suddenly enables you to capture users' requests so so it's worth keeping in mind All the Small Things you found and finally read research Miss and then repeat I know you're all staying up to date that's why you're here today that's really good but when you come across from an next CR request for finding and you think that's outdated I know what I'm doing go away and do a little bit more research on it now because you'd be surprised that what people are finding

now that bypass the same s restrictions as well as same it's kind of crazy so stay up the date and then stay up the gate a second time when you find a vulnerability that you think you understand to quickly recap let automation complement your testing try that stupid idea step back and reflect Embrace complexity and always push to Maximum Impact thank you very much don't forget to follow me on X that was my

box thank you brilliant talk we've got one minute if we've got any questions so perfect timing yeah one minute questions yes did you guys keep the bug bouncing from Microsoft or did that go no they have a policy you can keep it as long as you write a blog post about it which is on website along with my colleague's blog post on basically the same vulnerability but in H2 that we found literally a week after I found mine based on the same research um so yes we did I spend it on anything else all right thanks very much guys I really appreciate it thank you