Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
Improve security of website embeds and unauthorized origins #3602
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):
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:
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 :
We can enable some middle ground that allows to selectively open / close some embed functionality. This would involve:
We could wrap all this thing together in a single document, presented as a menu of options to deployers can take, i.e.:
Each option would come with setup explanations.
Then, we should pick and implement our approach with SaaS:
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:
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)
Who is it for? Who are the users?
People using embeds and developers
What privacy impacts does it have?
Who will this be deployed to?
Everyone is affected
What documentation needs to change?
~~ TBD from here below ~~
Who will test this?
Where will this be deployed and tested?
Does this deploy new services?