Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve security of website embeds and unauthorized origins #3602

Open
tuxpiper opened this issue Jul 1, 2019 · 0 comments

Comments

Projects
None yet
1 participant
@tuxpiper
Copy link
Member

commented Jul 1, 2019

Overview

A number of concerns have been voiced around attackers hijacking deployments, redirecting traffic and end-user interactions through endpoints different than those intended by the deployers.

These are some of the issues voicing these concerns or reporting actual security related events (pls comment in issues if you find more):

  • #2715 : someone plugging a different domain name to the deployer's web server IP address, allowing a different domain to serve the same deployment. It is unclear what the third-party was intending to gain from such action.

As a result, there have been conversations around how to mitigate attack vectors in the browser, and outputs identifying shortcomings and steps to improve. I'll classify the output of those conversations in 3 areas:

Area 1 . Headers to be provided along with the client, not affecting the embed functionality.

These are largely separate from the code, and affect only how we deliver SaaS and recommend the installation of Platform. It's fairly straightforward to enable them without breaking stuff. They are to be tackled in their independent issues, and are not a target of this Epic. This effort can go ahead unimpeded.

Area 2. Headers limiting embedded client functionality (Platform into an iframe)

This is a technique that we have seen being legitimately used for sharing maps, surveys, individual posts, and complete websites as well.

Whatever the usecase, the problem is that unrestricted iframing opens up the possibility of click-jacking attacks.

The decision of allowing or disallowing embeds in general (or from some specific domains) can be largely left up to the deployers and system administrators. All they need to know is about these headers and how to set them up. This is covered in:

  • #2720 - X-Frame-Options

BUT this largely leaves people with just an "all or nothing" option. In particular, we most certainly can't just disable embedding in the ushahidi.io SaaS , because it will break a lot of embeds from news articles, branded websites etc.

So additionally ... as suggested in the conversation under :

  • #1609 - No Clickjacking Protection

We can enable some middle ground that allows to selectively open / close some embed functionality. This would involve:

  1. Making the JS client aware of when it has been embedded and allow it to be configured to disable dangerous functionality in that case (i.e. disallowing login)
  2. Documenting the UI routes/screens that are considered safe to embed (i.e. viewing a post, or a map)
  • TBD: open issue for disabling dangerous functionality when client is embedded

We could wrap all this thing together in a single document, presented as a menu of options to deployers can take, i.e.:

  1. "I don't want to have anything to do with iframes, disable them completely"
  2. "I am fine using embeds from particular domains"
  3. "I am fine allowing embeds from the open internet, for screens where the consensus is that they are safe" (i.e. embedding a map)
  4. "I want to decide exactly what screens can be embedded from the open internet"
  5. "I don't care, lift all restrictions"

Each option would come with setup explanations.

  • TBD: open issue for documenting which routes are embeddable, available choices in degrees of security and setup explanations

Then, we should pick and implement our approach with SaaS:

  • TBD: open issue with SaaS changes
  • TBD: put together communication for SaaS users

Area 3. Cross Origin Resource Sharing

Currently the API is "tweaked" to indicate that any browser Origin as acceptable. This is covered in the following issue:

  • #3601 - No effective CORS origin restriction in the API

This is considered not secure and is opening up vectors for the API to leak data to websites controlled by attackers.

Tightening this may annoy some (non attacking) developers, by making it non-trivial to work on locally hosted platform-client code, communicating with an API hosted at the ushahidi.io SaaS . In other words, developing on the client without going through the complications of installing the API. It looks like there are browser extensions to tweak the Origin headers sent by one's browser, so at least there's a workaround (that we could document somewhere)

  • TBD: update developer documentation detailing this setup and the needed workarounds

Who is it for? Who are the users?

People using embeds and developers

What privacy impacts does it have?

None

Requirements

Who will this be deployed to?

Everyone is affected

What documentation needs to change?

Installation
Embedding feature
Security recommendations

~~ TBD from here below ~~

Test script

Who will test this?

Where will this be deployed and tested?

Deployment

Does this deploy new services?
Do the new services have health checks?
Can this be feature flagged and deployed disabled?

Dependencies

@tuxpiper tuxpiper changed the title Squaring security of website embeds and unauthorized origins Improve security of website embeds and unauthorized origins Jul 2, 2019

@tuxpiper tuxpiper added the P2 - Normal label Jul 2, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.