Anyone Can Hack APIs: A Crash Course For Pentesters And Bug Bounty Hunters

Thanks everybody for coming. Um, just a heads up, I've had a cough for a couple of weeks, so I'm not infectious anymore, but apologies for the coughing. So, I'll do my best not to cough directly into the mic. Um, this is our agenda today. So, we're going to go through it. So, I'm not going to talk about in too much detail. The talk is mostly around if you have done some pen testing, but maybe you're not an API specialist or if you're just starting um to attack APIs. hopefully you'll be able to take something away from today. Um, and I want to kind of focus a little bit more on the mindset and the traps people fall

into. And if you're a seasoned pentester, then hopefully there's at least one or two tidbits of information that um, uh, that you can take away from today. Even if it's just, um, you know, how good Postman is, rather than having 200 repeater tabs open in Burp Suite when you're trying to deal with APIs of one person is what I'm talking about. Um, very quickly, my name's Alex. Um, I did quite a bit of AppStack stuff in the past and then did some content creation stuff. Um, and now I'm at Integrity, so overseeing our hacker community there, um, at Integrity and it's, uh, it's been a lot of fun so far. Um, but you can connect with me on these things. Um, and

also today's labs, I've got a couple of demos for you. Um, I run a free CTF platform called bugforge.io. So, we have a nice small community. Um there's daily CTFs on there, but they're realistic full stack uh applications rather than, you know, 2005 PHP um and stuff that you don't really see so much these days. So um so yeah, feel free to to check that out as well. Um the beta key is in Discord, so you have to join the Discord server. Um so let's do Excuse me. So let's start very quickly um and get everybody up to speed on what APIs actually are and kind of what they aren't. Um, and I think the biggest

thing for APIs is that it's not a protocol. There's no there's guidelines, but there aren't necessarily rules. And um, when we're looking at things like REST APIs, um, we have like standard status codes and and things like this that return. A lot of people don't follow these rules. And so, um, that makes it quite fun to test. Um, but really when we talk about APIs, we're basically just saying that whenever we send a request, we get back structured data instead of a full page. Um, and usually we get back JSON. Um, and if you're unlucky, you might get back XML or have to deal with something else. Um, but yeah, pretty much um, uh, whenever

we get back structured data, um, it's really interesting to see because usually the back end of an application um, is mirrored by um, our API. So we can start to see what objects look like. We can see their structure. we can see what changes that are made to them um when we uh call an API or um try and see some logic. And so we actually get a ton of information just from from this. Um and if you've never seen an API before, just very quickly, excuse me, sorry about that. Um let's go into this one first. No, not that one. Uh hopefully you can all read that. Um it doesn't matter. You don't need to

read it yet. there. All right. So, when we curl um an API, we get something like curl localhost 3000 and I think we can do [snorts] uh if I can remember what one of the endpoints looks like. Let me see. Uh API facts random. So if we do API/facts/ random you can see that we get back some nice structured data. But if we um API uh API if we call uh something like a page so if we call localhost colon [snorts] 3000 and let's just do the API docs uh oh we get a redirect um we get like a full page structure. So, the content of this doesn't matter so much, but you can see the difference between

calling an API and calling um uh like a web page or an endpoint that's going to return a template or something like this. [clears throat] So, oh, let's take me back to the start. So, first up, APIs are chatty. um they're designed to give you uh a lot of information and when you load a page especially if you load like uh React front end you'll see dozens and dozens of API requests um coming and uh calls and then coming back and so background calls um polling um different APIs third parties uh and things like this and more calls basically means more attack surface which is good for us um so basically Basically, every time we see a request, this is

another place where logic can fail, authentication can fail, authorization can fail, um, validation can go wrong. And so the attack surface for APIs is really, really big. Um, I already mentioned this briefly, but APIs map really nicely to backend logic. Um and so things like users, orders, projects, um uh payments and things like this are all really well mapped and we can understand what's happening at the back end of an application just by calling an API endpoint. And then we see pretty much everywhere ids um so ids are almost everywhere within um API uh driven applications and also uh that also means idor is everywhere in APIdriven applications as well. Um but usually you'll also see CRUD style endpoints as

