「Snykを使ってコードをセキュアにした記事を投稿しよう！ by Snyk Advent Calendar 2023」7日目の記事になります。
Snyk がすごい
Snyk は DevSecOps のための統合プラットフォームのようです（雑）
無料で始めることができて、自身のソースリポジトリと紐付けて、継続的に脆弱性に目を光らせてくれるというすごいやつなんですが、これがなんと、自分のソースだけでなく、github の任意の public リポジトリを取り込んでソースコードに対するセキュリティスキャンをかけることができるのです。これも無料の範囲で！
No creadit card required なのが地味に嬉しい
つまり、自分のソースコードだけでなく、依存先の OSS ライブラリに対する脆弱性を監視することもできるし、OSS 選定のひとつの指標として使うこともできそうですね。
そこで今回は .NET で比較的スターの多い OSS をターゲットに、いくつかインポートしてみて、実際にどんな脆弱性が検出できるかを試してみました。
プロジェクトをインポートしてみる
Add Projects > Monitor public GitHub repos を選択
リポジトリの URL を入れるだけで簡単に取り込めます。
取込みが終わると自動的にスキャンされていきます。
なるほど。。（一応リポジトリ名を隠しておきました）
とりあえず、数だけ見ると予想以上に出てきてびっくりですね。
ヤバイ度順に、C, H, M, L として件数が表示されています。
ただし展開して見たところ、テストコードについて検出されたものなんかも含まれていました。
リポジトリを指定してインポートすると、中に含まれるプロジェクトを自動で見つけて取り込んでくれますが、個別に選択して削除することもできます。
本来はテストコードのプロジェクトなど監視の必要がないものは削除しておいたほうが良いですね。
それでは、どんなものが検出されているか見ていきましょう。
使用ライブラリの既知の脆弱性
プロジェクトで利用しているライブラリの中に、既知の脆弱性があるものが含まれていると検出してくれます。
直接依存しているライブラリだけでなく、依存先のライブラリで利用している別のライブラリへの依存（推移的依存）も含めてチェックしてくれるようです。
Microsoft.AspNetCore.Server.Kestrel.Transport.Sockets - Denial of Service (DoS)
ライブラリが依存している Microsoft.AspNetCore.Server.Kestrel.Transport.Sockets について、 Microsoft.AspNetCore v2.1.0 で見つかった DoS の脆弱性の影響を受けていることが検出されています。
v2.1.40 で修正されているというところまで教えてくれていますね。
詳細情報として、脆弱性データベースの当該情報へのリンクも記載されています。
Snyk: Microsoft.AspNetCore.Server.Kestrel.Transport.Sockets - Denial of Service (DoS)
System.Text.Encodings.Web - Remote Code Execution (RCE)
こちらは System.Text.Encodings.Web に含まれる、リモートコード実行の脆弱性ですね。
テキストエンコードの処理方法に問題があり、任意のコードを実行される脆弱性が存在したようです。
Microsoft Security Advisory CVE-2021-26701 | .NET Core Remote Code Execution Vulnerability #49377
こちらも System.Text.Encodings.Web のバージョンを上げることで解消されるようです。
実際には、AspNetCore v2.1.0 の参照先にこのライブラリが含まれていたようですね。
Newtonsoft.Json - Insecure Defaults
こちらは Newtonsoft.Json に含まれていた、Insecure Defaults の脆弱性が検出されています。
デフォルト設定のまま、ネストの深い JSON をシリアライズしようとすると StackOverflowException が発生する問題があったということのようです。
修正としては、処理するネストの深さのデフォルト値を変更したようで、脆弱性情報のページから github の修正プルリクエストまでたどることができました。
Snyk: Newtonsoft.Json - Insecure Defaults
Change JsonReader and JsonSerializer default max depth to 128 #2462
そしてなんとこちらも参照元は AspNetCore v2.1.0！
問題の多いバージョンだったんですね。。
その他
ほかには以下のような既知の脆弱性が検出されていました。
- System.Net.Http - Denial of Service (DoS) (CVE-2017-0247)
- System.Net.Http - Improper Certificate Validation (CVE-2017-0248)
- System.Net.Http - Information Exposure (CVE-2018-8292)
- System.Text.RegularExpressions - Regular Expression Denial of Service (ReDoS) (CVE-2019-0820)
コード分析
参照ライブラリの脆弱性だけでなく、ソースコードに対する静的解析により、危険なにおいのするコードを検出してくれます。
Use of Hardcoded Credentials
認証情報がハードコーディングされているっぽいところを検出していますね。
今回はテストコードでしたが、うっかりデバッグ中のコードをそのままコミットしてしまうようなケースもあるので助かります。
Path Traversal
コマンドラインの入力に対し、サニタイズせずそのまま File.Exists() に渡しているため、../../foo.txt みたいな指定が通ってしまうということですね。
これ、すごいのは、実際に File.Exists() を実行しているのは、呼び出し先メソッドの中からさらに呼び出したメソッドの先くらいなんですよね。
静的解析でそこまで追いかけて検出してくれるのはすばらしいです。
Deserialization of Untrusted Data
オブジェクトを JSON にシリアライズする際のオプションで TypeNameHandling.All が指定されていることを警告しています。
たとえば IPerson インターフェースを持つ Person クラスのオブジェクトをシリアライズする際、元の型が Person であったという情報が失われるとデシリアライズの際に困ることがあります。
TypeNameHandling の指定を使うと、元の型名 Person を含めて JSON にシリアライズすることができますが、これを悪用すると、シリアライズされた JSON の型名を BadPerson に書き替えた状態でデシリアライズさせて悪意あるオブジェクトを挿入することができてしまう、ということですね。
Use of Password Hash With Insufficient Computational Effort
MD5 のハッシュは安全でないので、SHA-256 とかを使いましょうというやつですね。
修正プルリクエストの作成
github との連携機能により、検出された脆弱性に対する修正のプルリクエストまで作成できます。
Snyk の管理画面から Settings > GitHub で、まず GitHub のアクセストークンを設定しておく必要があります。
アクセストークンは、GitHub の個人アカウント設定から、Settings > Developer Settings > Personal access tokens で作成できますね。
Tokens (classic) と、ベータ版の Fine-grained personal access tokens がありました。
今回は Fine-grained のほうで作成。
Generate new token から、期限や権限を選択します。
snyk からのプルリクエスト作成には、書き込み権限が必要ということでした。
なので、所属していない OSS リポジトリに対してはさすがに勝手に PR を作ったりはできなさそうですね。
修正 PR 作成可能な脆弱性については、「Fix this vulnerability」のボタンが表示されるようでした。
また、GitHub 統合の設定ページから、検出された脆弱性の修正や、依存ライブラリのバージョンアップのための PR を自動で生成することもできるようでした。
こちらは今回は試していません。
OSS リポジトリで見つかった脆弱性に対しては、公開の issues やプルリクエストよりは、リポジトリの Security タブにポリシーや報告先の記載があればそれに従うのがベターですね。
おわりに
Snyk は AWS との連携機能も充実しているようで、実際の開発では、CodePipeline に組み込んで CI でのビルドをトリガにスキャンを実行する、といった使い方もできそうです。
下記ページで詳しく紹介されていました。
Snyk を利用した AWS における脆弱性管理のベストプラクティス
今日のシステム開発では何百という OSS に依存したソフトウェアとなるケースも普通ですから、自分のコードだけに責任を持てばよいというわけにもいかなくなっています。
こういうツールをうまく活用して DevSecOps をまわしていきたいですね。