Avoid HTTP URLs in shrinkwrap files

Last week we were notified by security researcher Deian Stefan of a potential security issue for some packages in the npm Registry. The issue was publicly disclosed today. We appreciate his responsible disclosure of the issue, and his efforts in researching it thoroughly.

What’s the problem?

The root of the problem is that HTTP URLs are insecure and are vulnerable to interception by “man in the middle” (MITM) attacks. These insecure URLs can be embedded in shrinkwrap files, thus forcing a victim to download code that is not what they were expecting. An attacker who can deliver arbitrary code in this way can do any number of malicious things.

How serious is this?

We judge the severity of a security flaw by two criteria: impact and likelihood. The impact of this attack is very severe. However, the probability of this attack is very low:

• Only 0.03% of packages in the registry have shrinkwrap files that are vulnerable to this attack
• An attacker needs to be on the same network as the victim
• The victim must be downloading one of the specific packages for the first time at the time of the attack

How can I avoid this vulnerability?

The npm Registry has served metadata over HTTPS for over 4 years and switched entirely to HTTPS in April 2016. This probably accounts for why the number of affected packages is so low: packages created or updated since April 2016 will not have this vulnerability.

All registry packages are available over HTTPS, so if you discover a package with HTTP URLs in its shrinkwrap file, the fix is as simple as adding an “S” to the URLs and pushing an update to the package.

How will we avoid this in future?

The changes necessary to prevent this recurring have already happened, so only individual package authors need to act to update specific insecure packages. We also recommend authors deprecate insecure package versions with a message referring to the vulnerability.