A2: 認証の不備

OWASP Top Ten に以下の記載があります：

認証やセッション管理に関連するアプリケーション機能が誤って実装されることが多く、攻撃者はパスワード、キー、セッショントークンを侵害したり、他の実装上の欠陥を利用して他のユーザーのアイデンティティを一時的または永続的に引き受けたりする可能性があります。

HTTP がステートレスであるという性質から、Web アプリケーションがユーザを認証する方法として セッショントークン を使用するのはかなり一般的です。セッショントークンは、ユーザーがWebアプリケーションに対して認証されるたびに生成されます。セッショントークンは、多くの場合、ブラウザの Cookieを介してクライアント側に格納され、対応するリクエストごとにサーバーに送信され、ユーザーの身元を検証します。

弱いまたは予測可能な方法でセッショントークンを生成すると、システム内の別ユーザーをハイジャックして偽装を試みる攻撃者の影響を受けやすくなります。これにより、PII(Persionally Identifiable Information) データの漏洩、悪意のあるトランザクション、最終的に顧客の信頼が失われる可能性があります。 これを実証するために、デプロイしたWebアプリケーションがセッショントークンを生成する方法を確認しましょう。

  1. Web アプリケーション URL を開き、[OWASP Top 10 Examples] をクリックし、[A2: Broken Authentication] を選択します。 a2-Select

  2. ユーザー名とパスワードでログインするように求められます。攻撃者の資格情報 (ユーザー名:badguy パスワード:badguy) でログインしてみましょう。 a2-ログイン

  3. 正しい資格情報でログインすると、簡単なウェルカムページが表示されます。 a2-ようこそ

  4. ウェブブラウザの開発ツールを有効にして Cookie を確認しましょう。Mozilla Firefox の場合、ツール/ウェブ開発/ストレージインスペクターからアクセスできます。Chrome の場合、要素の検証/Application/Storage/Cookies から確認できます。 A2-クッキー

  5. sessionId の名前のクッキーが表示されるはずです。見た目からは、base64 でエンコードされた文字列のように見えます。開発者ツールから sessionID の値をコピーし、AWS Cloud9 ターミナルウィンドウに行き、コマンドを入力して sessionID をデコードします。

    echo <paste the copied sessionId>| base64 -d

  6. 出力を注意深く見てみると、ユーザーの認証に使用される SessionID トークンが、ユーザーがログインしたときのユーザー名とタイムスタンプを含む JSON オブジェクトから生成されたのが明らかです。予測不能な値がないため、攻撃者は自分のアカウントを乗っ取るためにユーザー名の値をシステムの既知のユーザーに置き換えるだけで、悪意のあるセッショントークンを簡単に作成できてしまいます。 a2-b64デコード

  7. では、john のアカウント乗っ取ってみましょう。デコードされたJSON文字列をコピーし、ユーザー名の値を john に置き換えるだけです。次に、base64 コマンドを使用して Cloud9 のターミナルウィンドウにこれを入力して、それをエンコードできます。

    echo '<the modified JSON object>' | base64 -w 0

  8. 前の手順のコマンドは、john のアカウントをハイジャックするための新しい base64 セッショントークンを生成する必要があります。 a2-b64エンコード

  9. 次に、そのエンコードされた値をコピーして、ウェルカムページに戻ります。開発者ツールを使用して、base64 でエンコードされた文字列をsessionID クッキーに貼り付けます。 A2-注入クッキー

  10. Refresh キーを押して、john のアカウントにログインされたことを確認します。 a2-エクスプロイト成功