Verify that the resolved URL references fetches the exact package it's nested under in the lockfile

[fabioberger]

Is your feature request related to a problem? Please describe.

Yes. I realized that it's not very hard for an attacker to publish a package to a trusted repository, and therefore simply verifying that all packages are pulled from a trusted repository does not drastically increase the difficulty of performing an attack via lockfile modification. Instead of modifying the lockfile to resolve a dependency to a Github repo, they could simply modify it to point to a malicious package that they've published on a trusted repository.

Example of attack:

ms@^2.1.1:
  version "2.1.2"
  resolved "https://registry.yarnpkg.com/malicious-package/-/malicious-package-2.1.2.tgz#d09d1f357b443f493382a8eb3ccd183872ae6009"
  integrity sha512-sGkPx+VjMtmA6MX27oA4FBFELFCZZ4S4XqeGOXCv68tT+jb3vk/RyaKWP0PTKyWtmLSM0b+adUTEvbs1PEaH2w==

Describe the solution you'd like

An additional check that would increase the difficulty significantly of an attack would be to check that the package being pulled from the trusted repository has the same name as that specified in the lockfile. That way, the attacker would be forced to compromise the legitimate package itself.

The solution I'm proposing is to add an additional verifier that checks that the package name in the lockfile key matches the package name in the resolved URL.

Describe alternatives you've considered N/A

[fabioberger]

@lirantal any feedback on this or the PR implementation?

[lirantal]

Thanks for the ping Fabio, let's take the discussion in the PR 👍🏼