nodeSolidServer / nodeSolidServer/node-solid-server
Access control by origin header not working?
还没有人认领这个 Issue。
- 主要语言
- 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 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库,在一个分支上完成修改。
- 提交 Pull Request,并在描述里引用这个 Issue 编号。
调研方向
首先,结合 PUT 请求的 Origin 标头,检查链接的 Web Access Control 指南以及 /places/hobby/.acl 中提供的 ACL。跟踪服务器对 acl:origin 的授权处理,并验证不匹配的 origin 是否会被拒绝,同时区分浏览器的 CORS 行为与服务器端访问控制。完成的标准是解释清楚该行为,并且如果这是一个 bug,则由可复现的测试覆盖。
由索引模型根据 Issue 内容生成。
评估
- 技术栈
- javascript
- 领域
- authorization, security
- Issue 类型
- 缺陷
- 难度
- 4/5
- 预计耗时
- 3-5 天
- 活跃度
- 停滞
- 描述清晰度
- 需要澄清
- 新手友好度
- 25/100