API Spyder: Doing the (Seemingly) Impossible

In my role at Cequence, I get to interact with our customers as well as with teams associated directly with product creation, data science and customer support. While sounding trite, these do some amazing and seemingly impossible things, for example:

I have witnessed some interesting attacks and creative solutions for detection and mitigation, in real time. We have implemented solutions to stop automated attacks on our customer’s application platforms as well as finding API errors that needed (and received) attention. All of the work done is done based on ML-based analysis on the customer data, none of which includes client side signaling.

Many times, I watch the data science team pull together data and start their work finding and separating the outliers in the normal data streams, uncovering patterns that then lead to the creation of detection mechanisms. The requested URL for an organization is a great example. When most of the traffic is going to example.com/cart, but some outlier traffic is going to example.com/carts, we can create a fingerprint for that outlying traffic. The traffic analysis provides the data without client side signaling and often our customers think what we are doing is impossible.

Alerts go off and the CQ Prime Threat Research Team jumps into action to make sure our mitigations are catching things and minding our customer’s “stores” to ensure that some sneaky attacker isn’t committing fraud. Often this is just monitoring and hunting for possible new attack methodologies. Attackers often re-tool their efforts in a matter of seconds and staying on top of attacks requires automation. Being able to monitor events means when one of our clients was concerned about credit card fraud, we found the traffic through volume analysis and stopped it with behavioral policies. Many of the day-to-day things the team does seem impossible.

The way our team is pushing the boundaries of what’s possible really hit home for me while attending Black Hat where I was presenting on how our newest product, API Spyder, can locate APIs via several different methods. While wandering the show floor, I asked some of the API security vendors how they generate an external view of their API footprint and was told, “that’s impossible”.

It is true that contextual cataloging of API endpoints requires some kind of app instrumentation or decomposition, in order to do real time assessments. However, if you do not know where the APIs are, instrumentation becomes exceedingly difficult, or even impossible. What if parts of your organization stood up products that have default APIs? What if we went from Version 5 to version 6? What if, what if, what if? The answer is that in order to stay ahead of attacks one must have an accurate inventory and needs to be constantly covering the APIs they are aware of as well as looking for what they aren’t aware of. In order to finding your APIs, new APIs, shadow APIs, etc…. one must search for them as well as instrument them for possible problems in the data flow.

The good news is there are many ways to find APIs in an enterprise infrastructure, it just takes an understanding of modern app infrastructure and an understanding where to look for the endpoints.

During a chat about the “that’s impossible” responses with our founder, he said, while writing, the team is doing the impossible. The consensus was “It isn’t possible to find APIs without knowing they are there.” Again, something that seems impossible. But is it?

Using just your corporate domain, API Spyder analyzes your API footprint giving you a view of what an attacker sees when they target your web applications. This is made possible via utilization of several partial techniques for finding API endpoints as well as finding default services that may be enabled with API endpoints enabled.

If you are facing an impossible challenge, engaging with an organization that regularly does impossible things might just be how you can achieve your goals.