Submitted by: madduck
Submitted at: 2019年07月05日T11:10:05Z
Prerequisites
- I performed a cursory search of the issue tracker to avoid opening a duplicate issue
- Your issue may already be reported.
- I also searched the existing issues at https://github.com/gorhill/uMatrix/issues
- This is not a support issue or a question
- Support issues and questions are handled at /r/uMatrix
- I tried to reproduce the issue when...
- uMatrix is the only extension
- uMatrix with default lists/settings
- using a new, unmodified browser profile
- I am running the latest version of uMatrix
- I checked the documentation to understand that the issue I report is not a normal behavior
- I used the logger to rule out that the issue is caused by my ruleset
Description
I have referrer spoofing turned on globally.
referrer-spoof: * True
In the case of Trademe, I found I need to disable the spoofing for the login to work. In this very example, trademe.nz is the website, and the login process causes a XHR to api.trademe.co.nz. This request is denied unless the HTTP referrer specifies trademe.nz.
Without any changes to the ruleset, the XHR does not contain any HTTP referrer
field, which is weird, because I thought spoofing would have it send the
target domain's root document, i.e. https://api.trademe.co.nz, but there is
no header whatsoever. Consequently, the XHR yields a 401 response.
Since api.trademe.co.nz needs the referrer data for security decisions
(let's not discuss this...), I decided that I need to turn off referrer
spoofing, and naively thought I'd just add:
referrer-spoof: api.trademe.co.nz False
This, however, did not have any effect.
It turns out that instead I need to add
referrer-spoof: trademe.nz False
I.e. I need to turn off referrer-spoofing for all of trademe.nz, which also means that the site can now send referrer information to all the other 3rd party servers it contacts, even though I don't want that to happen.
While the rules syntax, i.e. specifying the rule, the context, and the verdict, makes sense in the case of e.g. web workers (I want to disable web workers in the context of trademe.nz and there is no 3rd party involved), referrer spoofing is different, as it involves a context, and a 3rd party.
In some ways, I think that a different rules syntax is required, i.e.:
* * referrer block
* api.trademe.co.nz referrer allow
this may be too much of an ask at this stage.
And even though I think the behaviour should be different, i.e. specifying referrer-spoof: trademe.nz True should cause trademe.nz to always see fake/spoofed referrer information, the current behaviour (trademe.nz is spoofed when used in a referrer header) should be better documented.
What do you think?
A specific URL where the issue occurs
https://trademe.nz login calling out to https://api.trademe.co.nz
Steps to Reproduce
- Disable referrer spoofing globally
- Enable referrer spoofing for
api.trademe.co.nz - Log in to https://trademe.nz and watch it fail
- Use network console to inspect the request and witness lack of HTTP referrer header
- Change referrer spoofing rule to
trademe.nzand watch the request toapi.trademe.co.nzreceive a spoofed referrer, which makes the login work.
Ruleset
referrer-spoof: * True
referrer-spoof: trademe.nz False
#referrer-spoof: api.trademe.co.nz False
Supporting evidence
Request with referrer-spoofing enabled, as well as disabled for api.trademe.co.nz:
POST https://api.trademe.co.nz/v1/authentication/token.json HTTP/1.1
Host: api.trademe.co.nz
[...]
Origin: https://trademe.nz
[...]
Request with referrer-spoofing disabled for trademe.nz:
POST https://api.trademe.co.nz/v1/authentication/token.json HTTP/1.1
Host: api.trademe.co.nz
[...]
Referer: https://trademe.nz/(modal:login)
Origin: https://trademe.nz
[...]
Your environment
- uMatrix version: 1.3.16
- Browser Name and version: Firefox 67.0.4
- Operating System and version: Debian sid