Up next in 10
Building better security for your API platform using Azure API Mgmt || IT Security Conference 2021
21K views
Nov 9, 2023
These days we use APIs to expose all our microservices , processes, and data, and all this while working in a PaaS or serverless environment. But how do we ensure this is done in a secure and governed way? This is where Azure API Management comes in, where we can create a repository of all our APIs, and make sure to expose all of these securely in a standardized manner. In this session, we will dive into the most common security hazards, and see how API Management helps us solve these. You will learn all about the strengths and weaknesses of the product, best practices, and how to harden the defenses of your services. Conference Website: https://globaltechconferences.com/event/it-security-virtual-conference-2021/ C# Corner - Community of Software and Data Developers: https://www.c-sharpcorner.com C# Live - Dev Streaming Destination: https://csharp.live #AzureSecurity #APISecurity #Azure #Conference
View Video Transcript
0:00
First of all, thank you for having me here today
0:03
Thank you all for being here today. So yes, indeed I'm going to talk today how we can build better security on our API platform
0:09
using Azure API Management. So what I will be showing you today is how we can basically use API Management to secure
0:16
our API platform when we cannot secure our backend services. But first a little introduction about myself
0:22
I'm Al Troodsboog. I come from the Netherlands, live in Rotterdam, working in Rotterdam as well at Motion 10
0:27
10. So we are based here in this office here on the 42nd floor, top floor. So when we can
0:32
actually go back to the office, it's like an amazing view. Netlis is just opening up
0:36
a bit again. So hopefully we can actually be there again soon. But at most time, we
0:40
focus on everything Microsoft. So we do Azure, of course. I'm a technology leader myself
0:44
on Azure and integration. We also work with Office 365, data ytics. So basically we
0:50
do everything Microsoft Cloud. I'm also an Azure NP, so I love working with the community
0:55
So that's of course why I'm here today. I do a lot of speaking, writing, blogging, basically whatever I can do with the community
1:01
I'd like to do. If you have any questions, you can always contact me
1:05
You can call me on Twitter. So any questions, any remarks, please do drop them there
1:11
So let's have a look at API security. Because why do we need API security
1:16
Well, first of all, APIs are everywhere. If we look at a report from Akamai, by 2018, about 83% of the web traffic was actually API calls
1:28
So these are APIs calling each other, website calling APIs, devices calling APIs, you name it
1:33
So there's just a lot of traffic with API calls. But APIs are also vulnerable
1:39
By 2022, we expect that API abuses will be the vector responsible for most data breaches
1:46
So we really have to think about how can we make these APIs more secure so that we actually
1:51
protect our services and our data. And if I talk about API breaches, this is not just us like small companies
1:59
Like big companies also have this. So I had a look at, okay, what are the different kind of breaches that we see over time
2:07
So first of all, I found Venmo. And for those that don't know Venmo, Venmo is for micropayments
2:12
So I can pay to my friend. I can pay for dinner or for a drink or something
2:16
So just our payments that we do with each other. And Venmo had one of the APIs breach
2:21
and millions of those payments were actually exposed. So this is financial data that's being exposed
2:27
some that you don't want. Or Facebook. Well, everyone knows Facebook, of course
2:32
Facebook at some point had an API security breach exposing account details of 50 million users
2:38
So this is just your general data that's out on the street there. Or how about make your U.S. postal services
2:45
another API breach. In this case, it was about 60 million users
2:50
And so the last one I found was just dialed that through an API breach leaked over 100 million user details
2:57
So this is why security should be of prime importance. Because once we get breached, all our data can be exposed to the outside world
3:06
So let's have a look how API management can help us to build better security. And so first of all
3:13
before we go into details, I want to give a quick heads up
3:18
API management is one of the places where we can do this. And what we normally do with API management
3:22
we place API management on top of our APIs, and we actually add a security in API management
3:28
Now, of course, this doesn't mean that your backend is also protected now because you are just putting API management on top of it
3:33
So if you can, you should, of course, try to actually also fix your backend for whatever reason that data is being exposed
3:39
So if you have, like, an API that doesn't have proper authentication
3:44
You can put API management in the top of it, so to the outside world, we now have proper authentication, but should also, of course, also try to fix the API
3:51
However, as we all know, this is not always possible. It might be a SaaS application using or a third-party API
3:58
It might be that you don't have the source code for this API anymore
4:02
or maybe the person that created this API is gone and we cannot really change this
4:08
It might be there's just not enough time at the moment to change this, and this needs to be fixed in short time
4:13
So there's different reasons why we put API management on top of it and actually do those security fixes there
4:19
So let's have a look at what is actually API management because I already said, like, you put API management in front of your APIs
4:25
Let's have a look how API management actually works in a quick introduction. When we look at our API strategy, we normally have something like this
4:33
We have our service and data, so the APIs we're exposing that are exposing our services, our data
4:38
and we have connected experience that are consuming our services. So this might be devices, websites, it might be other APIs
4:47
it might actually be a person. So there's different consumers that are actually connecting to our APIs
4:52
And of course, you have the APIs here in between. So these are our APIs that we're exposing to this outside world
4:58
And if you talk about API management, we basically have three different factors that we are talking about
5:03
We have the API publishers, so us exposing these APIs, want to secure those APIs, maybe want to do something more, which we'll talk about in just a second
5:12
We have the APIs themselves. So these are actually those APIs that are exposing our backend and exposing them to our front-end users
5:20
And we have the app developers that are creating those connected experiences
5:26
So with these three pillars, let's have a look at what we want to do with API management
5:30
So first of all, the API publishers want to publish those APIs. So we have those APIs for our backend services, and we want to publish them for our Connect experiences
5:39
So in API management, we create proxies of these APIs. So we create facades over these APIs, and then we do this in the Azure portal
5:48
So in the Azure portal, we can load in WSDL, we can load in OpenAPI definition, we can load in Logic Apps or Functions or other Azure services
5:57
and it will get all the operations for those services, and we can then just expose them one-on-one
6:01
or we can actually create some composite services where you have different APIs
6:06
and expose them as one fronted API or we can only expose certain operations
6:11
So there's many different ways how we can actually create those APIs there. Now those API publishers want to do some different things
6:17
They want to add some security probably. They want to add some policies
6:20
around maybe throttling or caching or those kinds of things. So this is all done in Azure portal
6:25
where we create those policies, which we'll see in a moment. We create the APIs and then we actually expose them
6:31
Now, when we expose them, they are going to be exposed to the gateway
6:35
And this is the API management gateway itself. So this is basically the instance of the API management, where a connected experience
6:41
actually connects to API management, so they don't know about these backend services
6:45
Those connected experiences just connect to API management, and the API management makes
6:48
sure it's routed to the right backend services with the right policies and all those things
6:53
So basically, this is just a proxy or facade over our APIs
6:58
And finally, those app developers want to consume our APIs. So they want to know which APIs are available
7:03
how they look like, what are the calls that we need to make, which operations are available
7:09
And with this, we have the developer portal. So those app developers can actually go to a website
7:12
and they will see all the APIs that are available to them. They can get a good subscription on this
7:16
and they can actually start calling them. They can start trying them out. So they actually have a tried-out interface
7:22
where they can actually send calls to our back end. So make sure you don connect this to your production of course like pre maybe So and this way with these three pillars this is basically API management So Azure portal where we actually publish those APIs
7:36
the gateway which does mediation, and develop a portal where those app developers can come
7:40
to see what APIs are available to them. So I already mentioned policies
7:48
And policies basically allow us to create smarter services. Policies are XML snippets with maybe some C-sharp code in there
7:56
And through this, you can add capabilities or restrictions onto your APIs. For example, we can add security
8:03
So we have policies for setting up O-out authentication, basic authentication, certificate authentication
8:10
So there's different types of authentication I can actually add on my API. I can also add caching
8:16
So without touching the API itself, I can actually add caching in API management
8:19
with just two lines of code. I can just say whenever something is not in the cache yet
8:24
put it into the cache, set an expiration on it, and next time we hit the same item
8:28
it will actually come from the cache, so it will be much faster. We are uploading from our backend services
8:33
so there's a lot of nice things there as well. We can implement throttling through policies
8:38
so we can say you can only call me 10 times per second or maybe only 10,000 times per month
8:44
So we can actually add this throttling and get builds on top of there as well
8:49
We can do transformations. Now be careful here. So there's two different kinds of transformations. First of all, we have protocol translations. So we can actually have a, how do you say, a SOAP backend service, load the whistle in API management and expose this as a REST frontend. And API management does the transformation of messages and all those things for us. This is very awesome if you still have like those older services but you want to expose them as nice REST APIs. This is awesome
9:18
The second type of transformation you can do is message transformations. So you can actually transform your messages
9:24
You can map data. You can add nodes, remove nodes, all those kind of things
9:28
I would say be careful with that kind of transformations, because you can actually, for example, execute liquid transformations
9:35
which allow you to actually do powerful transformations. However, API management might not be the best place for those
9:41
For simple transformations, API management is perfect. But if you want to do more complex transformations
9:45
I will look at something like a function or a logic app. We can add mocking to those policies as well
9:53
So we can actually do like contract first design where we can have contract defined
9:57
We actually create a sample message. We put this into API management. Our connected experience can already start calling
10:02
API management. We'll get a response back. Meanwhile, we can build our backend service
10:06
And once our backend service is done, we can remove that mocking and actually start calling our actual backend service
10:12
But this allows those connected experience to already start connecting to us or start working with the data, or really start their process without having to wait for us to
10:19
actually build our back end. And there's many more policies. I think at the moment there's around 50
10:25
or so. They're all of course on docs.microsoft.com so you can just look them up. There's many different
10:30
policies and we'll see some of these today. So let's have a look at how we can create an API
10:37
strategy. And for most customers that I work with, when we come in, we will see them go to
10:45
these different stages. So different stages of API strategy. The first one is private APIs
10:52
Now we all know this. We have our own little network where we have our own private APIs that
10:56
are communicating with each other, but no one from outside is coming in. It's just all in our
11:00
little network. And we are happy and safe because it's our own little network. We know that no one
11:06
else can come there. So we might add no authentication, maybe some basic authentication
11:11
but we basically just expose APIs quite openly. We just get all the data from our database
11:16
expose all the data and have our client filter it. And we are just happy because it's only our own clients
11:21
that are communicating with this. Then comes next step. We are starting to give some access to our partners
11:27
maybe our vendors, maybe some customers, but we are starting to expose it to maybe to VNet
11:34
that we have with our partners, maybe already over the internet, but maybe with some IP whitelisting
11:39
But you're still like, okay, these are people we trust. So we can still be okay
11:43
maybe we need to add some kind of authentication, but we don't worry that much yet
11:49
But then we come to the third stage, where we actually start to publicly expose those APIs
11:54
So we are now exposing them on the internet. And all of a sudden we really have to think about
11:58
hey, but if this is open on the internet, everyone can call this API
12:02
So we now also need actual proper authentication on there. And we might not want to just expose all our data sets
12:09
but maybe you only want to expose a limited set of data. So the more we go to the right, the more open we get
12:17
but also the more risk we introduce. Because the more to the right we get
12:21
we are starting to think about, okay, we're actually exposing valuable data
12:25
which is fine if it's just our own APIs that are using this data and we can just filter it
12:30
But if we are exposing valuable data, just the outside world, and someone actually does reach this
12:34
and all of a sudden they get all the details from our users, for example
12:39
might not be something that won't actually happen. If we are just exposing some data with everything in there
12:46
they might get more data than you actually want out there. And this is an easily accessible infrastructure
12:53
This might be in the cloud, where everyone can just reach this. We have to think about, okay, but if this is easily accessible
12:57
how are we going to make sure that only those people actually connect to it, that we want to connect to this
13:03
So we have to start to think about firewalling, API management, what we're going to talk about today
13:07
Maybe we have to implement some other measures. And we have to think about our authentication
13:13
because if we have adequate authentication authorization, anyone can just start accessing our data
13:19
And we don't want this, because this might be valuable data. This might be our financial data, HR data, or the data
13:26
So we need to make sure that you actually authenticate, so we actually know who are you, but also to authorize
13:32
I mean, you might be actually someone I trust, but you might not be allowed to see all my data
13:37
So I can also authorize, are you actually allowed to see this data? And all of this comes down to not following the best practices
13:46
So let's have a look at those best practices. And I'm not going to say this is the exhausted list
13:51
but this is the one that we use most often. So in this list are 12 different best practices that we follow
13:58
This list comes from apifriends.com. There are others out there as well
14:02
So if you're using another one, definitely just use that. If you're not using a best practice list on building APIs, though, definitely start looking into this
14:10
Just make sure you can check off every box on this. First of all, always use encryption
14:17
Especially these days, there's no excuse anymore not to have an encrypted line. Nothing should go over the line anymore in the clear
14:24
So whether it's internal or external, you should always encrypt. Don't talk to strangers
14:30
Make sure you always know who is calling your APIs. It might be through an API key, might be through basic authentication
14:38
it might be through OAuth, as long as you know who's actually calling you
14:42
and also making sure they are actually allowed to see this data. And delegate responsibilities
14:48
don't try to reinvent the wheel but actually call out to something that
14:53
might already exist For example if you talk about authentication don build your own authentication provider but use something like OAuth or OpenID And talking about not reinventing the wheel call out the security experts
15:06
For example, if you are bringing in files or blobs, call out to an antivirus system that's already out there
15:13
Make sure you just use all those different servers that are already out there, and don't try to implement everything on your own
15:18
If there's already something out there, try to use that, because that means that will be maintained for you
15:23
they will actually take care of the whole maintenance the updates, all those kind of things
15:27
and chances are if you call out the secured expert, they know this
15:31
better than you yourself might do also make sure that you know everything that's going on in your environment
15:37
so log everything all that everything, version everything so when something happens, you know
15:43
what happens, by whom and at which point and share as little as possible, like I said
15:51
don't just share your whole data model out and trust in your clients to filter it out
15:55
because as soon as someone actually gets the data they should not have it they also have all this
16:00
data that you might not want out there so only share the data that you actually want to share
16:04
and filter out all the rest and protect your system through totalling through quotas if you
16:12
know your system will go down when it hits more than 100 connections per second make sure you can
16:18
never have more than 100 connections per second. If your client is trying to connect with 10,000
16:23
connections, either they are doing something wrong or they are trying to DDoS you. So just make sure
16:28
you cut this off at the beginning. Don't let it go to your system, just cut it off. Validate all
16:35
the data. Be picky about what you receive. Check if it actually adheres to your data model. Check
16:41
if it's not too big. Validate the content. Make sure you don't get something in your system
16:48
that you don't want there. Make sure your infrastructure is up to date
16:53
Now in the cloud, of course, this is being updated for you. But if you are still relying on your own infrastructure
16:58
make sure your infrastructure is always up to date. Use an API gateway, whether this is API management
17:05
or a different gateway. There's different other gateways out there as well, of course
17:09
But we are talking about Azure API management today. But use one of those gateways
17:13
Basically, everything that I have told you here so far is actually implemented in API management
17:18
So if you use something like API management, you can already just check off all these boxes
17:23
by using the right policies. And build a wall around your systems
17:28
Don't just trust on one single entry point. Now, for example, first implement a firewall
17:33
Then implement API management. Then have security on your API itself. Then have security on your databases
17:40
Assume breach. So assume that one of these can always be breached
17:45
And as if it's breached, they should just hit the next wall and not all of a sudden say, hey, I'm through the first wall
17:51
I can now just do whatever I want. And finally, follow the OWASP.10
17:56
So I think most people will know the OWASP.10. If you don't, it's the top 10 security issues
18:02
We have them for web and for APIs. And the one we are using today is, of course, those for APIs
18:09
I'm not going to run through all of these. We'll see some of these in our demos
18:12
I will come back to them later on about how API management solves this. But just to pick out one or two, for example, security misconfiguration
18:20
By the way, this is from apissecurity.io. You can just get a sheet. You can just read this for yourself
18:25
Also, I will share my slides later on if you want to see them there. But security misconfiguration is, for example, you can read it here
18:33
unpatched systems, missing cores, missing security headers, error messages with stack traces
18:39
So this is just all those configuration things that you might forget or might misconfigure
18:45
Or how about broken authentication? That's definitely one that we see a lot still at our clients, where they are exposing APIs
18:54
without authentication, or maybe just to basic authentication, which is still too weak, or
19:00
just have weak passwords, or all those kind of things, where basically we just can say
19:06
okay, if an attacker comes here, it will be very easy for them to actually breach to this API
19:14
So let's actually have a look at some demos because I think these things are better explained through demos
19:21
So the first demo I'm going to do is actually a broken authentication because this is the one that we see
19:26
at so many clients and not because they don't want to do right
19:30
but just because it's actually quite hard to actually properly build proper authentication
19:34
So what you often see is that, like I said, you have the three phases your APIs go through
19:39
so private, semi-public, public. And because they often start as those private APIs, what happens
19:46
We build an API, we bring it into production. At some point we say, hey, we are going to expose it now to our partners or someone else
19:54
And all of a sudden we now are just putting this unprotected API to the outside world
20:00
And now all of a sudden all our data is being exposed to the outside world. And anyone that can find our API can also call this API and get our data
20:08
Or maybe they have implemented authentication, but it's only basic authentication with a weak password, for example
20:13
So in this case, still very easy for any attacker to just try and break this and get in that way
20:20
Or it might be that they actually do have proper authentication, but then don't validate it
20:25
So they just as soon as you can get a valid authentication, we don't do authorization anymore
20:32
What this means, it might be, for example, we have some data that we can only expose to our admins, but because we don't do authorization, anyone can call this data, not just our admins
20:44
So those are the things that really have to think about, okay, who is allowed to call this, where are they calling from, and what are they allowed to see
20:52
So let's have a look how we can implement this using API management. Not this one
20:57
First of all, actually, let me show you my API. So I have built an API
21:02
It's running here. You can all call it if you want. But this API is just running on an API app
21:08
And if I use this one, if I could call the screen API
21:12
as you can see, it's just my API app on my Azure websites
21:16
And just a simple quad API so I can get my repairs. And what you see here, this is actually
21:21
based on the actual client of ours. This client maintains infrastructure alongside the roads
21:26
So they do street lights, traffic lights, generators, or everything that you see besides the road, basically, they maintain
21:34
And, of course, these things can break down. And what they allow is for people to lock one of these repairs
21:40
saying, hey, this traffic light here, for example, this traffic light is broken
21:45
Okay, please fix this. And they can also leave behind their details
21:48
if they want to get a notification, okay, this has been fixed. Now, what happens
21:53
They put in this request. Someone out on the road gets a notification saying
21:58
hey, please go to the street light, fix it. they have like a portable device, they will say
22:04
okay, where is the address? They will drive there, fix it, they will mark
22:08
it as fixed, and then email or notification goes out to the requester
22:14
So as you can see we have some different repairs in here, we can create new repairs of course
22:17
so I can create new repair repair number 6, I can retrieve of course single repair
22:24
I can update the repair so I can set this repair now to finished Let me just make sure there So if I now call it again we see that it finished
22:37
And finally, of course, I can also delete the repair. So like I said, it's just a simple quad-based API
22:43
We have all built one of these and it's just a simple API. Now, as you can see, there are some things like I can just call to this API without any authentication
22:53
I can call to it over HTTP. So I will already see some things where I'm like
22:59
this is kind of fishy. So let's start by building some authentication on top of this
23:05
So we are going to introduce API management. Over here. So I'm going to introduce API management
23:11
And in API management, as you can see, I'm just running API management on Azure here. I have some different APIs here
23:18
I can load in an API. So in this case, I just load my app service
23:23
So I can just call out my app service. As you can see, if I've loaded this from my different demos
23:29
I just have the same API here. So my clean API with all my different operations are here
23:35
It calls out to my API app. And the first one we are going to see is basic authentication
23:42
As you can see, still all my operations are here. And if I go to my policies, and like I said
23:47
policies are just XML snippets. And in this case, I have a policy check header
23:51
And my check header policy basically just checks for this authorization header with a specific value
23:58
This case is this basic authentication password that we're checking for, and it doesn't find it
24:02
It will return a 401. Now, as you can see, this basic authentication password is a token because of these that are next to it
24:10
If I go to my main values, that's where my tokens are. In this case, it's my basic authentication password
24:15
If I open this, I can see that this is connected to my key vault. So it's actually not just stored here
24:21
but it's actually stored in my key vault. So if I go to my key vault, to my secrets, I have my basic authentication password over here
24:28
I can now see that my basic authentication password is actually my password at word1
24:34
So whenever I call this API, it will go to my name value
24:40
It will go to my key vault. It will retrieve that value. It will cache it, of course, for a while
24:46
And it will then just check. So basically I'm checking for this header with basic authentication, uh
24:51
password one. So let's have a look at my implementation for that
24:57
So I'm now calling out to my API management, as you can see over here, I'm now calling out the API management instead of directing my API
25:03
If I now call this with no authentication, so I don't have my authorization
25:07
I don't know where I get a 401 as we would expect. Now, if I call this out with my authorization header, with my basic
25:14
authentication password, with my password sets, I should get my database. So already just by adding these few lines, like it's three lines, just by adding these
25:23
three lines, we now all of a sudden have gone from an unprotected API to a protected API
25:28
However, like I said, basic authentication is really not that secure. It's quite easy to, if you can sniff that network, you can very easily just get a password
25:39
out of there. So when I'm talking about more sensitive data, which we are talking about in this case, because
25:44
Because these are our, like, this very sensitive data, especially this data
25:48
Also this data you don't want just to get out to the world just for anyone
25:52
So let's actually just implement something better. So what we are going to do next is implement Oout
25:59
And once again, we are using a policy for this because pretty much everything with AKMN
26:03
is done through policies. In this case, I have this policy validate YOT
26:08
So in this case, I'm expecting a YOT token in my authorization once again
26:13
And I expect some things to be set here. So I authenticate Azure AD because this is my Azure AD configuration
26:22
And I'm going to check for some claims. I'm going to check that the application that is calling me is actually this API app registration application
26:29
So I have a registration in my Azure AD and this registration, only this registration
26:37
can call this API. I'm also going to check if this is actually my issuer
26:41
So my issuer from my Azure AD has actually created this job token
26:46
Now, if I call this, so this one. So first I have to call out to my Azure AD, of course, because I actually have to call out and say, hey, I'm this application
26:57
So as you can see, I've got this client ID over here. I've got my client secret
27:01
I've got my scope. So if I send this in, I get back a job token. And in this job token is some data
27:08
Let's open the job token. As you can see, there are some claims in here
27:14
So I have my audience over here. I have my issuer in here. There's other claims as well that we are not using
27:19
In this case, I could have some claims about, okay, which groups are you belonging to
27:23
So by this, I can already see, okay, what is the, as you can see, it has some information
27:28
like this is my application ID in my Azure ID. Now, if I call this with this token, so I have my response here in my alt
27:37
so if I call this, if I pass in this X token in my authorization header, I should
27:42
get back a response. And indeed we do. Now if I don't
27:46
have the proper token, if I call out like this, like I don't have the proper token
27:50
and I call out this, I get back in unauthorized. So this way
27:54
I already have much better authentication on top of this. Because now I actually have to
27:57
log in, I have to get an authorization header of my YOT token, which
28:02
is only which expires after I think like five minutes. So even if someone grabs this token, they can only use this token for five minutes and after that they don't have it anymore
28:13
So this is already much safer. Next, let's have a look at some misconfigurations
28:20
So for example, we already saw that we can call our API to HP instead of HPS
28:26
So this is something that we don't really want. We are exposing all my different operations
28:32
So for example, I'm also exposing my delete operation, which my clients actually never have to use
28:40
And what I also show you is that we are exposing verbose error messages
28:45
So let's have a quick look at this part. So we go back to my AP arrangement
28:53
We collapse this. And first of all, I want to show you is that indeed we are exposing all these different operations here
28:59
So actually, no, the first one is for HPS. sorry. So the first one is for HPS. So because as you saw here, I can just call my API management
29:09
to HPS well. Now I don't want this. I want to make sure that I can only call this over HPS
29:15
And this is actually very easy with API management because I can just go to my settings and I just had to switch this from both to HPS only. So over here in my previous one
29:24
I had to set the both. In this one, I just send it to HPS only. So if I now call out to this one
29:30
Let's see, I first have to log in. So if I go out now to this demo tree
29:36
which is one we are now using with HP, I should get back a 404 research not found
29:40
Because there's no endpoint which actually doesn't have this, which is exposed on HP
29:46
If I call the same endpoint but over HPS, then of course it does work
29:51
So next we are going to check for the errors and what I first want to show you over here
29:57
my design, is over here we don't have the data. delete operation anymore. Like I said, we have this delete operation here. I can very easily with
30:05
API management just say delete, or I can add a new operation. So this is just for site, like I said
30:11
so I don't actually have to have to complete the structure as my actual API. I can actually
30:16
call out multiple APIs on different operations. So by deleting this delete and repair, I already
30:21
make sure that no one can now just delete and repair. So this is also a part of security where
30:26
our clients never have to call this, so I can just remove this
30:31
I'm also going to catch some errors because I will show you what happens
30:35
If I call out to my API and I want to delete something that doesn't exist
30:42
I get some information back, okay, this is still okay, like it was not found
30:47
Okay, this is not great, but not too bad either. Now, if I actually go and try to update
30:52
a repair that doesn't exist, I'm getting this back. And this is actually very bad, because this is going back to my client and also so if someone
31:01
is actually trying to get into my systems, this will give them a lot of information
31:07
Because I already know I'm using entity framework core. So I can start looking, if I want to attack this API, I can start looking for vulnerabilities
31:14
in any framework. I will also, if I look over here, I can also see that this is running HP net with MVC framework
31:22
So I can also start looking into that. So there's a lot of information for anyone that wants to attack me that they can get from this
31:28
So I never want to expose this information. So what I'm going to do instead is I'm going to remove the data
31:40
And in APMH, you have different parts where you can implement policy
31:48
So you have the inbound part where this is as soon as my client calls me, this will be executed
31:53
So that's where we, for example, do our authorization. We have the back end part
31:57
This is when we are calling our back end. So we might want to do something there as well. And we have this outbound part, which is our response coming back and just before it goes
32:05
back to the client. And that's where we want to implement this. Just before it goes back to the client, I want to check if my response code is over 500
32:13
which was in this case. If it's over 500, I'm going to check, okay, does the body contain this kind of text
32:22
If yes, then we are just going to replace it with this nice error message. If not and still error, then we are just going to return a general error message
32:30
So if I call out to this one over here, so still I do the same, I put in all the same
32:39
things, but now I'm calling out to this other one where we actually have this policy that
32:43
removes that stack trace. And now all of a sudden I don't get back that whole stack trace, I just get back this repair
32:48
with that ID could not be found. This is perfectly fine. I did not find it, so I might even say
32:54
I might also just make another response, return code on this. But in this case, we just replaced this error message
33:01
with a nice error message, so now no one actually knows what I'm running on
33:05
They don't know I'm running on Entity Framework or anything like that. We are now, again, much safer
33:13
Let's have another look. So the next one we are going to look at is XS data exposure
33:18
And XS data exposure is about those full objects that we are returning
33:22
And as you could just see, I'm returning details by my repair, but also about that requester
33:27
And this is because we often trust on the client to actually filter this
33:32
But when we are exposing our data publicly, we cannot trust the client anymore because we don know who the client is So we might be exposing secure information that we actually don want to expose So as we could see here over here if I call out to this one I just getting back all
33:51
this information, including this GDPR data. And my clients actually don't need this data
33:56
My clients just need to know about this because they need to know where they need to go, like
34:00
on the guy with the mobile device, the person with the mobile device, needs to know where
34:05
do I need to go. They don't need to know, okay, which request was this because they don't care about this
34:10
Only our internal system needs to know about this. So we actually going to filter off or strip off this request in notes
34:19
So let's have a look in API management. Once again, clicking one screen
34:23
There we go. So API management, if you go over here, we can remove, go to this one
34:30
We open up our policy. And over here, we will see that we have this set body
34:36
And over here you see some C-sharp codes. Now, like I said, there's about 50-something policies out of the box
34:42
If you want to do something that's not out of the box, you can also create your own custom policies
34:46
And you do this with this C-sharp code. Now, you can only use a subset of the .NET code, so don't expect that you can build complete applications in this
34:56
It's mostly you can manipulate strings and JSON. That is mostly what you can do with this
35:02
So what you are going to do in this case, we are going to get the response that we got
35:05
from our backend service, and we are going to get a response body, we are going to make
35:10
a J token out of it. We are going to check if this is an array. If it's an array, we are just going to loop over all the different repairs in there
35:17
And what we are going to do is actually from each repair, we are going to remove that requesting note
35:23
We do the same if it was just a single item. And finally, we return the response
35:27
We just return it without that requesting note. So if I call out this API over, let's see, this one, so first authenticate and then we
35:41
are going to call out to it and now all of a sudden we only get back my assets
35:46
So we only get back the assets without the requesting note. So once again, by just introducing like a few lines of code, we have now made sure that
35:54
we are not exposing any valuable data anymore. So once again, everything with APMN, as you can see, it's just very easy to implement
36:03
but it helps you to really mitigate those risks that you have
36:08
Let's do one more demo, and then we are going to finish
36:12
So the last demo I want to show you is about lack of resources and rate limiting
36:17
So for example, if someone wants to brute force attack you, for example, they just try
36:23
to keep calling out to your API with different passwords. So they might just like to 10,000 or 100,000 tries every minute
36:32
It's not something that you want. Or maybe they don't want to deny or service you
36:36
They are just putting a lot of stress on your APIs until all the connections are filled
36:41
and you cannot actually handle proper calls anymore. Or maybe they are trying to send in large messages so that your systems get overloaded
36:49
All of these can also be solved by API management. Once again, this is the one I need
36:57
So let's have a look how we do this. Once again, it's true policy of course, so let's see the policies
37:04
I have two policies in this case. The first one is my validate content
37:09
So actually this is only 10K. There we go. But in the first one I just going to validate content and I have this max size over here So I just going to check if the max size is not over 10K If it is over 10K I have this exceed action that does prevent
37:27
So it's over 10K, it just says this is not allowed. Let's hope it actually starts to refresh
37:35
The second one is my rate limiting. And this is about, you can only call me in this case
37:39
five or 15 calls in one minute. If you call me more than 15 times in one minute
37:45
there we go. If you call me more than 15 times in one minute, you will get back a response that you are being trottled
37:52
So let's have another look. So first we are going to just call out to this API untrottled
38:00
So I can just keep calling this and I can call this as many times as I want
38:04
And I can now, for example, we loaded .io on this and I could just send in like thousands of requests
38:09
per minute and we'll just keep going. Let me actually just call this
38:14
As you can see, I can just keep on calling this. Oh, actually, I already started throttling one
38:19
Sorry. So this is the one I'm throttling. I should have started with this one, the non-throttled one
38:24
This one I can just keep calling. The throttled one, though, as you saw, I get a message back saying
38:29
hey, you are being throttled. Rate limit is exceeded. So I call this more than 15 times in one minute and tells me
38:35
hey, your rate limit is exceeded. Try again in 45 seconds. If I try this again, it will tell me, okay, you still have 34 seconds left
38:42
So while this is running down, let's go to the next one, which was accept data size
38:48
And my accept data size, of course, is about when I try to send in this large message
38:54
that's larger than 10 KB. So if I call out this and I just start to wait because I'm probably still being trottled
39:02
Yeah, so I wait 10 more seconds. But once I call this in, put this in, I will get back a response saying
39:07
hey, this is too large. You have a message of size X. You can only do size Y
39:12
So, one more second. So now I'm going to send this accept data size message in
39:16
And it will tell me your request body is 90 KB. It's only now to do 10 KB
39:23
So already this is only getting to API management. This is never reaching my backend
39:27
Same with these calls that are being throttled. They are never reaching my backend
39:31
So my backend doesn't even know about these calls. API management is just taking care for my API to not be overloaded
39:39
So like I said, this was the last demo. So with that, we're almost done
39:45
So we have seen how we can implement authentication. We have seen how we can implement throttling
39:50
We have seen how we can implement things like removing HPS or HP calls, just HPS
39:57
We have seen all these different things and all just by API management
40:01
We never had to touch our actual API. So if this is because the API is a SaaS service or whatever reason, you cannot touch your API
40:09
you cannot change there. API management will come to the rescue. And let's actually have a look at
40:14
those 10 different OWAF vulnerabilities and how API management can help on those. Now, the first
40:21
one is broken object level authorization, which means I have an object, for example, a specific
40:26
object in my database, which, for example, I might have users and one user is a VIP that is only
40:33
allowed to be accessed by admins. API management cannot help here because this is actually something
40:39
that you have to still filter on either your application or even better on your database
40:44
So API management cannot help there. However, all the other ones API management can help
40:50
Broken authentication, which we have seen today, I can implement things like OAuth
40:54
I can implement certificate authentication, I can implement basic authentication I can actually transform a request So I can actually for example add a header or remove a header to code my backend And this way I can actually fix the both authentication
41:10
So now in our case, we had an open API that was still only being exposed to it all out
41:16
I can accept data exposure. And this is one I just showed you where we actually returning all the data from the requesters
41:23
I showed you how you can actually filter this out. Or we could also have masked it
41:27
We could just have put in dummy data instead. Lack of resource and rate limiting
41:33
I also showed you I can do rate limiting, like I can only call me 15 times per minute
41:38
or 1,000 times per month. You can also do things like that. I can set my backend concurrency
41:44
so I can actually say, okay, to my backend, I only have 10 connections, so if I get more connections to that
41:48
I also can throttle that. I can throttle on the message size
41:52
and all those kind of things. So there's many different ways I can throttle through API management
41:57
Broken function level authorization. So we already saw broken object level authorization
42:02
which is a specific object. That doesn't work with API management. Broken function level authorization does work, though
42:08
Because on each API, I can set a different authentication, for example, on each operation
42:14
So if I made the lead operation, which I actually removed in my case, but I could also have said
42:19
well, the lead operation can only be called if you're in a specific group. So that's how we can do this
42:24
to keep token-based authorization or to customer authorization. Mass assignment is when I send in a message with just a complete object
42:37
So normally I might only need to send in like a status, but I could actually say I'm going to put in complete object
42:45
and I'm going to overwrite all the data. So mass assignments you can also prevent with API management
42:51
You already saw that validate content policy. In this policy, you can also have an additional properties field
42:57
So you can actually, you can show to, point to a specific schema
43:02
And everything that's not in the schema, you can say any additional properties just are not allowed
43:07
So in this case, when someone tries to send in more properties than are actually allowed
43:11
then it will just say, hey, this is not allowed, you get it back. It will never once again reach your backend
43:16
Security configurations, we also saw how we can do HPS, enforce HPS. You can do things like cores. We saw how we can clean up those response messages. So, as you mentioned, also helps here
43:31
We can also prevent injection. Once again, this validate content policy will help with that, where we can actually format
43:39
the properties and actually check if someone's trying to do injection in there
43:44
Impropriate assets management. So this is when we actually don't know what is out there. So we might have APIs that no one knows about, but are still living out there
43:51
With API management, we always know which APIs you're exposing because we are exposing to
43:54
API management. And we just have all these different APIs that I just showed you
43:58
So I can immediately see which APIs are being exposed. And also for my developers, the developers
44:03
of those consuming services, they also see which APIs are available to them
44:09
And finally, insufficient log and monitoring. API management has a lot of different options
44:14
actually do a lot of logging. It logs to log ytics and application insights
44:19
So I can also use things like application map, like see what is calling what, and where is latency
44:23
and what is going wrong. So there's a lot of options here as well
44:28
that API management will help them. So with that, I would like to say thank you
44:32
I hope you enjoyed the session