well. So create, read, update, delete, uh and things like this. Um and finally, they can be quite predictable. So we see a lot of consistent patterns. Um we see predictable versions. Uh so /v1/v2 um / beta for example. Um we see similar logic um used across lots of different endpoints and applications. Um and that means when we're attacking them, it's actually quite easy to automate and scale our attacks uh provided with using um the right tools. Um a lot of the time when you get a big collection of APIs and then you start trying to um find issues and you go through workflows, if you're testing kind of endpoint by endpoint, you probably won't find a lot

of things. But if you find groups of endpoints or workflows um for example you know add to car verify cart check out as a simple workflow um you're going to find issues when um applications move through different states and the nice thing about APIs is they're not meant to be able to see what happened before. Every API endpoint should be standalone but this isn't always the case. This isn't always followed. And so we can do things in different orders uh and do some crazy stuff. So access control is pretty much our biggest challenge. Um and this is because um we have every time a request comes in um we need to check for access control. And this is different to just

very briefly authentication. So au authentication is who you are. Access control is what you're allowed to do. Um and authorization is also the same as access control. So you check into a hotel, you give them your ID, you verify who you are. That's authentication. And then you get your room key and you go into your room and the pool and the gym and stuff like that. That's access control. Now, why is this? Um, I think it's because um something like this happens um probably not, but something like this happens when APIs come into existence. So, we've got our business requirements, and it's it's important to say here that like it's not the product owner's job to

decide who has access to what and what APIs have access to what data and how we structure objects within the back end of our application and and do all sorts of like uh horizontal and vertical access control. They're thinking about features. They want to deliver something. And then the same with the UX and uh the design team, they're thinking like what is the happy path? Um and they might design a path that is maybe from a design perspective inherently risky. Um and uh then the development team um takes that and then they have to implement it. But they're making a lot of different judgment calls. And if you ask lots of different people what sensitive data is and who should be

allowed to access what data, you're going to get lots of different answers. And then we have the other problems with like deadlines and um API code and um testing is like for QA um rather than um security testing and security testing is done but as we look to deliver APIs faster and faster and faster and faster. It's hard to keep up. Now five or six years ago when I was kind of like full-time doing ABSAC um I used to just tell everybody I'd be like where's your access control matrix? just document everything. And so just for fun, um, quick show of hands in the room, could we solve our access control issues with good documentation and good

communication? And you all know it's a trick question. That's why nobody's putting up their hands. Um, so my answer is have fun. Um, so these are microservices which obviously applications, but microservices use APIs to communicate. And this is uh this is Netflix. Uh, so this is Netflix's microservices. So trying to document access control across a very large codebase across hundreds thousands tens of thousand uh tens of thousands of APIs is basically impossible. So documentation isn't the key. I I think you should all have good documentation but um that isn't going to make IDOR or broken access control go away. So our first key attack um is broken access control. And then we're going to look at another key attack which is

probably my favorite one. mass assignment um uh afterwards. And so we have, excuse me, um horizontal versus uh vertical um privileges. And I'm just checking times quickly. We're good on time. Um horizontal access control. Um I'm a user. I can see my user data. If I can see another user's data, that's uh horizontal broken access control. Vertical is I'm a user. I can do admin stuff. um basically and I think one of the problems is is we have all of these dumb acronyms which don't translate across um normal application security across API security like there's no real reason we have IDORE baffler bola for example um Bola and IDOR are the same broken object level um uh authorization

um broken object level whatever it is um IDOR insecure direct object reference they're basically basically the same ambroken function level authorization. So the main difference is if you can read something it's idle or bola. Um if you can do something like I can access uh an admin function or I can update another user's password. It's baffler broken function level authorization. It's all just broken access control. It doesn't actually matter. We don't need to kind of like break it down into these subcategories. That's just my opinion anyway. There probably is a place for this but um just not for me. I'm too old for this. Um, so let's take a quick look at a lab and I'm going to walk you through kind

