What Is OWASP API Security Top 10: A Deep Dive

How Access Control Vulnerabilities are Exploited Access-Control vulnerabilities are incredibly commonplace in today’s APIs. They’re not hard to fix, but they’re hard to continuously validate and keep in check as the code base, and features grow. Hackers love these weaknesses as they’re hard to detect and mitigate at the network or firewall level. For example, take this simple scenario. Let’s assume certificate provider has these APIs POST /api/certificate // creates a new certificate POST /api/certificate/{UID}/renew // renews a certificate by UID DELETE /api/certificate/{UID}/revoke // revokes a certificate by UID PUT /api/certificate/{UID} // update certificate passphrase by UID GET /api/certificates // Lists all certificates Typically a customer would request a new certificate by calling the create endpoint, i.e., #1. The API then returns the newly created certificate along with the UID. Later on, if the customers want to renew, update or revoke certificate they can do this by merely using the mapped UID. If there is a flaw in the products business logic, and it doesn’t correctly check all the incoming UIDs against the caller’s credentials to validate if the user is entitled to the UID then this flaw would have allowed the attacker to use an altered or phished UID’s that belongs to other customers and perform automated attacks. Why it’s hard to keep the business logic working correctly: Because the logic grows crazily, and here is an example of that. loggedInUser.isOwner(UID) // v1: only owner can access the certificate.// v2: let’s allow the role collaborators access the certificates// v3: let’s allow the role support staff to help customers// v4: let’s allow role reader to only download the certificate Consequences of the breach These attacks are hard to detect and can take months before it’s known, and also, it could incur a huge cost on both the vendor and on the customers. The vendor would have to pay for forensics, legal and PR. For some customers replacing their certificate may incur a considerable cost, as they might be used in payment terminals and other hard-to-reach devices. How security teams can protect APIs targeting these flaw? The only way to prevent is to continuously detect and fix them early in the development cycles. You need 100% automated coverage either in-house build or using an API Security Scanners.

How did the Outlook email breach happen? According to Microsoft, one of its support agent’s credentials were compromised, allowing individuals to gain unauthorized access to Microsoft email accounts. Initially, Microsoft said the breach might have allowed unauthorized parties to “access and view information” related to affected email accounts (including folder names, subject lines of emails, and names of other email addresses) but not their contents. Symptoms of a Compromised Office 365 Email Account Users might notice and report unusual activity in their Office 365 mailboxes. Here are some common symptoms: Suspicious activity, such as missing or deleted emails. (This means they can delete inbox messages) Other users might receive emails from the compromised account without the corresponding email existing in the Sent Items folder of the sender. (They can send new messages and delete messages from sent folder) The presence of inbox rules that weren’t created by the intended user or the administrator. These rules may automatically forward emails to unknown addresses or move them to the Notes, Junk Email, or RSS Subscriptionsfolders. (They had access to forward rules, i.e. they had content view access for the new and old emails.) The user’s display name might be changed in the Global Address List. (Had access to update profile) The user’s mailbox is blocked from sending email. The Sent or Deleted Items folders in Microsoft Outlook or Outlook on the web (formerly known as Outlook Web App) contain common hacked-account messages, such as “I’m stuck in London, send money.” Unusual profile changes, such as the name, the telephone number, or the postal code were updated. Unusual credential changes, such as multiple password changes are required. Mail forwarding was recently added. An unusual signature was recently added, such as a fake banking signature or a prescription drug signature. Here is a list of Outlook features from its API documentation page. Check out the feature-role-mappings we created from the docs for regular user/owner and for the support user we learned from the PR (Note: I didn’t find any online docs for support role). Here is our 4 Point Analysis Microsoft said the “Support” role had access to only the subject lines. I think they needed access, will give it to them. Microsoft said the “Support” role had no access to the contents – This lowers the risk of leaking email contents. I believe their entire focus was around protecting the email body. But, it seems they had access to create, send, and delete messages Seems “Support” role had access to Rules, Profile, Password-Reset, Signature – I’m not sure why a Support role needs access to these features. Most importantly the Rules access because this negates the advantage of point #2. It seems the support can see folder names. I’m not sure why they needed this access and we’re not sure what else they can do on folders. How CISO/Security can prevent these kinds of attacks? First, the complexity of the attacks proves the attackers are years ahead of the security industry, especially on the application layer vulnerabilities (APIs and Features etc). Also, real-time detection and protection won’t work for these kinds of attacks. These vulnerabilities are in the code and it took Microsoft over 3 months to discover (January 1 to March 28, 2019) and they may have taken some time to fix these issues in the code before they made the announcements. What security teams needs is 100% visibility into API/Feature and Role mappings. The best approach at this point is to continuously Discover, Track and Fix Role-Based-Access-Control vulnerabilities early in the development cycle and as daily compliance checks. At APIsec we focus on similar (RBAC) vulnerabilities as a day-1 task. As a first step we auto-discover feature-role mapping then we sort and prioritize overlapped/escalated permissions.

More than 5 billion records from 6,500 data breaches were exposed in 2018 In this blog post, we will highlight the enormous impact of data breaches in 2018 as well as the status of GDPR violation since this guideline came into effect in May 2018. Data Breaches in 2018 “More than 5 billion records from 6,500 data breaches were exposed in 2018” — a report from Risk Based Security says. Hackers have been able to monetize by selling stolen user databases publicly. A new set of databases containing millions of hacked accounts from several websites has been made available for sale on the dark web marketplace. GDPR Violations in 2018 “More than 59,000 data breach notifications have been reported across the European Economic Area by public and private organizations since the GDPR came into force on 25th May 2018.” — a report from DLA Piper says. To date, 91 GDPR fines have been reported. “The highest GDPR fine imposed to date is €50 million, which was made against Google on 21st January 2019.” – according to a report from DLA Piper. This decision was made in France in relation to Google’s processing of personal data for advertising purposes without valid authorization, rather than actual data breach. Analysis More and more data breaches and GDPR violations are caused by API vulnerabilities (especially around API endpoint and data access controls) that allow hackers to extract millions of records containing personally identifiable information (PII). FX Labs is the answer to attacks targeting the API layer because our automated platform, APISec, can instantly test every API endpoint and is granular enough to detect the Top 20 API vulnerabilities (including access control vulnerabilities in RBAC and ABAC). No other platform can comprehensively secure your APIs, which is why some of the largest companies use APISec.