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

By -

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:
https://landing.edgescan.com/apitestingjourney

Comments

Post a Comment

Popular posts from this blog

By -
Image
The HSE Data Breach and the State of Irish Cyber Security Many years ago, shortly after I founded the Irish chapter of OWASP ( http://www.owasp.org ) (in 2007??) we were delivering free application and software development classes to anyone who wanted them. It was a local low key affair but every class we delivered was "sold out". We have 60-80 folks mostly developers willing to spend 4-5 hours on learning the fundamentals of secure application development and testing. I suppose we felt cyber security was an important issue because that's what we did. At the time many folks in business felt cyber security was an overhead or a "tax" and did not give it much time. A few years later (late 2010) when the the foundation of the NCSC (National Cyber Security Centre) was announced, a few of us (local OWASP Ireland leaders) wrote a number of emails to the Irish government offering free cyber security training. As we were working for a non profit (501.3c) charity (OWA...
Read more

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

By -
Image
I recently was interviewed by the Irish times on why is everything getting hacked and how can we change the game.... https://www.irishtimes.com/special-reports/cybersecurity-focus/criminals-have-an-inbuilt-advantage-in-the-great-cyber-arms-race-1.4651078  A recording of the Panel with Andy Purdy, CSO of Huawei North America. https://www.youtube.com/watch?v=cQJ1uSQ4IEk&t=33s Both are decent and worth a listen.
Read more

How Simple can it be.....XSS Prevention....

By -
Cross Site Scripting is sill a very common web vulnerability. Generally it is used to attack clients/users. It can be used for malware upload, botnet hooking, keylogging, a payload delivery system for clickjacking and CSRF attacks and much much more, all for 6 easy payments of $9.99...sorry got carried away there :) But is is easily preventable. You dont even have to know what XSS (type 0, type 1, type 2, DOM, Stored, Reflected) is to prevent it. One pretty simple way to prevent XSS is to use the OWASP ESAPI (Enterprise Security API). A very easy tool to use/invoke. It's also managed and attended to by Chris Schmidt ....A great guy... Regardless of what it does....if there was a mandate to use it on all redisplayed external input a site could become virtually XSS free!! (all for 6 easy payments of......). It's easy to deploy.... 1. Include in JSP (Java version) 2. Invoke in JSP 3. Job done!!! We include it by <%@ page import="org.owasp.esapi.ESAPI...
Read more