Add document describing blob security model

Problem: I still haven't found any best practices for how to run HTML on
your domain without any security concerns. I feel reasonably confident
that our current security precautions mitigate any potential attacks,
but I want to be very up-front with any security mitigations that aren't
so common that they're boring and predictable.  Resolves https://github.com/fraction/oasis/issues/5.

Solution: Add a document to describe our current security model and
mitigations so that we can point at it when asking friends to review the
model and ensure we don't have any holes.
This commit is contained in:
Christian Bundy 2020-02-02 13:56:27 -08:00
parent 82f080f3c6
commit e92d5adec6
1 changed files with 35 additions and 0 deletions

35
docs/blob-security.md Normal file
View File

@ -0,0 +1,35 @@
# Blob security
**This is how we secure blob pages from interacting with Oasis. If you notice
any errors or omissions, please follow the steps in the security policy.**
One of the problems we have when hosting content from other people in a P2P
network is avoiding
[arbitrary code execution](https://en.wikipedia.org/wiki/Arbitrary_code_execution).
In the context of Oasis, we need to be very sure that we aren't letting any code
other than Oasis run in the browser. Markdown is a security concern, but it's
got lots of eyeballs on the problem, whereas blob security is a security
concern without any common best practices. The problem we need to solve isn't
super common: hosting arbitrary data, especially HTML, in a safe way that doesn't
open security vulnerabilities.
The way we currently deal with this is a [content security policy (CSP](https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP),
which gives Oasis a way to tell the web browser which features can be safely
disabled. Since Oasis doesn't use any front-end JavaScript, we can disable all
JavaScript being run by the web browser. This is _huge_ and massively reduces
the surface area that might be vulnerable to attack. You can find all of the
CSP code in [`http.js`](https://github.com/fraction/oasis/blob/master/src/http.js).
With JavaScript out of the way, the only attack vector that we should worry
about is an [HTML form](https://developer.mozilla.org/en-US/docs/Learn/Forms#See_also).
If one of these were embedded in a blob, they would be able to send HTTP POST
requests to our API endpoints, impersonating the user. A button called "click
me", could publish posts, change follow status, make changes to our settings
page, or other bad behavior that we want to avoid.
The mitigation for this is a referrer check on all POST endpoints, which helps
us guarantee that all form submissions came from a non-blob page. If we receive
an HTTP POST without a referrer, we throw an error. If we receive a referrer from
a blob page, we throw an error. If a form submission passes these two checks,
we can safely assume that the POST request came from a legitimate person using
Oasis.