Cross-Origin scripts can access data without restrictions

[retog]

After login in on user.databox.me any page the user subsequently visits has full access to the user's data and can also add data to the user's LDPCs.

Steps to reproduce:

• go to https://beta.databox.me/ and log in as https://beta.databox.me/profile/card#me, the password is tester.
• Access https://retog.github.io/databox-cors-issue/

Expected results:

• https://retog.github.io/databox-cors-issue/ fails to create a resource on https://beta.databox.me/

Actual results

• https://retog.github.io/databox-cors-issue/ successfully creates a resource on https://beta.databox.me/

[RubenVerborgh]

I believe we need the equivalent of this Origin check: https://github.com/solid/solid-permissions/blob/v0.5.2/src/permission-set.js#L396

Note: We had a similar problem in node-solid-server (nodeSolidServer/node-solid-server#526), but the cause was different (it occurred with OIDC-based authentication).

[timbl]

Well, you get what you ask for.

accept-patch: application/json, application/sparql-update
accept-post: text/turtle, application/json
access-control-allow-credentials: true
access-control-allow-origin: https://retog.github.io
access-control-expose-headers: User, Location, Link, Vary, Last-Modified, WWW-Authenticate, Content-Length, Content-Type, Accept-Patch, Accept-Post, Allow, Updates-Via, Ms-Author-Via
access-control-max-age: 1728000
allow: OPTIONS, HEAD, GET, PATCH, POST, PUT, MKCOL, DELETE, COPY, MOVE, LOCK, UNLOCK
content-length: 0
content-type: text/plain; charset=utf-8
date: Fri, 15 Jun 2018 13:39:25 GMT
link: <https://beta.databox.me/evil-5099ea,meta>; rel="meta", <https://beta.databox.me/evil-5099ea,acl>; rel="acl", <http://www.w3.org/ns/ldp#Resource>; rel="type"
location: https://beta.databox.me/evil-5099ea
ms-author-via: DAV, SPARQL
status: 201
updates-via: wss://beta.databox.me/
user: https://beta.databox.me/profile/card#me
vary: Origin

These headers from the server say that the client origin is explicitly trusted. We can't get upset about cross-origin access when the browser goes to huge lengths to block it, and we have gone to even huger lengths to open it up again.

Protection against this attack is built into the browser.
We disable it by explicitly telling the browser that for any origin which access it, that origin is trusted. You get what you ask for.

Browser security is based on the Same Origin Model... if we want to tweak that we do it carefully but maybe not reinvent it. we have origin reflector code in the server specifically to give all origins ability to access data. We turned that on, to fix this we turn it off (work break warp etc) or make it speific to origins we trust.

[RubenVerborgh]

I think the reasoning is that: yes, we open up cross-origin requests, but we shield it off with another mechanism. I.e., when a user is not allowed to perform an operation, we want to be able to reply with 401/403, not with “cross-origin request blocked”.