这不是特定于语言的问题，但我使用的是 PHP5。
我正在从事一个包含一定数量 PII 的项目。从法律上讲，我们需要保护这些数据免受黑客攻击，因此我一直在研究防御常见攻击类型的最佳实践。显然，所有数据库调用都使用参数化查询，并且用户提供的所有数据都经过清理以防止注入。我还实现了会话和方法来防止会话劫持。
在防御表单上的 XSS 攻击时，最佳实践似乎是包含带有表单令牌的隐藏输入，然后在发布后检查令牌匹配。还有其他方法可以使这更安全。
我曾设想过一种攻击类型，但尚未找到解决方案。如果恶意站点加载了指向我站点的隐藏 iframe（例如，view-member.php?id=1234）并且由于受害者用户登录到我的站点，他们的会话会在该 iframe 中继续。是什么阻止了这个恶意网站遍历 ID 并撕毁数据以获取 PII？我是否应该为每个页面视图创建一个唯一令牌，并在页面加载时检查该令牌？
我不是 100% 确定，但假设我的网站使用 HTTPS，浏览器应该警告用户和/或阻止连接。那是对的吗？这足够安全吗？
【问题讨论】：
事实上，每次您展示表单或任何类型的交互时，您都应该包含一个随机的、可验证的信息，该信息每次都会发生变化。这不是为了防止 XSS 而是 CSRF：https://en.wikipedia.org/wiki/Cross-site_request_forgery
主要问题是：攻击者只需向您的输入处理脚本发送自动请求，而无需经历手动填写表单（甚至访问您的页面）的“痛苦”。
但是，您不会使用此技术阻止 XSS 攻击，因为 XSS 攻击主要是用户输入，其中包含未通过输入验证过滤的可执行代码 (javascript)。因此，为了防止 XSS，您应该始终确保不要在任何地方提供未经过滤的用户生成内容。
HTTPS 在这两种情况下都无济于事，除非您使用客户端证书，该证书只允许从受信任的客户端访问您的网站。 HTTPS 主要充当传输加扰器和身份验证器，但不会阻止机器人向您的表单发送有效（但恶意）数据。
只要您遵循同源策略，在 iFrame 中托管网站并不会授予攻击者从目标页面读取 cookie 或信息的权限（这会很糟糕）：https://en.wikipedia.org/wiki/Same-origin_policy
这样，只有您列入白名单的域才能访问您页面上托管的信息。
【讨论】：