of like, you know, a nice simple attack, but then we're actually going to hit a wall and um I'll be interested to see um how many people think we should report, shouldn't report, try to um um upgrade our attack uh and things like this. Let me just come out of here. Um [clears throat] I think it's this one.

All right. Sorry. Two seconds and then uh you can all ask me later while why why I'm using Kaido and not Burpuite and I have a good answer for you. It's cuz Burpuite doesn't play well with uh Arch Linux and I don't like troubleshooting JavaScript. Uh JavaScript uh Java, sorry. Um, all right. So, we have our application and I'm just going to sign in as Jeremy and Jeremy and then password like this. So, we take a look at our application and we come through and we click through everything. We create new snippets. We do different things and do all of this good stuff. And then we come back to our proxy and we see these

APIs. So hopefully you can kind of read that it says slappi/s snippets for example. Um and what's interesting is is eventually after walking through our entire application we get to the um profile endpoint and then we come back and then we can see that there's an ID on the end of this. But for a lot of you you'll recognize this as a yuyu ID. So we can't brute force this. But well we can't. I say can't. I'm sure somebody can. Um this is quite difficult to brute force but we should still check it for um idle. So, for example, if I come out of here and then come back out and then sign up again and

let's sign up as Alex. Alex alex alex.com password. And then we come to here and then all I'm going to do is let's use uh my current user uh Alex. And then I'm going to steal the um ID from Jeremy for example. So copy this replay. So you can see we send this and you get back Alex because that's me and then we pop in Jeremy's ID and then we get Jeremy's uh account. And interestingly we're leaking some sensitive information. So we're leaking the email. So hands up. Is this a valid finding? Who would report this? Ah, interesting. Okay, so on a pentest, I would report this as a weakness, not a vulnerability. Um because um we don't

have access to Jeremy's ID. So this is like a secret. But the problem is is that when we assume that an ID or some piece of information in a large application that has lots of APIs is secret and not all of the developers know that it's secret, it's going to be leaked somewhere. So in this case, if we report this uh as a bug, for example, on bug bounty, you're probably going to get a message back from the triager saying, "Hey, show us the impact." Because currently there is no impact because we can't guess this ID. But what I'd say to you is if you're new to bug bouncy or if you're new for pentesting, you have

something here. This is like the first step in in your attack. And what you should then do is you should come and continue to look at the application, find all of the endpoints, and we find this nice public snippets page which makes a call to oops / API/sippets/public. And here it leaks all of the user IDs. And so we can take the user ids from this public endpoints and then use them in our attack. And then we demonstrate the impact and then we get paid. Yay. Um and it's a probably a high finding in um in uh in our pentest. Not critical. The whole system's still fine, but we are leaking like sensitive data or customer

data for example like email addresses and things like this. So this is the first thing that I would say. Um when I was in APSAC um I was very much uh I would find something like this and I'd be like this is a major issue. It's only a major issue if there is impact. And nowadays I'm more like yeah if there is impact then it makes sense. Um, but it is in my opinion still a weakness and still something that should be fixed because even if we didn't have um these IDs being leaked um early on, at some point it's going to be leaked or there there's going to be a change. So that's our first main um kind of

attack out of the way. And that's that's our warm-up attack. Where were we? Um so whenever you find excuse me sorry um whenever you find uh broken access control um ask yourself all of these questions and this goes for any kind of weakness you find in a system um can we replicate it against another user is it impactful um can we do things now that we know that the endpoint is uh vulnerable to IDOR or bola can we update that uh objects instead of just viewing the profile data can we just change our HTTP verb to put. Um, can we delete that object? Um, can we change its state? So, for example, um, can we change things from

unpublished to published or private to public? Um, is there a confusion between the roles and ownerships? And when we access it, does the system think we own this data? Because the user object, our user object, we own that, but we may have permissions to other objects. Um, and depending on how the uh application interprets that, we can sometimes do crazy things. And then whenever you find a bug or vulnerability in an app, it's probably a prevalent issue. And I see this a lot um when I talk to um uh pentesters and and bug hunters. If you find it somewhere, you're going to find it in lots of other places as well. So this is something you should always keep

