投稿

実践Webペネトレーションテスト

投稿日
Preview Image
投稿者 usek
17 分で読めます

ペネトレーションテスト（侵入テスト）については、このブログでも何回か取りあげています。僕の会社も大手企業にシステムを納品していますが、そうした大きな会社ではセキュリティ部門が自社サービスに対して定期的にペネトレーションテストを実施し、最新の攻撃手法や新たな脆弱性に対してシステムが防御できているかを調べています。「そんな細かいところまで見られるのか」と驚かされる一方で、「これだけしっかり見てもらえると作る側としても安心だな」とも思います。 完璧なソフトウェアやシステムは存在せず、どこかに穴があるものです。そのため、ペネトレーションテストは最低でも製品リリースの前に一度はやっておきたいところです。リリース後はステージング環境に対して行うことで、本番環境に影響を与えずに確認できるためおすすめです。

とはいえ、ペネトレーションテストを実行する専門部署がある会社は、なかなかないのではないでしょうか。外部の専門企業に頼むにしても料金が高く、セキュリティが重要視される昨今とはいえ、簡単に依頼できるものではありません。しかし、今はAIの時代です。

AIがペネトレーションテストを自動化する時代が来た——2026年の主要ツールまとめ

AIにWebアプリを攻撃させてみた 【Strix】

自律型AIエージェントがペネトレーションテストを行ってくれる時代になりました。これは要チェックですね。 AIとセキュリティと言えば、今月政治の世界でさえ名前が挙がっている「Claude Mythos」にも注目です。

Mythosが引き起こす「脆弱性の嵐」に備えよ、専門家250人が対策を提言

Claude Mythos自体は汎用AIエージェントであり、セキュリティに特化したAIではありません。しかし、従来のAIに比べて圧倒的な性能を持つため、これまで安全とされていた、世の中で重要な役割を担うソフトウェアの脆弱性を次々と発見しています。当然、これが攻撃側に渡れば社会が大混乱することが予想されます。そのため、現在は政府機関やセキュリティ企業、OSS組織など限られた対象にのみ公開され、このレベルのAIが社会に広く普及する前に、Mythosを使って脆弱性を事前にできるだけ潰しておこうという活動が行われています。まるで第二次世界大戦後の核兵器のような取り扱いですが、実際それほどの攻撃力を持っていると考えても過言ではないかもしれません。

本書は、これまで専門エンジニアが行ってきた（そして今後はAIエージェントに任せることも期待できる）ペネトレーションテストが、どのような手法で行われているかを解説した一冊です。「実践」とあるように、実際にDocker上で脆弱性のあるサンプルシステムを起動させ、そのシステムに侵入する手法を体験できる、ハッキング・ラボに近い内容となっています。

まずは、このブログでも何度か紹介している「OSINT（Open Source Intelligenceの略）」について。これは一般に公開されている情報源からアクセス可能なデータを収集・分析し、意思決定に役立てる諜報活動の一種です。攻撃者がブラックハッカーであれば、ペネトレーションテスターはホワイトハッカーであり、使うツールは同じです。先日ネット上で話題になっていた以下の記事

外部からアクセス可能なhttpsサイトはドメイン設定後「即」攻撃にさらされる件

で初めて存在を知ったCertificate Transparency Lookupが本書でも紹介されており、個人的にとてもタイムリーでした。

本書を読むと、攻撃する側がいかに徹底的にOSINTを利用しているかが分かります。攻撃対象のOSSのGitHubリポジトリにあるIssueやPull Requestには、攻撃に必要な情報が含まれていることも少なくありません。特に強制Push（force push）でコミット履歴が消された場合、秘匿したい内容だった可能性が高いです。そこで、一見コミット履歴から消えた修正でも、コミットIDを直接指定すれば内容を確認できるというテクニックには驚かされました。

次に、セキュリティ分野ではおなじみの攻撃手法の解説に移ります。単なる用語解説にとどまらず、具体的なコードを用いてSSRFやOSコマンドインジェクションがどのように攻撃に活用されるかが詳細に紹介されています。

特に驚かされたのは、「小文字のiに点が付いていない文字（ı）」を使った攻撃手段です。内部で文字コード変換処理が行われる際に通常の「i」と同一視される仕様を悪用し、攻撃者が点のない文字を使ったメールアドレスを取得してWebサービスでパスワードリセットを行い、まんまと自分宛てにパスワードリセットURLを受け取るという手法です。「メールアドレスは一意である」という前提を覆す、こんな攻撃方法があったとは目から鱗でした。 そして、これら定番の攻撃手法を組み合わせてサンプルのWebサービスに侵入し、データベースの中身を窃取するペネトレーションテストの過程を、最初から最後まで実践します。侵入の糸口を掴むために様々な方法でヒントを収集していく一連の活動は非常に洗練されており、システム開発側は「1カ所でも穴を空けてはならない」というプレッシャーを再認識させられました。特に、設定ファイルの内容からサブドメインでZabbixが動いていることを突き止め、デフォルトのIDとパスワードで不正ログインしたうえで、管理画面からOSコマンドを流し込むという手法は、現場を知る人間として非常にリアリティを感じました。

ペネトレーションテストというと、これまではWebサービスのフロントエンドやバックエンド（API）のみを対象とするものだと思っていましたが、AWSクラウド環境に対するペネトレーションテストの存在も本書で知りました。IAMアクセスキー（とシークレットアクセスキー）を渡すだけで、そのIAM権限で何ができるかをリストアップしてくれるOSSがあることにも驚きです。以前このブログでも「aws login」について解説しましたが、IAMアクセスキーを静的に持たない運用はセキュリティ強化に直結するため、私の会社でも導入を進めて良かったと改めて感じました。 また、万一IAMアクセスキーが普段と異なるアクセス元から使われた場合でも、AWSのマネージド脅威検出サービスである「GuardDuty」が検知し、通知してくれる仕組みは心強いです。クラウド環境を運用する現代においては、有効化必須のサービスと言えます。

最後は、開発・運用側が設定したアクセス制限の「回避と突破」についての解説です。IPアドレスでWebサービスのアクセスを制限することは、その手軽さから私を含め多くの人が経験していると思いますが、きちんと実装しないとIPスプーフィング（偽装）を防ぐことができません。同様に、SAMLやOAuthも誤った実装を行うと、クエリに重要な情報が混入するおそれがあります。Chrome DevToolsやBurp Suiteなどを利用すれば通信内容は容易に読み取れるため、結果的に攻撃者によるなりすましや乗っ取りを許してしまいます。 一部のアプリケーションコードの解説については正直理解が及ばない部分もありましたが、「IPアドレスをレンジで制限していると、攻撃者が同じクラウド事業者のサービスを契約し、そこを踏み台にして攻撃を仕掛けてくる」というリスクは完全に盲点でした。普段はあまり意識しない設定かもしれませんが、設計・運用の際に頭の片隅に入れておきたい重要な知識です。

AIの登場が影響しているのか、最近は脆弱性に関するニュースと、それに伴う対応業務が急増しているように感じます。この記事を書いているのは2026年5月ですが、直近で覚えているだけでも以下の事案がありました。

僕はセキュリティ担当を通常業務の一つとして兼任しているのですが、これだけのペースで重要度の高い脆弱性が次々と報告されるのは珍しい気がします。対応にくたくたです。

bookreview
security
この投稿は投稿者によって CC BY 4.0 の下でライセンスされています。