Share:

Apache Optionsbleed is yet another vulnerability in an ever-growing list of threats targeting REST-based back-end applications aimed at compromising server memory. In this case, it is Apache’s https program can be compromised by using HTTP method OPTIONS as described here:

Forum Sentry protects against this attack as one of the many API threat vectors that Sentry protects against. This particular threat vector was detailed as #3 in our “Top 10 API Threats” list. The HTTP method is heavily utilized in REST-based apps and services where commonly used HTTP methods such as POST, GET, PUT and DELETE for CRUD (Create Read Update Delete) services. Forum Sentry API Security policies restrict the methods allowed to be used. Additionally, these restrictions can be user-specific with granular authorization that can be applied to any HTTP method.

Forum Sentry protected 100% of its customers from Heartbleed, and today protects 100% of its customers from this latest OptionsBleed vulnerability.

Share:

In this presentation, Jason Macy – CTO of Forum Systems, provides insight into best practices using a privileged access management (PAM) solution.

PAM solutions are built from traditional Identity Access Management… However, these IAM solutions are designed only to establish a trusted user and are not capable of enforcing user behavior based on the information being sent and received

Share:

The Instagram API vulnerability was exposed via a REST API used by the Instagram Mobile App to perform a password reset. By capturing the format that the Instagram App used to make the password reset, a brute force attack was then created to iterate permutations on this API to extract information about other users returned back in JSON format.

This attack was exposed because of the lack of API security mechanisms protecting the API. An Instagram spokesman told Fox News. “We fixed the bug swiftly and are running a thorough investigation.” Guess what, too little too late! With API breaches, the damage is done.

This is precisely why API Security should not be left solely in the hands of API developers. Developing secure APIs is certainly the right intent and approach, but there is simply no way that developers should be tasked with understanding and protecting against all of the security threat vectors that exist in the API realm. This would be akin to foregoing a corporate firewall, and instead just relying on your developers to prevent network attacks.

API breaches represent the continuing saga of cloud and mobile applications being exposed by API development toolkits that do not have inherent API security capabilities enabled. This is largely because API developers are not security specialists and API toolkits and API Management platforms are not security platforms. This increasing trend of API vulnerabilities will continue until the industry recognizes the need for API Security Gateway technology to protect their APIs. If you have a Web Application, you use a Web Application Firewall (WAF) to protect it, you don’t rely on your developers to protect the application. If you have an API, you use an API Security Gateway to protect it, you don’t rely on your developers for this.

The API Security wake-up call is growing louder each day, breach by breach.