Coders Conquer Security:シリーズ「シェア&ラーン」セッション管理の弱点とは?

2019年1月31日発行
ジャープ・カラン・シン著
ケーススタディ

Coders Conquer Security:シリーズ「シェア&ラーン」セッション管理の弱点とは?

2019年1月31日発行
ジャープ・カラン・シン著
リソースを見る
リソースを見る

あるウェブサイトにアクセスし、ログインします。いつものように、購入したい商品をカートに入れます。ところが、手が滑ってブラウザのタブを閉じてしまったのです。慌ててブラウザにサイトのURLを入力し直し、「Enter」キーを押します。すると、ログインした状態でサイトに戻り、カートの中にはすべての商品が残っていました。ふう。

再認証しなくても、どうやってサイトがあなたのことを知っていたのですか?それは、セッションを使用しているからです。セッションは、Webサイトを利用する際にユーザーエクスペリエンスを向上させる重要な要素です。しかし、セッションの管理を誤ると、攻撃者に悪用されるセキュリティホールが発生します。

ここで、セッション管理とは何か、セッション管理が不十分だとどうなるか、セッションを適切に管理するためにはどうすればよいかを確認しましょう。

セッション管理の弱点を理解する

セッションとは、アプリケーションを使用する一人のユーザーに固有の、サーバーに保存された値のことです。これが必要な理由は2つあります。まず、HTTPはステートレスなプロトコルです。まず、HTTPはステートレスなプロトコルであり、各リクエストは個別であり、前後のリクエストを知ることはできません。セッションは、誰がリクエストを送ったかをサーバーが追跡するのに役立ちます。そうでなければ、ボタンやリンクをクリックするたびにログインする必要があります。

セッションが必要な2つ目の理由は、ユーザーの認証です。セッション識別子を使用して、システム内で特定の権利を持つ特定のユーザーを認識することができます。アプリケーションは、その人が誰なのか、何をすることが許されているのかを知ることができます。

セッションには2つの要素があります。サーバー側のデータストアには、セッション識別子が保存され、ユーザーIDやカート情報などのユーザーに関する情報にマッピングされます。同じセッション識別子は、クッキーでブラウザに送信されます。クッキーは、ブラウザによってユーザーのシステムに保存されます。クライアントは、リクエストごとにクッキーを渡し、このリクエストが同じユーザーからのものであることをサーバーに知らせます。ほとんどのアプリケーションでは、認証前と認証後の両方でユーザーを追跡するためにセッションを使用しています。

適切なセッション管理は、アプリケーションのセキュリティに不可欠です。有効なセッションIDは、ユーザ名/パスワード、あるいは第二因子認証トークンと同じレベルの信頼性を持っています。

セッション管理の不備が危険な理由

セッション管理が不十分だと、アカウントが完全に乗っ取られる可能性があります。つまり、顧客データが盗まれたり、商品が不正に購入されたりする可能性があるのです。攻撃者が有効なセッションIDを取得する方法はいくつかあります。

セッション固定化攻撃は、ユーザーがシステムにログインしたときなどの重要なタイミングでセッションが変更されず、URLを使ってセッション識別子が設定できる場合に発生します。このようにセッション識別子を設定すると、同じ認証ソースを使用する異なるアプリケーション間でユーザーのログイン状態を維持するために使用されることがあります。この場合、攻撃者は Web サイトを閲覧してセッション ID を取得します。次に、攻撃者は、セッション ID を記載した URL を、無防備な被害者に電子メールで送信します。犠牲者はメールに記載されたURLをクリックし、ウェブサイトにログインします。ログイン時にセッションIDがローテーションされていない場合、攻撃者は有効で認証されたセッションIDを持つことになります。これにより、アカウントの完全な乗っ取りが可能になります。

貧弱なセッション管理に対するもう一つの攻撃は、ブルートフォースによる推測攻撃です。開発者が独自のセッション管理システムを作成しようとすると、多くの場合、簡単に推測できるようなセッションIDを使用します。セッションIDは、(1、2、3)のように連続していたり、ある種の予測可能なパターンであったりします。攻撃者は、有効なセッションIDが見つかるまで、単純にセッションIDを推測し続けます。これは、アカウントの乗っ取りにもつながります。

一定の時間が経過しても自動的に無効にならないセッションを悪用して、ユーザーを攻撃することができます。クロスサイトリクエストフォージェリ攻撃が成功するかどうかは、ユーザーがサイトを離れた後も有効なセッションがあるかどうかにかかっています。例えば、ユーザーが訪れたサイトに、攻撃者がiframeや画像を設置したとします。src」(ソース)属性には、脆弱なサイトのURLが設定され、ユーザーに代わってアクションを実行します。例えば、脆弱な銀行アプリケーションを利用して、ユーザーの許可なく攻撃者の口座に送金させることができます。

