Introduction to Imperva API Security: Community Webinar

By Christopher Detzel posted 08-10-2020 12:57

  
Find the pic here https://unsplash.com/photos/xsJK9yTIFbc

Login or Create a Login to Post a question here on the Imperva Community around API security


Imperva Resources: 
API Security API

Transcript found here: 

Peter Klimek: (00:08)
Hi, everyone. Peter Klimek. Welcome to the API security webinar. Today in this webinar, we're going to be talking about how you can actually go and secure your APIs. APIs are the most common way that applications are being developed these days, and for a lot of organizations there's a lot of confusion around how you can actually manage and control access to those APIs and mitigate some of the new and emerging threat vectors that are out there.

Peter Klimek: (00:32)
For many people, they're first introduced to APIs through DevOps. They might be first introduced to an API by interacting with another organization's API in order to achieve some form of goal. We as Imperva expose the APIs to you so you can go and interact with our products. Whether it's through our Securesphere, WAF gateway, DAM gateway solutions, or whether it's through the cloud WAF, we have APIs that we're able to work with so you can actually make your jobs easier and integrate with your systems.

Peter Klimek: (01:00)
Last but not least, as we look at application modernization initiatives, APIs are really the core of service-oriented architectures, the older model of interconnected applications, and more commonly now, microservices architectures. A lot of where we see organizations moving and building new APIs is not just for the edge, as they're looking at exposing data out to their customers, but they're also building APIs in this service-oriented and microservices architecture, so they can actually service other applications internally. We see lots of different use cases for how APIs are used.

Peter Klimek: (01:38)
Now, the flip side to this, and because we're in security, there's always a flip side, we ultimately find that many organizations are finding it difficult to control data access. This is really one of the biggest challenges that we have with APIs. Developers are developers. I'm a developer. I make errors all the time, and I don't know it. And a lot of times, it's the security teams that are really responsible for helping to find and fix those errors. The problem with APIs is that an error can be very costly in that it can lead to sensitive data exposure. Ultimately, you also have things like your API keys, which developers also accidentally check in the source control from time to time. This leads to API keys being compromised, and when those API keys get compromised, it ultimately leads to data breaches.

Peter Klimek: (02:25)
And of course, last but not least, as we look at the [inaudible 00:02:28] landscape, what we've seen is that application and API abuse is resulting in more and more breached records throughout the years. This is a trend that we're watching very closely. We're actually going to be doing a followup presentation with my colleague Brian Anderson. He's going to be talking about some of these aspects in a little bit more detail.

Peter Klimek: (02:46)
As we look at APIs, the other thing... There's the business type and the purpose of the API, but then there's also the API types. These are something that you need to keep in mind as you're starting to work with and secure APIs. Everything really started with SOAP. SOAP is Simple Object Access Protocol. It's basically a mechanism. It's very heavy-handed, but it's really based on XML over HTTP. More recently we had the introduction of REST. Restful APIs really started coming into prominence right around 2010, 2011 or so. Most commonly today, this is really the biggest that we see.

Peter Klimek: (03:19)
Newer and up and coming ones that we see from an API type is gRPC. GRPC was something that was developed by Google, so the G in gRPC. And the more recently, some of the new kid on the block here is GraphQL. GraphQL is something that was developed by Facebook, and it's used by some very prominent APIs that are out there on the web. If you've ever interacted with GitHub's new API, that's GraphQL-based.

Peter Klimek: (03:43)
As we're watching the trends and we're looking at where we're investing in our technology, this is something that we're monitoring very closely. A lot of what I'm going to be talking about today is going to be applicable for REST-based APIs, and the reason that it's applicable for REST-based APIs is if we look at just how they're trending, REST is far and above the most popular API type. Below that, we see that SOAP, while it's still popular and still used by many enterprises, especially enterprises that are really heavily invested in service bus technologies, ultimately we see it's still around, but it's declining.

Peter Klimek: (04:18)
Now coming into prominence is GraphQL and gRPC. GRPC is a little bit lower than GraphQL. GraphQL is certainly on the rise quite a bit. I'll probably be doing... that is a much later session. I'd really like to do a session on GraphQL, because I think it's really interesting technology, and it's not really well understood from a security perspective. But you guys will have to let me know how much interest you have in that.

Peter Klimek: (04:43)
As we look at the differences of these, I mentioned before some of the slight differences. With SOAP, we're looking at XML over HTTPS. When we talk about REST, it's JSON over HTTPS. That's one of the things that makes REST APIs really easy to work with. It's very simple. GRPC, slightly different. It's actually working with something called Protobufs, which is another Google creation, over HTTP/2. We're seeing gRPC used mostly on internal APIs, so as organizations are building out microservices, they're using gRPC for those internal communications, just because of the cost benefits that you get with gRPC, some of the control that you have around it.

Peter Klimek: (05:22)
But interestingly, we are finding more and more companies that are actually exposing gRPC out to the end. There's a great article that was just recently published around Microsoft Teams and how Teams actually switched from a REST-based to a gRPC API. The reason they did it was because the amount of data that they transfer back and forth, they were able to get pretty significant performance improvements by switching to gRPC. This is something that we actually just added support for pretty recently. I'm not going to go into detail into this session today, but this is something that I will cover in a followup session as well.

