Justin Bieber and Selena Gomez ramp up on API Security

When your ex-girlfriend's Instagram gets hacked through an API security breach, and your risque pictures go viral, you rapidly try to understand the root cause of this breach and commit to becoming an API security expert.

Maybe that is expecting too much from Justin Bieber and Selena Gomez, however, it should be something that should make API security concerns viral and mainstream. Initially, the API security breach was purportedly limited to "high-profile" users ala Gomez, et. al.

The latest report shows that database of over 10,000 users may have been exposed and potentially over 6 million users' data scraped for sale @ $10/query. For details see:

Site sells Instagram users’ phone and e-mail details, $10 a search

Technical Details: Here are the steps that the hackers may have taken for this API Security Breach:

1.  Pick outdated Instagram mobile app version 8.5.1
2.  Create a valid Instagram account
3.  Select password-reset option.
4.  Use web-proxy servers to act like the mobile app calling the Instagram Servers.
5.  Modify the request at the web-proxy with the user id of the celebrity.
6.  The Instagram server would send a JSON-formatted response with personal information.

For this particular attack, it seems like a legitimate user session is first established. Then a password-reset request with a user id other than the initial user is sent to the Instagram server that leaks the *impersonated* user's email address and phone number via a JSON response. I wondered why a password reset would send this data in a JSON response - perhaps because the mobile-app validates it against what it has stored internally on the smart phone. The web-proxy in the middle doesn't care about this validation. Had JSON Web Encryption (JWE) been enabled on the JSON response, the web-proxy-in-the-middle attack would have only seen the encrypted data.

API Security and MySQL -- A match made in Hell

What do API Security and MySQL have in common? Not much one hopes, especially if you are responsible for implementing enterprise-wide API Security. When picking any security product, particularly an API Security Gateway, an enterprise should carefully evaluate the architecture and components of the product that it's purchasing. If the components such as Operating System, PKI security stack and policy storage mechanisms are not secure, then an enterprise is increasing its API attack surface area rather than mitigating it through an API Security Gateway. And please don't have your security policies stored in a database such as MySQL -- a prime target for hackers. If you security policies are stolen, your entire enterprise API ecosystem is compromised. Alexei Balaganski's article -- "The Cargo Cult of Cybersecurity" -- critiques our false sense of security. We spend billions of dollars (120 Billion in 2017) on cybersecurity products that are poorly developed, improperly or never deployed, and rarely tested by a third party. By doing so, we are creating a false sense of security. Here is an excerpt from Alexei's article:

However, the exact reason for my today’s rant is somewhat different and, in my opinion, even more troubling. While reading the documentation for a security-related product of one reputable vendor, I’ve realized that it uses an external MySQL database to store its configuration. That got me thinking: a security product is sold with a promise to add a layer of protection around an existing business application with known vulnerabilities. However, this security product itself relies on another application with known vulnerabilities (MySQL isn’t exactly known for its security) to fulfill its basic functions. Is the resulting architecture even a tiny bit more secure? Not at all – due to added complexity it’s in fact even more open to malicious attacks.

For complete article, see: The Cargo Cult of Cybersecurity."

API Security - 4 Quick Steps to Lockdown

API Security is complex! Vendors like Forum Systems, IBM, CA and Axway have invested almost 2 decades of engineering effort and significant capital in building API Security stacks to lockdown APIs. The API Security stack diagram shown below is essential for rapidly locking down APIs. In the article, we review "The Four Pillars of API Security" --- SSL, Identity, Content Validation and Architecture.

API Security Stack

Before addressing the Four Pillars of API Security, it is essential to recognize that a robust PKI is a must of enterprise-grade API Security. Without proper key life-cycle management, the API Security Pillars cannot be built. Once a solid PKI foundation is in place, the following API Security four pillars should be built to ensure that an enterprise API attack surface area is significantly reduced. To implement API Security:

API Security - vendors look to develop NG-WAFs

API security is now a central concern for Web Application Firewalls (WAF).  For over a decade, WAFs have been  a necessary component of most web-based applications deployments. WAFs typically sit inline and protect inbound and outbound corporate traffic against vulnerabilities. These vulnerabilities have been cataloged by OWASP Top 10 for over 15 years. 2017, marks the first year where API security has made it in the OWASP Top 10 RC1.

Radware, a WAF solution provider has published an interesting article titled "Why there is no API security" where they make the following key points:

No single part of the application, nor any part of normal Internet filtering firewall defense, has enough visibility into the context to stop business exploits. Some examples of business logic exploits are:

