記事

巧妙なウェブサイト脆弱性:複数の欠陥が引き起こすセキュリティリスクの詳細解析

ウェブ管理者向けに複数の脆弱性が合わさったサイトのセキュリティ問題を解説。問題点の特定から対策まで具体的に示し、安全性向上を実現します。

巧妙なウェブサイト脆弱性:複数の欠陥が引き起こすセキュリティリスクの詳細解析

本記事は AI による翻訳をもとに作成されています。表現が不自然な箇所がありましたら、ぜひコメントでお知らせください。

記事一覧


数年前に発見された巧妙なウェブサイトの脆弱性の暴露

複数の脆弱性が重なって引き起こるウェブサイトのセキュリティ問題

Photo by [Tarik Haiga](https://unsplash.com/@tar1k?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText){:target="_blank"}

Photo by Tarik Haiga

はじめに

数年前、まだウェブ開発のサポートをしていた頃、社内のエンジニアチーム向けにCTF競技を開催する任務を任されました。最初は会社の製品ごとにグループ分けして攻防戦を行うつもりでしたが、主催者として参加者のレベルを把握するために、まずは会社の各製品に対して侵入テストを行いました。自分でいくつかの脆弱性を見つけて、イベントの進行に問題がないか確認するためです。

しかし最終的にコンテストの時間が限られており、エンジニアリング分野ごとの差異が大きいため、共通の基礎知識と面白い方向性で問題を出題しました。興味のある方は以前の記事「楽しいエンジニアリングCTFコンテストの作り方」をご参照ください。中には斬新な問題がたくさんあります!

発見された脆弱性

三つの製品で合計四つの脆弱性を見つけました。本文で取り上げる問題のほかに、以下の三つの一般的なウェブサイトの脆弱性も発見しました:

  1. Never Trust The Client!
    問題は基本的なもので、フロントエンドが直接IDをバックエンドに送信し、バックエンドがそれをそのまま受け入れている点です。ここはTokenで認証するように変更すべきです。

  2. パスワードリセットの設計欠陥
    実際には詳細を忘れましたが、プログラム設計に欠陥があり、パスワードリセットの手順でメール認証を回避できました。

  3. XSSの問題

  4. 本記事で紹介する脆弱性

検索方法はすべてブラックボックステストで行い、XSS問題が見つかった製品のみ私が開発に関わっており、他は一切コードを見ていません。

脆弱性の現状

ホワイトハッカーとして、発見した問題はすべて速やかにエンジニアチームに報告し修正しました。現在は2年が経過し、公開しても良い時期だと考えています。ただし、前職の立場を考慮し、本記事ではどの製品で発生したかは触れません。この脆弱性の発見経緯と原因のみ参考にしてください。

脆弱性の影響

この脆弱性により、侵入者は対象ユーザーのパスワードを自由に変更でき、新しいパスワードで対象ユーザーのアカウントにログインし、個人情報を盗んだり、不正行為を行ったりすることが可能です。

脆弱性の主な原因

タイトルの通り、この脆弱性は複数の原因が組み合わさって発生しました。以下の要素が含まれます:

  • アカウントログインは二段階認証やデバイスバインディングに対応していない

  • パスワードリセット認証でシリアル番号を使用している

  • ウェブサイトのデータ暗号化機能に復号の脆弱性がある

  • 暗号化機能の誤用

  • 検証トークンの設計ミス

  • バックエンドでの二次検証が行われていない

  • プラットフォーム上のユーザーのメールアドレスは公開情報となっている

脆弱性の再現方法

プラットフォーム上でユーザーのメールアドレスが公開情報であるため、まずプラットフォーム上でターゲットの侵入アカウントを閲覧します。メールアドレスを確認した後、パスワードリセットページに移動します。

  • まず自分のメールアドレスを入力してパスワードリセットを行います。

  • 侵入したいアカウントのメールアドレスを入力し、同様にパスワードリセット操作を行います。

上記の2つの操作はいずれもパスワードリセットの確認メールを送信します。

自分のメールボックスに入り、自分宛のパスワードリセット確認メールを受信する。

パスワード変更リンクは以下のURL形式にしてください:

1
https://zhgchg.li/resetPassword.php?auth=PvrrbQWBGDQ3LeSBByd

PvrrbQWBGDQ3LeSBByd は今回のパスワードリセット操作の認証トークンです。

しかし、サイトの認証コード画像を観察していると、認証コード画像のリンク形式も以下のように似ていることに気づきました:

1
https://zhgchg.li/captchaImage.php?auth=6EqfSZLqDc

6EqfSZLqDc5136 を表示します。

では、私たちのパスワードリセットTokenを入れたらどうなる?気にせずに! 入れてみよう!

ビンゴ!

しかし、認証コードの画像が小さすぎて、完全な情報を取得できません。

私たちは引き続き利用可能なポイントを探します…

ちょうどサイトはクローラーの妨害を防ぐために、ユーザーの公開プロフィールのメールアドレスを画像で表示しています。キーワード:画像で表示!画像で表示!画像で表示!

すぐに開いて確認してください:

個人プロフィールページ

個人情報ページ

ウェブページのソースコードの一部

ウェブページのソースコード部分

私たちも同様のURL形式の結果を得ました:

1
https://zhgchg.li/mailImage.php?mail=V3sDblZgDGdUOOBlBjpRblMTDGwMbwFmUT10bFN6DDlVbAVt

V3sDblZgDGdUOOBlBjpRblMTDGwMbwFmUT10bFN6DDlVbAVt[email protected] を表示します

もう気にしない!詰め込め!

ビンゴ!🥳🥳🥳

PvrrbQWBGDQ3LeSBByd = 2395656

パスワードリセットトークンを逆解析した結果、数字であることが判明した後

シリアル番号かもしれないと思いました。。。

再度メールアドレスを入力してパスワードリセットをリクエストし、新しく届いたメールのトークンを復号すると、2395657 … まさか本当にそうだったとは…

連番が分かれば対応は簡単なので、最初の操作ではまず自分のアカウントのパスワードリセットメールをリクエストし、その後に侵入対象のリクエストを行います。次にリセットするパスワードのIDを予測できるためです。

次に、2395657 をトークンに戻す方法を考えるだけです!

なんとまた問題を発見しました

サイトのデータ編集時のメールアドレス形式の検証はフロントエンドのみで行われており、バックエンドでの再検証はされていません…

フロントエンドの検証を回避した後、メールアドレスを次のターゲットに変更する

穴に火事だ!

私たちは得た:

1
https://zhgchg.li/mailImage.php?mail=UTVRZwZuDjMNPLZhBGI

この時点で、このパスワードリセットトークンを持ってパスワードリセットページに戻ります:

侵入成功!認証を回避して他人のパスワードをリセット!

最終的に二段階認証やデバイスバインディング機能がなかったため、パスワードが上書きされるとすぐに不正ログインが可能になりました。

事の発端

全体の流れを整理します。

  • 最初にパスワードをリセットしようとしましたが、リセット用のトークンが実際にはシリアル番号であり、本当のユニークな識別トークンではないことがわかりました。

  • サイトが暗号化・復号化機能を乱用し、機能ごとの区別がなく、ほぼ全サイトで同じキーを使用している

  • サイトにはオンラインで任意の暗号化・復号化が可能な入口が存在する(つまり、鍵が無効化されている)

  • バックエンドでユーザー入力の二段階認証を行っていない

  • 二段階認証保護やデバイス紐付け機能がない

修正方法

  • 最も基本的なことは、パスワードリセットのトークンはランダムに生成された唯一の識別トークンであるべきです。

  • サイトの暗号化・復号化部分は、機能ごとに異なる鍵を使うべきです。

  • 外部から自由にデータの暗号化・復号化を操作できないようにする

  • バックエンドはユーザーの入力を検証する必要があります

  • 念のため、二段階認証とデバイス認証機能を追加する

まとめ

全体の脆弱性発見の過程には驚かされました。多くは基本的な設計の問題だからです。機能だけを見ると動作は可能で、小さな穴があっても安全と思われがちですが、複数の穴が組み合わさると大きな穴になってしまいます。開発では本当に慎重になるべきです。

関連記事

ご質問やご意見がありましたら、こちらからご連絡ください

PostZMediumToMarkdown によって Medium から変換されました。


🍺 Buy me a beer on PayPal

👉👉👉 Follow Me On Medium! (1,053+ Followers) 👈👈👈

本記事は Medium にて初公開されました(こちらからオリジナル版を確認)。ZMediumToMarkdown による自動変換・同期技術を使用しています。

Improve this page on Github.

本記事は著者により CC BY 4.0 に基づき公開されています。