house
[Music]
what the are you people doing here
I thought there'd be like five people at
my dog don't you know you're supposed to
be out drinking at this point you're
doing it wrong
oh you're okay this woman's doing it
right all right you're awesome did you
bring extra for everybody no ah
nice
um who's got the flask because I have
not had a drink yet
um so hi I'm Robert Wagner and we're
gonna be talking about hacking and
defending uh apis who is it my talk
earlier today
good nobody oh man now you're going to
be bored um no this will this will be a
bit different
um
so uh so just a quick introduction
Robert Wagner
um uh Mr minion on the twitters uh I'm
an advisory ciso but started off my
career as a third shift sock analyst
um for some financials in Chicago worked
my way through engineer and architect uh
I'm a co-founder of hack for kids which
is actually going to be here at the con
as well tomorrow we're going to have a
whole kids track set up upstairs
um you're not actually allowed in if you
don't have a kid so don't try and social
engineer your way into that because it's
in bad taste but we teach kids about
Internet safety security and ethics I'm
also on the board of my Issa chapter in
Chicago I love dogs motorcycles and
scuba as you can see from some of the
pictures in fact for 14 years I had this
dog right here who rode motorcycle with
me since he was about six months old he
passed what's that rocket yes that was
rocket thank you John
um
I'm also an honorary wolf pup dad so
down in Lafayette Indiana there's a wolf
Research Park and I actually got to be
wolf Daddy for a day as you can tell I
washed with bacon soap that day but
um uh that's that's me
um let's get a little bit about this
talk so this talk was actually a
collaboration with this guy Corey ball
Corey's amazing he wrote the first book
on hacking apis and this only came out
like a year ago and he is amazing at
what he does so professional pen tester
but he's billable so he couldn't be here
for this talk unfortunately
um he uh he and I uh were talking
together about how we could turn what he
had done into an interesting talk but
for us to collaborate we took a red
versus blue approach to it so he knows
how to hack into it my whole goal with
the blue side of this because I've been
blue team you know my whole career was
to see how many ways I could with
his attacks basically uh so that's what
this is going to be about
um Corey's actually set up a uh a
security training for apis as well at uh
what is it appy University
um so check that out that's free
um and uh and it's good content but
let's get into it so what we're going to
be doing is we're going to be walking
through the API top 10. um talking about
how Corey regularly breaks in two
systems uh via the apis or abuses the
apis for information and I'll be talking
about how I'd try to counter some of his
attacks
so let's get right into API one this is
the most prevalent uh API vulnerability
I guess we'd call it vulnerability out
there and buy a significant amount which
is why it's listed as uh as number one
on Oasis API top 10. and
it's it's not rocket science right so
when Corey goes and he tries to pen test
an API first thing he's going to do is
get an intercepting proxy like burp or
one of the others and he's just going to
enumerate he's going to look for all of
the API endpoints so that's your get
requests and post requests to those
various paths
um and then all he does is come around a
second time and sees what he can
with so can I get to resources that I
should not be able to get to if I simply
replace
um the get uh get API Resource One with
five instead of one and get access to
resources that normally wouldn't be
available and yeah that that's all it
takes to do this hack and it is the most
prevalent vulnerability out on the web
today
um and it is all over the place so
um so simply by basically fuzzing the
values really of a path he's able to
often get to resources that really he
shouldn't be able to get to as the user
that he's authenticated as
um gets and posts um uh are usually the
most common methods that he'll use
um to to try and get this and uh and
this is usually
um caused by the fact that once you're
authenticated to if you're authenticated
at all that's a whole other problem but
once you're authenticated
um a lot of systems will just simply let
you get to any resource without
authorization to that resource
so
um
by to defend against this uh
a lot of this is block and tackle it's
stuff we should know Security
Professionals already it's stuff we
should know after doing 20 years
of web app vulnerabilities you'd think
that this wouldn't exist but it's
the freaking wild west out there every
mistake we made in the web app space is
right back there in fact if you're just
getting into pen testing this is the
place to go you can be a freaking rock
star in two days just by going after
apis
um there's often bounties on hacker one
and some of the other Bounty programs so
not only can you be a rock so you can
get some side hustle money replacing one
with five oh my god so um so to
defend against this it's the same stuff
we've been talking about for God knows
how long
um create an access policy you should
have one at this point anyway
um design design access the same way
domain admins design access right you're
going to have groups and you're going to
put people in the groups and apply
authorization instead of access to those
groups to limit what a user can get
access to
um and then you're going to need to go
all the way down and make sure that that
access is based literally on the
attribute and then deny everything else
where have we heard deny everything else
but God damn it right this is firewall
all over again
um so just deny everything except what's
explicitly allowed and this will stop
most of these attacks right in their
tracks
um you this doesn't mean you can get
away with not having a Gateway though um
you still need a Gateway once you're
past the Gateway it's easy to uh to
implement Ebola attack but that doesn't
relieve you of the duty of putting one
in place you do still need to get one so
don't think that you can do without and
um and then there's plenty of guides on
this right oasp SVS has a guide and this
has a guide on proper implementation of
authorization which is all it takes to
stop this attack
great so broken authentication that's
like our Gateway stuff but too often we
don't even have authentication to the
API in the first place or it's some sort
of thing where the if the front
end though the web app itself will
pretend that you had to like do some
stuff but the moment you just try and
access the API you go on right on
through so
um that kind of uh lack of
authentication or weak authentication
and then other again we've known
forever people rolling their own off oh
my God it's like rolling your own
encryption don't do that there
are libraries out there that are mature
robust open source often so they've been
checked don't roll your own freaking off
for God's sakes
um and then even just stupid things like
really weak uh Json web tokens I mean
there's literally a setting for the
encryption on a JWT that is none so yeah
there's just nothing there at all
um so uh exposed private Keys you know
the the typical stupid user tricks that
were used do are also the bane of your
existence in this attack
again no no rocket science here right
um this is all about abusing
authentication flows and think about
your authentication flows and we're
talking about flows we have to think
about things like the I forgot my
password authentication flow could that
be abused by the API oftentimes it can
so you have to look out for that kind of
stuff as well
um Jesus Christ get multi-factor
already why are we still even thinking
about this it is probably the biggest
bang for your buck as far as security
goes it doesn't solve just this sin it
solves a billion sins get it deploy it
everywhere don't be stupid don't go oh
yeah we'll just give it to like the
admins and the execs that that doesn't
work
um attackers will usually find out who
doesn't require it and and they'll get
through uh so you got to deploy to
everybody and I'm I'm like even your
third party vendors anybody that touches
your should have to do multi-factor
authentication
um
don't roll your own off we've talked
about that
um and uh uh people will sometimes think
that oauth or something like that will
will prevent that it doesn't prevent
that the easiest way to check whether or
not you still have this issue is just
simply brute force and I mean it's
simple stupid brute forcing
um and you can launch any tool that
reinforces authentication and you can
totally check this on your own
uh excessive data exposure so
um so it's very easy in AP in API
vulnerabilities and talking about them
to blame Developers for doing lazy ass
like we're going to talk about here
it's not the developer's fault most of
the time they don't really know what
they're doing is a problem and the
second problem is is often they're just
copying whether it's a library or a cut
and paste of code whatever they don't
know that these type of problems exist
out there as infosec Professionals in
this space one if if you're working with
with the devs or devsecops your job is
to be an empathetic guide to show them
how their apis can be abused you should
see the first time a developer sees what
happens when you do some SQL injection
against his or her API
I didn't know you could oh my God
it's very eye-opening for them but
it also gets them on your side right you
show them a little bit about how their
apis can be abused and all of a sudden
they're a willing uh Ally in this in
this uh in this fight so um so anyway
with excessive day exposure it's dumbass
things like
um providing all of the information
about an account when maybe you know in
this example we're only asking for
um just the uh the account name right so
Cloud plus Strife Cloud plus Strife
might should come back and maybe what
the privilege level is but instead the
dev is set it up so that it returns
everything including the fact that
um there's a privilege for super admin
and this account might have it uh and
whether or not two-factor authentication
is even uh asked for so tons and tons of
Target information accessible uh another
great example was there was a um a
security app for uh security webcams and
when when the app was set up if uh if
you did it through the um through the
web app portal it would give you the
feed from the camera you asked for but
if you hit it up through the API and
just give you all of them it'd be like
yeah which one you know here here's all
the uh webcams just just pick one
um that's a problem with filtering
happening at the client side which again
we learned this with web apps I
don't know why we're dealing with this
again but it's going to come back and
haunt us in several of these
vulnerabilities
um so uh so defense against this so
watch those streams right
um oasp recommends not recline requiring
clients to filter data
we all know this right this is not
something new to us
um and yet apis are being sent up in the
same stupid way that we were setting up
web apps 25 years ago
um we should never ever allow the client
to be responsible for the security of
the data simple as that
um check for other things like
sequential IDs right because they're
easy to guess look for things where
um uh you this might even show up in the
logs sometimes where you know a uh if
you're seeing like an excessive amount
of data being returned for what looks
like simple requests you might be able
to pick it up there
um and then and again uh check um uh
apply a least privilege again uh it's um
it's just like any other data access as
far as that goes and uh and if you do
have pii that needs to become part of
that whole creating a policy around your
data
um and applying that policy so that the
devs know that this is pii data they
can't be exposing anything other than
what was requested and authorized to
deliver by the endpoint
uh so lack of resources and and rate
limiting uh this you this particular
attack usually amounts to some sort of
denial Service uh to the to the service
itself
um and it's important because a lot of
newer apps actually use rate limiting to
monetize the product itself right so
it'll only deliver you so much data over
a certain period of time or something
like that
um and of course if you can bypass that
rate limiting you can get tons of
resources for free and the company loses
money and then you get laid off not that
that would happen anytime soon right no
I'm sorry so this cuts into the business
aspect and um and by uh
preventing it from happening you're
actually helping the bottom line and I
would even look for like this if
you find it actually measure that and
show how much money you're saving the
company by preventing that from
happening once you've found the flaw uh
so a typical attack will be um basically
if if you can make a request like uh the
the one up here ending in 9001 uh What
uh Corey will do when he's trying to
abuse it is send you know set up just a
script or an automation that will just
make tons of requests and he'll even be
clever enough to watch for things like
if all of a sudden there's like maybe a
rate Limited at 100 he'll just set the
script to make 99 requests and then wait
a minute and then send 99 more requests
and 99 more requests and he's still able
to uh to abuse the um the API itself uh
sometimes even things as simple as case
switching so is that here in the exam no
so uh case switching he doesn't have
case switching but he's what he's doing
on this last example here is just using
a little bit of uh obfuscation
um to uh to call 9001 but then add a
little something else that the API is
just going to disregard and chop off and
he still gets his request through but
the rate limiting didn't actually kick
in
uh so uh defensive throttling is
definitely going to be your friend here
um reach out to the site reliability
people they know all about rate limiting
and they can be your best friends here
um there are multiple ways to enforce
rate limiting um even Docker has
built-in limiting functions so this is
easy to defend against it'll show up
again in your logs and we're going to
hear about logs a lot in this this is a
great place to look for it and it's as
simple as looking for standard deviation
and just about any logging tool these
days will easily allow you to apply
standard Dev math to the amount of logs
they're coming through so if all of a
sudden you're you know your your regular
API requests you know are hitting you
know this particular amount of data
being sent uh standard deviation of
maybe two or something like that should
pop that out really quickly
um and if you want uh if you want to
take it a little further if you want to
apply maybe some algorithms scipy or our
project are great places free places to
start applying some more advanced
algorithms to that log volume and speed
and frequency
so a broken function level authorization
or baffle very simple similar to uh to
Bola but instead of um uh privileged uh
access or authorization this is more
about privileged actions it's like being
able to do admin actions um make certain
requests or send certain commands that
you shouldn't be based on who you're
authorized in as so in Corey's example
here
you'll see a a valid request where he's
basically sending in you know
this little request here and uh just
basically asking for information based
on user A's token
the attack then will be him logging in
as user B replacing the token just
simple replacement with user A's and
seeing if he can still get that
information uh from the other user
so this uh this will uh while Bola
allows you to request info and about an
account
baffle is much more serious because it
would let you do things in a financial
app for instance like transfer money
that should you shouldn't be able to
transfer right you'd actually be able to
access user B's money as user a and make
a transfer then to another account so
much more serious ramifications if if
this one exists
um defending against it will be very
similar to our uh to our defenses uh in
in Bola uh basically we're we're looking
at um an imposter um attack right here
where you're pretending to be another
user simply by substituting a token and
um and again
enforcing access uh on the server side
is one of the best defenses against this
if you're allowing the client to enforce
your security someone's going to be able
to with that pretty easily uh logs
for the win again here
um every logging tool out there has the
the concept of a rare function when
applying it to the data so look for you
know pairs that just shouldn't have
happened
um user A's account will always be using
user AIDS token if you see a rare value
where user a has user B's token that'll
stand out like a sore thumb just by
applying the concept of rare to those
logs
um and uh if you uh you're not going to
prevent the attack obviously in that
point but you'll at least find out if
that kind of abuse is happening
all right how are we doing that time
good all right uh Mass assignment is
again
something that happens when devs are
trying to move fast and we can't blame
them for moving fast the pressure on
them is there all the time right get
product out get product up get product
out I would have hoped with cicd and
stuff like that though we'd be avoiding
some of these problems at least right
back when it was web apps one of the
problems we had it seems like
waterfall or something like that is that
by the time you found the vulnerability
in the app the dev was on to the next
project but at this point with cicd we
can actually bake a lot of these tests
right into their automated processes
there's so many things you can check for
simply by using Postman to see if uh if
many of these things exist so and and
then there's commercial tools out there
that will test for many of them as well
uh one of the things that won't is your
standard vulnerability scanner and we'll
talk about that in a bit but Mass
assignment basically
is again where you're allowing
um
things to be accessed through a a an
HTTP call
um through the request parameters
and make changes to variables and uh
this is going to cause some harm it's
usually found in the registration
process but it will be it again it's uh
the dev set this up to really be able to
quickly register an account or something
like that but what's happening is
they're not making any checks so if you
come in there and you uh you see that
the regular registration process lets
you register as user and you see that
you can just replace user with admin
it'll just let you because it was like
oh yeah okay I see you're trying to
create a new account and you said that
the parameter is admin and you're just
passing that parameter right through the
HTTP it's like okay yeah you're admin
that's cool
um the real problem we have here is that
it's often all over the place in in
development environments
so the easiest way to get rid of it is
to disable Mass assignment
fortunately that's if it's if it's been
going on for a long time you're going to
break a ton of apps
yeah so a lot of times you can't take
that chance with production on shutting
this down so you're gonna have to set up
a long ass project to weed them all out
one by one and what you're going to be
doing is you're going to be looking for
ways to actually restrict that and
change the way that variables get set
through the HTTP requests
it's going to take a long time start
with your most valuable apps first but
there's not an easy solution for this
one
you might be able to get away with some
checks at the Gateway that might allow
some of these attacks to be stopped but
this is this is not an easy one to solve
for if it's prevalent in the environment
so API seven
um this is this is basically the
security catch-all for all the stupid
that could go wrong and as we know
in just regular uh Network and app
security
something will always go wrong I mean if
it's something stupid like you forgot to
patch right so it's everything from
directory traversal which oh my God I
mean it's like we went back to 1998
right
um these are stupid things that we
should have learned to stop by now they
exist again in the API space
um but uh it's this and more so how do
we defend against anything that possibly
could go wrong right how do we defend
against Murphy's Law and it's by
focusing on being resilient right we we
have to be resilient we have to be ready
for forgetting to patch
something
um or uh or uh not uh not applying um
certain uh parameters or even
authorization to stuff things will
invariably go wrong
what matters here is how quickly you can
recover for from it and the way to
recover is to have change management we
all hate it but it's got to be there we
have to have policies in place
Frameworks in place and then enforce
those things and one by one knock them
out and when things do go bad make sure
that you have the right things in place
whether it's backups
um whether it's uh um and it's a
response team something that can handle
the things that will go wrong that will
it's the same stuff we've been dealing
with
all right yeah yeah is this up or
what injection is still a problem in
apis I mean we know it's a problem on
web apps but we've been getting a little
bit of traction right we've been getting
a little bit ways uh with showing web
app developers on how to stop that
the the problem is so prevalent it's
ridiculous it's like nobody taught this
new generation of developers that this
can happen and again sometimes all it
takes is just showing them what
injection looks like on their app and
how easy it is to inject against it
um so I I don't think I have to explain
to you how injection works right but um
but it's all over the place and it's not
just SQL injection
um it's xxs uh nosql injection the the
whole Suite of stupid
um and uh and yeah this this should not
still be the main of our existence it
absolutely is
um and the solutions for this are well
documented sanitize validate filter
that's how you prevent injection
um it's it's not rocket science
um it's it's not always easy sometimes
we can create libraries of of good code
for them to copy into functions and
stuff like that but even knowing when
and where they should use it is
sometimes not evident to developers so
you're going to have to train them and
you're going to have to test early and
often but this is easy check right
during build right when they commit the
code you can run a postman script
that'll check to see if injections
possible super easy to write
um and you can you can probably copy a
lot of the injections right from the the
web app injections that we've been doing
forever
uh so improper assets management this is
this is all about oh you know shamans
that uh you know keep everything that's
going on with the development in their
head and it's not been documented uh so
it's things like um uh the new API
version of an API like V3 gets released
there was a vulnerability in AP in
version one but it was never removed
from wherever it's being hosted so it's
still there and it's still attackable
nobody has blocked or turned off that
path or deleted the code so you can an
attacker can still perfectly leverage
the old API which is still responding to
all its requests
um uh so if um if they allow access to
those um uh unsupported versions uh the
the worst thing is is that a lot of this
is documented for the attackers writing
GitHub
um I don't know why we still have
problems getting developers to actually
comment in their code but they will put
in GitHub that says oh yeah this
version was broken it had this
vulnerability we fixed it and used
version two now so you can find a lot of
right out in GitHub
um to make for your recon to actually
find Targets um this way and and it
happens a lot uh so this comes back to
us knowing where our crown jewels are
right uh one of the first things and I
see this so often in organizations
um you have to document your apis and
it's still not getting done just like
just like with other code right the the
sad thing here again is there's
automated tool tools that will document
your apis this is not uh this is not
difficult at all
um you just load it up in the tool it'll
document what you need
um and uh and get everything ready for
you and that's useful too when you're
going to start creating gateways in
Postman and stuff like that so it should
be part of the policy that all API apps
are documented this way but it doesn't
get done
um if you don't I've even been places
where they're not the security team is
not even sure where all the apis are
they don't know if they know all of the
apis that exist now there's a great tool
out there called Kite Runner that will
help you enumerate them Katie Paxton
fear who is a awesome researcher in this
space has a whole tutorial on how to
write Kite Runner just to enumerate your
apis so at least you don't have you know
Rogue developers just publishing apis
all over the place that you don't know
about running that will at least find it
as long as you know where to run it I
mean if they're really doing some wild
ass and hosting their own stuff
that's going to be tougher but there's
ways there's ways to find out
um change control again we all love
Canadian control CI CD tools automate
the out of this
ah so what a surprise that API 10 is
just insufficient logging we that never
happens in regular security space right
the rest of it has just gotten so no
they have not
um so lack of uh logging and monitoring
is bad the sad thing again here is again
since so much of this is cloud hosted
the logging is right there I mean it's a
checkbox log the right and
yet we still see over and over again
people not logging their it's a log
of because if you don't I'm going
to come to where you work or where they
work or whoever works and I'm going to
make them walk all over the Legos in
this presentation barefoot
thank you thank you yeah log your
um so do be careful
um there is a danger of false negatives
uh I've heard many a time people were
like yeah well we ran nessus against it
and it didn't come up with any of those
web apps yeah because it's not a
web app
um so
um don't run uh qualis or nessus or any
of the standard vulnerability tools
you're not likely to get the results you
want in fact that's exactly what
happened to the USPS a few years ago you
can actually read this report that was
published
um but in the report itself it's like
hey yeah overall we did really good
there's there's like no vulnerabilities
here and how it was like a couple weeks
later it was up in Krebs that 60 million
users uh had their information exposed
um and and it was it was one it was uh
it was the uh the bowling one so once
you are authenticated uh usps's men even
know has an app now where you can see
what mail is coming to you right you can
log in and they've scanned your mail and
you can see what's coming well once you
authenticated you could put in any
address you wanted and get the the
information of whoever lived there and
if you lived in an apartment and you put
in the apartments dress you get the
information of every person that lived
in that apartment building yeah it would
just go yeah give me I'm here I'll
give it all to you no problem uh so
um uh let's see so yeah the standard
tools don't work really well here but
the cool thing is is that there's a
number of just like Juice Shop for web
apps there's a number of good vulnerable
eight apis out there and web goat and
some of those others that were for web
apps there's good ones for apis as well
so you can load up something like crappy
and run your vulnerability scanner
against it to if people aren't believing
you that that it's not going to help you
just launch that up there's some other
web hosted you run your phone scanner
against crappy and in most cases you
will get results like no vulnerabilities
and this this crappiest vulnerable as
hell I mean it's got all of the
vulnerabilities in in the top 10 except
for you know I don't know if they're
logging or not it's hard to tell but um
but the the majority of the phones are
there most scanners will come back with
negative results
um even burp Suite so burp Suite will
pick up uh on some stuff but it won't
pick up on everything unless you're
making custom checks
um so uh but there are API specific
tools a wasp zap is a very cool free one
um from from OAS folks and it will pick
up the majority of the the uh the
vulnerabilities
um the only one that's really tough and
it's it's kind of a combination of these
vulnerabilities is where it's a logic
problem and logic problems are the same
things like remember when in Amazon if
you like put in a negative number you'd
get like you you could get like free
or something like that it's it's
the same kind of business logic that
really requires a manual check but for
the um stuff in the OAS pop 10 uh OAS
zap does a good job there's uh another
one I think it's called stack Hawk I
don't think it's free but it's not very
expensive
um so get people who know how to do pen
testing how wait how much time do I have
it I mean I thought it was way at a time
all right sorry we talked so fast to
this because we're getting very close to
the end but
um but actually having someone who knows
how to abuse apis uh is really going to
be then your your second line of checks
right the the um the automated apps will
find a lot of stuff someone who really
knows how to abuse apis will be able to
take it that much further but run the
automated ones first you can do that
yourself you don't need to to pay a pen
tester to just do those basic checks
um bug Bounty programs which we
mentioned a little bit these are a great
way to get some lots and lots of people
looking at your apis
um for not a whole lot of money and you
can get continuous checks going uh it's
also again a great way if you're
interested in getting into the field to
make a bit of a name for yourself and
some money there's plenty of bounties on
apis out on hacker one and stuff like
that uh so you can even just use it for
practice
um but why not get the money right so um
so check that out but uh but
um uh using both the professional pen
testing along with bug binding problem
Bounty programs is a great way to
approach the problem
um yeah I think you all know most of
this stuff right it's it's the business
logic that I said that's the hardest one
to check for
um uh here's actually several uh API uh
vulnerable apis that you can test again
I think
crappy right now is probably the best
one but these others will work as well
uh so some testing tips
um
when you're testing the apis
do it from the standpoint of an
authorized user right you're you're not
going to get as many results if you're
not authorizing to the API so I
certainly check on authorized too but
make sure you can do the tests as an
authorized user
and uh we know not to trust automated
scans to show us everything but they
will show us a lot and uh the the OS API
top 10 is really a good guide it gives a
lot of remediation advice as well as
um uh the the nuances of the
vulnerability itself so you can use that
to start building your testing plan
uh and then so I advised Kite Runner but
here's the problem a lot of times you go
hey I'm going to scan my environment and
what happens when change management
catches the wind of it they're like no
you're not nope you're not
bringing down a production so I came up
with a clever way that you could kind of
get around that so Kite Runner basically
uses something called word lists that
guesses at the most common uh beginnings
of paths for apis the developers tend to
like I said copy and paste a lot so
paths tend to take on a very similar
naming Convention as you're naming apis
so you can actually download the word
list themselves they're called dot kite
files and then just put a sniffer on the
wire and sniff all that traffic that's
going to your API and you can use the
well all the traffic in general that's
coming in and kite if you use something
again any logging tool to do a
comparison you can compare the word list
list against the captures that you're
doing and find apis and endpoints that
you might not have known about so kind
of a Down and Dirty way to get past
change management who we all know and
love right change Management Field yeah
no um we all know and love because they
protect us so much
um but this is a a little way that you
can do it if you can't run a scanner for
whatever reason on your environment
um deception tactics which I love in
general even work here so
um
maybe take a little bit more than your
typical honey token as far as creating
what you need but but these should work
pretty well so one way is
create deceptive comments or responses
with links to fake fake links or fake
credentials so basically as the API is
responding to certain things as you saw
the API might give indications that
there's an admin or that there's an
admin path or there's other ways to get
um you know stupid user trick stuff like
the credentials being there in in too
much disclosure right when when you get
more information that we asked for well
create code to replace your 400s with uh
your your code with 400 and 500s that
are 400 500 with a fake 200 to actually
trick the attacker into thinking they're
onto something so they make the IP API
request you're going to be like oh well
they should get a 400 but I'm going to
give them this 200 and I'm going to give
them something to think that there's an
admin path a way to get to data that
they shouldn't be able to get to waste
their time is basically what
you're trying to do here
um it'll it'll very least frustrate them
and then if you're logging the stuff
that nobody should be getting anyway now
you know someone's trying to mess with
you as well so it serves double duty
um oh that was my last one okay
yeah um so I've talked way too fast now
um so I can open it up for questions but
uh but that that was it um Corey and I's
contact information are are here so
we're certainly happy to answer more
questions but I can take questions right
now if anybody has any
so
um mulesoft uh if I remember right does
milsoft do Gateway stuff as well
okay so yosoft is not a security tool
you might be able to automate some
checks in mulesoft
um but it's not purposely made for this
so yeah it won't help you there
um other questions
yeah no oh some so I did a great job go
drinking
um thank you very much
foreign
[Music]