in mind. Um so let's talk about mass assignment. and then some water. So, um maybe a quick hands up. Who's seen mass assignment before? Not too many. Okay, this is my definitely one of my favorite vulnerabilities. And um it's a feature. Um and back when I was kind of doing apps stuff um I actually wrote quite a lot of code that was basically vulnerable to this because I like to cut corners and I like my application to do the heavy lifting for me. And uh you'll see why in a second. But this is a finding across many of my applications uh in the past. If you look at my old GitHub repos, you'll find out.

So the point here is that we're automatically um binding input to a new object. Um and since I'm doing stuff in node at the moment, we have the node spread operator. So our request comes in and we're basically saying, hey, my first name is Jeremy, my middle name is uh Jackson, and my last name is Jones. And with one line of code, we can create a user object with those inputs. And hopefully what we've also done is when we're creating that object, we've set defaults for the things that are missing. Now this one line of code is basically saying regardless of what we send, it's going into this new object and this is how we can abuse it. So for example, if

we create another user and the first name is Jesse Jameson Johnson. Confusing names, I don't know why I use them. Um, but also admin true. This is going to create a new user object and it's automatically going to take our um input and then pass it into an object. And this is a feature of many frameworks. And I don't blame them because sometimes we're working with objects that have thousands of properties or thousands of um uh fields in them. um and there's no practical way to sit there and write out the logic of taking uh fields one by one and then um building our object around it. So doing this in an automatic way makes complete sense but does open up

applications to attacks. [snorts] And I found a very similar issue um in a prominent wine application um a few years ago. Uh and I don't think they've fixed it yet, but um that was an interesting one because um they had all sorts of different roles um with different keywords um and I had to use like AI to like figure out what the keywords are and for it and then eventually found it. But um I did a talk in Portugal. It's somewhere on YouTube if you want to see that one. So, let's take a look at mass assignments. Oops, wrong key. And this is my favorite lab actually. Uh,

[cough and clears throat] all right. So, let's just refresh this. And here we have my [clears throat] favorite app because who doesn't love otterters and this is Instagram for otter. Uh and that's it. So um so here we have uh we can sign up and we can like posts and you can add comments and things and you can go to your profile and and and change things. Um what's interesting is is when we come and we take a look at the APIs and we look at API register we don't really get any clue that this is vulnerable to mass assignment. We have no information here that says hey you know um you might be given a default

role or uh your user object might not look something different to uh a randomly generated ID, username, email, password, full name. But what we can do is we can look at different parts of the application. Um, we can look in the front- end code. Uh, we can look in the JSON web token claims. Um, or we can look at our profile. So, for example, if I go to API/profile/jeremy, you can see that we do indeed have a user role here. And once again, this API endpoint is giving us the full structure and all of the data that's being held in the back of the application. And then we can use this information to basically pull off attacks. And this would be if

this was something like a little bit awkward like um user roll is super like I'm probably never going to be able to fuzz that. I mean yeah it's technically possible but um it's probably not going to happen. But when we're working with APIdriven applications we often get um insights into what's happening in the back end. This is also very easy with code review. So if it's open source you can find stuff like this quite easily. But we don't always have access to source code. So if we send a registration request back to replay and then let's say we add something like ro is admin and again in the real world you're probably have to going to uh probably

going to have to do some fuzzing. Um and let's just change this to Jeremy 1. Jeremy 1. [clears throat] Send this. Uh, we get okay. Come back to here. Let's sign out of Jeremy. Jeremy one password. And then down here we have access to the admin panel. So this is a way that we can use mass assignments and the autobinding of our inputs into objects to impact the application. And there are actually quite a lot of um cases of this where um you can do crazy things with like discount tokens or like um uh uh what they like coupon codes and and things like this where you basically get a similar behavior. But the easiest

one to kind of imagine is is is privilege escalation. All right. [snorts]

So, um I think as I mentioned, so this is important for API specifically because they're set up to expect and process objects um rather than specific fields. So in a more traditional web application, if you're working um with let's say you're working with PHP without like a framework um like Laravel for example, you might sit and process um every single um input and be like this is how this works and then you get an output. Um but with our APIs um maybe they're shared across mobile apps and web apps and internal apps and they need to be able to deal with all sorts of different uh data coming in. And so um that's why things like mass assignments