セッション管理は厄介なもので、弱点があると壊滅的な被害を受けます。しかし、これはよく知られた問題であり、解決することができます。

不安定なセッション管理の解消

セッション管理は、あらゆるウェブアプリケーションの中核をなすものです。そのため、多くのウェブ開発フレームワークには、セッション管理機能が組み込まれています。これらのシステムは、専門家によって精査され、問題点が発見され、排除されています。使ってみてください。

優れたセッション管理には、以下のような共通点があります。

     攻撃者が推測できないランダムなセッションIDの生成

     ユーザーがログアウトするとセッションが無効になる

     一定の時間が経過すると自動的にセッションが無効になる

     ユーザーがログインするとセッションIDが変更される

     ブルートフォースアタックを防ぐために128ビット以上のセッションIDを設定

SpringASP.NET CoreRailsDjangoなどのWebフレームワークはこれらの特性を備えており、今回はその高いセキュリティ基準を利用することになります。

結論から言うと独自のセッション管理システムをゼロから作るのはやめましょう。

セッションIDが作成されたら、それを保護する必要があります。セッション・クッキーには、Secure および HttpOnly フラグを "true" に設定します。これにより、JavaScript で値を取得することができなくなります。また、ブラウザは HTTPS 経由でのみクッキーを送信するため、攻撃者が送信中に誰かのセッションを盗むことを防ぎます。

セッションの保護

セキュアなセッション管理の詳細については、無料のラーニングリソースをご覧ください。セッションを保護する方法を学ぶことで、セキュリティ侵害によるユーザーアカウントの乗っ取り、評判の低下、収益の低下を防ぐことができます。セッションを保護して、ユーザーの安全を確保しましょう。

リソースを見る
リソースを見る

著者

Jaap Karan Singh

もっと知りたい?

セキュアコーディングに関する最新の知見をブログでご紹介しています。

当社の豊富なリソースライブラリは、安全なコーディングアップスキルに対する人間的なアプローチを強化することを目的としています。

ブログを見る
もっと知りたい?

開発者主導のセキュリティに関する最新の研究成果を入手する

ホワイトペーパーからウェビナーまで、開発者主導のセキュアコーディングを始めるために役立つリソースが満載のリソースライブラリです。今すぐご覧ください。

リソース・ハブ

Coders Conquer Security:シリーズ「シェア&ラーン」セッション管理の弱点とは?

2019年1月31日発行
Jaap Karan Singh著

あるウェブサイトにアクセスし、ログインします。いつものように、購入したい商品をカートに入れます。ところが、手が滑ってブラウザのタブを閉じてしまったのです。慌ててブラウザにサイトのURLを入力し直し、「Enter」キーを押します。すると、ログインした状態でサイトに戻り、カートの中にはすべての商品が残っていました。ふう。

再認証しなくても、どうやってサイトがあなたのことを知っていたのですか?それは、セッションを使用しているからです。セッションは、Webサイトを利用する際にユーザーエクスペリエンスを向上させる重要な要素です。しかし、セッションの管理を誤ると、攻撃者に悪用されるセキュリティホールが発生します。

ここで、セッション管理とは何か、セッション管理が不十分だとどうなるか、セッションを適切に管理するためにはどうすればよいかを確認しましょう。

セッション管理の弱点を理解する

セッションとは、アプリケーションを使用する一人のユーザーに固有の、サーバーに保存された値のことです。これが必要な理由は2つあります。まず、HTTPはステートレスなプロトコルです。まず、HTTPはステートレスなプロトコルであり、各リクエストは個別であり、前後のリクエストを知ることはできません。セッションは、誰がリクエストを送ったかをサーバーが追跡するのに役立ちます。そうでなければ、ボタンやリンクをクリックするたびにログインする必要があります。

セッションが必要な2つ目の理由は、ユーザーの認証です。セッション識別子を使用して、システム内で特定の権利を持つ特定のユーザーを認識することができます。アプリケーションは、その人が誰なのか、何をすることが許されているのかを知ることができます。

セッションには2つの要素があります。サーバー側のデータストアには、セッション識別子が保存され、ユーザーIDやカート情報などのユーザーに関する情報にマッピングされます。同じセッション識別子は、クッキーでブラウザに送信されます。クッキーは、ブラウザによってユーザーのシステムに保存されます。クライアントは、リクエストごとにクッキーを渡し、このリクエストが同じユーザーからのものであることをサーバーに知らせます。ほとんどのアプリケーションでは、認証前と認証後の両方でユーザーを追跡するためにセッションを使用しています。

