This week, we have the recent API vulnerabilities at GitLab and Grindr, the APICheck tool gets donated to OWASP, there’s a summary on the basics of API authentication options, and complimentary registration links for the online conferences API World and Apidays London next week.

Vulnerability: GitLab

Riccardo Padovani found an API vulnerability in GitLab related to Elasticsearch retrieving information in code and wikis of private groups by not authorized users.

This happened for groups that used to be public but were changed into a private group. Search API calls like /api/v4/search?search=password&scope=blobs could allow accessing data that was now supposed to be private. This issue clearly had its root in indexing and caching data, because if the work in the group continued, reindexing of the data got rid of the problem. However, if the data was never reindexed, the problem would have persisted.

This is an older vulnerability that got fixed quite some time ago, but it was not disclosed until recently.

Lesson learned: Make sure your performance optimization does not put security at risk.

Vulnerability: Grindr

From last week’s “dating blocks” to dating apps this week. An excessive data exposure flaw in Grindr’s password reset API allowed full account takeover.

The Grindr website allows users to reset their password. You enter an email address and a password reset token is sent to this email address. The problem was that under the hood the API behind the web page also returned the the secret reset code (and in plaintext):

That means that attackers did not have to get access to the actual email inbox. They could simply pick the reset code from the API response and reset the victim’s password. The additional “precaution” of verifying the login with the new password in Grindr app did not really protect anything.

Once the disclosure of the vulnerability finally succeeded (an instructive story in itself), the vulnerability was luckily quickly fixed.

Lesson learned:

• There’s a reason why API3:2019 — Excessive data exposure is in OWASP API Security Top 10.
• Document (and also review) what your APIs return and how they are used. In this particular case:
• Was the API returning the reset code for debugging purposes and someone forgot to remove the behavior?
• Was the same API also used somewhere internally by another function that needed the code to store or validate it? That kind of double use of one API for two scenarios with different security levels is bad.

We covered earlier API vulnerabilities in Grindr and other dating apps, for example, in our issue 45.

#api #cybersecurity #apis #authentication #elasticsearch #api security #gitlab #newsletter