npm uses auth token from registry on http[s]:// dependencies, breaking BitBucket URLs

[MaxMotovilov]

npm@2.10.1
Excerpt from the log:

1010 http fetch GET http://bitbucket.org/12qcp/sequelize/get/fc2.tar.gz
1011 verbose request using bearer token for auth

further:

1724 info retry will retry, error on last attempt: Error: Exceeded maxRedirects. Probably stuck in a redirect loop https://bitbucket.org/account/signin/?next=/account/signin/%3Fnext%3D/account/signin/%253Fnext%253D/account/signin/%25253Fnext%25253D/account/signin/%2525253Fnext%2525253D/account/signin/%252525253Fnext%252525253D/account/signin/%25252525253Fnext%25252525253D/account/signin/%2525252525253Fnext%2525252525253D/account/signin/%252525252525253Fnext%252525252525253D/12qcp/sequelize/get/fc2.tar.gz
1725 http fetch 302 http://bitbucket.org/12qcp/sequelize/get/fc2.tar.gz
1726 error fetch failed http://bitbucket.org/12qcp/sequelize/get/fc2.tar.gz
1727 warn retry will retry, error on last attempt: Error: fetch failed with status code 302

Removing auth token with npm logout helps. Apparently BitBucket server reacts badly to foreign auth tokens. This issue has not been observed with npm 1.x.

[othiym23]

This has been moved to the npm roadmap, which we're using instead of the confusing next-* labels now.

[wbinnssmith]

The 302s are definitely our (Bitbucket's) fault though. We should be able to get back a saner status code and stop the infinite redirect. Can anyone point me where the http request is made in npm?

[othiym23]

@wbinnssmith https://github.com/npm/npm-registry-client/blob/master/lib/fetch.js#L68-L91 is the bit that actually invokes request, but you'll need to look at https://github.com/npm/npm/blob/master/lib/cache/add-remote-tarball.js#L85-L122 to see where it's getting called from within npm. Thanks for taking a look!

[erikvanzijst]

I'm having trouble reproducing this (I'm one of the Bitbucket devs). Can you reproduce this with curl on the command line and hand me a command I can test with? Go ahead and obscure the actual token value.

[mmoskal]

I would think this can be considered a security issue - you're leaking the npm auth token to a web server hosting a dependency. For repro, you can use this:

{
  "private": true,
  "dependencies": {
    "typescript": "https://az742082.vo.msecnd.net/files/npm0/typescript-1.7.0-node4.tgz"
  }
}

The Azure blob storage will give you 403 because of the bearer token.

[mitar]

Yes, this is a security issue. I have reported this in November 2015 to security@npmjs.com and they confirmed it but nothing has changed since then:

Thank you for reporting this issue! As you have noted from the npm issue 8380, we were already aware of this particular problem, and a team is assigned to resolve it (because it is security related, the work is being kept internal to npm).

There is a related issue here: mapbox/mapbox-upload-validate#28

My full report to them is here:

---

I noticed that npm is adding Authorization header with all requests it is making, to all sites, giving my npm token to everyone. And it is doing that even over plain connections.

For example if I have package.json:

{
  "name": "test",
  "version": "0.0.0",
  "dependencies": {
    "test": "http://requestb.in/<bin ID>"
  }
}

And I run npm install, the resulting headers are:

Host: requestb.in
Via: 1.1 vegur
Authorization: Bearer <my auth token>
User-Agent: npm/3.4.1 node/v0.12.2 darwin x64
X-Request-Id: 5a5cacc5-64f8-4176-a123-bd5444ab9852
Referer: install
Accept: application/x-tar, application/vnd.github+json; q=0.1
Npm-Session: 3462b661f2514ef2
Connect-Time: 1
Connection: close
Version: 3.4.1
Total-Route-Time: 0

See the Authorization header.

My ~/.npmrc file contains:

//registry.npmjs.org/:_authToken=<my auth token>

So, observe that I used HTTP and not HTTPS with requestb.in.

I observed this when downloading file from AWS because AWS was returning HTTP 400 because the authorization header was invalid for them.