-
-
Notifications
You must be signed in to change notification settings - Fork 3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Don not use Access-Control-Allow-Origin: *
by default
#5996
Comments
Access-Control-Allow-Origin: *
by default Access-Control-Allow-Origin: *
by default
I checked default behavior with vanilla docker images and It seems to be present only for I agree with @Gozala, AFAIK there is no reason to expose webui resources with Current state of things below: v0.4.18$ docker run --rm -it --net=host ipfs/go-ipfs:v0.4.18 In v0.4.18 $ curl 'http://127.0.0.1:5001/api/v0/config?arg=API.HTTPHeaders'
{"Key":"API.HTTPHeaders","Value":{}} Nor is it hardcoded for $ curl -s -I -X GET 'http://127.0.0.1:5001/api/v0/version' | grep -i Access-Control-
Access-Control-Allow-Headers: X-Stream-Output, X-Chunked-Output, X-Content-Length
Access-Control-Expose-Headers: X-Stream-Output, X-Chunked-Output, X-Content-Length But indeed it seems header is hardcoded somewhere for the whitelisted webui path: $ curl -s -I -X GET 'http://127.0.0.1:5001/ipfs/QmSDgpiHco5yXdyVTfhKxr3aiJ82ynz8V14QcGKicM3rVh/' | grep -i Access-Control-
Access-Control-Allow-Headers: Content-Range, X-Chunked-Output, X-Stream-Output
Access-Control-Allow-Methods: GET
Access-Control-Allow-Origin: *
Access-Control-Expose-Headers: Content-Range, X-Chunked-Output, X-Stream-Output
|
Version information:
Repo version: 7
System version: amd64/darwin
Golang version: go1.11.1
Type:
Description:
From what I can tell by default go-ipfs configures itself such that
API/HTTPHeaders/Access-Control-Allow-Origin
is set to[*]
which exposes users to attacks from arbitrary sites. Given that API can be used to remote control IPFS node and the fact that any site can exploit that to deploy an attack.Please consider locking this down properly, in fact I would recommend to go as far as ignoring
*
value even it is set. REST API should really only talk to handful of origins.You could have one endpoint for requesting access so that arbitrary sites could trigger it. That would allow daemon to prompt user and add origin if user accepts.
The text was updated successfully, but these errors were encountered: