自分のブログを攻撃してみた

※この記事にはアフィリエイトリンクが含まれます。広告の有無で、記事の評価や内容を変えることはありません。

【大切な注意】 この記事で使うOWASP ZAPなどの診断ツールは、自分が管理している環境にだけ使ってください。許可のない他人のサイトやサーバーに使うと、法的な問題になることがあります。

また、自分のサイトであっても、インターネットに公開している本番環境や、VPSなど共有の基盤の上では、診断ツールを使わないでください。 他の利用者や事業者の設備に影響が及ぶ可能性があり、事業者の利用規約に反することもあります。

私は、診断ツールを自分のPC上の隔離した環境でだけ使い、診断ツールを本番のサーバーに使ったことは一度もありません。

この記事は、私自身の体験を紹介するものです。記事の内容を試した結果や、それによって生じた損害について、私は責任を負いかねます。実施は、ご自身の責任と判断でお願いします。

自作ブログを公開する前に、攻撃ツールを自分の環境の外に出さずに試す方法で診断しました。この記事では、その閉じ込め方の考え方と、診断の流れ、やってみて気づいたことを書きます。

設定値やコマンド、構成の細部、診断で見つかった個別の内容は載せません。方針と結果に絞ります。

なぜ、攻撃ツールを閉じ込めるのか

診断ツールは、アプリに対して本物の攻撃と同じ種類のリクエストを大量に送ります。設定を間違えると、次のような事故が起きえます。

• 診断の対象を取り違えて、本番のサーバーや他人のサイトに送ってしまう
• 診断中に見つかったリンクをたどって、意図しない外部のサイトにアクセスしてしまう
• テスト用のつもりで、本物のデータや認証情報を使ってしまう

だから私は、「間違えても外に出ない」状態を先に作ってから診断することにしました。気をつけて操作するのではなく、そもそも外に出られない構造にする、という考え方です。

なぜこの診断を始めたのかというと、実はコードの静的診断を行って、それで満足していたのですが、昨今の事情に鑑みて、動的診断も必要だと思ったからです。静的診断だけでは、どうしても限界があります。そこで、サンドボックス化したローカル環境で実際に試験を行い、安全性を確保したいと考えました。多層防御の考えで設計して構築していますが、最後の砦を抜かれないよう、さらに要塞化したいと考えたことも理由です。

閉じ込めの構造: ホストOSは「起動」と「レポートの受け取り」だけ

閉じ込めのルールは、次の3つです。設定値は載せず、考え方だけ書きます。

1. 診断専用のネットワークを作り、外へ通信できない設定にする。 アプリが外のインターネットにも、本番のサーバーにも届かない状態にします。
2. 診断ツールも、同じネットワークの中に置く。 外に出られないネットワークは、ホストOSからも直接つなぎにくくなります。そのため、ホストから診断するのではなく、診断ツール自体をコンテナにして、アプリと同じ中に入れました。
3. 診断の対象は、本番とは別のコピーにする。 データはテスト用のダミーで、認証情報も本番とは別のものを使います。

ホストOS(自分のPC)の役割は、コンテナの起動と停止、そして診断が終わったあとのレポートファイルの受け取りだけです。診断の通信そのものは、ホストを通りません。

図は、ローカルのテスト環境の構成を示したものです。本番の構成や、実際のアドレス・ポート番号などは載せません。

診断の流れ: 静的診断と動的診断を、交互に回す

公開前の診断は、次の順番で進めました。

1. 静的診断: コードを読んで、危ない書き方や設定を洗い出します。ここでは、AIのClaude Codeを使いました。
2. 修正: 見つかった問題を直します。
3. 動的診断: 隔離した環境で動かしたアプリに、OWASP ZAPで疑似攻撃を送ります。
4. 結果の確認と、追加の修正: レポートを読んで、必要な対策を足します。
5. 公開: 一通り確認できてから、本番にリリースします。

静的診断は「コードの中」を、動的診断は「実際に動いている姿」を見ます。コードだけでは分からない問題が、動かして初めて見つかることもあるので、両方を使いました。

実際には、細かな設定ミスが見つかりました。修正したあとに再度診断して、合格を確認してから、リリースしています。つまり、2回診断して確認しています。診断では、インフラの設定も確認しています。

見つかったものの種類

診断で指摘されたのは、次のような種類のものでした。個別の指摘の中身は、攻撃のヒントになりうるので載せません。

• ブラウザに安全な動きをさせるための、通信の付加情報(HTTPヘッダ)に関するもの
• 外部のサービスからファイルを読み込む構成に関するもの
• ページ内で動くスクリプトの扱いに関するもの

ZAPは自動のツールなので、指摘のすべてが本当の問題とは限りません。私は、指摘を一つずつ読んで、対応が必要かどうかを自分で判断しました。

意外だったこと

• 「設定されているはず」と思い込んでいたものが、実際に確認すると、期待どおりではなかった。 ZAPの指摘を受けて、本番の実際の応答を(診断ツールではなく、通常のリクエストで)確かめて、初めて分かりました。守りの設定は、思い込みではなく、実際の応答で確認するものだと実感しました。
• ZAPの「対策がない」という指摘が、誤検知だった。 実際には別の仕組みで守られていて、ツールがその仕組みを知らなかっただけでした。指摘をそのまま信じず、コードと照らし合わせて確かめる大切さを感じました。
• ブラウザからの違反報告で、新しい方式が手元では動かなかった。 仕様上は新しい方式が推奨されていますが、ローカルでは報告が1件も届きませんでした。古い方式に変えたらすぐ届いたので、「推奨されていること」と「実際に動くこと」は別だと分かりました。
• 使っていないと思っていた外部の読み込みが、終了済みの配信元を参照していた。 実際には動いていませんでしたが、使っていない外部への依存が残っていたので、整理しました。
• データの一意性を守る仕組みが、足りていなかった。 集計の処理を別のスレッドに移そうとして気づきました。そのまま移していたら、まれに、同じ番号の記事ができるところでした。

判断に迷ったこと

• 守りを強める設定を、すぐ本番で有効にするか。 有効にすれば守りは強くなりますが、広告やバナーの表示が壊れるおそれがありました。収益と審査への影響を考えて、広告の表示を確かめながら、慎重に進めることにしました。
• 運営者情報に、使っているソフトを書くか。 「自分で作って運用している」ことは信頼の材料になりますが、攻撃者の下調べの材料にもなります。名前は残し、版数や防御の仕組みは外しました。
• 自動で作るレポートに載せる攻撃のパスを、どこまで絞るか。 攻撃者が書き込んだ宣伝の文字列は載せたくないのですが、ファイルの拡張子と国別ドメインが同じ文字列になるものがあり、厳しくしすぎると、本物の攻撃の記録まで消えてしまいます。完全には止めず、最後は公開前に目視で確認する形にしました。

やってみて気づいたこと

診断をやってみて、特に強く残った教訓は、次の3つです。

1. 「あるはず」を、実際に確かめる。 設定は、思い込みではなく、実際の応答で確認する。
2. ツールの指摘を、そのまま信じない。 誤検知もあるので、コードと照らして確かめる。
3. 「使っていないはず」を疑う。 外部への依存や、残っている古い記述を、定期的に棚卸しする。

一番印象に残っているのは、診断ツールの指摘ではなく、処理を移そうとして初めて見つかった問題があったことです。ツールだけでは見つからないものがあるので、静的診断、動的診断、そして自分の目、の3つを組み合わせる意味があると感じました。

手元で確認してから、ConoHa VPSへ公開した

診断はすべて手元のPCで行い、問題を直したあとで、本番としてConoHa VPSに公開しました。診断そのものは、VPS上では行っていません。

本番に出す前に、手元で壊したり、攻撃したりできる環境があると、公開後の不安がかなり減ります。VPSは、そのあとの「公開用の場所」として使っています。

公開後のログや、攻撃を受けた実際の数字は、ConoHa VPSのセキュリティを見直して2週間、届いた攻撃ログと守りの考え方に書いています。

ConoHa VPSの最新の料金とキャンペーンは、公式ページで確認してください。

まとめ

攻撃ツールを使うときは、気をつけて操作するのではなく、間違えても外に出ない構造を先に作るのがおすすめです。ホストOSは起動とレポートの受け取りだけにして、診断の通信は専用ネットワークの中で完結させました。

セキュリティは本職ではありませんが、隔離した環境で、攻撃を受ける側の目線を試せたことは、大きな収穫でした。

繰り返しになりますが、診断ツールは、自分が管理する環境にだけ使ってください。