Products

Solutions

Resources

Search for API Security Tests

Akto as an API Security Automation Case Study

API Security Automation case study using Akto by Oleg Greb, Visa Security team

akto-case-study
akto-case-study
akto-case-study
Oleg Gryb - Block

Oleg Gryb

8 mins read

Introduction:

In this blog, Oleg - Security Partner at Block talks about the following:

  1. Five Pillars of Security Automation:

    • Capturing Traffic to discover APIs

    • Automated API Inventory

    • Adding test templates to find vulnerabilities

    • Automating testing

    • Collaboration amongst teams

  2. How to use Akto to do the above five?

Looking Ten Years Back

When I look 10 years back, an annoying and persistent question pops up: did we just lose those ten years in API security automation? The answer is not that obvious and details are important. Probably it’s just my PoV that becomes more pessimistic as the years are passing by.

10 years ago I worked for a mid-size fintech company doing application security and watching all those “need for speed” trends like DevOps, DevSecOps, and ultimately DevSecOpsAndEverybodyElse.

The problem with security automation was always a bit different compared to traditional testing where the results are more deterministic than in security where tools, security engineers, and product engineers keep arguing about vuln’s severity the same way as they did 10 years ago.

The situation below happened just recently, but it could easily happen in the distant past.

"There are some things in this world ... that will never change"

First Stab

There was definitely a disconnect between fully automated CI/CD process and mostly manual security assessments, be they manual application design review or penetration testing.

Burp Suite was as popular then as it is now, but I don’t believe that much progress was made in the last 10 years to make it more suitable for automation. It’s still very much a UI-based workbench for security engineers working as individual contributors.

I’ve tried to fix it then by creating a command line tool written in Ruby and integrated with Burp through extensions. An idea was to use a Ci/CD regression test that was run before each release as a payload generator hooked up to a Burp’s proxy. We implemented the same approach with OWASP ZAP to improve the fidelity of our findings.

The advantage of that approach was that it could be easily integrated with the pre-release regression test and with a Treatfix security dashboard that was used for triaging findings and pushing them to PD’s Jira if they were valid.

10 years back

An obvious disadvantage was that it was a passive scan since we’re afraid to break the regression test logic that would be definitely the case with active scan and injections. This framework was successfully used in an IoT startup whose mission was to connect all devices and people on Earth. I don’t know where we would end up with all that by now, but the startup went down taking our project with it.

That’s why I like OWASP and their chapters more than startups. They are definitely more persistent and you can still find our 2016 AppSec Cali presentation if you want to see the details of our approach

These Days

These days I work for a bit bigger and more innovative fintech company and am thinking: how can we implement a dynamic security API scanner that would be more efficient in regard of findings and supporting processes? 

Many cool new things have been implemented in Burp: more languages to write extensions, more OSS examples for those extensions, ActiveScan with tons of out of the box injections in Pro version, more parameters and config files that you can pass on a command line.

I decided to use it again, but write my extensions in Python this time, and integrate with our own security dashboard allowing me to review the findings before anything is submitted to product teams’ Jira.

Now

That works, and even finds some useful bugs that PD has already agreed to ti fix, but still I’d like Burp to be more friendly when it comes to automation:

  • Python 3 is not supported for extensions since it uses Jython that supports Python 2.7 only

  • It’s not possible to pass scan details and scan tasks config on a command line

  • It’s not possible to retrieve Burp’s collab server interactions originated from ActiveScan programmatically

Looking to the Next Ten Years 

Just like any other manual work in Security (threat modeling, design review, manual code review) penetration testing is still not scalable.

Security engineers need to test dozens of services in each BU to achieve a good level of confidence in the integrity of all their systems, but in reality we could not assess even 5% of them. Frequent changes  introduce new threats and vulnerabilities to the systems that have been already tested.

Since hiring new testers is not scalable either, we need to find ways to automate the initial testing as well as testing of all incremental changes to the existing systems.

An additional benefit of the approach described in this document will also include: 

  • Better visibility to what has been already tested and what not

  • A statement of work for each item that we have in the assets inventory

What (aka Pillars)

There are a few major tasks that will allow us achieving a better level of security testing automation:

  1. Implementing automatic (e.g. through AWS/GCP traffic mirroring) and semiautomatic assets/API discovery (e.g. coming from manual testing by Burp)

  2. Creating inventory of all API’s and apps that we need to test

  3. Creating templates for different categories of vulnerabilities 

  4. Creating or adopting tools allowing to retest API’s quickly using the existing template

  5. Creating a collaborative framework allowing to share the inventory items and templates between team members

How 

Let us take a closer look at each item described in the previous section

Discovery

Asset discovery is the first step for any automated security framework allowing to find documented or even undocumented service either in automated or semi automated manner, e.g. 

  • Mirroring AWS traffic and finding API calls automatically

  • Mirroring GCP traffic and finding API calls automatically

  • Using Burp (or other manual testing tools) traffic to find and store API calls with their payloads

