我一直在阅读CSRF / XSRF,其中很多似乎都在讨论cookie,因为他们可以参与自动记录用户。
所以我只是想知道您的网站是否不使用cookie,您是否仍然需要担心使用它,或者您是否需要担心在公共可访问表单上使用它?
我假设您仍然这样做,因为用户可能已经在浏览器中登录,然后他们可以接触到它。
至于公共表格,显然你想要保护这些表格的唯一原因是你不希望远程站点发布给他们正确!?
答案 0 :(得分:1)
跨站点请求伪造,CSRF,不是针对cookie实施站点的攻击,它是一种攻击,涉及能够使用户的浏览器访问站点A来调用站点B上的操作 - 通常是他们必须登录才能访问,但没有必要。
例如,假设您在站点B上有一个简单的“联系我们”表单。此表单可公开访问,无需用户登录。如果站点A可以通过javascript(或Flash等)从客户端的浏览器提交此表单 - 那么这将被视为CSRF,因为“联系我们”表单似乎源自从未实际访问过站点B的最终用户
现在,当行动比简单的“联系我们”表格更复杂时,这种攻击就更加危险,例如,“将账户X的资金转账到账户Y”。这些操作通常要求用户登录到站点,该站点通常也使用某种形式的cookie(会话ID作为cookie从浏览器来回发送到服务器)。如果没有CSRF保护(例如令牌),只要用户具有主动打开的会话,就可以执行“转移”操作。但是,如果网站实际上保存了一个cookie以允许“记住我”功能,而用户每次都不需要提交他们的凭证,那么CSRF应该能够在用户没有活动会话的情况下提交。 / p>
答案 1 :(得分:1)
跨站点请求伪造是在客户端维护任何状态并在未经用户批准的情况下提交的问题。
用于身份验证的最常见状态示例确实是HTTP cookie,但其他存在:
HTTP身份验证:基本身份验证,摘要身份验证或集成Windows身份验证; Basic Auth通常用于路由器管理界面,其中许多都容易受到CSRF的攻击。</ p>
HTTPS客户端证书;
使用客户端IP地址,HTTPS会话ID或用户代理等边际问题作为身份验证接受决策的不可靠部分。
如果在提交机构中没有可验证的服务器颁发的令牌使用其中任何一个与所涉及的主体相关联,那么您就会遇到CSRF问题。
如果您没有任何身份验证的概念,只有面向公众的表单,那么您实际上并没有这样的CSRF:用户说服用户B发布公开可用的表单并不算作如果网站无法区分用户A的提交和用户B的提交,则伪造。
然而,没有任何服务器发布的某种形式的令牌的开放公共表单将更容易遭受DDoS攻击:攻击者可以创建一个网站,将访问它的任何人推入其中,而不是自己攻击表单。提交表格。这会放大攻击并使其更难阻挡,因为它来自许多来源。令牌也可用作防御简单形式的垃圾邮件机器人。这些不是CSRF问题,但可以通过相同的防御来减轻它们。