This week, we have two vulnerabilities โ the first is the revelation that thousands of applications are leaking Twitter access tokens, and the second is a parameter smuggling attack in Golang affecting some well-known Golang-based projects. We also have an article on the benefits of API catalogs in delivering security benefits and, finally, a fascinating read on everything you could ever want to know about rate limiting.
Vulnerability: Thousands of applications leaking Twitter access tokens
Security researchers at CloudSEK this week disclosed the details of 3,200 mobile applications potentially leaking Twitter API keys. The researchers discovered that in many cases, developers had embedded Twitter API keys within their application binary or manifest, which would allow attackers to extract the keys and use them to access Twitter as if they were the application user.
Security savvy developers have long understood the need to prevent access keys and tokens from being shipped in production images, however less experienced developers may inadvertently ship keys and tokens in the production version. This can be done accidentally or by employing bad practices or build methods. We covered a rather epic example of this issue in the mobile application of a microbrewery.
The researchers suggested that these credentials can easily be harvested and used by Twitter bot armies to spread misinformation, run malware campaigns, run spamming campaigns, and automated phishing attacks.
The recommendations for protecting against token and key leakage include:
- Perform code reviews to identify instances of local, insecure storage.
- Ensure that files containing runtime variables in the source code are not shipped with the application.
- Use source code scanning tools (such as Semgrep) to scan code in repositories to identify stored credentials.
- Ensure you regularly rotate API keys, and have a strategy for key revocation in the event of leakage or disclosure.
Vulnerability: Parameter smuggling attack in Golang
This week’s second vulnerability comes from researchers at Oxeye, who have described a security vulnerability in Golang-based applications in detail. The root cause is due to unsafe URL parsing in affected versions of a core Golang library which could allow an attacker to bypass the validation of HTTP request parameters.
The Golang method to parse a URL (parseQuery) changed behavior in the manner in which it processed a semicolon as follows:
- Prior to version 1.17 the parser would (incorrectly) split the query around the semicolon as if it were a separator.
- From version 1.17 the parser would return an error code which, unfortunately, some other Golang modules chose to ignore.
The net result is demonstrated in the diagram below โ an attacker can supply a query with a semicolon via the user-facing service (using version >= 1.17) and pass this to the backend service (using version < 1.17), which will then incorrectly parse the query. The researchers claim that attackers could be able to smuggle requests containing query parameters that normally would be rejected.
The researchers reported that a number of well-known projects are potentially vulnerable, including the CNCF Harbor project, the Traefik reverse proxy, and the Skipper router.
The suggested remediation is to upgrade all versions of Golang, use alternate methods to parse queries, to sanitize the URL by stripping extraneous semicolons or using their Semgrep rule to identify vulnerable code.
A really interesting write-up and a great demonstration of the power of Semgrep.
Article: API catalogs deliver security benefits
TheNewStack covered an important element of API security, namely that of API catalogs or inventories. It is impossible to accurately assess risk exposure or develop a strategy for improving API security without understanding what APIs your organization has deployed. The author identifies two reasons why API catalogs are important from a security perspective.
Firstly modern development practices such as CI/CD automation and cloud providers allow developers to deploy an API literally at the touch of a button, often without the knowledge of the security teams. Additionally, since APIs can be changed so frequently, this poses a challenge for the versioning of APIs. This is referred to as the shadow and zombie APIs, respectively. Secondly, because APIs are primarily used to transmit data, they pose the greatest risk of data exposure, creating greater challenges for security and Governance and Risk Control (GRC) teams.
The author suggests three steps toward cataloging APIs:
- Use a single source of truth to maintain a catalog from a variety of sources and ensure this catalog contains metadata to indicate connectivity, version, visibility, etc.
- Use the catalog to auto-generate risk scores based on the metadata to ensure that security teams focus on the highest risk items.
- Use the OpenAPI Specification to allow producers and consumers to use a common language and leverage the benefits of automated testing and security scanning.
Great advice in general, however building a complete API catalog is a challenging task.
Article: The right way to rate limit
This week’s final article, from AuthAPI, is a great read on everything you could ever wish to know about API rate-limiting and then some. While rate-limiting appears to be a simple enough concept, there is a lot of devil in the detail to ensure a balance between usability and customer experience versus security and availability is achieved.
The key objectives of rate limiting are as follows:
- Consistent experience: ensure that all users have equal access to resources to maintain consistent performance under high load.
- Cost management: API resources cost money, and allowing customers unfettered access to APIs may lead to impacts on your bottom line. Balance the experience against the budget.
- Protected services: from a security perspective, rate-limiting is important to mitigate against malicious actors attempting to brute force an API endpoint.
A failure to implement rate-limiting correct can lead to Denial of Service (DoS) or Distributed Denial of Service (DDoS) attacks, cascading failures between dependent APIs, resource starvation, and resource exhaustion.
There are three main strategies for implementing rate-limiting, namely:
- Hard stop: once an API limit is reached (too many requests from a user in a fixed time window), the API will return a 429 ‘Too many requests’ error, forcing the user to back off for a period. This abrupt halt may be frustrating to users are not expecting this limiting to happen.
- Throttled stop: unlike a hard stop which returns an immediate error, the throttled stop introduces a delay in processing the request. Typically throttled stops are used in combination with hard stops to provide a more nuanced user experience; however, they are often a lot harder to implement.
- Billable stops: the final strategy to rate limiting is to allow the user to opt to pay for API access exceeding their quota. This allows users to determine their own priority โ either large request volumes at a price or lower volumes for free. It also allows the provider to generate revenue from high-demand users.
Finally, the author suggests some best practices, including:
- Don’t be greedy: avoid charging excessively for API usage that is typical of normal use cases.
- Be transparent: explain your rate-limiting and/or quota policies to avoid unexpected surprises down the line.
- Add counters: adding HTTP headers to the API response allows the client to back off before a limit is incurred.
Security teams need to be aware of the negative impacts the injudicial use of rate-limiting may have for users โ as ever, it is a balance between security and user experience.
Get API Security news directly in your Inbox.
By clicking Subscribe you agree to our Data Policy
