mur*_*a52 12 security authentication cookies authorization csrf
以下引用来自http://www.codinghorror.com/blog/2008/10/preventing-csrf-and-xsrf-attacks.html
当用户访问站点时,站点应生成(加密强)伪随机值并将其设置为用户计算机上的cookie.该网站应要求每个表单提交包括此伪随机值作为表单值以及cookie值.当POST请求发送到站点时,只有表单值和cookie值相同时才应认为该请求有效.当攻击者代表用户提交表单时,他只能修改表单的值.根据同源策略,攻击者无法读取从服务器发送的任何数据或修改cookie值.这意味着虽然攻击者可以使用表单发送他想要的任何值,但他将无法修改或读取存储在cookie中的值.由于cookie值和表单值必须相同,因此攻击者将无法成功提交表单,除非他能够猜测伪随机值.
上述方法通过比较cookie和表单中的伪随机值来防止CSRF攻击.但是,为什么还需要使用表单返回值？我假设表单和cookie具有相同的加密值,它们将返回到服务器.并且服务器通过解密该值来验证它.
因此,即使该值仅由cookie返回,服务器也可以对其进行解密并验证请求.使用表单返回加密值的目的是什么？
qre*_*0ct 47
好吧,让我们将问题分解为原子问题以便更好地理解:
什么是CSRF？
这是一种Web应用程序漏洞.在最基本的层面上,CSRF的原因是浏览器不理解如何区分用户是否故意执行某个操作(例如,通过单击表单上的按钮,或单击超链接等)或者用户在不知情的情况下执行了操作(比如用户从某个域访问过某个页面,比如说bad.com,而bad.com在用户登录good.com时向good.com/some_action发送了请求).
那么CSRF的影响是什么？
现在让我们用facebook.com取代上面的good.com.我们假设当登录到facebook.com的用户在他的墙上发布评论时,会发送一个HTTP GET请求,其格式为
https://facebook.com/postComment?userId=Abhinav_123&comment= HiIAmAbhinav.
现在让我们假设用户在登录facebook.com时访问bad.com上的页面.现在bad.com属于攻击者,他在bad.com上编码了以下内容:
<img src="https: //facebook.com/postComment?userId=Abhinav_123&comment=I_AM_AN_IDIOT>
现在,只要用户的浏览器在bad.com上加载此页面的内容,请求也会被发送到facebook.com,如下所示:
https://facebook.com/postComment?userId=Abhinav_123&comment=I_AM_AN_IDIOT
因为浏览器尝试呈现img标记.为此,它需要获取src中指定的资源,因此它发送上述HTTP GET请求.基本上,攻击者实际上可以代表用户向facebook.com提交请求,而他实际上并不知道这一点.
现在有什么可能阻止这种攻击？
如果只有某种方式来识别用户是否故意提出请求.所以要做到这一点,反CSRF令牌就出现了.它只是服务器生成的随机唯一字符串(在上面的示例中为facebook.com),并发送给用户并在用户的浏览器中设置为cookie.现在,对于涉及一些敏感操作的每个请求(比如在上面的我们的facebook示例中发布评论),浏览器将在执行操作之前发送此随机字符串以及请求和服务器将验证随机字符串是否是它具有的那个是否发送到浏览器.
这个想法是攻击者不知道这个随机字符串.因此,即使攻击者创建了如上所示的img src,并且用户访问bad.com,也不会执行(在上面的示例中发布评论)的操作,因为要执行的操作,除了URL之外,还需要一个额外的东西,即攻击者没有的随机字符串.
但是再次在cookie中设置这个随机字符串有一个巨大的缺陷
由于cookie的设计方式以及浏览器处理cookie的方式,在cookie中设置此随机字符串(反CSRF令牌)将无法满足我们的目的.根据设计,cookie会随着客户端向该服务器发出的每个请求自动发送到服务器(简单地说,为了简单起见,省略了详细信息.有关详细信息,请参阅:RFC2965)
因此,在上面的示例中,攻击者并不需要知道随机字符串.发布评论操作仍将完成,因为一旦用户访问bad.com并加载帖子评论URL(如上所述),随机反CSRF令牌(存在于cookie中)将自动伴随请求.
那么解决方案是什么呢？
服务器(facebook.com)需要将其作为隐藏参数放在表单中,并在用户请求发布此表单的注释(持有反CSRF令牌)时,而不是将反CSRF令牌放入cookie中.也应该张贴.
现在,攻击者无法代表用户执行此敏感操作(除非他以某种方式找到随机的反CSRF令牌本身)
现在出现登录CSRF和双提交cookie的问题
很多时候,网站会通过部署某种形式的anti_CSRF令牌架构来保护自己免受CSRF攻击.但很多时候网站并不关心保护他们的登录表格免受CSRF攻击.为什么？ - 因为即使登录表单容易受到CSRF攻击,并且攻击者试图通过他的域(bad.com)向good.com(facebook.com)发送登录请求来利用它,用户仍然需要输入他的有效凭证登录到facebook.com.这些凭据仅适用于真实用户而非攻击者,因此攻击者无法构建成功的登录请求.
那么这里攻击者的攻击机会是什么？
攻击者可以使用facebook.com创建自己的帐户.他现在拥有一套有效的证件.现在,他使用登录凭据和他的域(bad.com)将登录请求构建到facebook.com.现在,当用户访问bad.com页面时,用户将登录到我的帐户.我作为攻击者可以稍后看到用户在该帐户上执行的所有活动也可能泄露敏感信息(例如,如果用户选择发送新朋友请求,则发送朋友请求,发送给某人的消息,如果用户这样做登录到我的帐户后.所有这些可能性取决于用户是否确信他已登录到自己的帐户,攻击者可以通过使他自己的Facebook页面看起来尽可能接近受害者来处理他相信这是他的帐户)
那么现在针对此的缓解技术是什么？
这是我们现在需要的双提交cookie.
这到底是什么意思
双重提交cookie定义为在cookie和请求参数中发送随机值,服务器验证cookie值和请求值是否相等.
它如何帮助减轻攻击？
根据双cookie的实现原理,当匿名用户(未登录用户)访问登录页面时,服务器在用户的浏览器中设置一个带有一些随机字符串的cookie,并在请求参数中设置相同的字符串(比如说)表格隐藏字段).当用户提交登录请求时,这些内容会随请求一起提交 - 用户凭据,隐藏表单字段中的随机字符串以及保存随机字符串的cookie(当然会自动发送).
现在,攻击者可以访问自己的凭据,服务器在cookie中设置的随机字符串以及攻击者的隐藏表单字段.当攻击者将此精心设计的登录请求发送给用户(受害者),并且用户尝试发出此请求时,该用户仍未登录,并且到目前为止该服务器的匿名用户.因此,服务器将使用不同的(来自攻击者的)随机值在用户的浏览器上设置cookie.现在,当用户通过攻击者制作的链接发出登录请求时,请求将包含攻击者的凭据,攻击者在隐藏表单字段中的随机字符串,但用户在cookie中的随机字符串(来自用户的浏览器).现在,当此请求到达服务器时,cookie中的随机字符串和隐藏的表单字段将不匹配,因此将被标记为异常并进行相应处理.
所以这也是带有表单的加密值返回的原因.希望它能清除这个概念.
无论请求是由原始网站还是第三方网站发起,Cookie都会随每个请求自动发送.这就是为什么单独的cookie不足以满足每个请求都包含它的原因.
但是,通过在请求本身中也使用令牌,攻击站点不能再生成有效请求,因为它们无法保留用户的令牌.