Peter Klimek: (05:55)
Last but not least, there's GraphQL. From a protocol basis, it's a little bit of a hybrid. It has GraphQL schema definition language, which is really its own proprietary format. It's very JSON-esque. And then the responses are coming back in JSON, and this is served over https. We support GraphQL today with some limitations. I just want to make that known out there. We do have CSS that are using GraphQL in production today, and they are protecting it with the cloud WAF.

Peter Klimek: (06:22)
Now, we talk a lot about schemas when we talk about APIs. It's not required that you have a schema, but generally speaking it's the best practice. There's different schema types. We'll be focusing pretty heavily here today on Swagger and the Open API specification, but ultimately, if you are working with some of these other API types, like you're working with SOAP, there's going to be a WSDL file. If you're working with gRPC, there's basically a .proto struct, which is basically the way that the protobufs are used to define what the schema looks like. And GraphQL is a totally separate category, where the schema itself isn't really a defined file, but instead you actually query the GraphQL API and you ask it what does it look like. It's a really interesting, unique way of looking at it and something that we're investigating right now.

Peter Klimek: (07:08)
As I mentioned Open API and Swagger, just to give you an example of what this looks like, if I have an API request or something like GET /user, and it returns back a JSON structure, that basically shows all the common things, like my user name, my email, first name, last name. This is our old corporate headquarters address. I've got to update that. This can actually be represented and modeled using a YAML file or a JSON file. This is something that we refer to as the open... known as Swagger 2 or Open API 3, where effectively, what you're doing is you're defining different properties that are associated with the data models, you're defining what the expected request and response structures look like, and then you can also define different parameters that you're using really as an input validation perspective.

Peter Klimek: (07:58)
For example, if on my database schema I'm specifying that user name is actually a varchar with a max length of 30, then that's a good example for me to be able to say, in here I'm going to define that I expect this parameter to be between four and 30 in terms of the actual length and characters. So the schema gives you a way of really telling your developers and other consumers of the API what you're expecting to see.

Peter Klimek: (08:26)
Now, not all APIs and REST-based APIs will have a schema. It actually took a really long time throughout the journey of REST before schemes were really even a standard. What we often find from development teams is that, while a lot of the newer APIs that we work with will tend to have schemas, some of them don't have them. It's actually relatively time-consuming and manual process for most organizations to actually build out the Open API schemas, and it also leads to some problems with it.

Peter Klimek: (08:54)
I'm going to talk more about this in a followup session in terms of some of the challenges of defining schemas, but for right now, if you're working with REST APIs and you need to secure it, the first thing that you need to do is just talk to your developers and just ask them, "Hey, is there a Swagger or Open API spec for this API?" That's going to give you already an instant clue into what about the API is doing, and then we're going to use that file with our API security capabilities.

Peter Klimek: (09:21)
I mentioned before here that we're going to talk a little bit about API gateway versus API security. This is an interesting topic right now, obviously, if not very well understood across our customer base, as well as even within Imperva. To demystify it for you, the way that we view it personally is API gateways, in terms of what we see them good at. API life-cycle management is really the first and foremost thing. If you think about how you deploy and manage APIs, there's a life-cycle to how you manage that lifespan, how you do version controlling and upgrades and things like that. API gateways are really good at his.

Peter Klimek: (09:58)
[inaudible 00:09:58] very security-related [inaudible 00:10:00] we talk about API security. API gateways tend to be the place where a lot of our customers will implement their authentication and authorization controls. There's some nuances to this topic, and we'll go into detail on some of the nuances in a followup session, but I just wanted to put that in that category.

Peter Klimek: (10:20)
General mediation. How do you actually communicate to the backend services that are powering the API, as well as how do you control the different types of content that you have to work with? Some API gateways will do things like, if the request comes back in as... or if the content type that is requested is application XML versus application JSON, they'll actually do the transformations for you. Some API gateways will manage things like that, but more often than not, as you're looking to span out and to connect to different services, this is really what API gateways are good, some of the routing and plumbing capabilities.

Peter Klimek: (10:57)
Last but not least, we have monetization. Monetization is something that a lot of organizations are looking at their APIs for. They're not just saying, "I want to make this API available to my customers, but I also want to manage the consumption of that API, and I want to build based on how people are accessing that." That monetization capability is really something that API gateways are really, really well suited for.

Peter Klimek: (11:20)
Interestingly, there's a constant question that comes up that we get all the time, which is basically, "If someone goes over a quota or a limit, where do I block that?" Now we view that as really something that's a more use case that's specific, and driven more towards API gateways, and the reason why is because ultimately you hold that authentication and authorization capability, and so you have much greater context in terms of who the user actually is, and so making those decisions makes more sense... it's a business decision to stop that user there, so we would generally look at doing that directly within the API gateway.

Peter Klimek: (11:53)
Now, that's no to be said that API security isn't capable of doing this, but where we see API security really coming in is more around exploit defense. As you have vulnerabilities that are out there, as we're trying to protect against them, being able to stop those types of vulnerabilities is where API security capabilities are really key.