um works um particularly well in APIdriven applications um frameworks um pretty much like Ruby on Rails supports um uh I think it's called like autopop populate or populace there'll be a Ruby dev in the in the room who knows exactly what it's called. Um there's a bunch of different um uh names for it, but basically I just I'm just like yeah, the spread operator in node um with the automatic assignment. Um every framework has this um functionality. Now [snorts] so threat modeling, uh, threat modeling is something that we used to talk about a lot, or at least I did, um, five, six years ago when I was full-time ABSAC. Um, threat modeling is actually something you do as a pentester all the

time. You just don't obviously like subconsciously, you do it subconsciously. You don't um, actively think about it all the time. And this is kind of some advice that uh somebody gave to me when I started doing bug bouncy is that you need to actively threat model all the time. Whenever you see something, you need to think about okay what um what do you have? What could potentially go wrong? And I have some nice simple examples here. So for example, any endpoint that makes a call to the database, we should be testing for injection. Whether it be SQL injection, NoSQL injection, we can test for type confusion, etc. That's you threat modeling. Um, and I think when

you're hunting for bugs or when you're trying to go deep or find something critical rather than just following a checklist, you know, cuz some pentest checklists and some pentests are I want to find something really serious. If you want to find something really serious, you need to actively threat model all the time. And every time you get new information, you need to re-evaluate your threat model. And consciously thinking about this um is going to really really help you. Um same with an endpoint with um object ids and authentication, excuse me. Um we test for idle, bola, broken function level authorization, etc. So the things that we saw in our first lab and then also um endpoints that um move

money, credits or privileges, apply um discounts or refunds um and things like this. Um, we want to test for things like race conditions, broken logic, missing rate limits, doing things out of order, uh, and stuff like that. There's not really like any point in testing, for example, um, trying to think of a of a good example, but I'm probably going to think of something dumb. So, um, can't think of one off the top of my head, but try and target your attacks to what information you have uh, in front of you. And then hidden attack surface. So this is something that also me as a pen tester was terrible at. I usually got given a scope. Um often I'll get given

source code. Um and then I'd be like, "Hey, this is what we want to test. No recon required." And then after years and years and years and then I started to look at things like bug bounty. I was like, "Oh, where where is everything? What what's this subdomain doing here? Like I have to fuzz for subdomains. Ah, Cloudflare has blocked me. What do I do now?" Um, I ran into all sorts of um, recon issues and I still am terrible at recon. I'm not known for it at all. But with APIs, like I said before, um, APIs are pretty predictable. So, we see a lot of like v1, v2, um, and then when you're fuzzing, as soon as you see an endpoints

with like slash ID, for example, you then need to think about, okay, can we fuzz after that ID? Is there something there? um for example and then reading documentation is really really important but comparing the front end calls to what the documentation says um and then scouring the front end um so for example even if we just flip back to um autogram really really quickly um and just come into where are we where do I want to We don't want to be in storage. Uh I usually do this in Chrome. So if we come into here and then come in and then we come into our source and then our components and then our admin.

This isn't compiled. It's not built. It's just running as the dev, but even still the um endpoints will still be in clear text. So this basically works. Um there are tools that do this, but you can sit and scour for um interesting endpoints from the front end as well and then compare that to the documentation. Are there endpoints in your front end application that are not covered in the backend application as well? And it's really easy to basically just GP for that. Um I don't know why it keeps going back to the start. You can tell I don't use PowerPoint a lot. Um so yeah, fuzzing JS link is pretty good. inql if you're using GraphQL is pretty nice. Um I don't

attack GraphQL all that often, but um if you want some interesting tips, I'll be at the bot later, happy to spill my GraphQL secrets. Um I don't think there's anything that I do with GraphQL that's not probably already in the public domain, but if you want to talk about it, um happy to talk about it. Now, um, as I was talking about earlier, uh, in my opinion, Burp Suite and Kaido are not very good for APIs. Um, there's too many repeater tabs. Um, going through workflows and multi-step sequences across multiple repeater tabs where you have to go backwards and forwards and then you have to keep copying and pasting tokens and changing things and and like I it's just honestly

