Company News
Introduction
I sometimes wonder in the security industry if part of the issue with adoption of good practises is sometimes partly a self-created problem, don’t get me wrong I’m not saying people go out of their way to make it harder to secure things but I think that getting the right information to the right people in the right format is important.
An area I find that general/common knowledge is lacking is around security testing (penetration testing, adversary simulations and red teaming). In today’s blog I’m going to talk through the high-level steps that are conducted when testing APIs to try and remove some of the veil that I think surrounds this space. In this blog I’m going to talk through our approach to API testing to help you not only understand how we do it but also to help you scope your testing requirements, regardless of who does the testing! After all, sharing is caring!
Getting Started
The first thing we are going to want to do is ensure our API and services are secure, for this starting point we strongly recommend taking a grey/white box approach (within reason, some systems have third party propriety components so you can’t always access everything). But to start with we want to know that:
- Our infrastructure, platforms and data are secure
- Our API is secure from the inside out perspective
This way we are making sure that our company and customers/consumers are protected.
Using a Third Party
To do this it’s common a third-party firm will be engaged. So, let’s think about a sensible and good practise approach to ensuring we are getting the most out of the test, because the aim should be to ensure:
- Third party are enabled to understand the known good working on the service
- They have a scope which enables them to test likely threat scenarios
- They are efficient in doing so
I’ve personally worked with some orgs who decide to conduct an API test by saying here’s the endpoint, there’s no docs and there’s no baseline of normal operation, you have a day and good luck.
mRr3b00t
This really isn’t a great approach unless you have explicitly explained that you want to emulate a scenario where a threat actor has very limited resources and motivation and you want to test very little of the API attack surface. That’s not really where most organisations are when we talk to them.
Scoping
Before we get started, we ask for the following during scoping:
- A copy of a postman file (without authentication keys/creds)
- Access to API docs (swagger or other documents)
This not only helps us scope the testing scenario but it also means that when we are testing we spend more time on focused tests than simply trying to work out how your service works (that means better bang for your buck!)
Key Milestones
So, let’s break this down:
- Understand known good
- Understand the API design
- Identify likely risks and vectors of attack
Getting our hands dirty
One we have a view on the known good scenario it helps us then conduct testing.
- One of the activities is the validate the API against known good practises for API security
- Review (where possible given the scope constraints) against API good security practises checklists
- We also want to attack the API by fuzzing
- Look to see if there are any business logic flaws, we can leverage
- We also want to attack the API by reviewing against common API vulnerabilities
- OWASP API Security Top 10
Part of secure service design, release and operation also include activities such as:
- Asset Management
- Configuration Management
- Change and Release Management
- Logging, Reporting and Alerting
- Proactive Security Monitoring
- Vulnerability Management
A traditional technical control test will likely not include methods or mechanisms for this so we adopt a consultative approach to work with you to ensure you understand what is and isn’t included and where possible we like to work with your teams to ensure secure service operations are considered and validated.
Useful Resources
https://owasp.org/www-project-api-security/
https://www.templarbit.com/blog/2018/01/10/api-security-checklist/
https://github.com/shieldfy/API-Security-Checklist
Summary
API security testing isn’t particularly different to general security testing however it’s important that the key common API vulnerabilities are tested alongside ensuring that the API can be operated in a secure manner. Too many organisations seem to think “It’s only an API, what can go wrong” then find out the hard way when their main web apps are breached, and they have lost all their customer Pii. Our API testing services take a consultative approach to give you a view on how robust and resilient your API services are, and they go beyond just throwing bad packets at you!