Peter Klimek: (12:12)
Similarly, if we look at attacks, layer 3, 4 and 7 DDoS mitigation is another huge area where API security specific solutions are going to really excel. API abuse is something that I mentioned before a little bit in terms of the abuse and the monetization capabilities. There's some overlap in there, but ultimately, we're looking at things like scraping, rapid iteration through APIs, and even just people coming in and connecting from sources that they shouldn't be connecting in from. If you have an API that is exposing sensitive data, you probably don't want to allow connections coming in from Tor networks and anonymous proxies. Those are the types of abuse scenarios and use cases that we want to be able to stop a the API security layer, as opposed to the API gateway. What you need to be able to do that is you need a robust reputation database or be able to actually key in off of those types of clients.

Peter Klimek: (13:05)
Last but not least, data theft. This is really, really a big topic for us right now internally within Imperva. We're working on some new innovative solutions around this area. I'm not going to share too much today around this, because we're going to be talking about this a lot in the coming months, but we're really excited about some of the capabilities that we're developing and how we're really viewing our API security strategy beginning to evolve.

Peter Klimek: (13:27)
Last but not least, I mentioned API gateway versus API security. The truth is we love API gateways. We don't see these two as being something that should be independent of one another. We view them as something that really work in tandem together. It's not an either/or, it's an and question. API security solutions work great with API gateways. I view personally API gateways almost similar to how I view the relationship between a WAF and a web server. They really go hand in hand together, and it's something that we don't actually view as competing solutions.

Peter Klimek: (14:04)
Going into the threat landscape, we'll start digging into what are the threats that we're actually looking for, and more importantly, let's talk about how it's a little bit different than web application security. Everyone's probably really familiar with this, because we're all application security practitioners. We've got the OWASP top 10. Now, one of the great things was when we first started looking at APIs, basically everyone's like, "Well, do we need something specific? We've got the OWASP top 10. It's pretty similar for the most part." And OWASP actually put together... they realized that there was enough differences that it made sense for them to go and put together an API top 10, which is great. I'm extremely happy that OWASP did this.

Peter Klimek: (14:42)
When you first look at it, you're like, "Oh man, this looks totally different. There's a whole new set of vulnerabilities and CVEs and things that I need to protect against." But when you really dig into it and you really start to look at it, one of the things that you find pretty quickly is that a lot of the categories are actually the same.

Peter Klimek: (14:58)
Injection just moved from 1 to 8. Broken authentication became called broken user authentication. I don't know why they changed the name for it, but effectively it's still there. Sensitive data exposure is excessive data exposure. Again, I don't know why they changed the name. Broken access control, they split this into two. I see the reasons why. It's broken object level authorization and broken function level authorization, two important distinctions between there. We'll talk about this one in a followup webinar. Security misconfiguration stayed the same. It just moved from 6 to 7. And then insufficient logging and monitoring also stayed the same. It actually was 10 to 10.

Peter Klimek: (15:40)
Ultimately, if we look at it, there's some that are no longer present. XML external entities, cross-site scripting, insecure deserialization, using components with known vulnerabilities. And there's some new ones. We've got improper assets management, mass assignment, and lack of resources and rate limiting. I'll spend a lot more time on some of the new ones, but before we do that, I do want to just say that ultimately, API security is very similar to web app [inaudible 00:16:08] but there are some new challenges that we're going to have to consider as we're going into this in more detail. That's what we're going to talk about today.

Peter Klimek: (16:16)
First, from the four that are missing, let's just blow through these real quick, because everyone mostly knows these. As we look at XML external entities, big question is, it's not on the API top 10. Are APIs vulnerable to this? Yeah, they are, but generally only going to be SOAP-based APIs. Most modern REST-based APIs, GraphQL APIs, they don't use XML parsers, so this isn't something that really comes up, so it made sense for this one to be dropped from a top 10 perspective.

Peter Klimek: (16:48)
Cross-site scripting, we get asked this one actually quite a bit. Are APIs vulnerable to cross-site scripting? The answer is yes and no. While the API might actually be vulnerable to cross-site scripting, it might not do things like proper input validation, ultimately what ends up happening is when an attacker basically is able to persist that malicious data, the API is sending back that information with the content type of application JSON. The browser is smart enough to know that, "I don't execute things that are coming back in a content type of application JSON." It doesn't actually render it directly.

Peter Klimek: (17:24)
Now, one of the things that we ultimately will find, though, is that while the API technically was vulnerable to cross-site scripting, it's really the question of, is the client-side application that's consuming that API going to be vulnerable to this? And so ultimately, what we will find is that developers, being developers, like to disable protections, so some of the more common frameworks that basically work directly with APIs, so single page applications and frameworks like Angular, they've got this really cool feature in here called the DomSanitizer. The DomSanitizer is built to basically sanitize the DOM and so prevent any sort of malicious content from getting executed.

Peter Klimek: (18:05)
Now ultimately, if you go and look on Stack Overflow, the number one question about DomSanitizer is, "How do I disable DomSanitizer?" generally do a pretty good job, and they're most of the time not vulnerable. It is still something you have to watch out for, but it's probably going to be more on the clients, which you may or may not be able to control, than it will be on the API itself.

