nodeSolidServer / nodeSolidServer/node-solid-server
Access control by origin header not working?
まだ誰も着手していません。
- 主要言語
- JavaScript
- スター
- 1.8k
- フォーク
- 308
- PR マージ指標
- 30日以内にマージされた PR はありません
説明
First a disclaimer - it is very difficult to find any documentation about access control for web-apps, so I am possibly wrong here. But here we go anyway ...
Assuming I have a browser web-app that lets me register my pets. My pets are very valuable to me and I really don't want any other web-apps to snoop into my pet collection even if I am logged in to my POD with some third party web-app.
How do I prohibit other web-apps from accessing my pets? Well, first of all I make sure that access control for my /pets folder is "specific" according to the data browser, which seems to be identical to creating a .acl file for the container. Then what?
At https://www.w3.org/wiki/WebAccessControl#Giving_a_specific_resource_access_to_an_Origin the following is suggested:
[] acl:accessToClass [ acl:regex "https://bblfish.solid.example/.*" ];
acl:mode acl:Write;
acl:origin <https://apps.rww.io> .
So I add acl:origin <https://nothinguseful.org> to verify that no existing app, not even my own pet-app, have access and try to work with the data from the pet-app ... and still have complete access.
The ACL file is located at https://elfisk.solid.community/places/hobby/.acl and contains:
@prefix : <#>.
@prefix n0: <http://www.w3.org/ns/auth/acl#>.
@prefix hobby: <./>.
@prefix c: </profile/card#>.
:owner
n0:accessTo hobby:;
n0:agent c:me, <mailto:jw@elfisk.dk>;
n0:defaultForNew hobby:;
n0:mode n0:Control, n0:Read, n0:Write;
n0:origin <https://nothinguseful.org>.
The HTTP request sent is:
PUT https://elfisk.solid.community/places/hobby/yyy HTTP/1.1
Host: elfisk.solid.community
Connection: keep-alive
Content-Length: 347
authorization: Bearer ...
Origin: https://solidrc.azurewebsites.net
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.110 Safari/537.36
content-type: text/turtle
Accept: */*
Referer: https://solidrc.azurewebsites.net/Home/Locations
Accept-Encoding: gzip, deflate, br
Accept-Language: da-DK,da;q=0.9,en-US;q=0.8,en;q=0.7,sv;q=0.6,nb;q=0.5
Cookie: connect.sid=...
DNT: 1
@prefix : <#>. ... more turtle stuff ...
As you can see, the origin header is Origin: https://solidrc.azurewebsites.net - which is not matching the acl:origin value.
Is this a bug or me completely misunderstanding it all?
コントリビューションガイド
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
調査の方向性
まず、リンクされている Web Access Control のガイダンスと、/places/hobby/.acl に提供されている ACL を、PUT リクエストの Origin ヘッダーと併せて確認します。acl:origin に対するサーバーの認可処理を追跡し、一致しない origin が拒否されることを確認します。その際、ブラウザーの CORS 動作とサーバー側のアクセス制御を区別してください。完了条件は、動作が説明され、バグである場合は再現可能なテストでカバーされていることです。
索引モデルが issue の本文から書いたものです。
評価
- 技術スタック
- javascript
- 領域
- authorization, security
- issue の種類
- バグ
- 難易度
- 4/5
- 見積もり時間
- 3〜5日
- 活発さ
- 停滞
- 明瞭さ
- 説明が足りない
- 初心者へのやさしさ
- 25/100