nodeSolidServer / nodeSolidServer/node-solid-server

Access control by origin header not working?

オープン
#986 コメント 6 件 リアクション 0 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

主要言語
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?

コントリビューションガイド

コントリビューションガイドを開く

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. 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

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。