Peter Klimek: (18:31)
Insecure deserialization. This one, it's a huge topic. It's a huge topic because it's synonymous now with Apache Struts. It's unfortunate for Apache that that's now basically how everyone knows Struts, but effectively, insecure deserialization is basically, you serialize objects, it basically takes a Java-based object or a .NET-based object, and it creates really a text-based representation of that object, so you can pass it over the wire or you can store it in a database and things like that. That's what serialization's really designed to do.

Peter Klimek: (19:03)
Now, are APIs vulnerable to this? Maybe. It's generally not as common in APIs. This is a good reason why it's dropped off. The reason it's not as common as API is because APIs don't really rely on data serialization formats in the same way that an application typically would. With .NET applications and Java applications typically will use serialization methods as they're really transferring data across, where APIs, they rely on just pure JSON or XML as their data transfer. Pure JSON, pure XML, it's already [inaudible 00:19:41] directly in a database or transmitted over the wire. We don't see this as being something that's very common.

Peter Klimek: (19:48)
Now, of course there's a caveat to that. There's always a caveat to it about security. You can actually find this blog post... I've got it listed at the bottom here... where we did an analysis of an Apache Struts remote code execution vulnerability that was in a REST plugin. It's less common, but it is something that we have to watch out for.

Peter Klimek: (20:07)
Now, also when I go into the authentication topic and we start digging deeper into that, one of the things you're actually going to also find is there's insecure deserialization issues that come up when you're working with things like JSON web tokens. JSON web tokens basically get serialized and converted into a specific format. We do see developers making errors with how they're actually working with the JSON web tokens. Now the question is, is that an insecurity serialization error or a broken authentication error? More often than not, I consider it to be broken authentication, but it technically was insecurity serialization.

Peter Klimek: (20:43)
Actually, that's an important distinction. One thing that we often will find is that there's always a kind of... when we talk about APIs, it's a question of, are we talking about our APIs and how we expose it to our customers, or are we talking about securing your APIs? I generally like to distinguish the two I call securing your APIs, API security, versus interacting with our APIs. I generally try to consider it as a DevOps type of use case.

Peter Klimek: (21:10)
Last but not least here from the API top 10 omissions, number nine, using components with known vulnerabilities. I don't actually know why this was not included in the API top 10. This problem is really just as common in web applications as it is in APIs. There's a reason for that. Most development is moving to more of a model where its really component-heavy. When I say component-heavy, what I mean is basically developers are basically taking very common frameworks and packages and libraries, and we're layering them in on top of each other. So as I'm building an API in Node.js, I'm going to be using Node.js, TypeScript, Express.js, all these different packages really layered in on top of it.

Peter Klimek: (21:49)
As we look at software composition analysis, we see that of modern applications, only about 20% of that is actually custom code. The other 70% is open source components. There's 10% for just infrastructure-related plumbing and things like that, but that 70% open source components means that open source is everywhere, in not just web applications, but also APIs. And so ultimately, it's some of the big things you need to be looking out for. Even though it's not technically an API top 10, it's still something you need to make sure think about you are conscious of.

Peter Klimek: (22:24)
We're done with talking about the web apps and the stuff that's not in APIs. Clearly lots of different vulnerabilities are still present in APIs, even though they're not in web apps. Let's talk about what's new. As I look at the categories, one of the first things that really helps me is to have a mental model of really grouping them. If you just look at the 10 by themselves, they're all over the place, and you're not really developing a strategy. What I like to do is I like to group them based on common themes.

Peter Klimek: (22:53)
First theme that we have, and probably the lowest-hanging fruit, is really configuration and management. We look at things like security misconfiguration, improper assets management, which is new, and insufficient logging and monitoring. These are all really configuration management vulnerabilities. We've got input validation, which is really mass assignment, which is a totally new category, and injection. We've got data exposure and harvesting vulnerabilities, which are really excessive data exposure, lack of resources and rate limiting, authentication, which is really just broken user authentication, and then authorization, broken object level authorization and broken function level authorization.

Peter Klimek: (23:33)
Now as I was thinking about webinar schedule, what I really wanted to do then was maybe dedicate a webinar to each individual set of vulnerabilities, so we could spend more time really digging into the deep parts of it, as well as walking through more concrete examples of how you detect and how the... first of all, how the vulnerabilities work, then how you detect it and how you effectively mitigate and protect it. For today, we're going to focus on A7, A9, A10. In the next webinar, we're going to go deeper into input validation. We're going to talk about mass assignment in pretty serious depth. I'll even show code level examples, if you guys are interested, and then we'll go into injection. And then in followup ones, we'll go through data exposure and harvesting, authentication and authorization.

Peter Klimek: (24:19)
Without further ado, let's switch over to insufficient logging and monitoring. This one's pretty simple one. This is a softball in terms of being able to protect and secure your APIs. Insufficient logging and monitoring, it's exactly what it sounds like. Basically, you don't know when you're getting attacked. It's really easy for an attacker to basically go through and start to probe and iterate through APIs, especially when you publish a schema that tells them exactly what the API looks like. And so, a lot of times, if you don't have proper logging and monitoring systems in place, they do it, and the only way that you often know about things is when they break it.

