登录页面是否可以缓存？

Question

我正在考虑使登录页面可缓存的相对好处/缺点。请注意，这里我指的是包含用户输入用户名和密码的表单的页面。

当然，它没有添加任何针对SSL剥离的保护(出于缓存目的，HTTP页面被视为与HTTPS时代分离的实体)。

它似乎在保护表单不被流氓证书修改以及可能针对SSL中的未来问题方面增加了一些价值--尽管它只能提高输入数据的表单的完整性--然后必须通过一个受损的连接发送。这会不会影响从本地缓存加载页面的所有好处？

我确实找到了本报告，它断言缓存登录页面是一个漏洞，理由是“不建议允许web浏览器保存任何登录信息，因为当存在漏洞时，该信息可能会受到破坏”--但是，在发送到浏览器之前，登录页面肯定是我们不想预先填充的一种形式？OTOH在使用基于挑战/响应的机制时会出现问题，其中的挑战是在登录页面中发布的--但是这样它就不能工作，而不会损害安全性。

它不会通过浏览器缓存打开一个新的攻击向量--当页面被用作不可缓存时(尽管如果页面已经在缓存中，它可能会使这个根目录下的攻击变得更简单)。

我在这里是否忽略了一个重大的好处/劣势？

Answer 1

根据OWASP应用程序安全性，任何可以具有敏感信息的页面，如果可以被公共共享计算机(如库)访问，就不应该被缓存。

https://www.owasp.org/index.php/OWASP_应用程序_安全性_常见问题

在用户登录后的任何页面都比它自己的登录页面(因为登录页面是公共的)更敏感，更适合不缓存。

我认为，在“可缓存登录页发现”报告中，他们混淆了两个概念。一个概念是缓存页面本身中包含的敏感信息。另一个是缓存登录和密码信息，作为浏览器配置的一部分。据我所知，一个指令不影响另一个指令(也就是说，认为页面不可缓存不会影响用户在浏览器配置文件上存储密码的能力)。

若要要求浏览器不要存储登录信息，可以使用autocomplete='off‘form属性。

https://stackoverflow.com/questions/32369/disable-browser-save-password-functionality

Answer 2

登录页面不是登录信息；后者应该非常谨慎地缓存。但是这页本身并不是秘密，每个人都可以得到它。因此，对该页应用与所有其他页面相同的缓存机制是没有问题的。

至于额外的保护，不要指望它。如果攻击者可以以某种方式突破SSL，那么他就可以向用户提供一个假页面，因为HTTP缓存主要是这样工作的:客户端请求一个页面，但声明它已经拥有一个来自日期T的副本；然后服务器可以响应“您可以重用旧的副本”，或者发送一个新的副本。

Answer 3

考虑一个场景，我认为登录页面本身的缓存可能是一个问题。

以一个应用程序为例，用户将收到登录表单，并被要求使用他的电子邮件和密码登录。如果电子邮件或密码是关闭，甚至由一个字符，然后登录失败。然后，一些应用程序可能会将电子邮件和密码作为响应的一部分发送回浏览器，以便进行更正和重新分配。因为登录页面本身是可缓存的，所以电子邮件和密码也可能被缓存。

注:我还没有测试这一点，所以请觉得分享您的想法在这一点。