脆弱性診断のレポートを書くときに気をつけていること

はじめに
セキュリティエンジニア向けから開発者向けのレポートへ
レポートのフォーマットは一致しているか
- 可能な限り複数人で集まって取り組んだ
まとめ

はじめに

今年8月~10月にかけて行われた第8回千葉大学セキュリティバグハンティングコンテストに参加してきました。

この度、第8回千葉大学セキュリティバグハンティングコンテストにて、RiSTが最優秀賞を受賞しました。

昨年度は優秀賞にて、惜しくも叶わなかった最優秀賞を受賞できて感無量です！！（懇親会も大変楽しませて頂きました！！） pic.twitter.com/4b4Blpp57D
— RiST@立命館セキュリティチーム (@realRiST) 2023年11月28日

今回はコンテストで脆弱性診断のレポートを書くときに気をつけたことや、前回参加時からの改良点などについて書いていきたいと思います。また、本業の診断士の方は温かい目で見てくださると幸いです。

セキュリティエンジニア向けから開発者向けのレポートへ

脆弱性診断のレポート書く上で大切に考えているのは「相手がセキュリティエンジニアだと限らない」ということです。診断を行い、レポートを提出する相手が必ずしもセキュリティエンジニアではないということです。これを考慮するようになれば気にすべき点が複数見つかります。

レポートでセキュリティの専門用語を無駄に多用していないか

レポートを読む対象がセキュリティの専門用語を理解しているとは限りません。もし理解していない場合相手がレポートを読むのに多くの時間や体力を使うことになりあまりフレンドリーではないと思われます。

ただ、利用しないということではなく無駄に多用しないということを意識しました

脅威性や危険度などについてわかりやすく説明できているか

脆弱性の危険性について診断側はある程度理解していますが、相手がそうとは限りません。診断側からすればOSコマンドインジェクションやSQLインジェクションなどの脆弱性が見つかればその時点でかなりの脅威になり得ることがわかりますが、相手にとってその脆弱性がどういったもので、どの程度の脅威になるのかがわからないこともあるでしょう。そのため脅威についての説明については詳細に行うことが大切になります。

脆弱性の再現方法に専用ツールを用いた説明をしていないか

これはまさに前回のレポートです。脆弱性の再現方法についての部分でBurp Suiteやsqlmapを用いた説明を書いてしまい酷評を受けました。専門ツールは便利ですが「相手がそれをインストールしているか」「使い慣れているだろうか」などを考えれば説明として不適切なのは明らかです。今回のコンテストでは、再現にどうしても必要という場合以外では再現方法の項目で利用しないことにしました。

JavaScriptのPoCを記載する形に

PoCはProof of Concept（概念実証）の略であり、新しい概念や理論、アイデアを実証するための検証を指します。サイバーセキュリティの世界では、公開された脆弱性が実際に悪用できるかどうかを実証するためのプログラムやドキュメントを指すことが多い https://www.sompocybersecurity.com/column/glossary/poc

今回のレポートでは再現方法の手順を記載する際にJavaScriptでPoCを作成し、ブラウザの開発者ツールのコンソールに貼り付ければ再現できるようにしました。

(PoCとはここでは脆弱性を再現するプログラムになります。ちなみにJavaScriptのPoCをレポートで利用するという手法は、とある企業のインターンに行ったときに学んだことです)

そうすることで小難しい作業を必要とせず再現ができるようになり、レポートを読む側の負担が減ります。実際には説明 + スクリプトという形で以下のような感じで書きました。

## 再現方法

対象サイトにて任意のユーザーでログインを行ってください
ログイン後〇〇が〇〇であることを確認してください

ログイン後対象サイトの任意のページにて開発者ツールを開き、コンソールに以下のスクリプトを貼り付け実行してください
以下のスクリプトは〇〇を行い〇〇するプログラムです。

---
(async () => {
  const hoge = "taro", huga = "yamada";
  const res = await fetch("https://hogehoge.huga", {method: 'POST',
  credentials: "include",
  headers: {
    "Content-Type": "application/x-www-form-urlencoded",
  },
  body: `xxx=${hoge}&yyy=${huga}`})
  .then(response => {
    if (!response.ok) {
      console.error('サーバーエラー');
    } else {
      console.log("正常に送信されました");
    }
  })
  .catch(error => {
    console.error('通信に失敗しました', error);
  });
})();
---

今回のコンテストではレポートはwordを用いて書いたためスクリプトを書くだけでもデベロッパーフレンドリーなフォントを用いたり、スクリプト部分をコピーしやすくするなどの工夫をしました。

また「相手が開発者ツールをまともに利用できない方だったらどうしよう」という意見も出ましたが「ブラウザの開発者ツールを使えないWebデベロッパーは救えない」という過激派の意見の元割り切ることにしました。

レポートのフォーマットは一致しているか

今回のコンテストでは検査する場所によって複数人で複数の脆弱性に関してレポートを書くことがありました。

コンテストでは大枠のフォーマットは決まっておりそれに従って書けばほとんど問題はないのですが、細かい部分でフォーマットが決まっていないとそれぞれ独自の形式になってしまい大変です。

見る側への配慮はもちろんですがフォーマットを決めておくと、脆弱性診断のレポートを書いたことがないメンバーが書いても一定の質を担保できます。そしてそれをレビューする側も楽です。そのため一石三鳥くらい良いことがあるのです。

可能な限り複数人で集まって取り組んだ

フォーマットもそうですが、診断方法や動き方などについてもある程度共有しておくと効率が良いと思い、今回は数日だけ集まって脆弱性診断に取り組む時間を設けました。形式としては机にモニターを一枚置いてモブプロのような形式であれこれツッコミを入れながらと言った感じです。

これが意外にも刺さりました。1人だと見逃しがちな部分までツッコミが入ることにより、かなり深い部分まで根堀りして脆弱性を見つけることに繋がりました。

夜はこんな感じでしたﾀﾊﾊ...

まとめ

以上が脆弱性診断のレポートで気をつけていることになります。

余談ですが、千葉大学のコンテストは千葉大学生以外でも参加できるようになっているので興味の湧いた方はぜひ参加しましょう！ここだけの話、入賞すれば賞金が貰えるのと、懇親会で超美味しいご飯を食べながら色んな方々とお話ができるのでとてもおすすめです。

記事が参考になりましたら幸いです。