Peter Klimek: (24:58)
Now, I hate to say it. Sorry, not sorry. We also made attackers' lives easier by publishing an automated API attack tool. I'm not going to go through it in this presentation. I'll actually go through it in the next webinar. But this was something that we developed because as we were actually testing our API security capabilities, we found that there was actually a serious lack of good API attack tools out there. One of our great developers, Boris, he was the person that basically spearheaded this initiative. Go out to Imperva or github.com/Imperva, and you'll find the automatic API attack tool out there. If you need a tool to be able to actually go take your Swagger specifications and start [inaudible 00:25:39] your APIs, this is exactly what it's designed to do.

Peter Klimek: (25:44)
Let's look at the mitigations. First and foremost, we have attack analytics. I'm going to jump in here, I'm going to show you all these, but I'm just going to set it up right now. Then we look at WAF plus API security capabilities, and then we look at SIEM logging. These are the three controls that I recommend always having in place for all of your APIs. Let's jump in here real fast and talk through why.

Peter Klimek: (26:06)
Some recent additions that we just made. I'm going to start out in Attack Analytics. Personally, I generally like starting in Attack Analytics for pretty much everything that I do, just because it's a good central eyes and ears place for me to get a good view of just exactly what we're seeing. Even more so, one of the things that we've introduced is our insights feature. Now our insights feature, the way that we really view this is a way for us to be able to highlight information that you might not be aware about, about your applications and APIs.

Peter Klimek: (26:36)
One of the really cool new features that we just rolled out here was... first, origin servers are exposed. This is bad on me. This is actually a security misconfiguration where I didn't lock down the backend server. But then also we have unprotected API hosts. This is more that we literally, literally just released on Sunday as part of Attack Analytics, and what this basically does is this shows you that we had an incident on a host, and it's not protected by API security. The great thing about this is this gives us the ability to basically go and to see which APIs I already have in my environment. As long as I've onboarded the website into cloud WAF, I'm going to be able to actually very quickly see now which ones are APIs, even if I haven't configured API security.

Peter Klimek: (27:22)
I'm going to go on over into my website now. Actually, before I do that, let's go in and enable logging. You can go into logs on the side here. As we go into it and we look at site-level logs... first, from a log setup, we're going to do a deeper webinar on logging and SIEM integration, but just let it be known, my personal preference, send all my data to S3. From S3 there's so much that you can do with it. You can query it directly. You can send it to your SIEM and forward it. It's a really easy way to set up and get access to everything.

Peter Klimek: (27:51)
The biggest and most important thing is really choosing how you want to receive the data. Now, for certain applications you might just say, "Well, security logs is fine. I don't want to spend that much money. I don't want to get that much data coming back." The flip side of that is, for some of your APIs, especially some of your sensitive APIs, if you really need to track a lot of information and you need just more metrics than we provide in the cloud WAF, what I'll usually do is set this to all logs.

Peter Klimek: (28:16)
By setting this to all logs, what we're doing is basically providing you with the equivalent of Apache Commons logging, but with a whole lot of extra data. We provide all of the other metadata that we have around the connecting client, like the client type, whether it's malicious or not, basically all sorts of additional context, geolocation information, things like that. That's all included in the all logs. It's also included in the security logs. As you're looking at APIs, if you need to start doing a little bit deeper analysis on it, switching between all logs and security logs is a quick and easy way to be able to do it.

Peter Klimek: (28:51)
Now the last thing too is I mentioned API security and basically onboarding the application to that. What I'm going to do is I'm going to go into my API site here. Not a lot of traffic. This is just one of my test domains. I'm going to go in here, and I've already onboarded this guy because I was doing a bunch of work with it yesterday. But effectively, if you need to add a new API to here, it's really easy to do. You basically go in, you select Add API, you take your Swagger specification that you have... we now support... we previously only supported Swagger or Open API Specification 2. Recently we added support for Open API Specification version 3. You choose this file, you upload it, and effectively you can specify exactly what this does by default. Right now I've got it set to alert only. I actually want to change that to blocking.

Peter Klimek: (29:45)
What ends up happening is basically, when we change this over to block request, this is going to make the default action for all of the different API endpoints as blocking. Basically, if the application does not conform to the Swagger specification for these different areas... really, what we're doing is we're enforcing the application to adhere to the Swagger specification. Many developers, they think of API specifications as a contract, and really what this is doing is it's ensuring that not just the clients enforce and adhere to that contract, but from a development perspective, you've got to make sure that your contract is up to date and accurate.

Peter Klimek: (30:26)
This is something that really we see mature organizations doing as they're developing APIs and really working with it, but it takes time to get there. A lot of my customers, it literally will take them years to get to the perspective of... they have Swagger specifications that are so good that they generally will write the Swagger specifications before they actually write the API. That's the best practice that we usually like to see.

Peter Klimek: (30:48)
Other times, we have some organizations that will auto-generate their Swagger specifications based on their code. That's actually a great way to do it as well. It's a lot easier than writing it by hand. But ultimately, it is something that you need to make sure that if you're going to put this into blocking mode, you've got to make sure your developers are actually going to be good enough to make sure that that documentation is up to date. Usually, what I recommend is keep this in alert only mode until you have good... you basically understand that this is going to be something that you can actually do. If I also need to move a specific API endpoint into alert mode, I can go ahead and I can do that. I just have to edit this, and I can go ahead and set this to alert only.

