Hmm, I mean in general its probably a terrible idea to be calling bitcoind's RPC from a browser directly...I would probably be happy to see this if we force the setting of an -alloworigin=$ORIGIN option (which implies IP whitelist as well) to force users to use it at least somewhat securely.

There's plenty of good reason to enable RPC from browser, but I agree we have to make it opt-in. Will add that to the patch.

Things like this are not sufficient to make access from browsers safe, because we must also be safe even if the user has old browsers with CORS bugs on their system. (e.g. IIRC old IE was trivially bypassable).

As a result there would have to be a lot of developer resources available to implement, review, and characterize the full set of protections needed to prevent that from being a gaping vulnerability-- and a commensurate really good application for it.

@gmaxwell Done: I've added the flag -rpccorsdomain to match the existing options (and similar option in Ethereum's Geth.)

I've also added tests for that flag.

As for your question: we have an internal website that we use to sign transactions with hardware wallets. We use RPC to send out the signed transactions. We'd prefer to do this without a service (which needs audits, security updates, etc..)

Needs rebase. I'm generally a fan of correct CORS / CSP headers, will review later.

POST works (assuming bitcoin:bitcoin credentials, running on port 8085):

curl -X POST \
  http://localhost:8085/ \
  -H 'Authorization: Basic Yml0Y29pbjpiaXRjb2lu=' \
  -H 'Cache-Control: no-cache' \
  -H 'Content-Type: application/json' \
  -d '{
	"method": "getblockchaininfo"
}'

But OPTIONS doesn't:

curl -X OPTIONS \
  http://localhost:8085/ \
  -H 'Authorization: Basic Yml0Y29pbjpiaXRjb2lu=' \
  -H 'Cache-Control: no-cache' \
  -H 'Content-Type: application/json'
JSONRPC server handles only POST requests

That was using Postman which doesn't set the origin header, but I get the same error from a browser for the OPTIONS request.

@Sjors Just using OPTIONS doesn't make it a valid CORS pre-flight request. Try this:

curl -X OPTIONS \
    http://localhost:8085/ \
    -H 'Authorization: Basic Yml0Y29pbjpiaXRjb2lu=' \
    -H 'Cache-Control: no-cache' \
    -H 'Content-Type: application/json' \
    -H 'Origin: null' \
    -H 'access-control-request-method: POST' \
    -d '{
	"method": "getblockchaininfo"
  }'

Same error unfortunately.

Incorrect OPTIONS request should probably throw a unique error regardless.

I tried your full example, but since the JSON payload itself shouldn't be needed in an OPTIONS request, I think it can be shortened a bit:

curl -X OPTIONS \
    http://localhost:8085/ \
    -H 'Authorization: Basic Yml0Y29pbjpiaXRjb2lu=' \
    -H 'Cache-Control: no-cache' \
    -H 'Content-Type: application/json' \
    -H 'Origin: null' \
    -H 'access-control-request-method: POST'

@Sjors Did you provide the -rpccorsdomain command line arg?

Yes, I used -rpccorsdomain=http://localhost:8080. However I used the wrong port in my Origin header.

Better error messages would be very useful here, either through the browser or rpc log entries.

This worked:

curl -v -X OPTIONS \
    http://localhost:8085/ \
    -H 'Origin: http://localhost:8080' \
    -H 'Access-Control-Request-Method: POST' \
    -H 'Access-Control-Request-Headers: authorization,content-type'

I added -v so you can see the returned headers. I also removed the Authorization header from the OPTIONS request in this example, because browsers won't send credentials during such a request.

If anyone else wants to test a POST request:

curl 'http://localhost:8085/' \
   -H 'Authorization: Basic Yml0Y29pbjpiaXRjb2lu=' \
   -H 'Origin: http://localhost:8080' \
   -H 'Content-Type: application/json' \
   -H 'Accept: application/json' \
   --data-binary '{"method":"getblockchaininfo"}'

Nice to have: support for multiple -rpccorsdomain arguments.

Any malicious website would need to trick the user into handing out RPC authentication details, as well as setting server=1 in bitcoin.conf.

For HTTP Basic Auth they need to trick the user into configuring rpcuser= and rpcpassword= or run the credentials script. Otherwise they need to make the user find and upload the cookie.

I think it would be particularly useful for data visualization. E.g. a mempool chart is much easier to build using client-side javascript that just fetches the data through ajax.

Although potentially very useful for hardware wallets, facilitating wallet access from a browser potentially opens a can of worms. For a non-wallet node I don't see much downside.

Perhaps a compromise (for now) could be to only allow this flag when built with --disable-wallet or --seatbelts=0. A less strict rule could work too, but is likely more difficult to implement and maintain.

@gmaxwell regarding old browsers, I think we should work under the assumption that CORS is broken and any request can be made. Afaik enabling CORS is just a way to allow modern browsers to use the RPC (they require the OPTIONS request to return the right data), not to prevent older browsers from doing that.

@Sjors The default is still CORS disabled. Would you still want it to only be available with --disable-wallet or --seatbelts=0?

Needs rebase if still relevant

@MarcoFalke @Sjors Rebased.

any news on that one? is it going to be merged anytime soon?

Rebased, if anybody still cared.

This patch got merged in Bitcoin ABC which was what I cared about ;)

@lionello that was quick, thank you.
I hope this will get merged soon, since I'd like to spin up some CORS-enabled bitcoind nodes.

This seems like a nice change, and I'd really curious to know what some use-cases are. (Lacking web background, or enough of an imagination myself...)

Maybe something about this could also be added to the documentation https://github.com/bitcoin/bitcoin/blob/master/doc/REST-interface.md

@ryanofsky in my case, I'm considering to use in disablewallet mode as a bitcoin node, that is used by a web wallet, for fetching and sending transactions (transactions are signed on the client, so no private key's are sent around the network). Ofc we can't say for sure, who (which IP) will use the web wallet, but they have one thing in common: the URL of the webwallet. We can leverage this piece of information if the btc node is CORS-enabled.

@ryanofsky The scenarios are having a website interact with the blockchain node directly, without the need for a backend: browser --rpc--> bitcoind. You can do transaction signing in the browser (JS libs, or HW device) and send transactions directly.

Actually NAT doesn't help, because an attacker could tell a user to run bitcoind -rpccorsdomain=http://evil.com/ and have them visit http://evil.com/ which would then empty the users wallet (https://evil.com might not work because some browsers refuse to XHR to http from an https site, but I'd have to test that).

I missed how much RPC and REST are intertwined; it's one and the same server, not a separate one as I assumed. So in the examples above I'm just making normal (authenticated) JSON-RPC requests. Let's try that again:

curl 'http://localhost:8080/rest/chaininfo.json' -H 'Origin: http://localhost:8080'    -H 'Content-Type: application/json'  -H 'Accept: application/json'

The REST interace doesn't expose anything private.

So all you need to change is the only add CORS headers to /rest/*. In that case -restcorsdomain would still be a better param name I think.

After brief IRC discussion today I'm switching to light Concept NACK.

The REST API wasn't intended for this use case. It's meant as a more performant alternative to the JSON-RPC (using bin and hex formats). It's not battle hardened so should only be called by semi trusted software locally. It's not safe against DoS.

I think it's better to recommend users who really want this to run nginx and have that add the headers, as well as shield URLs that are not part of /rest/, only whitelist URLs their application really needs, etc. That seems both safer and to prevent scope creep.

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Conflicts

No conflicts as of last run.

Going to close this. A couple of (implied?) NACKs, and a reversal from a utACK to NACK, no further discussion for 8 months.