Issue 108: API vulnerabilities in Thrillophilia and GitLab ✉️

Thrillophilia is an Indian online platform for discovering and booking travel experiences and tours. Ehraz Ahmed found that Thrillophilia exposed about 2 million customer records.

As many consumer sites, the Bengaluru-based company offered the social login option of using 3rd-party accounts, in this case Facebook, to log in to their site. However, their API implementation for this was flawed and the API blindly trusted the email parameter that it received.

This meant that attackers could authenticate with their own account, but then change the email parameter from theirs to that of their victim. Thrillophilia APIs did not verify that the email parameter matched the rest of the authentication information. It simply accepted the integrity of the information and that this was an authenticated user, and gave access to the user records based on the email parameter (that the attackers had switched).

Thrillophilia has since fixed the issue.

Bottom-line: be careful with social login or any federated authentication. These can give you the false sense of security unless you carefully verify that no tampering with the tokens and any parameters is possible.

Ahmed has a record of uncovering vulnerabilities related to social login. We have previously covered him in our issues 53, 59, 61, and 64.

GitLab has just pushed out a set of security updates, namely 13.5.2, 13.4.5, and 13.3.9.

These do not include fixes to any API security flaws in GitLab’s own code, but a couple of fixed vulnerabilities did stem from the 3rd-party components they use:

• Kubernetes agent API leaked private repositories:
  A vulnerability in the internal Kubernetes agent API allowed unauthorised access to private projects.
• Terraform state deletion API exposed object storage URL:
  The Terraform API exposed the signed URL of object storage on the DELETE operation, allowing a malicious project maintainer to overwrite the Terraform state, bypassing audit and other business controls.

This is just another reminder on the big impact that 3rd-party components and services can have for your overall security. Make sure to study their levels of security carefully and implement whatever additional protection you can: perform additional data validation on their calls, limit visibility and access to your code only, and so on.

OpenID Connect (OIDC) is a popular authentication protocol based on OAuth2.

There’s a new free (registration required) 4-part online OpenID Connect (OIDC) training course from Michał Trojanowski (Curity). The course includes:

1. Overview of OIDC
2. ID Tokens and UserInfo EndPoint
3. Authentication with OIDC
4. OIDC Logout and session handling

More internet security products are starting to adopt positive security model for APIs  that is based on the OpenAPI Specification (OAS). Recently, Cloudflare has announced the launch of their API Shield service.

For existing Cloudflare customers who have centrally managed public APIs with well-defined OpenAPI definitions, this can be a quick way to improve runtime security.

At the moment, API Shield offers mutual certificate authentication (mTLS) enforcement and JSON schema validator (in beta). The roadmap includes rate limiting, DDoS protection, web application rules designed for APIs, and analytics.