3wordchant/oasis
0
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

Merge pull request #142 from christianbundy/describe-blob-security

Browse Source 
Add document describing blob security model
This commit is contained in:
Jonathan Dahan 2020-02-02 17:20:45 -05:00 committed by GitHub
commit 5be294b89e
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 35 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

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.