启动隐身/隐私浏览会话时,不应存在来自其他浏览配置文件的 cookie。例如,如果我在我的主要浏览配置文件上登录到一个站点,然后开始一个新的私人浏览会话,我就没有登录到同一个站点(cookie 没有被转移)。假设这是一个新的私人浏览会话,则根本不应该有任何现有的 cookie 或敏感信息可用。
由于没有敏感数据可以窃取,这是否也具有防止或消除 XSS 攻击的副作用?或者这是一种虚假的安全感?
启动隐身/隐私浏览会话时,不应存在来自其他浏览配置文件的 cookie。例如,如果我在我的主要浏览配置文件上登录到一个站点,然后开始一个新的私人浏览会话,我就没有登录到同一个站点(cookie 没有被转移)。假设这是一个新的私人浏览会话,则根本不应该有任何现有的 cookie 或敏感信息可用。
由于没有敏感数据可以窃取,这是否也具有防止或消除 XSS 攻击的副作用?或者这是一种虚假的安全感?
XSS 攻击主要不是关于 cookie。这也不是关于窃取敏感数据。相反,它是关于在您访问的站点的上下文中在客户端执行攻击者控制的代码。这段代码可以造成什么样的伤害取决于实际的站点和上下文。
使用私人浏览会话本身不会阻止 XSS,但它可能会限制 XSS 可能造成的危害的影响——即它无法访问来自非私人浏览器会话的 cookie 或其他存储数据。虽然它可能仍然会造成伤害,但这又取决于您访问的特定上下文和站点。
主要有两种 XSS 攻击:持久性和临时性。
私人浏览会话将保护您免受临时 XSS 攻击,但不会受到持续攻击。
持久性 XSS 的工作原理是攻击者将脚本代码注入敏感页面的某处,这可以通过在平台上向您发送准备好的消息来完成,或者通过将数据注入敏感页面的存储的其他方式来完成。当您登录敏感页面查看某些数据时,注入的数据将由服务器加载并传输到您的浏览器,如果该站点存在漏洞,则会执行该数据。一个例子是在线银行交易中准备好的消息。攻击者会向您发送真实交易,并且消息部分将包含有害脚本。不涉及其他页面,因此您无法保护自己免受此影响,只有页面所有者可以。
临时 XSS 可以通过让您单击包含注入数据的准备好的链接来工作。这样的链接可能看起来像https://banking.securebank.com/searchTransaction?query=<script>doEvil(...)</script>
注入的脚本是链接的一部分。攻击者会试图让你点击这个链接,或者会尝试在他自己准备的页面中通过 JavaScript 在后台执行它。因此,如果您在单独的会话中打开电子邮件链接和不受信任的页面,您在敏感页面上的用户帐户将不会受到这种攻击,因为您没有在隐身会话中登录敏感页面。因此,虽然 XSS 可能仍会执行,但它不会对您自己在敏感页面上的帐户造成任何损害,而这正是我们想要保护的。
正如 Steffen 已经提到的,XSS(跨站点脚本攻击)在定义上不仅仅适用于 cookie。如果有人可以访问数据库并编辑某些字段,这些字段包含可以在某些网页上执行的脚本标签,他就可以执行 XSS 攻击。
这只是意味着有人在您正在访问的页面上的浏览器中运行脚本以从您那里检索信息(可能是 cookie)或通过调整 DOM 来欺骗您,例如将支付按钮链接到他的错误网站。