• Modification of authentication flags and privilege escalations Business constraint exploitation/modification or business logic bypass to generate fraudulent transactions

• Requested parameter modification Developer’s cookie tampering and business process/logic bypass 

• Exploiting clients’ side business routines embedded in JavaScript, Flash, or Silverlight Identity or profile extraction 

• LDAP parameter identification and critical infrastructure access 

Business logic attacks are not trivial in their consequences and are successful on even the largest organizations. A few of the large organizations that fell victim to business logic flaws are Facebook, Nokia, and Vimeo.

Radware's perspective clearly shows that WAFs have to extend their world-view to address API security. It's not just about protecting websites - with APIs becoming a connective tissue of all portal, device, and cloud communications, corporations are looking at Next Generation WAFs to now include significant API-awareness and API-borne threat mitigation capabilities.

API Security - SD Times Review of OWASP Top 10 - RC1

API Security has finally made it into mainstream security consciousness. The premiere web application security OWASP Top 10 Threats has published its Release Candidate 1 (RC 1). SD Times provided a comprehensive overview on the implications of including API Security as a part of OWASP Top 10 2017 - RC1. Here's an excerpt for SD Times article:

The next major addition is Underprotected APIs, since the use of APIs has exploded in modern software, said Williams. There are a variety of protocols and data formats used by these APIs, including SOAP/XML, REST/JSON, RPC, GWT, and others. It’s important to note that these APIs are often unprotected, and they contain numerous vulnerabilities, said Williams. He also added that these APIs represent a “major blind spot” for security programs in organizations, and OWASP is helping to refocus teams on this expanding problem.

“To me, T10-2017 reflects the move towards modern, high-speed software development that we’ve seen explode across the industry since the last version of the T10 in 2013,” said Williams. “While many of the vulnerabilities remain the same, the addition of APIs and attack protection in this version is designed to focus organizations on the key issues for modern software.”

A10 - Unprotected APIs snapshot is presented below:

Relevant sources:

• OWASP Top 10 2017 - RC1
• Forum Systems - API Security 
• SD Magazine Article

Buy vs. Build: API Security Solutions

Three factors that will help determine the best approach for your organization

In the world of application security, there are numerous options in the marketplace for both buying and building.  Purchasing a centralized API security solution isn’t cheap but it can be less expensive than building your own, depending on your situation.  In this blog post, we will look at three critical factors that will help you determine which API security solution is best for you.

The number of API security policies needed

This might seem obvious but the number of security policies needed is one of the easiest factors to help determine which option is best for your company.  The math is pretty simple, the more applications you develop, the more security policies you will need. And, the more security policies needed, the longer it will take to code them.  Configuring a security policy through a centralized API Security system takes much less time than building it from scratch.  The key is to figure out the threshold where it makes more sense to buy instead of building them yourself.

It’s also important to consider your product road map.  Are you planning to dramatically increase the number of applications being developed?  That will likely influence your decision.

The nature and use of your applications

How many of your applications will be integrating with other applications? Are those other applications internal or external?  The ease of creating integrated applications has allowed developers to quickly build rich and powerful programs but it also increases an application’s exposure to breaches and other security risks.

It’s important for organizations to look at the type of information that is at risk and what are the consequences if their application is breached.  For example, a company that stores PII (Personally Identifiable Information) in their application should be much more cautious than an online forum that stores email addresses and usernames.  The company that stores PII should see a lot more value in a centralized API security solution and would likely work with an outside vendor rather than building and maintaining the policies in house.

Resources & Timing

Let’s say you wanted to code your own security policies, does your development team have the necessary skill set and bandwidth?  How long will it take them to define and code the API security policies?  Building will probably require a project manager or product manager to lead the process.  If you ask any seasoned product manager or developer, defining and building usually takes longer than originally anticipated.  Hiring new team members also takes time and money - finding the right people isn’t easy!  There’s an opportunity cost to be evaluated when looking at the time it takes to properly staff and build vs. working with a vendor but we will go over that in a future blog post.

Organizations also need to consider the cost of maintenance: is your organization willing to dedicate someone’s time to updating and maintaining your in-house security policies? If you saved time by hiring contractors to build the security policies, are you willing to keep them on staff to keep up with the maintenance?

With any major infrastructure decision, there are pros and cons to each side. What’s important is to look at both sides and decide what’s best for your company. These topics and criteria are some of the main items that need to be considered.  If you’ve gone through this process, share in the comments what other factors should be included in the buy vs. build analysis?