it's it's horrible. Imagine if you've got 100 APIs and you want to test them to see whether your JSON web token is valid and you make one change to your JSON web token. You then have to send 100 requests. I mean, come on, who has time to do that? You could spend the day writing a script that does everything for you, but that script only works one time. Uh it's not really like scalable across your workflow. So my one of my big takeaways today is that um as pentesters in the community, we do not use Postman or Postman like tools often enough. If you have a big collection of APIs or if you're going to test

something for more than one week, you should be setting up um your whole collection in Postman and you can do some crazy scripting and it's so easy to retest. And if you're a bug bounty hunter and that um application is receiving all those APIs are receiving updates um you just press one button and it retests everything and then you don't have to go and retest spend two days retesting everything that you've already just done. Um so my biggest thing is that I don't think we use um automated or more advanced scriptable tools um as uh security people as often as we should. Um, Postman does have a bit of a learning curve. Um, but it's, you know,

if if you're in pentesting, it's not that big of a learning curve um, at all. That's not to say Burpu and Kaido aren't great. They are, they're really good tools. They're not set up for dealing with APIs. And there are some plugins and things that, you know, make life easier, but it's honestly it's like it's like going from jogging to a car. It's just night and day difference. Um, how am I doing for time? Oh, we're okay. And we'll have a bit of time for Q&A at the end as well if you want. Um, so scanners don't understand ownership and roles. And this is one of the best things that um I think I've found is

that like logic and um uh uh flaws in workflows and multi-step sequences. Um, scanners are not very good at finding these. So you should be prioritizing these uh as much as possible when it comes to um attacking actually any application and not just um APIs. Prioritize the stuff that you know takes some thought and and things like this. So this is something that's really really important and a lot of people say like yeah okay AI also helps but um for example if we um use an AI powered scanner and it finds um our ID door from earlier it's probably not going to go and find um uh the leaked um IDs from earlier and then put it in and then give like a

meaningful result uh for example. So, it misses out these things and it doesn't do very well on the criticality or or the impact. Um, that's not to say scanners aren't good. I think they have their place, but as pentesters, um, you know, this is, um, something that we should be aware of. Now, if you're just starting out, if you're a seasoned pentester, you probably these slides aren't going to be very useful for you. But if you're just starting out, um when I was teaching a lot and mentoring a lot of people, I find it much more effective to basically give them questions to answer. And so, if you're just starting doing bug bounty or if you're just doing um just started

doing pen testing, um try and answer these questions. Don't focus on finding um something impactful that will come. when you answer all of these questions and you test thoroughly, it's part of like you've got to go through the process. Sometimes you get lucky. Um but but yeah, um I would say what are you looking at? Always try and fill this in as much as possible. Create yourself a notion template and then put the questions in and then just type everything in. Um, and you'll start to see that once you start writing things down, let's say you're like, "Ah, it has MongoDB." And then I found this Idor, but then it's not leaking tokens, but actually you start digging and because

you've written down that it's MongoDB, you see that there's some blog post somewhere and the um automatic ID. It's like a time stamp plus a bunch of other things and it's not actually that difficult to brute force. And so you're like ah now I found like a vulnerability just because I paid attention to the fact that the back end is using MongoDB and not MySQL progress etc. So all of these things kind of come together when you're actually testing um mapping the text surface. So just basic steps scouring the front end. I think a lot of people don't look at front-end code enough. I think that holds a lot of secrets um and also holds

a lot of intentions behind things. And you'll also find um assumptions there. And you'll find that front-end controls don't map backend controls. Obviously, front end security controls are not really a thing cuz you know we use proxy. But um you'll see that uh you might see some front end uh escaping. And then you'll be like, okay, is this exactly the same in the back end? And if it is, you're like, cool, now I have the backend code and I know how to um uh bypass it or figure out a bypass. Or you'll be like, no, it's different. And now we can bypass it because um between the two of them they've been doing a good job but not once somebody starts to

