安全でないパスワード

  1. 攻撃
    1. Clickjacking
    2. Cross-site leaks (XS-Leaks)
    3. Cross-site request forgery (CSRF)
    4. Cross-site scripting (XSS)
    5. Manipulator in the Middle (MITM)
  2. 証明書の透明性
  3. ユーザーによる有効化によって制御される機能
  4. Firefox security guidelines
  5. 無信頼の iframe Experimental
  6. 安全でないパスワード
  7. 混在コンテンツ
  8. 実践的なセキュリティ実装ガイド
    1. Content Security Policy (CSP)
    2. Cross-Origin Resource Policy (CORP)
    3. Cross-Origin Resource Sharing (CORS)
    4. フォームの自動補完を無効にするには
    5. MIME type verification
    6. Referrer policy
    7. robots.txt configuration
    8. Secure cookie configuration
    9. Subresource integrity (SRI)
    10. Transport Layer Security (TLS)
  9. Referer ヘッダーのプライバシーとセキュリティの考慮事項
  10. 同一オリジンポリシー
  11. 保護されたコンテキスト
    1. 保護されたコンテキストに制限されている機能
  12. サブドメインテイクオーバー
  13. サブリソース完全性
  14. トランスポート層セキュリティ
  15. 脆弱な署名アルゴリズム

HTTP を通じてログインフォームを提供することは、ユーザーのパスワードを暴くための広範にわたる攻撃に対して特に危険です。ネットワークの盗聴者は、ネットワークを覗き見たり、転送によって提供されたページを変更したりしてユーザーのパスワードを盗むことができます。

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

この問題を修正するためには、 TLS 証明書をサーバーにインストールし構成してください。様々なベンダーが無料または有料の証明書を提供しています。クラウドプラットフォームを使用しているのであれば、 HTTPS を有効にする方法を独自に持っているかもしれません。

パスワードの使い回しに関するメモ

ウェブサイトがユーザー名とパスワードを求めても、実際には微妙なデータを保存しないことがあります。例えば、あるニュースサイトがユーザーが読み返したい記事を保存しても、ユーザーに関する他のデータを保存しない場合などです。ニュースサイトのウェブ開発者は、サイトやユーザーの資格情報を安全にする必要があるとはあまり考えないかもしれません。

残念ながら、パスワードの使い回しは大きな問題です。ユーザーは複数のサイト (ニュースサイト、SNS、メールサービス、銀行) で同じパスワードを使用します。つまり、サイトが管理するユーザー名とパスワードに何者かがアクセスしたところで、自分たちに大きなリスクがあると思えなくとも、銀行のウェブサイトでも同じパスワードでログインしているユーザーにとっては非常に大きなリスクなのです。攻撃者はより賢くなっており、一つのサイトでユーザー名とパスワードの組を盗んだ後には、より金目のあるサイトに同じ組でログインできないか試しているのです。

関連情報