更好更安全的互联网
邪恶的Flash小游戏
2008年底，某个月黑风高的夜晚，当时中国第一个微博网站饭否（）正值风光，我对这个网站进行了一次授权安全测试，其中有个漏洞引起了我的思考：如何最大化利用，如何发起一次新颖的攻击。
这个漏洞是CSRF（Cross Site Request Forgery，即跨站请求伪造），这个在当时是普遍不能再普遍，渺小不能再渺小的漏洞。我知道利用这个漏洞可以让用户的权限被劫持，然后自动做些用户无法预知的“坏事”。
由于我比较擅长Flash，当年大学期间做过N个Flash小动画，Flash里的ActionScript脚本也是客户端脚本，同样可以做些坏事（不就是 发出一些伪造的HTTP请求嘛？对于懂编程的人来说，太简单了），于是我就想到利用Flash为载体，来进行一个静悄悄的攻击：
我找了个开源的Flash小游戏（连连看）；
修改了里面的ActionScript代码，植入会发起伪造HTTP请求的代码；
重新生成出这个邪恶的Flash；
发布到自己的网站上；
发了条微博：“终于编写了第一个flash游戏：连连看:)，太不容易了- -...欢迎测试：/enjoy_flash_game.php?hi=yyyy”；
我的好友看到后，点击链接过去玩，他们会不会觉得还挺好玩的？哈哈；
玩的过程中，Flash里的ActionScript代码执行了，发起了跨站伪造的请求，这个请求会带上这些人的Cookies（关键点），那么这个请求对于饭否来说就是合法的了，于是成功完成了一些邪恶操作：他们都发了篇微博，内容一样，还发了私信给自己的好友；
于是传播开了……
月黑风高嘛，还能传播，这说明夜猫子是很多的:)，12:00-&12:30半小时的时间，传播的很猛，人群开始紧张了，有人开始骂了，有人开始分析了，有人开始质疑了……
互联网开始沸腾了，我满足了，撤下了这个邪恶的Flash小游戏，写了个安全评估报告给了饭否，然后写出了第一篇Paper（第二天从北京到了阿里巴巴，参 加他们的第一届精武门安全会议（也是唯一的一届），那时还是刺当主持人呢，圈子各位名声大的黑客也来了），我的第一次演讲就献给了这个Flash CSRF蠕虫，这是一个内部会议，所以没人知道那时发生了什么，很久之后我才公开。
之后CSRF完成了很多经典的攻击，比如直接打后台权限、搞下Gmail、银行网站等。CSRF的防御开始在那些开源Web应用中得到普及，各大互联网（具 备SNS性质的）都开始注意到CSRF带来的恶意攻击，曾经人人网的一个链接就能摧毁一个人的所有日志，一个链接就能搞定一个站长的网站后台，黑客的手上 拥有多大的权限……
爱因斯坦是最大的黑客
IC（知道创宇CEO）经常和我们说爱因斯坦的一句名言：“世界不是因为那些破坏者而变得危险，而是因为看着他们破坏而无动于衷的人而变得危险。”他说：“爱因斯坦才是最大的黑客！”
我们这些年尝试向Web应用厂商与站长去说明CSRF的危害可以如何的大，但，我们发现他们刚开始都无动于衷……这个在预料之内的（想想别人给我们“盛气凌人”的建议时？），基本都是出了安全问题才开始警惕，所以我们认为“通过无危害安全评估，证明出这个漏洞足够大的危害后，他们才会被触动；如果发生了有危害的黑客事件后，他们会立马行动。”
我 们的网站体检中心对导致Flash CSRF漏洞的原因之一（网站根目录下是否有crossdomain.xml且这个xml的allow-access-from是否为通配符，通配符表示 任意域可以跨域获取本域的隐私数据）进行了统计，统计样本是hao123上那些热门的网站：7709个。
发现，18%的网站有这个crossdomain.xml，这其中有61%存在Flash CSRF漏洞。
注意下：前面说了crossdomain.xml配置不安全会导致任意域可以跨域获取本域的隐私数据，注意是读取，如果要跨域发送POST请求，还得看目标表单是否做了Token防御或验证码防御，是否判断了请求来源（比如只有本域内发起的POST请求才合法）。
这个Flash CSRF的防御很简单：
1. crossdomain.xml的安全配置可以参考，指定好信任的域：/crossdomain.xml；
2. 注意：Discuz!安装后网站根目录下的这个文件，默认是不安全的，比如：/crossdomain.xml；
答应开源的一个Flash安全测试小工具在这：/evilcos/xss.swf，怎么使用自己看了:)
----------分割线----------
我们会持续性的进行安全科普，大家有什么问题可以在微信里给我们留言，我们会认真对待每份留言，并在下次发文时进行必要的解答。如果大家有什么安全八卦也欢迎投稿给我们。
科普改变世界，我们一起努力让这个互联网更好更安全吧！
本文由知道创宇安全研究团队-余弦撰写。
本文在我们的官方微信上首发，请用微信关注：网站安全中心。
作者：余弦 | Categories: | Tags: 、、
至今 还没有被重视起来吧。CSRF防御 - 为程序员服务
什么是CSRF攻击
这个网上一大把解释，直接google就可以了。这里就不赘述了。
目前对CSRF的基本都是一种处理方式——使用token校验。简单来说，就是对于每一个需要做CSRF检查的请求（一般是POST请求），服务端会根据一定的策略分配一个token（或者前端js生成。比较少见，因为这样token的算法暴露了。当然如果token需要的输入攻击者拿不到的话，问题不大。），这样当页面提交的时候，服务端判断该请求是不是需要做CSRF检查，如果是，则会拿用户提交的token跟后端保存的token（一般是在session中）或者用同样算法计算出来的token做比较，如果不同，则认为是CSRF攻击。
下面的一些做法，可以在一定程度上提高CSRF攻击的难度：
任何修改操作，不要用GET请求。但是POST请求也是很容易构造的。
服务端对提交页面进行Referer的合法性验证，可以在一定程度上避免这种CSRF攻击。但是Referer是可以伪造。目前已知历史上flash多次出现可伪造referer的漏洞。同时，有些浏览器、防火墙、代理或许会过滤原始请求的referer导致应用异常。不过如果没有referer伪造漏洞，检查referer不失为一种轻量级的防御CSRF攻击的办法。需要特别注意的是应该匹配顶级域名。比如不能简单的正则匹配arganzheng.me，黑客只要将攻击域名设置为api.arganzheng.，就很容易就绕过了。
思路一: 服务端分配csrfToken
token一般存放在session中，这也是很多框架的默认实现。不过分布式环境下应该使用Redis这样的集中式缓存进行token的存放，token的过期时间可以根据业务需要设置。优点是客户端无感知，缺点是服务端有状态。
思路二: 服务端和客户端通过一样的算法和输入计算token值，进行比较
在所有的请求中添加一个g_tk参数，用于判断用户的真伪。g_tk由客户端skey（sessionKey, 存放在cookies中）进行time33加密生成，在服务端对skey进行同样的操作后，判断g_tk的一致性。
1. 前端JS库提供四个基础函数：
addToken: 添加token的函数
getCookies：获取cookie的函数
time33: time33算法函数
getToken: 获取token函数
具体实现如下：
* type标识请求的方式，j132标识jquery，j126标识base，lk标识普通链接,fr标识form表单
function $addToken(url,type){
var token=$getToken();
return token==""?url:url+(url.indexOf("?")!=-1?"&":"?")+"g_tk="+token+"&g_ty="+
function $getToken(){
var skey=$getCookie("skey"),
token=skey==null?"":$time33(skey);
function $getCookie(name){
//读取COOKIE
var reg=new RegExp("(^| )"+name+"=([^;]*)(;|$)"),
val=document.cookie.match(reg);//如果获取不到会提示null
return val?unescape(val[2]):
function $time33(str){
//哈希time33算法
for(var i = 0, len = str.length,hash = 5381; i & ++i){
hash += (hash && 5) + str.charAt(i).charCodeAt();
return hash & 0x7
针对不同的请求，token的提交方式如下：
form表单提交：遍历页面中所有的form表单，并修改form的原始action，在action后自动添加token数据
&script type="text/javascript"&
$(document).ready(function(){
var forms=document.getElementsByTagName("form");
for(var i=0,len=forms.i&i++){
forms[i].action=$addToken(forms[i].action,"fr");
ajax：使用getToken手动追加
超链接提交：使用$addToken对a链接的href进行手动处理。
2. 后台拦截器做校验
package me.arganzheng.study.csrf.
import javax.servlet.http.HttpServletR
import javax.servlet.http.HttpServletR
import mons.lang.StringU
import org.springframework.beans.factory.annotation.A
import org.springframework.web.servlet.handler.HandlerInterceptorA
import me.arganzheng.study.csrf.exception.CsrfTokenInvalidE
* @author arganzheng
public class CsrfTokenCheckerInterceptor extends HandlerInterceptorAdapter {
@Autowired
public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
if (!request.getMethod().equalsIgnoreCase("POST")) {
// Not a POST - allow the request
// 默认所有POST都需要检查（后面可以考虑试用anotation来区别。但是Spring MVC 3.1之前的版本Interceptor中拿不到controller的信息，没法做到method级别的控制。。）
String token = getCsrfToken(user.getSkey());
if (StringUtils.equals(token, request.getParameter("g_tk"))) {
throw new CsrfTokenInvalidException();
public String getCsrfToken(String skey) {
return time33(skey);
public String time33(String skey) {
if (skey == null)
int hash = 5381;
for (int i = 0, len = skey.length(); i & ++i) {
int cc = skey.charAt(i);
hash += (hash && 5) +
hash &= 0x7
return String.valueOf(hash);
由于token是根据skey动态算出来的，成本不大，所以这里不需要保存token，每次都是重新计算好了。
当然，token也可以是服务器在页面渲染之间计算并放入的。这样客户端就没有逻辑了。
由于COOKIE不可跨域，所以第三方网站不可能知道计算出正确的TOKEN值，服务器后台校验TOKEN，即可在SESSION级别在客户端一层防止CSRF。但是，假如黑客拦截了请求，得到sessionKey，那么在用户这次SESSION中，请求是可以被伪造的，上面方式就被破解了。根据业务需要，可以将SESSION级别的CSRF升级为请求级别的CSRF。
skey本身类似于一个sessionId，具有时间性，根据传递性，csrf token也具有时间性。
拦截器这里简单对所有POST进行CSRF校验，其实可以使用 anotation 进行更细粒度的控制，但是Spring MVC 3.1之前的版本Interceptor中拿不到controller的信息，没法做到method级别的控制。
使用anotation可以这么写：
package me.arganzheng.study.csrf.
import java.lang.annotation.ElementT
import java.lang.annotation.R
import java.lang.annotation.RetentionP
import java.lang.annotation.T
@Target(ElementType.METHOD)
@Retention(RetentionPolicy.RUNTIME)
public @interface CheckCsrfToken {
boolean required()
然后在interceptor中这样判断：
HandlerMethod method = (HandlerMethod)
if(method.getMethodAnnoation(CheckCsrfToken.class)!=null){
// check csrf ...
原文地址：, 感谢原作者分享。
您可能感兴趣的代码相关文章推荐
CSRF——攻击与防御author: lake20x01 什么是CSRF攻击
CSRF是Cross Site Request Forgery的缩写（也缩写为XSRF），直译过来就是跨站请求伪造的...
为什么要拿CSRF来当“攻击手法系列”的开头篇呢？因为CSRF/XSRF我个人喜爱他的程度已经超过XSS了。如果说XSS是一个老虎，那么CSRF就是隐藏在暗处的蛇。??????
??相信现在很多人不...
什么是csrf？
django为用户实现防止跨站请求伪造的功能，通过中间件 django.middleware.csrf.CsrfViewMiddleware 来完成。而对于django中设置防跨站请求伪造功能有分为全...
利用django的中间件CsrfViewMiddleware，settings里配置
MIDDLEWARE_CLASSES = (
浅谈CSRF攻击方式
22:44 by hyddd, 158141 阅读, 107 评论, 收藏, 编辑
一.CSRF是什么？
　　CSRF（Cross-site ...
CSRF攻击介绍及防御
/reprint/csrf.html
CSRF概念：CSRF跨站点请求伪造(Cross—Site Req...
CSRF，跨站请求伪造，简单来说是盗用用户的身份，以用户的身份发送恶意请求，比如以用户的身份进行银行转账等。
原理：用户登录信任网站A，并生成本地cookie，在没有登出A的情况下，访问了危险网站B...
CSRFTester的使用
1，安装CSRFTester
CSRFTester是一款CSRF检测工具，点击本文附件进行下载。
解压附件zip文件，然后打开run.bat，修改JAVA_HOME的...
除了在每个表单页面里加入hidden input外，还有一种利用csrfcode进行防御的方法，这种方法把csrfcode的相关数据放在cookie中，但并不是把csrfcode放到cookie中，比...
他的最新文章
讲师：董晓杰
讲师：姚远
他的热门文章
您举报文章：
举报原因：
原文地址：
原因补充：
(最多只允许输入30个字)一、什么是CSRF？
CSRF是Cross Site Request Forgery的缩写，翻译过来就是跨站请求伪造。那么什么是跨站请求伪造呢？让我一个词一个词的解释：
1、跨站：顾名思义，就是从一个网站到另一个网站。
2、请求：即HTTP请求。
3、伪造：在这里可以理解为仿造、伪装。
综合起来的意思就是：从一个网站A中发起一个到网站B的请求，而这个请求是经过了伪装的，伪装操作达到的目的就是让请求看起来像是从网站B中发起的，也就是说，让B网站所在的服务器端误以为该请求是从自己网站发起的，而不是从A网站发起的。当然，请求一般都是恶意的。
看到这里，你可能会问：为什么要伪装成从B网站发起的呢？从网站A直接向B网站服务器发起请求不可以吗？
要回答这个问题，就需要我们对Cookie机制有一定的认识。关于Cookie机制我会单独写一篇文章，这里不做详细介绍。这里你只需要知道：之所以要伪装成从B网站发起的，是因为Cookie是不能跨域发送的。结合上面这个例子来说就是：如果从A网站直接发送请求到B网站服务器的话，是无法将B网站中产生的Cookie一起发给B服务器的。
可能你还会问，为什么非要发送Cookie呢？这是因为服务器在用户登录后会将用户的一些信息放到Cookie中返回给客户端，然后客户端在请求一些需要认证的资源的时候会把Cookie一起发给服务器，服务器通过读取Cookie中的信息来进行用户认证，认证通过后才会做出正确的响应。
A网站访问B网站服务器的一些需要认证的资源的时候，如果没有Cookie信息，服务器是拒绝访问的，那么A网站就无法进行恶意操作。而伪造成B网站的请求，就可以将B网站的Cookie一起发到B服务器，这个时候就服务器就认为该请求是合法的，就会给出正确的响应，这个时候，A网站就达到目的了。
简单一句话就是：攻击者盗用了你的身份，以你的名义发送恶意请求。
那么，A网站通过CSRF能够做那些操作呢？
二、CSRF能够做什么呢？
CSRF能够做的事情包括：以你名义发送邮件，发消息，盗取你的账号，甚至于购买商品，虚拟货币转账……造成的问题包括：个人隐私泄露以及财产安全。等等等等。
三、通俗点的例子
下面我们举个例子来说明CSRF攻击是如何实现的。
假设有一个微博网站B，B有一个“加关注”的功能，即一个用户可以关注另一个用户，而这个功能是这样的实现的：用户每次点击“加关注”按钮的时候，就会向服务器发送一个GET请求，URL如下：
URL中的参数uid表示的是你要关注的用户的ID。
在正常情况下，即你登录B网站后，点击“加关注”按钮，浏览器会将上面的URL连同B网站产生的Cookie一起发送到B网站的服务器，B服务器首先通过Cookie进行用户认证，如果Cookie中的信息正确，就会进行向数据库中写入记录，这样，你就成功关注了ID为123的用户。
假如我是一个恶意用户，我想让更多的人关注我，而我又不想通过正常的渠道去实现，因为毕竟正常渠道比较浪费时间，于是我便开始想歪主意，碰巧，B网站的“加关注”的实现原理被我发现了。这个时候，我便进行了如下操作：
首先我在我自己的网站A里发了篇文章，文章中全是妖娆的美女图片，大家都喜欢美女嘛，所以就会有很多人来看我的这些美女，我们知道，图片在网页中大都是通过&img scr=”http://….”/&这样的形式实现的，图片加载的时候就会请求src中指定的URL，而我就把众多美女图片的src写成了B博客里“加关注”的URL，不同的是将参数uid的值都写成了我在B网站中的ID（假设是456），即：
在网站A中的代码中就是：&img src=”/addfriends?uid=456″ /&，当用户点击我发的文章的时候，浏览器就会请求这个src中的URL，这样就达到了在A网站中请求B服务器资源的目的，但是这样还差了一步，因为请求还是从A网站发出的，所以就没有B网站产生的Cookie，所以还是达不到目的，那该怎样做呢？
这就需要利用用户的上网习惯了，我们平时都会同时浏览很多网页，比如，你打开浏览器登录了B网站，与此同时，你可能也打开了我的网站A，而碰巧被我网站里全是美女的帖子吸引住了，就忍不住打开了这个帖子，这个时候，我的网站A就发起了上面的那个到B服务器的请求，而此时，你已经登录了B网站，Cookie已经产生了，浏览器一看请求的域名是，便将存放在客户端的B网站的Cookie给顺带一起发了过去，这样，服务器就会误认为是你主动要关注我的，于是，便向数据库写入了一条记录，而你就在不知不觉中，默默无闻的关注我了~~~
这样，我的目的就达到了~~~~
而如果很多用户都像你一样，在登录B微博的同时查看了我的帖子，那么他们也一样，默默无闻的关注了我~于是，我的粉丝量就大增！~~~
这里要说明一下：上面例子中说的同时打开多个网页只是可以被利用的方法中的一种，但并不是唯一的一种，你要知道，黑客们可不是吃素的啊，他们手段多着呢~在此顺道向黑客们的技术深深的致一敬~！
四、下面借用别人的图文来说明一个整个CSRF的过程：
从上图可以看出，要完成一次CSRF攻击，受害者必须依次完成两个步骤：
1.登录受信任网站A，并在本地生成Cookie。
2.在不登出A的情况下，访问危险网站B。
看到这里，你也许会说：“如果我不满足以上两个条件中的一个，我就不会受到CSRF的攻击”。是的，确实如此，但你不能保证以下情况不会发生：
1.你不能保证你登录了一个网站后，不再打开一个tab页面并访问另外的网站。
2.你不能保证你关闭浏览器了后，你本地的Cookie立刻过期，你上次的会话已经结束。（事实上，关闭浏览器不能结束一个会话，但大多数人都会错误的认为关闭浏览器就等于退出登录/结束会话了……）
3.上图中所谓的攻击网站，可能是一个存在其他漏洞的可信任的经常被人访问的网站。
五、GET还是POST
上面我举得例子中，B网站用的是GET请求，所以就被我轻松的利用了，那么，如果B网站“加关注”的实现方式采用的是POST请求，是不是就能有效防止CSRF攻击了呢？
不是这样的，如果B改用了POST请求，那么通过&img src/&这样的方式的确无法达到目的了，但是攻击者还是可以通过人为构造POST请求的方式达到目的。
那么，在开发过程中，应该如何有效避免CSRF攻击呢？
要回答这个问题，请参考：
/hyddd/archive//1432744.html
&&相关文章推荐
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：130998次
积分：2027
积分：2027
排名：千里之外
原创：48篇
转载：181篇
(1)(3)(1)(1)(1)(48)(27)(16)(2)(19)(16)(44)(50)
(window.slotbydup = window.slotbydup || []).push({
id: '4740887',
container: s,
size: '250,250',
display: 'inlay-fix'