章节大纲

  • 大多数浏览器现在都实现了一种称为"同源 cookie"的机制，这是与 cookie 相关的一个属性。当发送请求时，浏览器会检查这个属性，并决定是否在跨站请求中附加此 cookie。如果一个 Web 应用程序不希望某个 cookie 用于跨站请求，他们可以标记该 cookie 为同源。例如应用程序可以把 session ID cookie 设为同源 cookie，从而阻止任何跨站请求使用 session ID，因此无法发动 CSRF 攻击。

    为了帮助学生了解如何利用同源 cookie 来防御 CSRF 攻击，我们在一个容器中创建了一个名为  www.example32.com 的网站。请访问以下 URL。我们已将主机名映射到 10.9.0.5。
    URL: http://www.example32.com/
    一旦你访问过这个网站，你的浏览器将设置三个 cookie： cookie-normal,  cookie-lax 和 cookie-strict。如名称所示，第一个 cookie 是一个普通的 cookie；第二个和第三个是两种类型的同源 cookie（Lax 类型和 Strict 类型）。我们设计了两组实验来测试哪些 cookie 会被发送给服务器。

    请点击网页中的链接。链接 A 指向 example32.com 的页面，而链接 B 则指向 attacker32.com 的页面。这两个页面内容是相同的（除了背景颜色），它们分别发送了三种不同类型的请求到 www.example32.com/showcookies.php，该页面仅仅显示浏览器发送的 cookie。通过查看显示结果，可以知道哪些 cookie 被发送。请完成以下任务：
     
    •   请描述你看到的内容并解释在某些场景下为何有些 cookie 不会被发送。
    •   根据你的理解，请描述同源 cookie 如何帮助服务器检测请求是跨站还是同源的。
    •  请描述如何使用同源 cookie 机制来帮助 Elgg 防御 CSRF 攻击。你只需描述一些基本想法，无需实现它们。
    额外加分：尽管这不是强制要求的，我们鼓励学生修改 Elgg 应用程序以利用同源 cookie 机制来防御 CSRF 攻击。建议讲师给予那些成功完成此任务的学生额外加分。学生应该与他们的导师讨论额外得分事宜。