API Detection and Assessment: What they don't tell you in class...


API’s  (Application Programming Interfaces) are backend services  which expose an interface which can be used to connect to and transact or read/write information to and from a backend system. The are super useful and a great architecture decision delivering flexibility and extensibility of a service.

API’s deliver functionality once the client service knows how to “talk” to the API. API’s generally sit behind a HTTP port and can’t be “seen” unlike a website but they may deliver an equal level of value and functionality to the requesting client.
Many websites may use an API but the User does not invoke the API directly but rather the Website /App is a proxy for the API. API’s are not built to be human readable, like a website, but rather machine readable.

There are two challenges relating to API security assessment:

1. API Discovery: Do we have an inventory of all API’s deployed on the public Internet.
You may have API’s hosted on systems behind HTTP ports but are undiscovered. They may be well known but they may also be old or development deployments which are forgotten about. We can’t secure what we don’t know about.

Adequate assessment involves coverage of entire corporate ranges (CIDR ranges), large lists of IP’s, domain names (FQDN’s) and using a multi-layer probing methodology detailed below:

API discovery is a combination of both host layer and web layer investigation. Some are easier to discover than others.

Discovering API artifacts
Discovery of API’s may require multiple layers of probing. If we don’t know how to invoke a given API. API identification across may levels is required to accurately provide a confidence interval of if an API is present or not.

Detection probes (in edgescan) include: • Known API format requests • HTTP status type checks • TLS Certificate checks • API format Requests (SOAP/JSON etc) • Standard and Non-Standard API indicators • Manifest file detection • Hostname checks • Cert common name checks • Common API routes detection • API description files (Swagger/WADL) • SOAP protocol detection • JSON/XML response analysis • API endpoints Metadata detection • API routes in HTTP attributes • Cookie based API detection

2. API Assessment: Keeping pace with change and development.

Assessment of API’s can be difficult as the assessment methodology requires knowledge of how to communicate and invoke the API.

Running a simple web scanner against an API simply does not work. A scanner would just hit an initial URL and not know how to invoke or traverse the various API calls.

Good API assessment should have the ability to read/ingest descriptor files in order to understand how to communicate and invoke the API. 
Once this is done a scanner can assess the API method calls. 

As the development team alter and change the API the assessment technology can read the newly updated descriptor file and assess the API including new changes. – Keeping pace with change.

Assessment of vulnerabilities specific to API’s is also important. Items discussed in the OWASP API Top 10 are an important aspect to true API specific testing.

Devops: In a DevOps environment the descriptor file can be used to determine change/deltas since the last deployment of the API and only assess the changes saving valuable time in a fast DevOps environment - Iterative testing when frequent change occurs.



For more on edgescan's API services see:

Comments

Popular posts from this blog

Edgescan, why we do what we do.....

20 years of Vulnerability Managment - Why we've failed and continue to do so.

Edgescan and Huawei - Cybersecurity - Irish Times Article and Panel Discussion