scratch below uh below the surface. Excuse me. Um so fuzzing and documenting every endpoint um is also um really really useful. You'll always find like little random endpoints that help you out at some point or another. Um, like I said before, prioritizing based on your threat model or your preferred attacks or checklist. Now, again, if you're a pentester, you probably have a checklist. You probably need to check a bunch of things. If you're a bug bounty hunter, do what you like and do what gets you out of bed in the morning. Um, you know, the world is your oyster. Um, but I would always still say prioritize based on your threat model. So, um you want to find

good findings for your clients. Even if you have a checklist of things to check because maybe you're just doing um a pen test because of compliance reasons, you still want to find cool stuff um for your client. You still want to add value um and you still want to find things that um make them come back and do do more testing. Um I would say check individual endpoints but honestly um most of the time beyond scanning um I don't really look at individual endpoints anymore. Um I always try and look at workflows. Um so looking at um uh registration, login, email, validation workflows for example, adding to cart, checking out, payment workflows for example, anything where there's a

sequence where the application expects something to have happened before or the API, you need to hit them in a certain order. This is where you're going to find bugs and this is where you're going to find a lot of race conditions and and other issues like this as well. So there's loads of interesting stuff that happens in multi-step sequences because doing like designing edge cases and building applications for to handle every edge case in a multi-step sequence is hard work. It's really really hard work and in you know one update breaks everything. So and then of course yeah finding edge cases. So documenting what security controls exist um is really really important. The first thing about

bypassing stuff is documenting it. Um, and usually once I've written something down and gone and made a cup of tea and come back, I've been like, "Ah, actually, yeah, maybe you can do this or you can do that or you find some different thing." Um, if you just try something and it doesn't work and you don't document it, you're not going to find interesting findings. And then [snorts] I [clears throat] have a um uh an old document called tricks. And so one of my um favorite findings and one of my top tricks is whenever I see an application take JSON, I send it XML and don't forget to update the content type header. Uh otherwise it won't accept it.

And then [snorts] do the same every time a application takes XML, feed it some JSON and don't forget to update the content type header cuz a lot of frameworks uh and a lot of um applications will actually process this in a normal way and developers might not even know that it processes. Okay. And then you might open up a whole new attack surface just from utilizing um this automatic ingestion of um different content types. No other tester has probably looked at it. Um so this is probably like one of my favorite tricks. Doesn't like doesn't work that often, but when it does work, it's like it's so good. Um so, but again, this is kind of

like attacking behavior, not attacking um you know um uh a specific vulnerability, for example. And then briefly, so the modern API landscape, uh, complexity is increasing a lot and APIs were exploding in volume and now they're exploding more because of vibe coding, which is great. It's going to keep all of the apps stack engineers in a job for years to come, which is lovely. Um, REST APIs still dominate the landscape. Um, but what I would say is I'm seeing more and more applications where the base application is rest but then they have some specific functionality that's using GraphQL or sockets something like this. Um, and that's because again with vibe coding with AI as a developer um

suddenly um I can throw sockets into my application without really even needing to learn how sockets work and get like notifications and fancy toast messages working pretty much overnight. So even talented developers who have never touched sockets or um or GraphQL or something like that can then go and implement these things. And so we're seeing a lot of people like expand their repertoire basically of what they're implementing. Um but I still say that REST um is a guideline like reading the rules of REST is quite useful because then you know what assumptions a lot of people are making and then you can just break the assumptions because they're not enforced. Rest is not a protocol.

It's just a set of rules that it's like the pirate code. It's like, you know, you kind of, you know, follow it when you want. Um uh kind of thing. Um using AI. I didn't want to talk a lot about AI because uh everybody's talking about it and I'm kind of like um a medium dabbler, I suppose. Like I use AI tools and and um I quite like Claude. It does some uh nice scripting for me, especially for front- end code. Um but uh one of my big use cases is um AI for generating word lists. So, if you're against an application, and I I think I briefly mentioned this, the the wine application that I found mass assignment