Inventory

We need to create a data repository where all testing entities will be stored. For each entity at least the following information should be stored:

  • Name

  • Endpoint

  • Date of discovery

  • Authentication type

  • Request and response format preferable in formal notation such as a swagger document

  • Sensitive data elements with DSL levels

  • State, e.g.

  • Documented/undocumented

  • Deprecated

  • Last tested date

  • Planned EOL date

  • All prior reports covering testing for this API

Templates

Templates are reusable code snippets written in common languages (e.g. Java, Python, Ruby, etc.) or in popular security specific notations such as Nuclei. They usually include payload that needs to be sent in a request and could include parameters enumerated through common attack techniques such as:

  • BatteringRam

  • Pitchfork

  • Clusterbomb

While templates are usually specific and will work with certain API calls only, categories of vulnerabilities are common and well defined, which means that we can have many templates in each category (or sub-category)

Testing Tools

While Discovery, Inventory and Templates are important even without tools (e.g. it will definitely increase visibility to our security posture and help new hires to create attack payloads using existing templates), tools and collaborative frameworks are the ones that could really make a difference when it comes to automation.

Good tool should allow:

  • Selecting an existing API from inventory

  • Finding a template related to this API

  • Modifying the template quickly

  • Running an attack against the selected endpoint using the modified (or original) template

Collaborative Framework

All pillars described in the prior sections allow a single security engineer to find assets, create attack payloads, run an attack, and store a result. However the whole organization can benefit tremendously if artifacts created by a single engineer can be shared with the team.

Even though security engineers usually work independently on their project, the attack patterns are common, and a template created for application A could often be reused for testing a  application B  

Having all testing results in one place is also good from analytics point of view since it simplifies finding common threats and vulnerabilities that could be addressed by Infosec in a centralized manner.

Monthly product updates in your inbox. No spam.

Hope: Akto as a Security Automation Case Study

Akto is an early stage startup in the business of automating security API testing. While Akto addressed all described pillars at a conceptual level well and demonstrated how they could be implemented, the implementation itself can be improved.

The limitations that Akto has mentioned include: (1) requests must have a body; (2) response must be in Json format, which doesn’t allow using gRPC that becomes popular lately

High Level Architecture

There are three options for deploying Akto Dashboard:

  1. On-prem local deployment

  2. Akto cloud

  3. AWS/GCP Deploy

Only the first one was tested in the scope of our quick PoC:

  1. Installing on Mac laptop was not possible due some Doecker related issues

  2. Installing the Arch Linux box was very fast and straightforward. We also had to install Nginx to be able to serve custom nuclei templates

There are three sources used by Akto’s Discovery

  1. Burp traffic

  2. AWS mirror

  3. GCP mirror

Custom templates

  1. Nuclei templates served through HTTP can be used, which were tested in the PoC

  2. There are examples of templates written in Java in Akto’s repo

Discovery

There are three Discovery mechanisms provided by Akto (only the first one was tested in the scope of DWW):

  • Integration with Burp

  • AWS traffic mirroring

  • GCP traffic mirroring

After an API was discovered it can either be sent to the Akto’s Dashboard through its API automatically or it can be manually exported to HAR file from Burpsuite and then imported into the Dashboard

Inventory

API entries will be stored in Mongo DB after they have been discovered. Inventory can be seen in the Akto’s Dashboard UI

Templates

While a number of templates are available in Akto Dashboard by default, custom templates can be created through the UI by providing an HTTP link to a Nuclei script:

Adding Nuclei Template

We’ve created an Nuclei script for testing an XSS in ‘name’ parameter and successfully added it to Akto’s Test Library

Nuclei example for XSS

The new custom template can be seen in Akto’s testing Dashboard now

Creating new template for XSS

Testing Tools

Akto itself can be used for retesting all API that were imported to their framework. A user would need to select an API and then apply one or more templates available in the Testing section.

The Nuclei template described in the “Templates” section was used to test and API exposed by swagger.io.

First we submitted a request in Repeater to their Pet REST API:

Testing Template

Akto plugin exported it automatically to Akto Dashboard at which point we were able to retest it with the custom XSS Nuclei template:

Running Template

Testing history is stored in the dashboard with test results showing if the testing was positive. In the case that we’ve tested XSS was not found in the ‘name’ parameter.

Testing History for an Endpoint

Collaborative Framework

Akto allows other team members to be invited to use and contribute to the existing tests, however this option is available in Akto or AWS/GCP Cloud version only and was not tested in the scope of our PoC.

This blog was originally published here by the Author Oleg Gryb, Security Partner at Block.

Follow us for more updates

Follow us for more updates

Follow us for more updates

Want to ask something?

Our community offers a network of support and resources. You can ask any question there and will get a reply in 24 hours.

Want to ask something?

Our community offers a network of support and resources. You can ask any question there and will get a reply in 24 hours.

Want to ask something?

Our community offers a network of support and resources. You can ask any question there and will get a reply in 24 hours.

Table of contents