This week, we check out a recent API vulnerability in Twitter. In addition, it looks like API vulnerabilities are a bit of theme in apps by political parties: vulnerabilities were discovered in apps by Israel’s Likud and the Democratic Party in USA. We also have two API security talks: one recorded and one upcoming webinar.
Vulnerability: Twitter
Twitter has disclosed a recent API exploit. The API endpoints to make finding friends in Twitter by their phone numbers easier were abused, possibly by state-sponsored actors, to mine accounts by mapping them to phone numbers. Detecting and throttling the exploit was hard because the phone numbers were not sequential and attackers used multiple accounts and IP addresses in their attacks.
Twitter has since changed the responses from API so that it no longer returns specific account names. They have also suspended any accounts involved in the exploit.
This is a reminder on why API4:2019 โ Lack of resources and rate limiting is a big deal for API security. A lot of companies view throttling as a mechanism of resource protection and think that generic rate limiting across APIs is sufficient.
Instead, they should identify sensitive API methods: such as the ones related to authentication, signup, password reset, and sensitive information access. Then, these endpoint should receive their own much more limited policies that would limit mass use and include automated lockouts to prevent abuse.
Vulnerability: Likud Elector app
Ran Bar-Zik has discovered an API vulnerability in the app by Likud, the ruling party of Israel. The app exposed the personal details of over 6 million Israeli voters:
- A link to an admin API endpoint was embedded in the source code of the app (OWASP API5:2019).
- This endpoint was accessible without authentication (OWASP API2:2019).
- The API response included the credentials of the site admins, including their passwords (OWASP API3:2019), in cleartext (!)
This reads like a schoolbook bad example on what we have been highlighting:
- Never, ever, store or transport credentials in cleartext. In fact, passwords should never be stored at all – only their hashes.
- Review your API designs. It is unlikely that any security specialist would ever approve creating an API for administrative credentials retrieval.
- Always protect sensitive information and endpoints with authentication.
- Don’t include sensitive information (like unprotected admin endpoints in this case, but also API keys, secrets, credentials) in your code.
Unsurprisingly, these shortcomings provided easy access to the API backend and the database containing voter details. It is unclear if these details leaked before Bar-Zik uncovered the vulnerability, but the scope of the details makes the potential impact very serious.
The original story, in Hebrew, can be found here.
Vulnerability: Iowa caucus app
Sadly, looks like API security really is not a strong suite with political parties: turns out that Iowa’s Democratic Presidential primary caucus app also leaves lot to be desired when it comes to API security.
Motherboard requested several researches to evaluate the caucus app. One issue that a team of researchers from Stanford University found were the hard-coded API keys included, again, in the source code of the app. The team was able to decompile the app, get the keys, and access the API and its backend.
Source code cannot be considered a safe place to store secrets like credentials and API keys. Modern platforms have native secure storage that can be used. Application keys and secrets need to be combined with delegated authentication mechanism such as OAuth2 to generate temporary API keys for the actual API access.
Webinar: Protecting microservices APIs with API Firewall
On February 20, Isabelle Mauny from 42Crunch will be giving a webinar on API security for microservices in Kubernetes. The webinar “Protecting Microservices APIs with 42Crunch Kubernetes API Firewall” will focus on, for example:
- North-South vs East-West protection
- Firewalling individual microservices
- Whitelisting based on API contracts following the OpenAPI Specification
- CI/CD DevSecOps pipeline
To register and secure your place, click here.
Video: Common API pitfalls
The slides and the recording of Philippe De Ryck’s talk “Common API security pitfalls” from GOTO Chicago 2019 conference have been published.
This session touches on lots of common issues, such as:
- Transport
- Authentication
- Authorization
- JWT
- Input validation
- Tokens vs cookies
- Keys and secrets
- CSRF
- XXS
Slides available from Philippe’s site here.
Get API Security news directly in your Inbox.
By clicking Subscribe you agree to our Data Policy