Peter Klimek: (31:28)
Switching back over here real quick on the recap perspective, we talked about attack analytics, we talked about WAF and API security, we talked about SIEM logging. Insufficient logging and monitoring, it's done. That ones easy. Like I said, that was the softball. That's the freebie one out of the API top 10. You guys are already WAF customers. Whether you're using Securesphere WAF gateway or you're using cloud WAF, we [inaudible 00:31:53] provide the capabilities for you to be able to check this one off should be no problem.

Peter Klimek: (32:00)
Let's dig into something that's a little bit more complex now. A9, improper assets management. Here's the scenario. APIs tend to expose a lot of different endpoints, more so than a traditional web application. If you think about traditional web applications, when I'm developing a page, if all of a sudden we don't use that page anymore, I just remove that page. Or if I'm thinking about something that we want to include in the future, but we're not using it today, usually I don't write that page or expose it.

Peter Klimek: (32:29)
APIs are different. APIs, developers will expose details and pages endpoints that basically might be used in the future. Or even harder, a lot of times through that API life-cycle management, you have to maintain older APIs and keep old APIs online for a really long period of time. The general way that you can think about working with and managing APIs through its lifecycle is you can easily add to an API, but it's really hard to take away from an API. The reason why it's really hard to take away from an API is because you have to maintain backwards compatibility, or you have to go through this process of basically notifying your customers that, "Hey, we're removing this endpoint." It's painful. Trust me. We just removed an API endpoint in our API. We got a lot of very angry phone calls from that, and we made lots of noise about it. We basically let everyone know for about three months that we were going to do it. We still got a lot of angry complaints. I apologize. We are very sorry for doing that.

Peter Klimek: (33:28)
Something that security teams also need to be aware of it is a lot of times APIs will also expose hidden parameters or endpoints or status check or health check pages. This is pretty common, especially if you're working in cloud services environments, where you need to worry about things like an elastic load balancer. You need to basically have pages for it to be able to hit and to check status and things like that, and sometimes even APM tools will be a poll-based method.

Peter Klimek: (33:55)
And so, generally what this might look like is... even if I have something as simple as a hidden GET /server-status, this might return a lot of extra data. And so of course, this is exactly what I'm going to show you here. I'm going to just do a quick new share here and switch over to a Postman environment. Real fast, in terms of working with APIs, there's lots different tools that are out there. Personally, I'm a really, really, really big fan of Postman. It is hands down one of the best tools for working with REST-based APIs, makes it really, really easy for you to be able to actually save your requests. You can do lots of scripting with it as well. Where a lot of security practitioners are really comfortable working with tools like Burp Suite when they're working with applications, I actually just use Postman for most of my security testing capabilities. The pre-requests scripts and the tests and things that you can do, you can actually weaponize Postman. It's really great.

Peter Klimek: (34:51)
Ultimately, you can see here, this is my GET /server-status request. It's returning a ton of data. This is way more data than you should ever be returning through a server status page, but it gives you really a good point of exactly the type of stuff that some developers will do. A lot of this may be benign. It's really about, hey, how's the server looking? What does it look like from a process perspective? But I've got all sorts of juicy details in here, like internal IP addresses. You know I'm running this on AWS' network because it's EC2.internal. You can see the different CPU types that I'm using and exposing, so you basically know, "Hey, if I need to DDoS this thing..." This is actually a really tiny CPU in terms of how much I've actually provisioned to it. Of course, it's a test server. This is the problem.

Peter Klimek: (35:35)
Now ultimately, one of the things that we do, and part of the reason why we strongly advocate... actually, let me back up here first. Let me jump back into the web browser, and I'm going to walk through what does the mitigation process actually look like before this. There's a couple of different ways that we do this. First of all, if I have something like a server status page, I can mitigate this very quickly and easily by building a custom rule. This can easily limit who's allowed to access it and still keep this page online. This is a good option. This is something that I strongly advocate doing. I'm going to walk through what that rule looks like in just a second.

Peter Klimek: (36:13)
Now alternatively, there's a better option, and this is actually using that API security schema enforcement capability that I showed just a little bit ago. This actually provides much more comprehensive protection. The reason why this provides much more comprehensive protection is because ultimately, if I did not define this in my Swagger specification file, and this is a hidden endpoint that basically we only want to make available, API security is actually going to enforce that and say, "We don't want to allow any hidden endpoints to be exposed."

Peter Klimek: (36:44)
This is really, really powerful, because what this means is that even if you don't know that a developer has added a new endpoint, and they didn't declare it in the Swagger specification, this means that they can't actually expose it until they officially declare it. This is what we mean by contract enforcement with that schema file. We're actually enforcing it down to the letter, and so if you don't declare it, I'm sorry, it's not allowed in.

Peter Klimek: (37:07)
Let's walk through both scenarios here. That first scenario, if I go into our rules here, you're going to see... I already created the rule just to save time, but this is a super, super simple rule. Basically, if I go in here, all I have to do is say URL = /server-status. I set my action to block, block request. Usually block request is fine. One important thing, if you're working with APIs, never use require JavaScript support or require captcha support. Probably don't even require cookie support. The API's probably... depending on the consumer of the API, it's probably not going to be able to pass it, so we usually just rely on blocking request itself. This rule is it. It's super simple. It's really easy. This will shut down that access and at least will stop it.

