应用程序具有多因素登录。用户登录其电子邮件和密码,然后以下屏幕询问一个通过电子邮件接收或由移动应用程序生成的一次性密码。
在第二个屏幕中,还有一个名为"cancel登录“的链接,指向例如/login/cancel
。用户可以单击此按钮取消登录进程,进程的会话/cookie将被清除,您将不得不重新开始。
我的问题是关于这种“行动”的链接。单击它实际上会发送一个GET
请求,但不仅仅是为了显示页面或检索数据,而是为了在应用程序中执行一个操作。在实践中,另一个网站可能包含一个链接,甚至一个图片,指向我们的应用程序的“登录取消网址”,并注销未知的用户。简单地说,是CSRF的攻击。
我使用Laravel框架,并对html表单使用内置的CSRF保护。但是,我想知道如何正确地实现GET
请求的这种保护。将查询参数添加到操作链接的url,然后手动验证包含的CSRF令牌是否就足够了?另外,我想知道在web应用程序中使用链接来执行操作是否可以接受。它工作得很好,但是GET
请求在语义上不是用来“说/执行”的。另一种选择是,我不使用链接,而是使用一个小表单,它包含一个隐藏的CSRF令牌字段和一个提交按钮,该按钮充当(并被设计为)链接。然后使用POST
请求发送表单。什么是最佳实践,是否有任何安全指南?
发布于 2023-05-30 13:19:47
你几乎回答了你自己的问题,只需使用带有CSRF保护的表单。GET url更容易被恶意方滥用(通过链接和图像等)。但是CSRF的保护也同样有效,我相信Laravel会支持这一点。
或者,您可以对链接进行签名,并拒绝对url的任何没有有效签名的请求。
发布于 2023-05-31 18:56:28
通过正确使用cookie和查询字符串参数,您可以模拟许多CSRF缓解策略使用的内容。在深入研究cookies的安全之前,这就是这个过程所需要的:
400 Bad Request
响应。只有在正确设置cookie的情况下,才能防止CSRF攻击。当第一次设置cookie时,服务器应该响应如下内容:
HTTP/1.1 200 OK
...
Set-Cookie: CSRF=abc123; expires=date; Domain=example.com; Path=XXX; HttpOnly; Secure; SameSite
...
<DOCTYPE HTML>
<html>
注销的URL将类似于https://example.com/logout?CSRF=abc123
。
单击此链接将发送类似于以下内容的HTTP请求:
GET /logout?CSRF=abc123 http/1.1
...
Cookie: CSRF=abc123
...
由于cookie标记为HttpOnly,JavaScript无法访问cookie,因此恶意脚本无法读取cookie并将其发送到某个地方供以后使用。cookie上的SameSite属性意味着浏览器将根本不会发送cookie,除非页面是从相同的来源(协议+主机+端口)加载的-参见同一原产地政策。这防止了作为脚本标签嵌入到某个黑客网站上的驱动程序请求。想象一下其他一些网站在其源代码中嵌入了这样的内容:
<script src="https://example.com/logout?CSRF=abc123"></script>
浏览器会很高兴地提出这个请求,但是即使攻击者猜到了CSRF令牌,也不会发送CSRF cookie。由于没有发送cookie,您的服务器将使用400 Bad Request
进行响应。
https://softwareengineering.stackexchange.com/questions/445796
复制