Please note, this is a STATIC archive of website developer.mozilla.org from 03 Nov 2016, cach3.com does not collect or store any user information, there is no "phishing" involved.

Revision 913823 of 安全でないパスワード

  • リビジョンの URL スラグ: Web/Security/Insecure_passwords
  • リビジョンのタイトル: 安全でないパスワード
  • リビジョンの ID: 913823
  • 作成日:
  • 作成者: hashedhyphen
  • 現行リビジョン? いいえ
  • コメント Initial translation into Japanese

このリビジョンの内容

HTTPS プロトコルは、ネットワーク上での盗聴(機密性)や改ざん(完全性)といった脅威から、ユーザのデータを保護できるように設計されています。 ユーザのデータを扱う Web サイトは、ユーザを攻撃者から守るために HTTPS を使うべきです。HTTPS を使わなければ、ユーザの情報(ログインの資格情報など)が盗まれるのは当たり前になってしまいます。このことを Firesheep が証明したのは有名です。

安全でないログインフォームを提供することは、幅広い攻撃手段を与えることになるため特に危険です。ネットワークを盗聴している者は、スニッフィングでユーザの機密情報を直接盗んだり、攻撃の幅を広げるために受信中のページを書き換えたりします。

Firefox の Web コンソール にあるセキュリティタブは、ログインフォームのようにパスワード入力を求めるページがある場合、それが安全でない通信路で提供されていると開発者に警告を出します。Web の開発者がユーザのログイン処理を保護できないシナリオには、以下のようなものが考えられます。

Web サイトがユーザ名とパスワードの入力を求めることはしばしばありますが、そのとても機微なデータを実際に格納しているわけではありません。とあるニュースサイトを例に考えると、ユーザが読み返したい記事を保存するかもしれませんが、ユーザに関するあらゆるデータは保存しないかもしれません。そのニュースサイトの Web 開発者は、サイトとユーザの機密情報を保護しようとはほとんど考えていないかもしれません。残念ながら、パスワードの使い回しは大きな問題となっており、ユーザは複数のサイト(ニュースサイト、SNS、メール、銀行)で同じパスワードを使います。つまり、自分たちのサイトが管理するユーザ名とパスワードに何者かがアクセスしたところで、自分たちに大きなリスクがあると思えなくとも、銀行の Web サイトでも同じパスワードでログインしているユーザにとっては非常に大きなリスクなのです。攻撃者はより賢くなっており、一つのサイトでユーザ名とパスワードの組を盗んだ後には、より金目のあるサイトに同じ組でログインできないか試しているのです。

  1. ログインフォームが HTTP で提供されている場合を考えます。たとえ、form の action 属性が HTTPS の URL であったとしても、ユーザのログインフォームは保護されません。なぜなら、これからユーザが受信するページを攻撃者が書き換えるのは可能だからです(例えば、ユーザの入力を記録するスクリプトを挿入できたり、機微なデータの送信先を攻撃者の管理するサーバに変更できたりします)。下のスクリーンショットは、この問題に対する警告が Web コンソールのセキュリティタブに表示されているようすです。
    Login fields on an insecure page
  2. form の action 属性が HTTP の URL である場合を考えます。 この場合、ユーザが入力したあらゆるデータはネットワーク上を平文で流れます。ユーザが入力したそのパスワードは、ユーザのコンピュータを離れてあなたの Web サーバに届くまでの間、ネットワークをスニッフィングしている全員がはっきりと読み取ることができます。次のスクリーンショットは、この問題を抱えている form の HTML ソースについて警告のメッセージが表示されているようすです。
    Login fields on a form with an https:// action
  3. ログインフォームが HTTP の {{HTMLElement("iframe")}} (または、HTTP のフレーム内に埋め込まれた HTTPS の {{HTMLElement("iframe")}})で提供されている場合を考えます。たとえ最上層のページが HTTPS であったとしても、HTTP の {{HTMLElement("iframe")}} にパスワードの入力欄を含めてしまえば、HTTP のページに入力欄があるのと同じになってしまいます。攻撃者はページを書き換え、ユーザの機密情報を盗むことが可能です。
    Login fields on an https:// iframe

このリビジョンのソースコード