Peter Klimek: (37:57)
The other thing that you can always do here too is I can always add additional predicates. Let's say I want to actually allow this, but I only want to allow this from certain IP addresses, like an internal IP, where we go and query it. Or let's say I'm using a poll-based method for an application performance monitoring solution, and we're basically collecting data from an external service. I would probably go and add those to an allow list to effectively allow those connections in.

Peter Klimek: (38:22)
Let's look at the other side, though. As I go in and I look at the actual API security, I already uploaded the Swagger. I already basically had it set as a blocking mode before, when I was running this yesterday, so I'm just going to show you what this looks like from an alert perspective. Basically, when I mark that as blocking, and so I set the default action for blocking for whenever we don't see something, what ends up happening is we raise an API specification violation. You can see right here. Now interestingly, one things we're always asked about is in terms of, how do rules execute and how do they work? You'll also see here that end cap rules were raised, so my A9 demo, improper assets management rule, was also raised when I had it previously set to block.

Peter Klimek: (39:04)
We actually triggered on three different violations on one individual API request. The reason is because all of the policies actually technically run on every request, and we just take the highest enforcing action. You can see here I had a request blocked, an alert raised, and then ultimately this was blocked. But you can see that you'll, this is where we had a violation type of invalid URL. Invalid URL on an API specification violation means that this URL was not defined as part of that Swagger specification. This is how we look at basically being able to mitigate this capability.

Peter Klimek: (39:38)
Now, switch back over to Postman here. I'm going to walk you through a caveat. When I go and I block that very first time, this is the response that I'm going to get. Now, there's a problem here, if anyone sees it. It's an API, and I responded back in HTML. No APIs are going to be able to speak HTML. They don't expect this type of data coming back. This is the default behavior, so you need to make sure that you're very cautious of this.

Peter Klimek: (40:08)
Now, what ends up happening is we need this API to respond back in JSON format, because that's the way that it's really designed. To do this, what we're going to do is we're going to switch back over here, and there's a setting. There's actually a couple of settings, and I'll walk through both of them. Under settings for the site, we go into general, and we scroll all the way at the bottom here. There's API security settings, where we basically have abilities to modify some of the default behaviors here, and then there's this poorly, poorly named miscellaneous flag here. I've already told our UX designers, and they're going to fix this.

Peter Klimek: (40:44)
But we have something in here called Enable Content-Based Error Messages or Error Responses. There's very little documentation around this, but this is really, really important. When you check this box, what this means if I go back over into Postman, and I go back over to my server status page now, where I basically have a saved example, if my header comes across, and I basically specify my content type and my accept... the key thing that we're keying off here is the accept header. The accept header is basically what the client is indicating to the server, "This is what I expect to get back in terms of a response." If I set this to application JSON, and I have that header set or that flag set in the settings, this is the error message that I'll get back. Instead of getting back HTML, now I'm actually going to get back JSON.

Peter Klimek: (41:38)
This is great. This is exactly what we need in terms of the API. There's just one problem. If we go in and we look at the error response that's defined in the Swagger specification, if we look at how the API is designed, it unfortunately doesn't match what we're expecting. The error code comes back. You can see here that this is a 403 bad request, but ultimately, when an unsuccessful request to this API comes back, this API actually is generally expected to return a status object which contains success false, a code that's actually pasted back in the body that matches 401 unauthorized here, and a message. Especially for a lot of your applications, they're going to be coded to expect this type of response, so while it's great that we were able to go and actually return JSON back, it has no idea what to do with this because it doesn't look like the JSON that's actually defined.

Peter Klimek: (42:33)
Luckily, we've got a fix for this. I'm going to go back over here real fast, and if we go back into our rules, this is another new feature. We've released it. I actually didn't even know about this until one of my colleagues let me know about it, so that's how stealthy we are about releasing some of these features. Ultimately, we have this rewrite response category. I'm going to dig into this in just a second a little bit further, but you can see here we've got our... Whoops, wrong one. You can create custom error responses for APIs in here.

Peter Klimek: (43:07)
It's pretty simple to set up. Don't define any predicates to match, unless you want to make specific match criteria based on whether this XML or JSON. We basically can support both. And then ultimately, what we want to do is we want to set the rule action to rewrite response error. We can set the error type, so basically the HTTP response code. In this case, I'm going to basically just say access... Sorry, this is going to be based on any type of access denied issue, but we have lots of other different error types that come up, so basically any of these you can set. Basically, if there's backend server errors and things like that, I can modify that. And then the response status code. In this case, I'm going to go ahead and I'm going to say this was a bad request.

Peter Klimek: (43:50)
And now in the response body, I can actually go in and I can define what the actual structure looks like. Here's my status object here, and then I'm going to go ahead and I'm going to create a new details object, and I'm going to put all of the various details that we can... in the placeholders that we have to ensure that we get the correct messaging and everything across.

Peter Klimek: (44:10)
Now if I go back over to Postman and I show you what this looks like, I basically have... let me switch to a good error response looks like, best error response looks like. Here we go. I have all that same information, but now it's actually following in the same structure as what the API is expecting, and I'm returning a 400 bad request. This is awesome. This is something that I really, really strongly recommend as you're starting to onboard your APIs. Take the time to make sure that the actual response and error pages that we're returning actually follow and match what the API specification and schema looks like.

