web-dev-qa-db-ja.com

Nugetを安全に使用する方法はありますか？

Visual Studioには、インターネットからソフトウェアパッケージをダウンロードして更新するパッケージマネージャーが含まれています。これの一般的な名前は「Nuget」です

私が抱えている問題は、誰でも誰かになりすますことができるということです 所有者フィールドをスプーフィングすることによって 。これにより、更新に関するすべてのワームが開かれ、すべてのパッチの信頼性が検証されます。

  • これらは有効な懸念事項ですか？ （見逃しましたか？）

  • リスクを制限するために実装できる技術的および手順上の制御は何ですか？

  • 安全な方法でNugetを使用する方法はありますか？

appsecsource-codeopensourcepatchingupdates
7
goodguys_activate

Nugetが パッケージID予約 をサポートするようになりました（以下も参照してください プレスリリース ）

これにより、開発者とプロデューサーの間の追加の信頼が可能になりますが、継続的インテグレーション（CI）ビルドの信頼の正しい方向へのステップでもあります（確定的ビルド 不可能 .NETの場合）

0
goodguys_activate

NuGetは現在、パッケージまたはnuspecファイルのコード署名をサポートしていないため、パッケージの作成者を正確に特定できません。この問題は2010年に機能リクエストとして提起されましたが、あまり注目されず、実装されていません。 http://nuget.codeplex.com/workitem/79 を参照してください。

現在、既存のパッケージNuGetは、最初にアップロードされたのと同じアカウントでのみアップグレードできますが、これは、実際に取得しているコードの作者を確認するものではありません。

NuGetの外では、アセンブリのコード署名はまだ存在します。これに基づいて、理想的には次のことをお勧めします。

  • 信頼できる発行元からの署名されたアセンブリのみを使用してください。
  • プロジェクトで厳密な名前の参照を使用します（プロジェクト/アセンブリを特定の公開鍵にバインドします）。
  • ダウンロードする各アセンブリの署名を確認します。

おそらくもう1つの懸念は、NuGetパッケージにPowerShellインストール/アンインストールスクリプトをアタッチできることです。これは、NuGetパッケージのコマンドラインを使用するときに自動的に実行されます。 NuGet 1.4+はPowerShellスクリプトのコード署名をサポートしているため、PowerShell実行ポリシーをRemoteSignedのままにしておくことをお勧めします。

または、NuGetを使用せずに、公式リリースから.msi/.exeをダウンロードして、ファイルの署名を確認します。

4
Bernie White

CLRからサードパーティライブラリまですべてがASP.NET vNextのNuGet経由で配布されるため、NuGetチームは、Visual Studio 2015のリリースまでに、署名されたパッケージのサポートに取り組んでいると思います。

ブログの発表を参照してください： http://blog.nuget.org/20150203/package-signing.html

また、署名仕様を参照してください： https://github.com/aspnet/Signing/blob/dev/Spec.md

2
Josh Pearce