<p><a href="https://en.wikipedia.org/wiki/HTTP_Secure" title="https://en.wikipedia.org/wiki/HTTP_Secure">HTTPS</a> プロトコルは、ネットワーク上での盗聴(機密性)や改ざん(完全性)といった脅威から、ユーザのデータを保護できるように設計されています。 ユーザのデータを扱う Web サイトは、ユーザを攻撃者から守るために HTTPS を使うべきです。HTTPS を使わなければ、ユーザの情報(ログインの資格情報など)が盗まれるのは当たり前になってしまいます。このことを <a href="https://codebutler.com/firesheep/" title="https://codebutler.com/firesheep/">Firesheep </a>が証明したのは有名です。</p>

<p>安全でないログインフォームを提供することは、幅広い攻撃手段を与えることになるため特に危険です。ネットワークを盗聴している者は、スニッフィングでユーザの機密情報を直接盗んだり、攻撃の幅を広げるために受信中のページを書き換えたりします。</p>

<p>Firefox の Web コンソール にあるセキュリティタブは、ログインフォームのようにパスワード入力を求めるページがある場合、それが安全でない通信路で提供されていると開発者に警告を出します。Web の開発者がユーザのログイン処理を保護できないシナリオには、以下のようなものが考えられます。</p>

<p>Web サイトがユーザ名とパスワードの入力を求めることはしばしばありますが、そのとても機微なデータを実際に格納しているわけではありません。とあるニュースサイトを例に考えると、ユーザが読み返したい記事を保存するかもしれませんが、ユーザに関するあらゆるデータは保存しないかもしれません。そのニュースサイトの Web 開発者は、サイトとユーザの機密情報を保護しようとはほとんど考えていないかもしれません。残念ながら、<a href="https://www.lightbluetouchpaper.org/2011/02/09/measuring-password-re-use-empirically/">パスワードの使い回し</a>は大きな問題となっており、ユーザは複数のサイト(ニュースサイト、SNS、メール、銀行)で同じパスワードを使います。つまり、自分たちのサイトが管理するユーザ名とパスワードに何者かがアクセスしたところで、自分たちに大きなリスクがあると思えなくとも、銀行の Web サイトでも同じパスワードでログインしているユーザにとっては非常に大きなリスクなのです。攻撃者はより賢くなっており、一つのサイトでユーザ名とパスワードの組を盗んだ後には、より金目のあるサイトに同じ組でログインできないか試しているのです。</p>

<ol>
 <li>ログインフォームが HTTP で提供されている場合を考えます。たとえ、form の action 属性が HTTPS の URL であったとしても、ユーザのログインフォームは保護されません。なぜなら、これからユーザが受信するページを攻撃者が書き換えるのは可能だからです(例えば、ユーザの入力を記録するスクリプトを挿入できたり、機微なデータの送信先を攻撃者の管理するサーバに変更できたりします)。下のスクリーンショットは、この問題に対する警告が Web コンソールのセキュリティタブに表示されているようすです。<br />
  <img alt="Login fields on an insecure page" src="https://mdn.mozillademos.org/files/5951/insecure_page2_with_arrows_cropped.jpeg" style="height:386px; width:800px" /></li>
 <li>form の action 属性が HTTP の URL である場合を考えます。 この場合、ユーザが入力したあらゆるデータはネットワーク上を平文で流れます。ユーザが入力したそのパスワードは、ユーザのコンピュータを離れてあなたの Web サーバに届くまでの間、ネットワークをスニッフィングしている全員がはっきりと読み取ることができます。次のスクリーンショットは、この問題を抱えている form の HTML ソースについて警告のメッセージが表示されているようすです。<br />
  <img alt="Login fields on a form with an https:// action" src="https://mdn.mozillademos.org/files/5947/insecure_form_action2_with_arrows_cropped.jpeg" style="height:468px; width:800px" /></li>
 <li>ログインフォームが HTTP の {{HTMLElement("iframe")}} (または、HTTP のフレーム内に埋め込まれた HTTPS の {{HTMLElement("iframe")}})で提供されている場合を考えます。たとえ最上層のページが HTTPS であったとしても、HTTP の {{HTMLElement("iframe")}} にパスワードの入力欄を含めてしまえば、HTTP のページに入力欄があるのと同じになってしまいます。攻撃者はページを書き換え、ユーザの機密情報を盗むことが可能です。<br />
  <img alt="Login fields on an https:// iframe" src="https://mdn.mozillademos.org/files/5953/insecure_iframe3_with_arrows_cropped.jpeg" style="height:710px; width:800px" /></li>
</ol>
このリビジョンへ戻す