ログインページはキャッシュ可能にする必要がありますか？
ログインページをキャッシュ可能にすることの相対的なメリット/デメリットを検討しています。ここでは、ユーザーがユーザー名とパスワードを入力するフォームを含むページを参照していることに注意してください。
確かに、SSLストリッピングに対する保護は何も追加されていません（HTTPページは、キャッシュの目的でHTTPS時代とは別のエンティティとして扱われます）。
フォームを不正な証明書による変更から保護し、SSLの将来の問題から潜在的に保護することで、データを入力するためのフォームの整合性を強化することしかできませんが、セキュリティ侵害された接続を介して送信する必要があります。これは、ローカルキャッシュからページをロードすることのすべての利点を高めますか？
私は このレポート を発見しました。これは、ログインページのキャッシュが脆弱性であると断言します。「Webブラウザーがログイン情報を保存できるようにすることはお勧めしません。脆弱性が存在します」-ただし、ログインページは確かにone形式であり、ブラウザに送信する前に事前入力したくないのですか？ OTOHチャレンジ/レスポンスベースのメカニズムを使用すると、ログインページ内でチャレンジが発行されるときに問題が発生しますが、実際には機能しません。セキュリティを損なうよりも。
ブラウザキャッシュを介して新しい攻撃ベクトルを開きません-これは、ページがキャッシュ不可として提供されたときにすでに存在します（ページが既にキャッシュにある場合、このルートによる攻撃が少し単純になる可能性があります）。
ここで見落としている大きなメリット/デメリットはありますか？
OWASPアプリケーションセキュリティによると、機密情報を含む可能性のあるページは、ライブラリなどの公共の共有コンピュータからアクセスできる場合は、キャッシュしないでください。
https://www.owasp.org/index.php/OWASP_Application_Security_FAQ
ユーザーがログオンした後のページは、それ自体のログインページよりもはるかに機密性が高く、キャッシュなしの候補になります（ログインページがパブリックであるため）。
「見つかったキャッシュ可能なログインページ」レポートでは、2つの概念が混同されていたと思います。 1つの概念は、ページ自体に含まれる機密情報のキャッシュです。もう1つは、ブラウザ構成の一部としてのログイン情報とパスワード情報のキャッシュです。私が知っているように、1つのディレクティブが他のディレクティブに影響を与えることはありません（つまり、ページをキャッシュ不可と見なしても、ユーザーがブラウザープロファイルにパスワードを保存する機能には影響しません）。
ログイン情報を保存しないようブラウザに要求するには、autocomplete = 'off'フォーム属性を使用できます。
https://stackoverflow.com/questions/32369/disable-browser-save-password-functionality
ログインページはログインではありません情報;後者は、十分に注意してキャッシュする必要があります。しかし、ページ自体は秘密ではありません。誰でも入手できます。したがって、そのページに他のすべてのページと同じキャッシュメカニズムを適用しても問題はありません。
余分な保護については、それを当てにしないでください。攻撃者が何らかの方法でSSLを突破できる場合、ユーザーに偽のページをフィードすることができます。これは、HTTPキャッシングのほとんどが機能するためです。クライアントはページを要求しますが、日付からのコピーが既にあると述べています[ 〜＃〜] t [〜＃〜];サーバーは「古いコピーを再利用できます」と応答するか、新しいコピーを送信します。
ログインページ自体のキャッシュが問題になる可能性があるシナリオを考えてみます。
ユーザーにログインフォームが表示され、自分の電子メールとパスワードを使用してサインインするように要求されるアプリケーションの例を取り上げます。電子メールまたはパスワードが1文字でもオフの場合、ログインは失敗します。次に、一部のアプリケーションは、修正と再送信のために、応答の一部としてEメールとパスワードの両方をブラウザーに送り返す場合があります。ログインページ自体はキャッシュ可能であるため、電子メールとパスワードもキャッシュされる可能性があります。
注：私はまだこれをテストしていませんので、これについて共有してください。