適切なセッション管理は、アプリケーションのセキュリティに不可欠です。有効なセッションIDは、ユーザ名/パスワード、あるいは第二因子認証トークンと同じレベルの信頼性を持っています。

セッション管理の不備が危険な理由

セッション管理が不十分だと、アカウントが完全に乗っ取られる可能性があります。つまり、顧客データが盗まれたり、商品が不正に購入されたりする可能性があるのです。攻撃者が有効なセッションIDを取得する方法はいくつかあります。

セッション固定化攻撃は、ユーザーがシステムにログインしたときなどの重要なタイミングでセッションが変更されず、URLを使ってセッション識別子が設定できる場合に発生します。このようにセッション識別子を設定すると、同じ認証ソースを使用する異なるアプリケーション間でユーザーのログイン状態を維持するために使用されることがあります。この場合、攻撃者は Web サイトを閲覧してセッション ID を取得します。次に、攻撃者は、セッション ID を記載した URL を、無防備な被害者に電子メールで送信します。犠牲者はメールに記載されたURLをクリックし、ウェブサイトにログインします。ログイン時にセッションIDがローテーションされていない場合、攻撃者は有効で認証されたセッションIDを持つことになります。これにより、アカウントの完全な乗っ取りが可能になります。

貧弱なセッション管理に対するもう一つの攻撃は、ブルートフォースによる推測攻撃です。開発者が独自のセッション管理システムを作成しようとすると、多くの場合、簡単に推測できるようなセッションIDを使用します。セッションIDは、(1、2、3)のように連続していたり、ある種の予測可能なパターンであったりします。攻撃者は、有効なセッションIDが見つかるまで、単純にセッションIDを推測し続けます。これは、アカウントの乗っ取りにもつながります。

一定の時間が経過しても自動的に無効にならないセッションを悪用して、ユーザーを攻撃することができます。クロスサイトリクエストフォージェリ攻撃が成功するかどうかは、ユーザーがサイトを離れた後も有効なセッションがあるかどうかにかかっています。例えば、ユーザーが訪れたサイトに、攻撃者がiframeや画像を設置したとします。src」(ソース)属性には、脆弱なサイトのURLが設定され、ユーザーに代わってアクションを実行します。例えば、脆弱な銀行アプリケーションを利用して、ユーザーの許可なく攻撃者の口座に送金させることができます。

セッション管理は厄介なもので、弱点があると壊滅的な被害を受けます。しかし、これはよく知られた問題であり、解決することができます。

不安定なセッション管理の解消

セッション管理は、あらゆるウェブアプリケーションの中核をなすものです。そのため、多くのウェブ開発フレームワークには、セッション管理機能が組み込まれています。これらのシステムは、専門家によって精査され、問題点が発見され、排除されています。使ってみてください。

優れたセッション管理には、以下のような共通点があります。

     攻撃者が推測できないランダムなセッションIDの生成

     ユーザーがログアウトするとセッションが無効になる

     一定の時間が経過すると自動的にセッションが無効になる

     ユーザーがログインするとセッションIDが変更される

     ブルートフォースアタックを防ぐために128ビット以上のセッションIDを設定

SpringASP.NET CoreRailsDjangoなどのWebフレームワークはこれらの特性を備えており、今回はその高いセキュリティ基準を利用することになります。

結論から言うと独自のセッション管理システムをゼロから作るのはやめましょう。

セッションIDが作成されたら、それを保護する必要があります。セッション・クッキーには、Secure および HttpOnly フラグを "true" に設定します。これにより、JavaScript で値を取得することができなくなります。また、ブラウザは HTTPS 経由でのみクッキーを送信するため、攻撃者が送信中に誰かのセッションを盗むことを防ぎます。

セッションの保護

セキュアなセッション管理の詳細については、無料のラーニングリソースをご覧ください。セッションを保護する方法を学ぶことで、セキュリティ侵害によるユーザーアカウントの乗っ取り、評判の低下、収益の低下を防ぐことができます。セッションを保護して、ユーザーの安全を確保しましょう。

弊社製品や関連するセキュアコーディングのトピックに関する情報をお送りする許可をお願いします。当社は、お客様の個人情報を細心の注意を払って取り扱い、マーケティング目的で他社に販売することは決してありません。

送信
フォームを送信するには、「Analytics」のCookieを有効にしてください。完了したら、再度無効にしてください。