Issue 102: Vulnerabilities in Facebook and campaign apps, creating defensible APIs 🛡️

Marcos Ferreira found a Broken Object-Level Authorization (BOLA/IDOR) vulnerability in Facebook’s GraphQL API.  The vulnerability allowed anyone to change the URL of a Facebook Page (so not your Facebook profile or user account), and then take over the old URL.

Facebook allows page admins to create a “username” for their page, so that the URL of the page would be more human-readable, instead of using the page ID.

The API for that posts a JSON with the page ID and the “username” you want to assign to it:

The attackers could simply find the page ID of their intended victim and send an API call for creating a username for a Facebook Page using this page ID.

POST /api/graphql/ HTTP/1.1
Host: facebook.com

fb_api_req_friendly_name=PagesCometAdminEditingUsernameMutation&

doc_id=2886327251450197&

variables={"input":
  {"end_point":"comet_left_nav_bar",
   "entry_point":"comet",
   "page_id":"0",
   "skip_save_for_validation_only":false,
   "username":"TEST123456",
   "actor_id":"0",
   "client_mutation_id":"9"
  }
}

Change page_id with your target’s Page ID

Response

"data": { 
  "page_edit_username": { 
  "error": null, 
  "username": "TEST123456" 
  } 
}

As the result, the URL of the existing page gets changed to the username in the API call, leaving the attackers free to use the recently vacated URL on their own Facebook Page.

With social media playing bigger and bigger part in how people get their information, are influenced, and do business the possible gains (including monetary) for attackers could be significant. Fake profiles and pages impersonating as public figures and businesses have long been a problem in Facebook, so this looks like just another way in.

Facebook has since fixed the issue.

The best way to avoid these kind of issues is naturally to make sure that you have object-level authorization in place not letting anyone make changes that they are not supposed to make.

The US presidential elections are fast approaching, and campaigning is on the final stretch. In this time and era, there obviously is an app for it. Among more traditional analysts, application security specialists have been looking into the campaigns as well. In neither case did they come away empty-handed.

Researchers behind “The App Analyst” blog analyzed the apps for both campaigns and found security issues in both of them. The Biden app was more complex in terms of its functions, and had a couple of API security flaws, namely Excessive Data Exposure:

1. JSON object returned for each object contained more data than the user interface exposed – for example it included projected voting history and date of birth:

2. They also had API that the app could make to submit information from user contacts. That API was returning data not used by the app but containing pretty sensitive information including home address:

The vulnerabilities were responsibly disclosed and fixed within few days.

Meanwhile, Website Planet discovered that the more basic Trump app exposed several API keys to different parts of the app in its Android APK file. These keys in turn could have potentially allowed attackers to impersonate the app (for example, Tweet on behalf of the campaign), or even potentially access user data. In this, too, the vulnerabilities were fixed within days of being reported.

Don’t put your API keys in the app and don’t expose in your APIs more data than you are OK with users seeing.

Formal, machine-readable API definitions are key to security automation, and OpenAPI (aka Swagger) is by far the dominant standard here.

You can learn more about the standard and its practical use in Josh Ponelat’s book “Designing APIs with Swagger and OpenAPI” (Manning Books).

It’s a great hands-on primer for describing, planning, and designing web APIs, from planning and tools to developing and documenting your API. The book is still work in progress and if you subscribe, you can get chapters as they get out (and the full book after it’s done.)

Use the coupon code 42Crunch40 to get 42% off at the checkout.

The text below was Mohammed Aldoub‘s contribution to our 100th newsletter issue. The text was definitely much longer and much more detailed than what the format of that issue could allow, so we decided to put it on its own in one of the later newsletters: this one 😉

Mohammed is a well-known API security trainer known, for example, for his 2-day API security classes at Black Hat conferences. Below is a quick summary of the key points that he teaches in his classes. To learn more, we highly recommend joining them.

APIs need to be easy to use right, and hard to use wrong.

Easy to use securely, and hard to use insecurely.

But how?

Approaches:

• Secure defaults.
• Strict data validation
• Adherence to standards/expectations/conventions.
• Clear documentation
• Logging and Monitoring

Secure defaults

If you design a feature to be secure by default, you will worry less about API consumers’ levels of experience, trust or interest in security.

Secure defaults provide us with better protections against novice mistakes, incomplete assumptions and rushed deployments.

Examples of secure defaults:

• Using default strong password hashing and storage methods.
• Auto-generated administration passwords instead of default passwords.
• Encoding all output data by default, unless requested otherwise.

Strict data validation

Making sure your API only accepts a verified format of input and output data results in more secure APIs.

Examples of strict data validation:

• Strict validation of input data according to one format (JSON or XML)
• Strict declaration of expected input and output elements, and discard for any unexpected or extra elements.
• Conforming data to certain lengths or content-types.
• Validation of digital signatures and integrity codes (Hash, Mac)

Adherence to standards/expectations/conventions

The less assumptions API consumers have to make about your API, the less chances exist for abuse and exploitation. A secure API needs to pull no surprises or weird behavior.

Examples include:

• Utilizing and respecting HTTP standard features:
  • Never change state/data on a GET or HEAD request.
  • Create new resources with POST.
  • Update specific resources with PUT or POST.
  • Respecting HTTP caching headers.
  • Proper data content-types (json, xml, text… etc)

Clear documentation

If a feature is not very well documented in writing, API users will still document it in their heads (or their internal wikis!) based on what they assume, understand or test.

Where there are assumptions, there are vulnerabilities.

Documentation must be very clear on:

• Unsafe methods that should only be used in certain circumstances.
  • E.g. methods that output unvalidated data.
  • For example: ReactJS’s dangerouslySetInnerHTML
• Edge cases that need to be handled or understood by developers.
• Errors and exceptions

Logging and monitoring

An API needs to have advanced, multi-level logging capabilities and methods.

Suggested Log levels for APIs:

• Detailed, for debugging purposes.
• Production, just enough details but no sensitive info and redacted PII (Personally Identifiable Information) especially passwords.
• Basic, for statistics, anomaly analysis and business tracking.

Logging formats:

• Cloud provider logs  (e.g. AWS CloudWatch)
• Logging provided by language/framework.
• Web server logging format.
• Some services (CDN, Cloud, WAF) also log in JSON format.
• OS level logging (e.g. Windows Event Logs)

Logging has very significant security impact, mainly in two ways:

• Logging Security-related events.
• Securing the log data itself.

Logs can determine attack sources, attack payloads, exploits used, and also whether or not attacks were successful and data was stolen.

It’s therefore essential to log suspicious request and responses, and also essential to protect the logs themselves just as well as we protect the databases.

Solutions to protect logs:

• Never logging sensitive data fully (Passwords …. Etc)
• Apply access controls to determine who’s allowed to read logs.
• Encrypt logs at rest and transmit, and securely archive old log files.
• Periodically review what gets logged
• Protect systems that handle log files: Log aggregation, log analysis and log transmission. E.g. Protect Apache Solr and ElasticSearch & Kibana endpoints.
• Also log access attempts to the logs themselves! Know who viewed the logs and what for!