Peter Klimek: (44:56)
There we go. Just a quick recap on improper assets management. Number one, custom rules. They work in a pinch. They're a good way to be able to get you started, and if you need to shut down a vulnerability really, really quickly, more often than not we see this as a result of a pen test. Good way to do it, but schema enforcement is ultimately a better way and a better solution to be able to do this, because it's more comprehensive. You don't have to play whack-a-mole. You can basically enforce that contract. Of course, last but not least, don't forget to set your error responses.

Peter Klimek: (45:26)
Got a few minutes left here. I'm going to try to get through this. A7, security misconfiguration. This is a big topic. There's actually lots of different vulnerabilities that fit into this one category. I'm going to talk through probably the most common one that we see. It basically comes down to the fact that APIs are often used to power single page apps and mobile apps, and a lot of times the exact same API is used to work across both. When the API endpoint is hosted at API.example.com, but the single page app is hosted at my.example.com, the single page app must make what's called a cross-origin request to access that data.

Peter Klimek: (46:02)
What does this look like from a flow or sequence diagram? Basically, SPA client says, "Hey, GET /user HTTP/1.1. Here's the host, API.example.com. Origin, I'm running from my.example.com." API server responds back, and it says, "Okay, cool. Here you go. Access-Control-Allow-Origin is set to *, and Access-Control-Allow-Credentials," which is the CORS header that basically allows you to pass across authenticated session information, like a cookie, "I'm going to set that to true." And the browser is smart enough to basically say, "No, we're not going to allow this."

Peter Klimek: (46:37)
The reason why the browser is smart enough to say that we're not going to allow this is because you're trying to basically say, "Access-Control-Allow-Origin is *, and Access-Control-Allow-Credentials is true." This is basically way too permissive. The browser manufacturers basically knew this is what developers were going to do, and they basically said, "No, we're not going to do that." So developers basically came back and said, "Okay, well, we're going to reflect back the Origin header to overcome browser restrictions. What does this look like? They basically say GET /user, and it makes that same exact request, and the API server now basically responds back with Access-Control-Allow-Origin, my.example.com, and Access-Control-Allow-Credentials is true, and this will work.

Peter Klimek: (47:21)
Now, there's nothing inherently wrong with this approach. This is actually the recommended approach of how you work with this, but there's a caveat. You have to make sure that you're using an allow list of approved Origins. Otherwise, an attacker can basically go and use any other origin server or any other site across the web, interact across Origin with your request, and be able to basically interact with it. Interestingly, what this will make the application vulnerable to is cross-site request forgery.

Peter Klimek: (47:52)
Let's talk about how we can actually mitigate this real fast. I'm going to switch back over here into my console. Getting really close on time, so I'm going to try to blow through this one quickly. We'll make the slides in a presentation available. If I go in here and I look at my responses, I'm going to go back to my rewrite response capabilities, and on this one I have my A7 demo, which is enforcing CORS header. In here we basically are looking for instances where the header value, the Origin, does not match API.[inaudible 00:48:27].me, or actually in this case... sorry, that was actually even wrong. I wanted to make this my.[inaudible 00:48:32].me in this case, which is basically my endpoint that I want to have.

Peter Klimek: (48:38)
What I want to do here is I want to rewrite this response header. I can basically say Access-Control-Allow-Origin, and I'm going to set it to API.[inaudible 00:48:48].me. Basically, what this is saying is that regardless of what the request comes back with, I'm going to go ahead and I'm going to make sure that this is actually correct. If I go in here real fast and I switch over to Postman, I'll show you what this looks like.

Peter Klimek: (49:04)
Over here, I have my head request, where basically I have... head request is used as a preflight, basically, for a lot of CORS in the browsers. Basically, what you can see here is I'm specifying somesite.example.com. I can tell that this is going to be vulnerable to this if basically the server responds back... Give me one second here. I have saved examples, luckily. You can see here in my response and the headers here, you can tell that this is going to be vulnerable because it's going to actually reflect back somesite.example.com. What I specified as the Origin header here, it basically just said, "This is what I'm seeing back." This is what we would consider to be a security misconfiguration for an overly permissive CORS header.

Peter Klimek: (49:56)
Now, with the fixed version of that, when I implemented that rule, basically what it said was that regardless of what I had from an Origin, it's automatically going to reflect back the origin that I specify, so the API.[inaudible 00:50:10].me. This is an easy way basically for you to go in and fix this. Now ultimately it's going to be something that has to be fixed at either the API gateway level or the code level, but it's a quick and easy way to be able to do that.

Peter Klimek: (50:21)
Switching back here, I'm going to just go ahead and do a quick finishing up before I get yanked by Chris. I feel the hook coming. Last but not least, security misconfiguration. Things to recap, developers like to break things. I'm a developer. I like to break things. Response rules, they allow you to fix things, so they're great. We recommend using them. It's the reason why we built I. But as I mentioned, security misconfiguration, there's a big topic. There's lots of different things and capabilities that are out there, so watch out for other misconfigurations.


#APISecurity
#Webinar
#video
0 comments
839 views

Permalink