CSRF(跨站请求伪造)攻击
CSRF(Cross Site Request Forgery,跨站请求伪造)是一种近年来才逐渐被大众了解的网络攻击方式,又被称为One-Click Attack或Session Riding。
攻击原理
CSRF攻击的大致方式如下:某用户登录了A网站,认证信息保存在cookie中。当用户访问攻击者创建的B网站时,攻击者通过在B网站发送一个伪造的请求提交到A网站服务器上,让A网站服务器误以为请求来自于自己的网站,于是执行响应的操作,该用户的信息边遭到了篡改。总结起来就是,攻击者利用用户在浏览器中保存的认证信息,向对应的站点发送伪造请求。用户的认证是通过保存在cookie中的数据实现,在发送请求是,只要浏览器中保存了对应的cookie,服务器端就会认为用户已经处于登录状态,而攻击者正是利用了这一机制。
攻击示例
假设我们网站是一个社交网站(example.com),简称网站A,攻击者的网站可以是任意类型的网站,在我们的网站中,删除账户的操作通过GET请求执行,使用下面的视图处理:
@app.route(‘/account/delete‘) def delete_account(): if not current_user.authenticated: abort(401) else: current_user.delete() return ‘Deleted‘
当用户登录后,只要访问http://example.com/account/delete就会删除账户。那么在攻击者的网站上,只要创建一个显示图片的img标签,其中的src属性加入删除账户的URL:
<img src=”http://example.com/account/delete”>
当用户访问B网站时,浏览器在解析网页时会自动向img标签的src属性中的地址发送请求。此时你在A网站的登录信息保存在cookie中,因此,仅仅是访问B网站的页面就会让你的账户被删除掉。
当然,现实中很少有网站会使用GET请求来执行包含数据更改的敏感操作,这里只是一个示例。
现在,假设我们吸取了教训,改用POST请求提交删除账户的请求。尽管如此,攻击者只需要在B网站中内嵌一个隐藏表单,然后设置在页面加载后执行提交表单的javaScript函数,攻击仍然会在用户访问B网站时发起。
防范措施
正确使用HTTP方法
防范CSRF的基础就是正确使用HTTP方法。在普通的Web程序中,一般只会用到GET和POST方法。而且目前在HTML中仅支持GET和POST方法(借助AJAX则可以使用其他方法)。在使用HTTP方法时,通常应该遵循下面 的原则:
1、 GET方法输入安全方法,不会改变资源状态,仅用于获取资源。页面中所有可以通过链接发起的请求都属于GET请求。
2、 POST方法用户创建、修改和删除资源。在HTML中使用form标签创建表单并设置提交方法为POST,在提交时会创建POST请求。
在GET请求中,查询参数用来传入过滤返回的资源,但是在某些情况下,也可以通过查询参数传递少量非敏感信息。
在删除资源时,应该将删除按钮内嵌在使用了POST方法的form元素中
CSRF令牌校验
当处理非GET请求时,要想避免CSRF攻击,关键在判断请求是否来自自己的网站。理论上讲,通过HTTP referrer可以判断原站点从而避免CSRF攻击,但是referer很容易被修改和伪造,所以不能作为主要的防御措施。
除了在表单中加入校验码外,一般的做法是通过在客户端页面中加入伪随机数来防御CSRF攻击,这个伪随机数通过被称为CSRF令牌(token)。
在计算机语境中,令牌(token)指用于标记、验证和传递信息的字符,通常是通过一定算法生成的随机数。
在HTML中,POST方法的请求通过表单创建。我们把在服务器端创建的伪随机数(CSRF令牌)添加到表单中的隐藏字段里和session变量(即签名cookie)中,当用户提交表单时,这个令牌会和表单数据一起提交。在服务器端处理POST请求时,会对表单中的令牌值进行验证,如果表单中的令牌值和seesion中的令牌值相同,就说明请求来自自己的网站。因为CSRF令牌在用户向包含表单的页面发起GET请求时创建,并且在一定时间内过期,一般情况下攻击者无法获取到这个令牌值,所以我们可以有效地区分出请求的来源是否安全。
对于AJAX请求,我们可以在XMLHttpRequest请求首部添加一个自定义字段X-CSRFToken来保存CSRF令牌。
如果程序存在XSS漏洞,那么攻击者可以使用javaScript窃取cookie内容,进而获取CSRF令牌。
原文地址:https://www.cnblogs.com/xiaxiaoxu/p/10428483.html