on previously, um I would never have found the keyword that um escalated my privileges without being like, "Hey, what's like um different types of wine connoisseurs called and then in that list was like I think it was Sumeia, Somalia. I'm not sure how to say it, but that was basically the word that that gave me the extra privileges." Um I did um also use AI before. So I was against a target. I found out who the main developer was. They had a prominent GitHub repository. Um and then I basically did source code analysis on all of their public repos and found similar issues in the main application that was on their open source projects. Um and a very fast way to do that is um

you know either use a SAS tool or use AI to be like hey I pulled in this codebase. What are some of the quirks weaknesses? I would say if you look for weaknesses within our codebase um you're probably going to get better results rather than being like where can I find SQL injection um because a seasoned developer probably doesn't have SQL injection uh in their codebase they're probably using prepared statements um but looking for weaknesses and then assuming that they've followed the same code patterns in their uh day-to-day job um can lead to some interesting findings and then troubleshooting error messages. So, if you're working on a tech stack that you don't fully know, um, or

identifying a tech stack, AI is really good at recognizing error messages and explaining them. So, I use this pretty much all the time. Um, sorry, Stack Overflow. I haven't been to Stack Overflow in like 2 years now, so you know, too bad. Um, and then payload manipulation. So, um, if you want to test some variants or edge cases and you're not sure how to, um, change them, um, AI is pretty good at making variants of payloads if you give it a bunch of payloads. Um, excuse me. So, some advice I can give, try not to think about endpoints so much. You, if you're pentesting, you have to check out endpoints because you've got a list of things to do and

sometimes you'll hit some lowhanging fruit. Sometimes you get lucky. But um think about the objects uh that get returned by endpoints and what comes back. Um I would say if you're just starting out um build your own APIs, build like you know five or 10 API end points that do something interesting and then also expand on it because your behavior of your API targets is going to change based on the architecture. So is it a microservices application? Is there an API gateway? Um how is authentication handled? How is authorization handled? um is it done discreetly across lots of different places or is there like a solid middleware all of these things um it sounds really confusing when you say

it like that because it is but once you start building stuff you start recognizing the behavior and then you're like I probably does this and then that's going to help you guide your threat models and testing and things like this now I say get comfortable without using um a client as well so get used to using Postman Suite Kaido whatever it is you use curl um I like curl a lot I I think the dev tools within web browsers are kind of underused as well. So um you can do a lot of cool stuff um just from poking around in the dev tools and the front end source code. Um some stuff you should check out. I

didn't want to put like loads of resources. Um just because there's like so much good stuff out there and it just depends on what you like. Um the asset note word lists. If you're fuzzing for API endpoints, I would say this is definitely the best word list. Uh the only caveat is is once you find uh a root and then it's like you've got slash something sl something an ID or or or something that's changeable, you then need to start generating what the next part of that might look like as well. So don't stop with just the word list. Generating your own word lists uh dynamically is also an important skill to have. And if you're doing bug bounty

hunting, you'll find interesting cool things um like that as well. Um the like I could be like Portzswer Academy is great obviously is like amazing. Um but the academy from Postman is also really good and very API focused and if you want to be able to um uh attack things and automate things and do testing at scale um or over a long period of time, I would say that this is definitely worth checking out. Um and then API University does some good stuff. I've got a course on API hacking. Um, if you liked the labs today, like the mass assignment and stuff, that's the kind of stuff that's in my course, so check it out if you like it. A lot of

it's on YouTube, so it's free. Um, and read a write up every day. Something that I started doing like maybe 18 months ago. Um, I started reading Pentest Land and then I moved on to um, uh, something else. I can't remember what it was, but now I'm using Bug Bounty daily and I read an article every single day. And honestly, the the return on investment just from 10 minutes of reading. Sometimes it takes you longer cuz you have to do some like googling, but um [clears throat] the return on investment just from reading one article every day is is crazy. You recognize so many more things when you're testing. And like I say, we have

a nice small community um on Bug Forge.io. If you want to come and join us, um feel free. And I think that is everything. So, thank you very much. These are my two cats. They say thank you. Um, and yeah, that's it.