typosquatting — 名前のなりすまし

攻撃者は、人気パッケージの名前を少しだけ変えた名前で、悪意あるパッケージを公開します。たとえば(実在するかどうかに関わらず、パターンとして):
・文字の入れ替え(cross-env → corss-env)
・文字の欠落(electron → electorn)
・似た見た目の文字(l と 1、rn と m)
・スコープの誤認(@babel/xxx に似せた無関係のスコープ)
インストールコマンドを急いで打つとき、1文字のタイプミスだけで、まったく別の、悪意あるパッケージを入れてしまう危険があります。

このコースでは、実在する悪意あるパッケージ名を具体的には挙げません。手口のパターンを理解し、防御の習慣を身につけることが目的です。特定のパッケージ名を晒すことは、かえってそれを探す人を増やしかねません。

1. npm の公式ページで、名前を確かめる。https://www.npmjs.com/package/<名前> を開き、綴りが正しいか、目で見て確認する。
2. ダウンロード数を見る。週間ダウンロード数が桁違いに少ない、あるいは公開されたばかりなのに有名パッケージのふりをしている——は危険信号。
3. リポジトリのリンクを確かめる。公式ページに「Repository」として貼られているリンクが、実在する・信頼できる組織のものか。誰も管理していないような空のリポジトリは危険信号。
4. メンテナと更新履歴を見る。有名パッケージのふりをして、実際の作者と違う人物が最近作ったばかりのパッケージでないか。

npm install は、コマンド一発で気軽に打てます。だからこそ、急いでいるときほど、タイプミスに気づきにくい。sec-tooling で見た「出どころを選ぶ」の精神を、ここでも思い出してください——知らないパッケージ名を打つときは、一呼吸置いて、公式ページで確かめる。とくに、package.json に新しい依存を足す・チーム外から共有されたコマンドをコピペする、といった場面で、この一手間が効きます。

前章の integrity ハッシュは、typosquatting そのものは防げません(名前を間違えて指定すれば、その通り違うパッケージが lockfile に記録されてしまいます)。でも、一度確認して正しくインストールされた依存が、その後こっそり中身を差し替えられる——という別の脅威に対しては、しっかり効きます。それぞれの防御が、それぞれ別の脅威に効く——これも多層防御の一形です。