content security policy doesn't allow to open website running in local area
Categories
(Core :: DOM: Security, defect)
Tracking
()
People
(Reporter: prism-rut-haiku, Unassigned)
References
Details
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:133.0) Gecko/20100101 Firefox/133.0
Steps to reproduce:
I'm running BitWarden service on internal network at http://192.168.1.50:9093.
Here is docker-compose example:
version: '3'
services:
bitwarden:
depends_on:
- db
image: bitwarden/self-host:beta
restart: always
ports:
- "9093:8080"
volumes:
- ./bitwarden:/etc/bitwarden
environment:
BW_DOMAIN: "bitwarden"
BW_DB_PROVIDER: "mariadb"
BW_DB_SERVER: "db"
BW_DB_DATABASE: "bitwarden_database"
BW_DB_USERNAME: "myUserName"
BW_DB_PASSWORD: "MyPassword"
BW_INSTALLATION_ID: "get_installation_id_from_bitwarden"
BW_INSTALLATION_KEY: "get_installation_key_from_bitwarden"
db:
environment:
MARIADB_USER: "myUser"
MARIADB_PASSWORD: "myPassword"
MARIADB_DATABASE: "bitwarden_database"
MARIADB_RANDOM_ROOT_PASSWORD: "true"
image: mariadb:10.6.11
restart: always
volumes:
- ./data:/var/lib/mysql
You can also run JS fetch from FireFox console:
await fetch("http://192.168.1.50:9093/", {
"credentials": "omit",
"headers": {
"User-Agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:133.0) Gecko/20100101 Firefox/133.0",
"Accept": "text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8",
"Accept-Language": "en-US,en;q=0.5",
"Upgrade-Insecure-Requests": "1",
"Sec-GPC": "1",
"Priority": "u=0, i"
},
"method": "GET",
"mode": "cors"
});
Actual results:
Firefox does not open website: "Unable to connect...", while Safari opens it just fine. Also CURL is able to open it.
From JS fetch (code in replication steps) you will get errors:
Content-Security-Policy: The page’s settings blocked the loading of a resource (connect-src) at http://192.168.1.50:9093/ because it violates the following directive: “default-src chrome:”
And
Uncaught (in promise) TypeError: NetworkError when attempting to fetch resource.
<anonymous> debugger eval code:2
<anonymous> debugger eval code:15
Expected results:
Firefox should have open website.
Updated•2 months ago
|
In addition I checked transmissionbt - which runs webui on port 9092, the same issue.
Safari opens it via http://192.168.1.50:9092, but Firefox says:
Unable to connect
Firefox can’t establish a connection to the server at 192.168.1.50:9092.
The site could be temporarily unavailable or too busy. Try again in a few moments.
If you are unable to load any pages, check your computer’s network connection.
If your computer or network is protected by a firewall or proxy, make sure that Firefox is permitted to access the web.
I also run php website - http://192.168.1.50:9091 and Firefox once again does not open with the same error as above.
NOTE:
When I reverse-proxy internal website and access them with subdomains (example: myphp.example.com), they are actually opening in Firefox just fine. They have exactly the same content security policy headers. But accessing from internal network via 192.168.1.50 - results in refusal to connect.
Comment 2•2 months ago
|
||
The Bugbug bot thinks this bug should belong to the 'DevTools::Debugger' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
Comment 3•2 months ago
|
||
CORS requests are in the domain of Core :: Dom: Security
.
Comment 4•2 months ago
•
|
||
I think the issue here might be that the requests are getting upgraded to HTTPS.
Could you please try to reproduce with a Firefox Nightly were we have more nuanced heuristics for upgrades?
Also note, that the following error occurs because the fetch command was executed in a browser chrome (UI) context:
Content-Security-Policy: The page’s settings blocked the loading of a resource (connect-src) at http://192.168.1.50:9093/ because it violates the following directive: “default-src chrome:”
This could happen, for example, when you use devtools of about:preferences but is probably unrelated to this issue.
If it is indeed an issue with HTTPS upgrades you can temporarily disable them by setting dom.security.https_first
to false.
Comment 5•2 months ago
|
||
Just in case, please check if your Firefox has the permission to find and communicate with devices on the local network under "System Settings" > "Privacy & Security" > "Local Network". Otherwise you get blocked by the OS.
(In reply to Simon Friedberger (:simonf) from comment #5)
Just in case, please check if your Firefox has the permission to find and communicate with devices on the local network under "System Settings" > "Privacy & Security" > "Local Network". Otherwise you get blocked by the OS.
Yeah, you are right, it was issue with privacy and security.
I'm a bit embarrassed about this, firefox can access local area now.
Can you give me a bit more insight to why it works that way? I mean firefox has no issue accessing the same resources provided domain or subdomain name, however unable to access directly via ip?
Thank you.
Comment 7•2 months ago
|
||
It has been a common issue to have unsecured devices on the local network, like a NAS or printer which is why people might want to block apps from accessing it. There are also several well known attacks where hackers have used Javascript in the browser to access devices on the local network.
You might also want to check out the videos linked at the top of https://developer.apple.com/documentation/technotes/tn3179-understanding-local-network-privacy
(In reply to Simon Friedberger (:simonf) from comment #7)
It has been a common issue to have unsecured devices on the local network, like a NAS or printer which is why people might want to block apps from accessing it. There are also several well known attacks where hackers have used Javascript in the browser to access devices on the local network.
You might also want to check out the videos linked at the top of https://developer.apple.com/documentation/technotes/tn3179-understanding-local-network-privacy
Thank you.
Comment 9•2 months ago
|
||
Hm, I think this is something we should reflect in the error message. We could expand it in the "Unable to connect..." reasons when trying to connect to a local resource on MacOS. I'm filing a bug.
Reporter | ||
Comment 10•2 months ago
|
||
(In reply to Manuel Bucher [:manuel] from comment #9)
Hm, I think this is something we should reflect in the error message. We could expand it in the "Unable to connect..." reasons when trying to connect to a local resource on MacOS. I'm filing a bug.
Good idea!
Description
•