Csrf | 乐趣区

关于csrf:一文深入了解CSRF漏洞

1.1. 定义跨站申请伪造（英语：Cross-site request forgery），也被称为 one-click attack 或者 session riding，通常缩写为 CSRF 或者 XSRF，是一种挟制用户在以后已登录的Web应用程序上执行非本意的操作的攻打办法。跟跨站脚本（XSS）相比，XSS 利用的是用户对指定网站的信赖，CSRF 利用的是网站对用户网页浏览器的信赖。跨站申请伪造攻打，是攻击者通过一些技术手段坑骗用户的浏览器去拜访一个用户本人已经认证过的网站并执行一些操作（如发邮件，发消息，甚至财产操作如转账和购买商品）。因为浏览器已经认证过，所以被拜访的网站会认为是真正的用户操作而去执行。这利用了web中用户身份验证的一个破绽：简略的身份验证只能保障申请是发自某个用户的浏览器，却不能保障申请自身是用户被迫收回的。 Note 简略来说就是你点击我结构的歹意链接，我就能够以你的名义去发动一个http申请 1.2. 举例如果X银行用以执行转账操作的URL地址如下 https://bank.example.com/withdraw?amount=1000&to=PayeeName一个歹意攻击者在另一个网站中https://evil.com/中搁置如下代码 <img src="https://bank.example.com/withdraw?amount=1000&to=Bob" />如果有登陆了X银行的用户拜访歹意站点https://evil.com/，那么就会携带cookie去申请对应的转账URL，向Bob转账1000元Note 这种歹意的网址能够有很多种形式，藏身于网页中的许多中央，只有能让受害者发动对应的申请即可，如上述中的转账申请。攻击者也不须要管制搁置恶意代码的网站，例如他能够将这种地址藏在各大论坛，博客等任何用户生成内容的网站中，这意味着如果服务端没有适合的进攻措施的话，用户即便拜访相熟的可信网站也有受攻打的危险。通过例子也可能看出，攻击者并不能通过CSRF攻打来间接获取用户的账户控制权，也不能间接窃取用户的任何信息。他们能做到的，是坑骗用户的浏览器，让其以用户的名义执行操作。 1.3. 攻打流程具体的攻打流程如下：用户失常登录web服务，并始终放弃在线服务器返回用户凭证Session ，并将其保留在Cookie中攻击者生成payload，并搁置在用户可拜访的中央攻击者诱导用户点击在第3步搁置的链接，此时用户始终在线，且是用同一浏览器关上（保障Cookie未生效）用户点击歹意链接歹意链接向服务器申请，因为用户Cookie未生效，就携带用户Cookie拜访服务器服务器收到申请，此时用户Cookie 未生效，并断定为“用户”发动的失常申请，并做出响应1.4. 分类1.4.1. GET型这种是最容易利用的，相比于POST型来说，攻击面也大很多，比方上述CSRF转账例子中就是GET型的在web利用中，很多接口通过GET进行数据的申请和存储，如果未对起源进行校验，并且没有token爱护，攻击者能够间接通过发送含有payload的链接进行诱导点击；亦能够通过评论区或相似性能处公布图片，通过批改img地址的形式保留至页面，用户拜访便会进行主动加载造成攻打 <img src="https://bank.example.com/withdraw?amount=1000&to=Bob" />1.4.2. POST-表单型相比于GET型，这种就要多很多，因为很多开发在提交数据的性能点时都会采纳POST，如创立用户、创立文章、发消息等，利用起来也绝对麻烦点 Note 测试时，为了扩充危害，能够尝试将POST数据包转换成GET数据包，后端采纳如@RequestMaping("/")这种同时承受POST和GET申请的话，就能够胜利利用起来无非也是结构一个主动提交的表单，而后嵌入到页面中，诱导受害者拜访，受害者拜访后会主动提交表单发动申请 <form action=http://bank.example.com/csrf method=POST><input type="text" name="amount" value="1000" /></form><script> document.forms[0].submit(); </script>1.4.3. POST-JSON型当初越来越多的零碎都采纳RESTful格调开发，前后端拆散，ajax申请后端获取数据再到前端渲染，所以上述表单型也越来越少了如果咱们发现申请头中的Content-Type值是application/json，基本上就能够确定采纳了前后端拆散了这种个别有4️种利用手法： json转param闭合JSONajax发动申请flash+307跳转json转param局部网站可能同时反对json和表单格局，所以咱们能够尝试进行转换，也算是一个小tips吧如把 {"a":"b"} 转换为 a=b，服务端可能也会解析闭合JSON这种要求对Content-Type没有限度，比方传输的数据为 {"a":"b"}，那么咱们就能够结构一个表单 <form action=http://test.example.com/csrf method=POST>  <input type="hidden" name='{"a":"' value='b"}' /></form><script> document.forms[0].submit(); </script>这样主动提交表单的时候，提交的data就是 {"a":"=b"}，闭合成了json ...

关于csrf:2312321312

2131232132131232132132131 @Servicepublic class MultiDatasourceService { @Resource private MultiDatasourceService multiDatasourceService; @Resource private TestMapper testMapper; @Transactional public void updateNameById(Long id) { int i = 1; testMapper.updateById(id, "clcl"); // 调用另外一个事务办法 multiDatasourceService.updateNameById1(id); int j = 2; } @Transactional(propagation = Propagation.REQUIRES_NEW) public void updateNameById1(Long id) { int i = 1; testMapper.updateById(3L, "clcl"); }}

关于csrf:CSRF攻击的示例讲解

原文：https://mp.weixin.qq.com/s?__...微信公众号：毛毛虫的小小蜡笔CSRF简介Cross-site request forgery，跨站申请伪造，通常缩写为CSRF或者XSRF。 CSRF之get申请攻打发动get申请攻打比较简单，只须要通过img标签就可实现。因为受浏览器同源策略限度，因而不能通过ajax来发动get申请。 Demo验证代码：// 这段代码是网站B的页面，只是发动了网站A的申请// src的值就是网站A下的get申请<head> <meta charset="utf-8"> <title>csrf之get申请攻打</title></head><body> <img src="http://xxx"></body>成果：用户关上攻击者网站B，则会主动发动网站A的get申请，状态码200示意胜利。如下截图所示：通过抓包查看，申请是带上了cookie，响应也是失常的。如下截图所示：就是如果在别的网站能发动网站A的申请，网站A就是存在CSRF破绽了。只是get申请的危害没有post申请那么大，但也不能疏忽。但凡破绽都要提起十二分精力。 CSRF之post申请攻打相比get申请的攻打，想发动post申请的攻打，就没那么容易实现。首先咱们晓得，在网站B是不能通过ajax发动网站A的post申请的，因为有同源策略限度。但须要留神的是，同源策略只是限度了XMLHttpRequest和Fetch API，而html的form标签则不受同源策略限度。同样，get申请的img标签也不受同源策略。 1. 测试form表单发动post申请是否能攻打胜利代码：// 这段代码是网站B的页面，只是发动了网站A的申请<head> <meta charset="utf-8"> <title>csrf-post</title></head><body> <form id="form" action="http://xxx" method="POST" target="iframe1"> <input type="text" name="id" value="70"> <input type="text" name="biz_module_id" value="[15]"> <input type="text" name="deploy_path" value=""> <input type="text" name="description" value="test"> <input type="text" name="name" value="config.txt"> <input type="text" name="version" value="1"> </form> <iframe name="iframe1"></iframe> <script> document.getElementById('form').submit() </script></body>成果：论断：很显著申请是不胜利的。但能把网站A的登录态带过来，也算是胜利了一部分。比照下网站A的post申请，发现两者的申请数据格式不一样。网站A的如下图所示：剖析：form申请的数据格式跟enctype属性无关。默认的是application/x-www-form-urlencoded，此时就是Form Data。编码类型总共三种，还有两种是：multipart/form-data和text/plain。前者是上传文件用的，后者用的比拟少。但正是通过text/plain，能够将数据格式改为Request Payload。 2. 再次验证代码：// 在下面的代码的根底上，把form新增enctype属性<head> <meta charset="utf-8"> <title>csrf-post</title></head><body> <form id="form" action="http://xxx" method="POST" target="iframe1" enctype="text/plain"> <input type="text" name="id" value="70"> <input type="text" name="biz_module_id" value="[15]"> <input type="text" name="deploy_path" value=""> <input type="text" name="description" value="test"> <input type="text" name="name" value="config.txt"> <input type="text" name="version" value="1"> </form> <iframe name="iframe1"></iframe> <script> document.getElementById('form').submit() </script></body>成果：论断：胜利的把数据格式改为Request Payload了，但为啥接口仍然报错？ ...

关于csrf:演示怎么批量把excel表格通讯录导入苹果iphone手机

咱们在下班的时候，可能会接到下面传来的一份excel表格，须要你来告诉外面的人。然而下班的工夫是无限的，你想把表格里的号码和铭字存入到手机通讯录里，不便你的上班后回家持续工作以及之后放弃联系。那么怎么批量把excel表格通讯录导入苹果iphone手机？这里借助一个网络上常见的软件，金芝号码提取导入助手，来做演示它是如何疾速简略的实现这个事件的。此外，安卓手机，像小米华为等也是能采纳同样的形式的。第I步：像我下图那样，把铭字和号码都筹备好，一行一列，如果没有铭字只有号码也能够，拿号码作为铭字就能够了。或者应用软件上的“铭字随机生成性能”来失去铭字。申明：我图片里的铭字，张三李四这些都是虚构的并非精确，随机编写，用来做演示通俗易懂的过程而已。第II步：关上软件，金芝号码提取导入助手，把你的铭字复制放进第一个框，把你的号码复制放进第二个框，都放好了，点上面的，转换通信禄，很快失去一个文件，你把文件保留到电脑桌面，文件铭本人写简略点，比方aaa。第III步：电脑上的工作做完了，把方才桌面的文件aaa，发送给你的手机某信或者手机某扣，很简略的，通过电脑某信或者电脑某扣就能够发送，平时不都是这么发文件的吗。第IV步：关上的手机某信或扣，找到方才发过来的文件，点开它，选“其余利用形式关上”，抉择“通信禄”，存储，导入，确定即可。无论你是安卓手机还是苹果手机，不论是几的零碎，都是能够关上存入的，很疾速的几步即可。如果你的遇到这种须要反复操作的问题，比方你还在想一个个手动把11位数字和人铭汉字一个个敲打存入手机通讯录，那么还在手工操作的话，你就out了。当初是科技倒退的时代，技术是能够解决这种反复干燥的问题的。通过借助于网上常见的便当工具软件，金芝号码提取导入助手，那么这类的状况是不须要花多少工夫和精力的，就能批量把excel表格通讯录导入苹果iphone手机，当然了安卓手机小米华为等也能。

关于csrf:如何使用-Apache-APISIX-CSRF-安全插件拦截跨站点伪造攻击

CSRF（Cross-Site Request Forgery），即跨站点申请伪造。发动跨站点申请伪造攻打的关键点在于让指标服务器无奈分辨泛滥申请的起源是实在用户还是攻击者。攻打的个别流程为：首先攻击者会诱导用户导航至攻击者提供的网页上。该网页蕴含一个主动发送到指标服务器的申请。而后该网页失常加载，这个申请就会主动发送至服务器。在服务器看来，这个申请和用户失常发送的申请截然不同，殊不知这是由攻击者发动，而用户却毫不知情。因为该申请携带了用户的一些凭据，攻击者通过解析这些凭据，就能够获取用户信息，进而产生平安危险。本文介绍了 Apache APISIX 的 CSRF 平安插件 csrf，并具体阐明如何在 Apache APISIX 中借助 csrf 插件来爱护您的 API 信息安全。插件介绍csrf 插件基于 Double Submit Cookie 计划实现。依据 RFC 7231#section-4.2.1 的定义，咱们把 GET、HEAD 和 OPTIONS 这三种办法称为平安办法。依照这一约定，csrf 插件会间接放行这三种办法，但会对其余的办法做查看并拦挡其中的不平安申请。为了抵挡 CSRF 攻打，咱们须要制作一个无奈伪造的令牌或标识符，并且保障这个不会与攻击者的申请一起发送。用户须要将 csrf 插件依赖的 token 携带在申请头，token 应用密钥进行签名计算。这样就保障了 token 无奈被别人伪造，从而保障了 API 的平安。 [外链图片转存失败,源站可能有防盗链机制,倡议将图片保留下来间接上传(img-yyZwLqQV-1645607360060)(https://tfzcfxawmk.feishu.cn/...)] 在路由中开启 csrf 插件后，拜访该路由的所有申请响应中都会蕴含携带了 csrf token 的 Cookie。用户须要在对该路由的不平安申请中携带这一 Cookie，并在申请头增加额定的字段携带 Cookie 的内容。字段为插件配置中的 name 值，这样的申请能力通过 CSRF 插件的校验。用户在插件的配置中提供一个随机密钥，插件应用该密钥对 token 信息进行 sha256 哈希加密，而后生成 CSRF token，从而保障该 token 不可伪造。如何应用配置开启 CSRF 插件的路由在 APISIX 中应用 Admin API 创立一条路由并启用 csrf 插件： ...

关于csrf:qc世乒赛落幕樊振东完美收官国乒取4金瑞典1金1银成绩超日本

北京工夫11月30日，世乒赛落下帷幕，最终的男单决赛中，樊振东轻松击败瑞典小将默雷加德，首次拿下世乒赛男单冠军。国乒本次世乒赛最终4冠收官！樊振东面对默雷加德这场较量尽管是男单决赛，但实际上悬念不大，一个是世界第一，一个世界排名第77，能进入决赛挑战樊振东，默雷加德多亏了赛程，下半区他没有对阵国乒选手，半决赛面对波尔的时候，对手又受伤了。因而，樊振东迅速火力全开，11-6、11-9、11-7连下3局，获得了3-0的劣势。之后的较量，樊振东遭逢对手最初的反扑，仍然11-8胜利拿下胜利，总比分4-0取得冠军。樊振东首次拿下世乒赛男单冠军，这样一来也是世界杯男单、世乒赛男单的获得者了，只差奥运会冲击男单冠军。这样一来，本次世乒赛全副完结。冠军如下：男单：樊振东女单：王曼昱男双：法尔克/卡尔松女双：王曼昱/孙颖莎混双：王楚钦/孙颖莎整体来看，国乒拿下4金，整体体现稳固，但也有一点遗憾。这个遗憾天然就是男双，法尔克/卡尔松连胜国乒2对组合，帮忙瑞典乒乓球队时隔30年取得冠军，国乒则是没有进入决赛。然而思考到马龙与许昕都没有来，实际上也能够承受了，毕竟正如刘国梁说，乒乓球是属于世界的，不只是属于中国的，所以拿下4金的国乒曾经十分杰出了，何况还有1枚银牌与5.5枚铜牌。当然，瑞典取得了1金1银，问题超过了日本，排名第二位。

关于csrf:学习fetch从这里开始

一、fetch() 是什么？fetch() 是浏览器内置的全局 JavaScript 办法，用于收回 http 申请，无需下载安装，能够间接应用。 // 一个简略 http 申请fetch('http://example.com/movies.json') .then(function (response) { return response.json(); }) .then(function (myJson) { console.log(myJson); });二、怎么应用？1、简略应用实例fetch() 的第二个参数是 init 对象，用于设置 http 的配置信息。 postData('http://example.com/answer', { answer: 42 }) .then(data => console.log(data)) .catch(error => console.error(error))function postData(url, data) { return fetch(url, { body: JSON.stringify(data), cache: 'no-cache', credentials: 'same-origin', headers: { 'user-agent': 'Mozilla/4.0 MDN Example', 'content-type': 'application/json' }, method: 'POST', mode: 'cors', redirect: 'follow', referrer: 'no-referrer', }) .then(response => response.json())}2、配置具体阐明method ：申请应用的办法，如 GET、POST、PUT、DELETE 等。headers ：申请的头信息。body ：申请的 body 信息，留神 GET 或 HEAD 办法的申请不能蕴含 body 信息。mode ：申请模式，可用值： cors、no-cors、same-origincredentials ：是否发送 cookie 给服务器：omit(任何状况都不发)、same-origin(同源才发)、include(任何状况都发)cache ：可用 cache 模式：default、no-store、reload、no-cache、force-cache、only-if-cached 。redirect ：重定向，Chrome中默认应用 follow ； ...

关于csrf:怎么防止跨站请求伪造攻击CSRF

一、CSRF 是什么？跨站申请伪造（英语：Cross-site request forgery），也被称为 one-click attack 或者 session riding，通常缩写为 CSRF 或者 XSRF，是一种挟制用户在以后已登录的Web应用程序上执行非本意的操作的攻打办法。二、理论攻打场景上面用一个银行网站的转账性能，阐明攻打原理。备注：波及到 URL 等信息都是虚构。 1、登录账号失常登录了一家银行网站，查看其后盾信息后，没有退出登录；假如这家银行操作转账的 URL 是： https://bank.example.com/withdraw?account=AccoutName&amount=1000&for=PayeeName2、歹意链接此时你看到其余网站的一个诱导链接，你下意识点开了；诱导链接中蕴含恶意代码（用转账链接代替实在图片链接） <img src="https://bank.example.com/withdraw?account=Alice&amount=1000&for=Badman" />3、攻打实现点击链接后，浏览器会关上 <img> 中 src 属性的链接来加载图片，但实际上执行了转账操作；转账申请所用电脑、浏览器、ip等环境跟登录账号时的环境截然不同，银行网站后盾会认为这就是你自己在操作，所以验证通过，间接转账。三、避免 CSRF 攻打服务器端对申请做一次身份验证，回绝掉无奈通过验证的申请，即可形式 CSRF 攻打。 1、第一种办法：验证码给手机发送数字验证码、图形化验证码让客户辨认、让用户再次输出账号密码等进行再次身份验证。 2、第二种办法：TokenToken 应用过程： 1、服务器生成一个 CSRF token；2、客户端(浏览器) 提交表单中含有 CSRF token 信息；3、服务端接管 CSRF token 并验证其有效性。原理阐明：攻击者有可能在下面客户端中拿到 CSRF token，然而攻击者只能应用 JavaScript 来发动申请，如果服务器不反对 CORS(跨域资源)，那么攻击者的跨域 JavaScript 申请是会被服务器回绝，达到避免 CSRF 攻打目标。 Node.js 我的项目中举荐应用 csurf ，具体应用办法，看这里！四、参考文档怎么避免跨站申请伪造攻打（CSRF）？

关于csrf:CSNote1

计算机系统计算机系统包含软件+硬件硬件 0. 主机(中央处理器(CPU)+内存储器(内存)) 1. 外部设备(输出/输出设备,外存储器) 软件 0. 系统软件(操作系统,语言处理程序,数据库管理系统等) 1. 应用软件(如浏览器,文件管理器,影音播放器等) 内存分为随机存储器RAM,和只读存储器ROM 0. 内存储器次要寄存计算机以后正在运行的程序,用到的数据信息和运算成绩等.1. 通常说的内存容量指RAM的大小,RAM的内容能够随机读出或写入,断电时,RAM的内容会失落.2. ROM中的内容是由生产厂商一次性写入固化的,应用时只能读不能写入. C语言中,经常说的调配的内存是指RAM ROM的内容是“只读”的,在电脑运行期间,是不可以往其中存入信息的。程序设计语言机器语言,即二进制0和1,它是惟一能被计算机了解并执行的语言.汇编语言,它是计算机指令的符号化,能间接拜访零碎接口. 计算机指令:管制计算机的二进制代码高级语言,靠近自然语言,须要先通过编译程序翻译为机器语言目标程序,再通过链接程序链接成为执行程序程序=数据结构+算法软件=程序+数据+文档操作系统操作系统是治理和管制计算机软硬件资源的计算机程序, 是间接运行在"裸机"上的最根本的系统软件, 其它任何软件必须在操作系统的反对下方可运行.操作系统是用户和计算机的接口,同时也是计算机硬件和其它软件的接口. Linux历史初版UNIX操作系统由B语言编写. 起初从B语言中倒退出了C语言,UNIX迅速被用C语言重写. Linus Torvalds在类UNIX零碎衍生版Minix的根底上,设计出了第一代Linux. 因而,Linux零碎是由C语言编写的. 记住，在Linux，所有皆文件，网络接口、甚至鼠标键盘显示器都是文件计算机信息中的所有都能够用0和1来示意,包含像素的显示地位(屏幕坐标),像素色彩(RGB值),声音(波长)等等, 这些决定了图片,文字,视频,音频等屏幕上的显示开关量,和显示模拟量. 算术逻辑单元(Arithmetic&logical Unit)是中央处理器(CPU)的执行单元, 是所有中央处理器的外围组成部分, 由"And Gate"(与门) 和"Or Gate"(或门)形成的算术逻辑单元, 次要性能是进行二位元的算术运算, 如加减乘(不包含整数除法). 基本上, 在所有古代CPU体系结构中, 二进制都以补码的模式来示意.一个锁存器或触发器能存储1位二进制数，所以由N个锁存器或触发器能够形成N位寄存器

关于密码学:密码学系列之csrf跨站点请求伪造

简介CSRF的全称是Cross-site request forgery跨站点申请伪造，也称为一键攻打或会话劫持，它是对网站的一种歹意利用，次要利用的是已受权用户对于站点的信赖，无辜的最终用户被攻击者诱骗提交了他们不心愿的Web申请。歹意网站能够通过多种形式来发送此类命令。例如，特制的图像标签，暗藏的表单和JavaScript XMLHttpRequests都能够在用户不交互甚至不知情的状况下工作。如果产生了CSRF攻打，可能导致客户端或服务器数据意外透露，会话状态更改或者批改用户的信息。 CSRF的特点在CSRF的歹意攻打中，攻击者的指标是让被攻击者在人不知;鬼不觉中向有权限拜访的网站提交歹意的web申请。通过对该申请进行精心的设计，使其蕴含URL参数，Cookie和其余对解决该申请的Web服务器而言失常显示的数据。通过保留在用户Web浏览器中的cookie进行身份验证的用户可能会在人不知;鬼不觉中将HTTP申请发送到信赖该用户的站点，从而导致不必要的操作。为什么会有这样的攻打呢？因为对于web浏览器来说，它们将在发送给该域的任何Web申请中主动且有形地蕴含给定域应用的任何cookie。 CSRF攻打利用了此属性，因为浏览器收回的任何Web申请都将主动蕴含受害者登录网站时创立的任何cookie（包含会话cookie和其余cookie）。如果用户被诱骗通过浏览器无心中提交了申请，这些主动蕴含的cookie将使伪造也可能通过指标服务器的认证，从而产生歹意攻打。为了生成这样的攻打URL，歹意攻击者须要结构一个能够被执行的web申请，比方在指标页面上更改帐户明码。攻击者能够将该链接嵌入攻击者管制范畴内的页面上。比方它能够嵌入到发送给受害者的电子邮件中的html图像标签中，当受害者关上其电子邮件时，该图像会主动加载。一旦受害者单击了链接，他们的浏览器将主动蕴含该网站应用的所有cookie，并将申请提交到Web服务器。 Web服务器将会执行该歹意申请。 CSRF的历史早在2001年，就有人开始应用它来进行攻打了。不过因为攻打应用的是用户本人的IP地址，看起来就像是用户本人的一个失常的申请，所以很少有间接的攻打证据。目前晓得的比拟有名的CSRF攻打如下： 2006年Netflix爆出了泛滥CSRF破绽，攻击者能够更改受害者的账户收货地址，从而为攻击者本人来购买商品。YouTube在2008年也受到了CSRF的攻打，这使得任何攻击者都简直能够执行任何用户的所有操作。McAfee Secure也已经受到过CSRF的攻打，它容许攻击者更改公司零碎。2018年，一些路由器也受到了CSRF的攻打，从而可能批改路由器的DNS设置。 CSRF攻打的限度要想达成CSRF攻打是须要肯定的条件的，事实上CSRF攻打也并不是一个很简略的事件,必须满足上面的条件：指标web服务没有查看申请的referrer header，如果只容许同源申请的话，则无奈应用CSRF。攻击者必须在指标站点上找到表单提交文件，或者发现具备攻打属性的URL，该URL会执行某些操作（例如，转账或更改受害者的电子邮件地址或明码）。攻击者必须为所有表单或URL输出确定正确的值；如果要求它们中的任何一个是攻击者无奈猜到的机密身份验证值或ID，则攻打很可能会失败（除非攻击者在他们的猜想中十分侥幸）。当受害者登录到指标站点时，攻击者必须诱使受害者进入带有恶意代码的网页。攻击者只能发出请求，然而无奈看到指标站点响应攻打申请发回给用户的内容，如果操作具备连续性的话，后续的CSRF攻打将无奈实现。CSRF攻打的防备因为web浏览器对不同的HTTP申请解决形式是不同的，所以针对CSRF攻打的防备跟HTTP申请的办法相干。在HTTP GET中，应用CSRF攻打非常简单，比方将攻打URL带入IMG标签就会主动加载。然而，依据HTTP标准，GET办法不应该被用于批改数据。应用GET进行更新数据操作的应用程序应切换到HTTP POST或应用反CSRF爱护。 CSRF的HTTP POST破绽取决于应用状况：在最简略的POST模式中，数据编码为查问字符串（field1 = value1＆field2 = value2），能够应用简略的HTML模式轻松实现CSRF攻打，这就意味着必须采取反CSRF措施。如果以其余任何格局（JSON，XML）发送数据，规范办法是应用XMLHttpRequest收回POST申请，并通过同源策略（SOP）和跨域资源共享（CORS）避免CSRF攻打。其余HTTP办法（PUT，DELETE等）只能应用具备同源策略（SOP）和跨域资源共享（CORS）来避免CSRF的XMLHttpRequest申请；然而，在应用Access-Control-Allow-Origin：*标头明确禁用它们的网站上，这些措施将有效。上面咱们来具体解说几个防备CSRF的技巧 STP技术STP的全称是Synchronizer token pattern。也就是说在所有的HTML表单上蕴含一个暗藏的token字段，token是能够由很多种办法来生成，只有保障其随机性就行了。因为攻击者无奈预测到这个token的值，所以无奈进行CSRF攻打。比方上面的代码： <input type="hidden" name="csrfmiddlewaretoken" value="KbyUmhTLMpYj7CD2di7JKP1P3qmLlkPt" />STP是兼容性最好的，因为它仅依赖HTML，然而每个申请都带上token会减少程序的复杂性，因为token是惟一且不可预测的，因而还会强制执行适当的事件程序，这会引发一些可用性的问题（例如用户关上多个选项卡）。能够通过应用每个会话CSRF令牌而不是每个申请CSRF令牌来放宽它。 Cookie-to-header token如果web应用程序次要应用javascript来进行交互的话，能够思考应用这种形式。在首次拜访web服务的时候，会在cookie中设置一个随机令牌，该cookie无奈在跨域申请中拜访： Set-Cookie: csrf_token=i8XNjC4b8KVok4uw5RftR38Wgp2BFwql; Expires=Thu, 23-Jul-2015 10:25:33 GMT; Max-Age=31449600; Path=/; Domain=.wikipedia.org; SameSite=Lax; Secure在客户端运行javascript的时候，从cookie中读取这个token值，并将其复制到随每个事务申请发送的自定义HTTP标头中 X-Csrftoken：i8XNjC4b8KVok4uw5RftR38Wgp2BFwql服务器验证令牌的存在和完整性。因为从歹意文件或电子邮件运行的JavaScript无奈胜利读取cookie值以复制到自定义标头中。即便将csrf token cookie与歹意申请一起主动发送，服务器任然须要无效的X-Csrf-Token头。这项技术曾经被很多框架实现了，比方Django 和AngularJS，因为令牌在整个用户会话中放弃不变，所以它能够与AJAX应用程序很好地协同工作。留神，应用这项技术，必须确保同源政策。Double Submit Cookie这个办法与cookie-to-header办法相似，但不波及JavaScript，站点能够将CSRF令牌设置为cookie，也能够将其作为每个HTML表单中的暗藏字段插入。提交表单后，站点能够查看cookie令牌是否与表单令牌匹配。同源策略可避免攻击者在指标域上读取或设置Cookie，因而他们无奈以其精心设计的模式搁置无效令牌。与同步器模式相比，此技术的劣势在于不须要将令牌存储在服务器上。 SameSite cookie attribute当服务器设置cookie时，能够蕴含一个附加的“ SameSite”属性，批示浏览器是否将cookie附加到跨站点申请。如果将此属性设置为“strict”，则cookie仅在雷同起源的申请中发送，从而使CSRF有效。然而，这须要浏览器辨认并正确实现属性，并且还要求cookie具备“Secure”标记。 Client-side safeguards浏览器自身能够通过为跨站点申请提供默认回绝策略，来阻止CSRF。比方Mozilla Firefox的RequestPolicy或者Firefox和Google Chrome / Chromium 的uMatrix之类。然而，这可能会重大烦扰许多网站的失常运行。 ...

关于csrf:sqlmap绕过CSRF检测进行注入-CanMeng

最近在筹备较量，打sqlilabs时看了一下sqlmap的wiki，发现了–csrf-token和–csrf-url的参数，于是写了个php版本的bug试了一试。同时也理解了一下大家对csrf注入的广泛做法：sqlmap+burp正则匹配，两相比拟，还是sqlmap自带的性能比拟不便。写一个bug CSRF的广泛进攻办法是减少anti-csrf token，也就是一串不可预测的字符串。于是入手写了一个php版本防csrf的sqli脚本，这里写的并不标准，工夫戳是能够被预测的，而且此脚本能够被绕过token检测，有趣味能够推敲一下。 <?php session_start(); //生成随机token $token = md5(time()); //获取name参数 $name = isset($_GET['name']) ? $_GET['name']: ''; //校验token if ($_GET['token'] == $_SESSION['token']) { //执行sql语句 $mysqli = new mysqli("127.0.0.1","root","root"); $mysqli->select_db("test"); if (!$mysqli->connect_error) { $query = "select * from admin where username = '$name'"; $result = $mysqli->query($query); if (!$mysqli->error) { while ($row = $result->fetch_row()) { echo $row; } } else { echo $mysqli->error; } } else { echo $mysqli->connect_error; } $mysqli->close(); } else { echo "no token"; } //以hidden表单元素的模式输入token echo "<input type="hidden" name="token" value="$token">"; //刷新SESSION中token $_SESSION['token'] = $token;?>破绽利用 ...

关于csrf:关于CRSFTester的测试crsf漏洞的注意事项之一

在应用CRSFTester的抓取页面FORM申请时，页面的IP地址不能是127.0.0.1或localhost，如果是本地，须要批改一下IP的映射，在C:\Windows\System32\drivers\etc目录中的hosts文件最上面增加：127.0.0.1 eureka.com，而后在将本地页面的申请门路里的IP改为eureka.com即可，如：http://eureka.com:8001/test/testUrl?code=110100。

关于csrf:回顾CSRF-Cross-Site-Request-Forgery

之前我的项目中遇到了SameSite的应用, SameSite次要解决CSRF (Cross Site Request Forgery)问题，顺便也回顾下CSRF吧。一、原理利用被攻打网站服务器对用户网页浏览器的信赖。用户对非法网站的认证cookie(登录态等）会保留在浏览器端；跨站申请时浏览器会携带相干cookie的；当用户浏览歹意网页时，攻击者通过一些技术手段坑骗用户的浏览器去拜访一个用户已经认证过的网站并运行一些操作（如发邮件，发消息，甚至财产操作如转账和购买商品）。因为申请也是携带认证cookie信息的，服务端没有适合的进攻措施的话就很难辨认申请是用户失常申请还是CSRF申请。 1.1 特点：联合原理和CSRF命名能够看出CSRF的特点： Cross Site：攻打方在第三方站点；Request Forgery：当用户浏览歹意站点时向被攻打的服务器发送操作申请。攻击者不要获取用户的信息（cookie等），间接坑骗用户的浏览器，让其以用户的名义运行操。二、攻打伎俩间接引入前端平安系列之二：如何避免CSRF攻打？的DEMO：受害者登录a.com，并保留了登录凭证（Cookie）。攻击者诱惑受害者拜访了b.com。b.com 向 a.com 发送了一个申请：a.com/act=xx。浏览器会默认携带a.com的Cookie。a.com接管到申请后，对申请进行验证，并确认是受害者的凭证，误以为是受害者本人发送的申请。a.com以受害者的名义执行了act=xx。攻打实现，攻击者在受害者不知情的状况下，假冒受害者，让a.com执行了本人定义的操作。三、进攻针对CSRF的攻打原理，制订进攻策略：攻打来自第三方站点： sameSite cookie：通知浏览器禁止跨站申请携带cookie；同源检测（验证HTTP Referer字段）：服务器加强校验。伪造申请生成无奈伪造的数据，服务器加强校验，辨认伪造申请。3.1 验证HTTP Referer字段计划[[科普]跨站申请伪造-CSRF防护办法](https://www.freebuf.com/artic... 毛病尽管在CSRF攻打中，Referer是无奈伪造的，然而保护比拟艰难；Referer配置不精确的话，很容易阻断失常申请；前期保护艰难，随着url的变动需一直批改Referer；总之不举荐应用 3.2 在申请地址中增加token并验证计划[[科普]跨站申请伪造-CSRF防护办法](https://www.freebuf.com/artic...利用token标记非法申请。 CSRF token的生成，下发，上送，校验1. 生成由服务端生成随机惟一的字符串（GUID, UUID等），并保留到服务端的session或者其余服务端缓存（如Redis）; token的缓存最好有过期工夫；如果心愿进步token的安全性能够对生成的token进行对称加密。2. 下发下发是服务端如何把生成的CSRF token传给客户端，形式很多了，看客户端怎么不便提取并传给后端。千万别，千万别，千万别通过Set-Cookie下发；喷到页面里作为约定的全局变量；最好和后端一起确定一个规范的下发和上送形式。3. 上送上送：是客户端调用接口时提取CSRF token并传给服务。看申请接口类型也后很多上送形式。针对GET申请能够放入queryString里；Form POST申请能够增加暗藏域；AJAX, fetch申请还能够采纳放入request header里；最好和后端一起确定一个规范的上送形式。4. 校验服务端从申请里获取客户端上送的token；解密（如果之前有加密的话）；再跟缓存（Session/Redis）的值比照。四、哪些场景须要思考CSFR重要的场景都须要并且倡议采纳token计划，一些常见的case有：领取类场景（领取，转账，充值）；勾销/关注好友，转发，删除（日志，帖子等），发邮件等操作；信息更改类（更改手机号，邮箱等）。参考：整顿自GitHub笔记：CSRF

安全篇如何预防CSRF攻击

1、CSRF是什么？咱们简直每天都要用到浏览器，咱们的信息也会被浏览器“保留”。那咱们首先来看一下，浏览器是如何保留你的身份信息的。当咱们在拜访一个 Web 页面的时候，并不是咱们本人去获取页面信息，而是浏览器去获取了这些信息，并将它们进行了展现。这就阐明，你容许浏览器代表你去和 Web 的服务端进行交互。为了可能精确地代表你的身份，浏览器通常会在 Cookie 中存储一些必要的身份信息。所以，在咱们应用一个网页的时候，只须要在首次拜访的时候登录就能够了。从用户体验上来说，这当然是十分不便的。然而，黑客正是利用这一点，来编写带有歹意 JavaScript 脚本的网页，通过“钓鱼”的形式诱导你拜访（诱导你拜访到他的网站）。而后，黑客会通过这些 JavaScript 脚本窃取你保留在网页中的身份信息，通过仿冒你，让你的浏览器发动伪造的申请，最终执行黑客定义的操作。而这所有对于你本人而言都是无感知的。这就是 CSRF（Cross-Site Request Forgery，跨站申请伪造）攻打。 CSRF攻打攻打原理及过程如下：用户C关上浏览器，拜访受信赖网站A，输出用户名和明码申请登录网站A；在用户信息通过验证后，网站A产生Cookie信息并返回给浏览器，此时用户登录网站A胜利，能够失常发送申请到网站A；用户未退出网站A之前，在同一浏览器中，关上一个TAB页拜访网站B；网站B接管到用户申请后，返回一些攻击性代码，并收回一个申请要求拜访第三方站点A；浏览器在接管到这些攻击性代码后，依据网站B的申请，在用户不知情的状况下携带Cookie信息，向网站A发出请求。网站A并不知道该申请其实是由B发动的，所以会依据用户C的Cookie信息以C的权限解决该申请，导致来自网站B的恶意代码被执行。举一个栗子受害者 Bob 在银行有一笔贷款，通过对银行的网站发送申请 http://bank.example/withdraw?account=bob&amount=1000000&for=bob2 能够使 Bob 把 1000000 的贷款转到 bob2 的账号下。通常状况下，该申请发送到网站后，服务器会先验证该申请是否来自一个非法的 session，并且该 session 的用户 Bob 曾经胜利登陆。黑客 Mallory 本人在该银行也有账户，他晓得上文中的 URL 能够把钱进行转帐操作。Mallory 能够本人发送一个申请给银行：http://bank.example/withdraw?account=bob&amount=1000000&for=Mallory。然而这个申请来自 Mallory 而非 Bob，他不能通过平安认证，因而该申请不会起作用。这时，Mallory 想到应用 CSRF 的攻击方式，他先本人做一个网站，在网站中放入如下代码： src=”http://bank.example/withdraw?account=bob&amount=1000000&for=Mallory ”，并且通过广告等诱使 Bob 来拜访他的网站。当 Bob 拜访该网站时，上述 url 就会从 Bob 的浏览器发向银行，而这个申请会附带 Bob 浏览器中的 cookie 一起发向银行服务器。大多数状况下，该申请会失败，因为他要求 Bob 的认证信息。然而，如果 Bob 过后凑巧刚拜访他的银行后不久，他的浏览器与银行网站之间的 session 尚未过期，浏览器的 cookie 之中含有 Bob 的认证信息。这时，喜剧产生了，这个 url 申请就会失去响应，钱将从 Bob 的账号转移到 Mallory 的账号，而 Bob 过后毫不知情。等当前 Bob 发现账户钱少了，即便他去银行查问日志，他也只能发现的确有一个来自于他自己的非法申请转移了资金，没有任何被攻打的痕迹。而 Mallory 则能够拿到钱后绳之以法。 ...

系统的讲解-PHP-WEB-安全防御

常见漏洞看到上图的漏洞是不是特别熟悉，如果不进行及时防御，就会产生蝴蝶效应。往下看，可能会找到你要的答案。 SQL注入攻击定义SQL注入攻击是通过WEB表单提交，在URL参数提交或Cookie参数提交，将怀有恶意的“字符串”，提交给后台数据库，欺骗服务器执行恶意的SQL语句。案例//以用户登录为例，当验证用户名和密码是否正确时$sql = "SELECT * FROM user WHERE username = '".$_GET['username']."' AND password = '".$_GET['password']."'";用户恶意输入： $_GET['username'] = "' or 1=1 -- '";$_GET['password'] = "123456";注入后的Sql语句： $sql = "SELECT * FROM user WHERE username = '' or 1=1 -- ''AND password = '123456'";执行注入后的Sql语句，可以返回 user 表的全部数据。平时我们可以进行自测，比如使用单引号、双引号，如果是数字进行+1或-1。 SQL注入的危害很大，利用SQL注入可以进行，拖库、删库、删表、UDF提权、读取文件、... 推荐一个开源的自动化的SQL注入工具。 SQLmap：http://sqlmap.org/ 支持各种数据库管理系统（MySql、Oracle、SQL Server、SQLite ... ）。支持自动识别密码哈希格式并通过字典破解密码哈希。支持枚举用户、密码、哈希、权限、角色、数据库、数据表和列。支持完全地下载某个数据库中的某个表、某个列。支持在数据库管理系统中搜索指定的数据库名、表名或列名。支持下载或上传文件。支持执行任意命令并回现标准输出。支持布尔型盲注、时间型盲注、基于错误信息的注入、联合查询注入和堆查询注入。尝试着利用工具，注入自己的项目，发现问题，然后解决问题。 SQL注入的危害，远比我们想象的要大！防御推荐解决方案是使用 PDO 或 MySQLi 的数据库扩展。 PHP官方文档中介绍，MySQL扩展自PHP 5.5.0起已废弃，并在自PHP7.0.0开始被移除。如果已经在用MySQL扩展了，可以对传入的每个参数做验证，并使用框架的ORM进行查询。另外：addslashes 和 mysql_real_escape_string 这种转义是不安全的！ ...

常见前端安全 - XSS/CSRF/cookie/密码/HTTP传输/点击劫持

XSS定义：Cross site本网站运行了来自其他网站的代码数据变成了程序XSS实例:页面上输出query参数页面上显示搜索框脚本引入外部js资源富文本 - 写日志 - 富文本 - 塞入的 - 加入scrpit在线商城 - 订单信息input消息的填写 - 订单信息流入后台 - 获取后台的管理员信息和后台地址XSS危害：获取页面数据获取cookie document.cookie劫持前端逻辑发送请求攻击分类：XSS攻击点：包含用户输入行为HTML节点内容1.HTML属性红框内为输入内容，导致属性标签闭合添加了新的属性2.javascript代码 - 强制标签闭合 - 搜索3.富文本：富文本自带HTML防御方法1.浏览器自带 X-XSS-Protection 取值： 0关闭 1默认(开启) 1后面带参数 - 拦截后自动发送到该网址上限制：只拦截反射类型注入 - 只对HTML属性和节点内容有用demo（koa）2.HTML节点内容/属性 - 转义成HTML实体不被浏览器解析正常显示< > 内容“ ‘ 是属性3.javascript代码JSON.stringfy - 所有的单引号/双引号都会被转义4.富文本黑名单 - 正则替换 - 因为变形有很多，只能阻挡一部分白名单 - 在白名单的HTML允许写入 - 实现复杂 - 把html解析成树状结构 - 依次分析过滤每个节点的name,attr，过滤掉不在白名单内的属性和tag 使用npm包 - xss自动实现 https://www.npmjs.com/package/xss5.csp - http的头content security policy内容安全策略，用于指定哪些内容可执行类型Child-src 页面子内容 iframeConnect-src ajaxDefault-src fallback 所有的内容Font-srcFrame-srcImg-srcManifest-src webappMedia-src audio/videoObject-src 插件Script-src Style-srcWorker-src serviceWorker配置选项 - 那些可信任那些不可信任<host-source> 主机域名<scheme-source> 协议Self 同域 - 引入的资源Unsafe-inline 直接插入页面的内容Unsafe-eval none 不信任任何内容 Nonce-<base64-value> 指定一次性凭证凭证匹配时可执行<hash-source>Stric-dynamic 引入的后续网址是否demo没有指定的全部不信任,只信任同源的引入文件，对于直接插入的不信任CSRF ...

使用SpringSecurity处理CSRF攻击

CSRF漏洞现状CSRF（Cross-site request forgery）跨站请求伪造，也被称为One Click Attack或者Session Riding，通常缩写为CSRF或XSRF，是一种对网站的恶意利用。尽管听起来像跨站脚本（XSS），但它与XSS非常不同，XSS利用站点内的信任用户，而CSRF则通过伪装成受信任用户的请求来利用受信任的网站。与XSS攻击相比，CSRF攻击往往不大流行（因此对其进行防范的资源也相当稀少）和难以防范，所以被认为比XSS更具危险性。 CSRF是一种依赖web浏览器的、被混淆过的代理人攻击（deputy attack）。POM依赖<!– 模板引擎 freemarker –><dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-freemarker</artifactId></dependency><!– Security (只使用CSRF部分) –><dependency> <groupId>org.springframework.security</groupId> <artifactId>spring-security-web</artifactId></dependency>配置过滤器@SpringBootApplicationpublic class Application { public static void main(String[] args) { SpringApplication.run(Application.class, args); } /** * 配置CSRF过滤器 * * @return {@link org.springframework.boot.web.servlet.FilterRegistrationBean} / @Bean public FilterRegistrationBean<CsrfFilter> csrfFilter() { FilterRegistrationBean<CsrfFilter> registration = new FilterRegistrationBean<>(); registration.setFilter(new CsrfFilter(new HttpSessionCsrfTokenRepository())); registration.addUrlPatterns("/"); registration.setName(“csrfFilter”); return registration; }}在form请求中添加CSRF的隐藏字段<input name="${(_csrf.parameterName)!}" value="${(_csrf.token)!}" type=“hidden” />在AJAX请求中添加header头xhr.setRequestHeader("${_csrf.headerName}", “${_csrf.token}”);jQuery的Ajax全局配置jQuery.ajaxSetup({ “beforeSend”: function (request) { request.setRequestHeader("${_csrf.headerName}", “${_csrf.token}”); }});

前端安全问题及解决办法

一、随着前端的快速发展，各种技术不断更新，但是前端的安全问题也值得我们重视，不要等到项目上线之后才去重视安全问题，到时候被黑客攻击的时候一切都太晚了。二、本文将讲述前端的六大安全问题，是平常比较常见的安全问题，当然如果还有其他必要重要的安全问题大家可以帮忙补充：1、XSS（Cross-Site Scripting）脚本攻击漏洞；2、CSRF（Cross-sit request forgery）漏洞；3、iframe安全隐患问题；4、本地存储数据问题；5、第三方依赖的安全性问题；6.HTTPS加密传输数据；下面将对这些问题进行分享说明。三、XSS（Cross-Site Scripting）脚本攻击漏洞XSS是前端谈论最多的安全问题，是通过在你的输入文本当中或者这HTML标签当中插入js脚本进行攻击，比如会在你的a标签或者img标签之前插入一些脚本文件就能攻击到你的网站，所有在用HTML去切入到div的时候一定要注意，或者长串的字符串嵌入到a标签的时候。解决办法：1：如果要使用HTML进行转换内容的时候，写代码时改为innerText而不用innerHTML，或者把<script><iframe>等标签替换掉； var HtmlUtil = { /1.用浏览器内部转换器实现html转码/ htmlEncode:function (html){ //1.首先动态创建一个容器标签元素，如DIV var temp = document.createElement (“div”); //2.然后将要转换的字符串设置为这个元素的innerText(ie支持)或者textContent(火狐，google支持) (temp.textContent != undefined ) ? (temp.textContent = html) : (temp.innerText = html); //3.最后返回这个元素的innerHTML，即得到经过HTML编码转换的字符串了 var output = temp.innerHTML; temp = null; return output; }, /2.用浏览器内部转换器实现html解码/ htmlDecode:function (text){ //1.首先动态创建一个容器标签元素，如DIV var temp = document.createElement(“div”); //2.然后将要转换的字符串设置为这个元素的innerHTML(ie，火狐，google都支持) temp.innerHTML = text; //3.最后返回这个元素的innerText(ie支持)或者textContent(火狐，google支持)，即得到经过HTML解码的字符串了。 var output = temp.innerText || temp.textContent; temp = null; return output; } };2.对一些切入标签的字符串进行转义：var HtmlUtil = { /1.用正则表达式实现html转码/ htmlEncodeByRegExp:function (str){ var s = “”; if(str.length == 0) return “”; s = str.replace(/&/g,"&"); s = s.replace(/</g,"<"); s = s.replace(/>/g,">"); s = s.replace(/ /g," "); s = s.replace(/'/g,"'"); s = s.replace(/"/g,"""); return s; }, /2.用正则表达式实现html解码/ htmlDecodeByRegExp:function (str){ var s = “”; if(str.length == 0) return “”; s = str.replace(/&/g,"&"); s = s.replace(/</g,"<"); s = s.replace(/>/g,">"); s = s.replace(/ /g," “); s = s.replace(/'/g,”'"); s = s.replace(/"/g,"""); return s; } };四、CSRF（Cross-sit request forgery）漏洞CSRF也称为跨站请求伪造，其实就是对网站中的一些表单提交行为被黑客利用。比如你的网站登录的时候存到cookie的一些个人信息，当你访问黑客的网站有一段相同代码隐藏div，但你点击的时候就会导致你的网站被登出或者被登录，就是在对别的网站就行操作的时候会对你之前访问的网站发送请求。解决办法：1.增加token验证.因为cookie发送请求的时候会自动增加上，但是token却不会，这样就避免了攻击2.Referer验证。页面来源的判断五、iframe安全隐患问题有时候前端页面为了显示别人的网站或者一些组件的时候，就用iframe来引入进来，比如嵌入一些广告等等。但是有些iframe安全性我们无法去评估测试，有时候会携带一些第三方的插件啊，或者嵌入了一下不安全的脚本啊，这些都是值得我们去考虑的。解决办法：1.使用安全的网站进行嵌入；2.在iframe添加一个叫sandbox的属性，浏览器会对iframe内容进行严格的控制，详细了解可以看看相关的API接口文档。六、本地存储数据问题很多开发者为了方便，把一些个人信息不经加密直接存到本地或者cookie，这样是非常不安全的，黑客们可以很容易就拿到用户的信息，所有在放到cookie中的信息或者localStorage里的信息要进行加密，加密可以自己定义一些加密方法或者网上寻找一些加密的插件，或者用base64进行多次加密然后再多次解码，这样就比较安全了。七、第三方依赖安全隐患现如今的项目开发，很多都喜欢用别人写好的框架，为了方便快捷，很快的就搭建起项目，自己写的代码不到20%，过多的用第三方依赖或者插件，一方面会影响性能问题，另一方面第三方的依赖或者插件存在很多安全性问题，也会存在这样那样的漏洞，所以使用起来得谨慎。解决办法：手动去检查那些依赖的安全性问题基本是不可能的，最好是利用一些自动化的工具进行扫描过后再用，比如NSP(Node Security Platform)，Snyk等等。八、HTTPS加密传输数据在浏览器对服务器访问或者请求的过程中，会经过很多的协议或者步骤，当其中的某一步被黑客拦截的时候，如果信息没有加密，就会很容易被盗取。所以接口请求以及网站部署等最好进行HTTPS加密，这样防止被人盗取数据。前端安全问题先分享到这里，后续再慢慢补充，喜欢的可以点关注，谢谢！ ...

XSS和CSRF详解与防御

开年遇到的第一个问题就是解决XSS攻击>_<,可见要时刻保证网站的安全性至关重要。做好网站安全，不仅维护网站的稳定性，更保证用户数据的一致性。对此，总结一下笔者在工作中遇到的安全问题以及防御方法。前端中常见的两种网站应用安全漏洞攻击的方式是 XSS 与 CSRF,本文详细介绍两种攻击方式的概念、原理以及防御方式。XSSXSS(Cross-site scripting)跨站脚本攻击是恶意用户在网站中注入的脚本，当正常用户打开网站时受到影响并可能获取用户cookie等信息一种安全攻击行为。常见的例子是用户进入某个网站的时候一直弹出alert框等。常见的 XSS 方式分为两类：持久性和非持久性，也有机构将其分为传统型(由服务器端代码缺陷引起)和基于 DOM 型（有客户端引起）。下面介绍三种类型：反射型反射型跨站脚本攻击最常见的方式是客户端输入查询信息，服务器端将其返回并且显示在页面上造成攻击。如直出页面，后面根据参数查询返回对应的查询信息和结果。或者用户在input输入框中进行查询等,值得注意的是，使用 innerHTML 插入 <script>alert(document.cooke)</script 并不会执行 script 中的代码，需要构造对应事件触发。如： <img src=“xxx.jpg” width=“0” height=“0” border=“0” onload=“javascript:alert(document.cookie);">存储型存储型与反射型 XSS 攻击的区别在于是否存储在数据库中，如用户写博客和评论等，这种方式的影响是持久的。基于 DOM恶意用户构造的脚本并不会经过服务器端，完全发生在客服端，如通过链接（?userName=<img onload=“javascript:alert(document.cookie)”/>）的查询参数来显示用户名等。针对 XSS 攻击，经常有以下两个方式来进行防御：设置重要的cookie信息为 httpOnly 对于重要的 cookie字段，如：可以通过 cookie 某个字段和某个接口获取好友关系的，需要将其设置为 httpOnly,使得恶意用户无法获取。对输入进行检测和转义对用户输入的或者从链接获取参数需要展示到页面中需要校验合法性和使用转义函数进行转义，如常见的函数如下：function escHTML(str) { if (!str) return ‘’; return str.replace(/&/g, ‘&’) .replace(/</g, ‘<’) .replace(/>/g, ‘>’) .replace(/x27/g, ‘'’) .replace(/x22/g,’&quto;’);}CSRFCSRF(Cross-site request forgery)是一种攻击，迫使用户在受信任网站上执行不需要的一些操作。具体过程如下：用户向信任站点如example.com发送请求用户验证通过、获得信任站点的身份信息，并放入cookie中，用户此时可以在站内进行其他请求;用户未退出登录example.com,然后访问hack.com网站，该网站返回攻击性代码并且在页面中存在访问example.com的请求;浏览器在用户可能不知情的情况下向example.com发送请求;由于同域名可以带上cookie信息，因此信息认证通过，请求伪造成。针对 CSRF 攻击，常用的防御方式如下：检测请求来源在请求头中有一个refree字段，refree记录了发送请求的域名，比如：hack.com向example.com中发送请求，那么refree就为hack.com，只要在处理请求中做相应的校验就可以中断请求。加入token校验 crsf之所以能够伪造请求成功，其原因之一在于所有的用户信息放于cookie中；因此可以在每次请求中加入token，然后后台进行校验，如果校验通过则进行处理。生成token方式之一如下：function getToken (token) { var str = token || ‘’; var hash = 5381; for (var i = 0, len = str.length; i < len; ++i) { hash += (hash << 5) + str.charCodeAt(i); } return hash & 0x7fffffff;}具体攻击示例点击查看 ...

前端安全系列之二：如何防止CSRF攻击？

背景随着互联网的高速发展，信息安全问题已经成为企业最为关注的焦点之一，而前端又是引发企业安全问题的高危据点。在移动互联网时代，前端人员除了传统的 XSS、CSRF 等安全问题之外，又时常遭遇网络劫持、非法调用 Hybrid API 等新型安全问题。当然，浏览器自身也在不断在进化和发展，不断引入 CSP、Same-Site Cookies 等新技术来增强安全性，但是仍存在很多潜在的威胁，这需要前端技术人员不断进行“查漏补缺”。前端安全近几年，美团业务高速发展，前端随之面临很多安全挑战，因此积累了大量的实践经验。我们梳理了常见的前端安全问题以及对应的解决方案，将会做成一个系列，希望可以帮助前端同学在日常开发中不断预防和修复安全漏洞。本文是该系列的第二篇。今天我们讲解一下 CSRF，其实相比XSS，CSRF的名气似乎并不是那么大，很多人都认为“CSRF不具备那么大的破坏性”。真的是这样吗？接下来，我们还是有请小明同学再次“闪亮”登场。CSRF攻击CSRF漏洞的发生相比XSS，CSRF的名气似乎并不是那么大，很多人都认为CSRF“不那么有破坏性”。真的是这样吗？接下来有请小明出场~~小明的悲惨遭遇这一天，小明同学百无聊赖地刷着Gmail邮件。大部分都是没营养的通知、验证码、聊天记录之类。但有一封邮件引起了小明的注意：甩卖比特币，一个只要998！！聪明的小明当然知道这种肯定是骗子，但还是抱着好奇的态度点了进去（请勿模仿）。果然，这只是一个什么都没有的空白页面，小明失望的关闭了页面。一切似乎什么都没有发生……在这平静的外表之下，黑客的攻击已然得手。小明的Gmail中，被偷偷设置了一个过滤规则，这个规则使得所有的邮件都会被自动转发到haker@hackermail.com。小明还在继续刷着邮件，殊不知他的邮件正在一封封地，如脱缰的野马一般地，持续不断地向着黑客的邮箱转发而去。不久之后的一天，小明发现自己的域名已经被转让了。懵懂的小明以为是域名到期自己忘了续费，直到有一天，对方开出了 $650 的赎回价码，小明才开始觉得不太对劲。小明仔细查了下域名的转让，对方是拥有自己的验证码的，而域名的验证码只存在于自己的邮箱里面。小明回想起那天奇怪的链接，打开后重新查看了“空白页”的源码：<form method=“POST” action=“https://mail.google.com/mail/h/ewt1jmuj4ddv/?v=prf" enctype=“multipart/form-data”> <input type=“hidden” name=“cf2_emc” value=“true”/> <input type=“hidden” name=“cf2_email” value=“hacker@hakermail.com”/> ….. <input type=“hidden” name=“irf” value=“on”/> <input type=“hidden” name=“nvp_bu_cftb” value=“Create Filter”/> </form> <script> document.forms[0].submit();</script>这个页面只要打开，就会向Gmail发送一个post请求。请求中，执行了“Create Filter”命令，将所有的邮件，转发到“hacker@hakermail.com”。小明由于刚刚就登陆了Gmail，所以这个请求发送时，携带着小明的登录凭证（Cookie），Gmail的后台接收到请求，验证了确实有小明的登录凭证，于是成功给小明配置了过滤器。黑客可以查看小明的所有邮件，包括邮件里的域名验证码等隐私信息。拿到验证码之后，黑客就可以要求域名服务商把域名重置给自己。小明很快打开Gmail，找到了那条过滤器，将其删除。然而，已经泄露的邮件，已经被转让的域名，再也无法挽回了……以上就是小明的悲惨遭遇。而“点开一个黑客的链接，所有邮件都被窃取”这种事情并不是杜撰的，此事件原型是2007年Gmail的CSRF漏洞：https://www.davidairey.com/google-Gmail-security-hijack/当然，目前此漏洞已被Gmail修复，请使用Gmail的同学不要慌张。什么是CSRFCSRF（Cross-site request forgery）跨站请求伪造：攻击者诱导受害者进入第三方网站，在第三方网站中，向被攻击网站发送跨站请求。利用受害者在被攻击网站已经获取的注册凭证，绕过后台的用户验证，达到冒充用户对被攻击的网站执行某项操作的目的。一个典型的CSRF攻击有着如下的流程：受害者登录a.com，并保留了登录凭证（Cookie）。攻击者引诱受害者访问了b.com。b.com 向 a.com 发送了一个请求：a.com/act=xx。浏览器会默认携带a.com的Cookie。a.com接收到请求后，对请求进行验证，并确认是受害者的凭证，误以为是受害者自己发送的请求。a.com以受害者的名义执行了act=xx。攻击完成，攻击者在受害者不知情的情况下，冒充受害者，让a.com执行了自己定义的操作。几种常见的攻击类型GET类型的CSRFGET类型的CSRF利用非常简单，只需要一个HTTP请求，一般会这样利用： <img src=“http://bank.example/withdraw?amount=10000&for=hacker" > 在受害者访问含有这个img的页面后，浏览器会自动向http://bank.example/withdraw?account=xiaoming&amount=10000&for=hacker发出一次HTTP请求。bank.example就会收到包含受害者登录信息的一次跨域请求。POST类型的CSRF这种类型的CSRF利用起来通常使用的是一个自动提交的表单，如： <form action=“http://bank.example/withdraw" method=POST> <input type=“hidden” name=“account” value=“xiaoming” /> <input type=“hidden” name=“amount” value=“10000” /> <input type=“hidden” name=“for” value=“hacker” /></form><script> document.forms[0].submit(); </script> 访问该页面后，表单会自动提交，相当于模拟用户完成了一次POST操作。POST类型的攻击通常比GET要求更加严格一点，但仍并不复杂。任何个人网站、博客，被黑客上传页面的网站都有可能是发起攻击的来源，后端接口不能将安全寄托在仅允许POST上面。链接类型的CSRF链接类型的CSRF并不常见，比起其他两种用户打开页面就中招的情况，这种需要用户点击链接才会触发。这种类型通常是在论坛中发布的图片中嵌入恶意链接，或者以广告的形式诱导用户中招，攻击者通常会以比较夸张的词语诱骗用户点击，例如： <a href=“http://test.com/csrf/withdraw.php?amount=1000&for=hacker" taget="_blank”> 重磅消息！！ <a/>由于之前用户登录了信任的网站A，并且保存登录状态，只要用户主动访问上面的这个PHP页面，则表示攻击成功。CSRF的特点攻击一般发起在第三方网站，而不是被攻击的网站。被攻击的网站无法防止攻击发生。攻击利用受害者在被攻击网站的登录凭证，冒充受害者提交操作；而不是直接窃取数据。整个过程攻击者并不能获取到受害者的登录凭证，仅仅是“冒用”。跨站请求可以用各种方式：图片URL、超链接、CORS、Form提交等等。部分请求方式可以直接嵌入在第三方论坛、文章中，难以进行追踪。CSRF通常是跨域的，因为外域通常更容易被攻击者掌控。但是如果本域下有容易被利用的功能，比如可以发图和链接的论坛和评论区，攻击可以直接在本域下进行，而且这种攻击更加危险。防护策略CSRF通常从第三方网站发起，被攻击的网站无法防止攻击发生，只能通过增强自己网站针对CSRF的防护能力来提升安全性。上文中讲了CSRF的两个特点：CSRF（通常）发生在第三方域名。CSRF攻击者不能获取到Cookie等信息，只是使用。针对这两点，我们可以专门制定防护策略，如下：阻止不明外域的访问同源检测Samesite Cookie提交时要求附加本域才能获取的信息CSRF Token双重Cookie验证以下我们对各种防护方法做详细说明：同源检测既然CSRF大多来自第三方网站，那么我们就直接禁止外域（或者不受信任的域名）对我们发起请求。那么问题来了，我们如何判断请求是否来自外域呢？在HTTP协议中，每一个异步请求都会携带两个Header，用于标记来源域名：Origin HeaderReferer Header这两个Header在浏览器发起请求时，大多数情况会自动带上，并且不能由前端自定义内容。服务器可以通过解析这两个Header中的域名，确定请求的来源域。使用Origin Header确定来源域名在部分与CSRF有关的请求中，请求的Header中会携带Origin字段。字段内包含请求的域名（不包含path及query）。如果Origin存在，那么直接使用Origin中的字段确认来源域名就可以。但是Origin在以下两种情况下并不存在：IE11同源策略： IE 11 不会在跨站CORS请求上添加Origin标头，Referer头将仍然是唯一的标识。最根本原因是因为IE 11对同源的定义和其他浏览器有不同，有两个主要的区别，可以参考MDN Same-origin_policy#IE_Exceptions302重定向：在302重定向之后Origin不包含在重定向的请求中，因为Origin可能会被认为是其他来源的敏感信息。对于302重定向的情况来说都是定向到新的服务器上的URL，因此浏览器不想将Origin泄漏到新的服务器上。使用Referer Header确定来源域名根据HTTP协议，在HTTP头中有一个字段叫Referer，记录了该HTTP请求的来源地址。对于Ajax请求，图片和script等资源请求，Referer为发起请求的页面地址。对于页面跳转，Referer为打开页面历史记录的前一个页面地址。因此我们使用Referer中链接的Origin部分可以得知请求的来源域名。这种方法并非万无一失，Referer的值是由浏览器提供的，虽然HTTP协议上有明确的要求，但是每个浏览器对于Referer的具体实现可能有差别，并不能保证浏览器自身没有安全漏洞。使用验证 Referer 值的方法，就是把安全性都依赖于第三方（即浏览器）来保障，从理论上来讲，这样并不是很安全。在部分情况下，攻击者可以隐藏，甚至修改自己请求的Referer。2014年，W3C的Web应用安全工作组发布了Referrer Policy草案，对浏览器该如何发送Referer做了详细的规定。截止现在新版浏览器大部分已经支持了这份草案，我们终于可以灵活地控制自己网站的Referer策略了。新版的Referrer Policy规定了五种Referer策略：No Referrer、No Referrer When Downgrade、Origin Only、Origin When Cross-origin、和 Unsafe URL。之前就存在的三种策略：never、default和always，在新标准里换了个名称。他们的对应关系如下：策略名称属性值（新）属性值（旧）No Referrerno-ReferrerneverNo Referrer When Downgradeno-Referrer-when-downgradedefaultOrigin Only(same or strict) originoriginOrigin When Cross Origin(strict) origin-when-crossorigin-Unsafe URLunsafe-urlalways根据上面的表格因此需要把Referrer Policy的策略设置成same-origin，对于同源的链接和引用，会发送Referer，referer值为Host不带Path；跨域访问则不携带Referer。例如：aaa.com引用bbb.com的资源，不会发送Referer。设置Referrer Policy的方法有三种：在CSP设置页面头部增加meta标签a标签增加referrerpolicy属性上面说的这些比较多，但我们可以知道一个问题：攻击者可以在自己的请求中隐藏Referer。如果攻击者将自己的请求这样填写： <img src=“http://bank.example/withdraw?amount=10000&for=hacker" referrerpolicy=“no-referrer”> 那么这个请求发起的攻击将不携带Referer。另外在以下情况下Referer没有或者不可信：1.IE6、7下使用window.location.href=url进行界面的跳转，会丢失Referer。2.IE6、7下使用window.open，也会缺失Referer。3.HTTPS页面跳转到HTTP页面，所有浏览器Referer都丢失。4.点击Flash上到达另外一个网站的时候，Referer的情况就比较杂乱，不太可信。无法确认来源域名情况当Origin和Referer头文件不存在时该怎么办？如果Origin和Referer都不存在，建议直接进行阻止，特别是如果您没有使用随机CSRF Token（参考下方）作为第二次检查。如何阻止外域请求通过Header的验证，我们可以知道发起请求的来源域名，这些来源域名可能是网站本域，或者子域名，或者有授权的第三方域名，又或者来自不可信的未知域名。我们已经知道了请求域名是否是来自不可信的域名，我们直接阻止掉这些的请求，就能防御CSRF攻击了吗？且慢！当一个请求是页面请求（比如网站的主页），而来源是搜索引擎的链接（例如百度的搜索结果），也会被当成疑似CSRF攻击。所以在判断的时候需要过滤掉页面请求情况，通常Header符合以下情况：Accept: text/htmlMethod: GET但相应的，页面请求就暴露在了CSRF的攻击范围之中。如果你的网站中，在页面的GET请求中对当前用户做了什么操作的话，防范就失效了。例如，下面的页面请求：GET https://example.com/addComment?comment=XXX&dest=orderId注：这种严格来说并不一定存在CSRF攻击的风险，但仍然有很多网站经常把主文档GET请求挂上参数来实现产品功能，但是这样做对于自身来说是存在安全风险的。另外，前面说过，CSRF大多数情况下来自第三方域名，但并不能排除本域发起。如果攻击者有权限在本域发布评论（含链接、图片等，统称UGC），那么它可以直接在本域发起攻击，这种情况下同源策略无法达到防护的作用。综上所述：同源验证是一个相对简单的防范方法，能够防范绝大多数的CSRF攻击。但这并不是万无一失的，对于安全性要求较高，或者有较多用户输入内容的网站，我们就要对关键的接口做额外的防护措施。CSRF Token前面讲到CSRF的另一个特征是，攻击者无法直接窃取到用户的信息（Cookie，Header，网站内容等），仅仅是冒用Cookie中的信息。而CSRF攻击之所以能够成功，是因为服务器误把攻击者发送的请求当成了用户自己的请求。那么我们可以要求所有的用户请求都携带一个CSRF攻击者无法获取到的Token。服务器通过校验请求是否携带正确的Token，来把正常的请求和攻击的请求区分开，也可以防范CSRF的攻击。原理CSRF Token的防护策略分为三个步骤：1.将CSRF Token输出到页面中首先，用户打开页面的时候，服务器需要给这个用户生成一个Token，该Token通过加密算法对数据进行加密，一般Token都包括随机字符串和时间戳的组合，显然在提交时Token不能再放在Cookie中了，否则又会被攻击者冒用。因此，为了安全起见Token最好还是存在服务器的Session中，之后在每次页面加载时，使用JS遍历整个DOM树，对于DOM中所有的a和form标签后加入Token。这样可以解决大部分的请求，但是对于在页面加载之后动态生成的HTML代码，这种方法就没有作用，还需要程序员在编码时手动添加Token。2.页面提交的请求携带这个Token对于GET请求，Token将附在请求地址之后，这样URL 就变成 http://url?csrftoken=tokenvalue。而对于 POST 请求来说，要在 form 的最后加上： <input type=”hidden” name=”csrftoken” value=”tokenvalue”/>这样，就把Token以参数的形式加入请求了。3.服务器验证Token是否正确当用户从客户端得到了Token，再次提交给服务器的时候，服务器需要判断Token的有效性，验证过程是先解密Token，对比加密字符串以及时间戳，如果加密字符串一致且时间未过期，那么这个Token就是有效的。这种方法要比之前检查Referer或者Origin要安全一些，Token可以在产生并放于Session之中，然后在每次请求时把Token从Session中拿出，与请求中的Token进行比对，但这种方法的比较麻烦的在于如何把Token以参数的形式加入请求。下面将以Java为例，介绍一些CSRF Token的服务端校验逻辑，代码如下：HttpServletRequest req = (HttpServletRequest)request; HttpSession s = req.getSession(); // 从 session 中得到 csrftoken 属性String sToken = (String)s.getAttribute(“csrftoken”); if(sToken == null){ // 产生新的 token 放入 session 中 sToken = generateToken(); s.setAttribute(“csrftoken”,sToken); chain.doFilter(request, response); } else{ // 从 HTTP 头中取得 csrftoken String xhrToken = req.getHeader(“csrftoken”); // 从请求参数中取得 csrftoken String pToken = req.getParameter(“csrftoken”); if(sToken != null && xhrToken != null && sToken.equals(xhrToken)){ chain.doFilter(request, response); }else if(sToken != null && pToken != null && sToken.equals(pToken)){ chain.doFilter(request, response); }else{ request.getRequestDispatcher(“error.jsp”).forward(request,response); } }代码源自IBM developerworks CSRF这个Token的值必须是随机生成的，这样它就不会被攻击者猜到，考虑利用Java应用程序的java.security.SecureRandom类来生成足够长的随机标记，替代生成算法包括使用256位BASE64编码哈希，选择这种生成算法的开发人员必须确保在散列数据中使用随机性和唯一性来生成随机标识。通常，开发人员只需为当前会话生成一次Token。在初始生成此Token之后，该值将存储在会话中，并用于每个后续请求，直到会话过期。当最终用户发出请求时，服务器端必须验证请求中Token的存在性和有效性，与会话中找到的Token相比较。如果在请求中找不到Token，或者提供的值与会话中的值不匹配，则应中止请求，应重置Token并将事件记录为正在进行的潜在CSRF攻击。分布式校验在大型网站中，使用Session存储CSRF Token会带来很大的压力。访问单台服务器session是同一个。但是现在的大型网站中，我们的服务器通常不止一台，可能是几十台甚至几百台之多，甚至多个机房都可能在不同的省份，用户发起的HTTP请求通常要经过像Ngnix之类的负载均衡器之后，再路由到具体的服务器上，由于Session默认存储在单机服务器内存中，因此在分布式环境下同一个用户发送的多次HTTP请求可能会先后落到不同的服务器上，导致后面发起的HTTP请求无法拿到之前的HTTP请求存储在服务器中的Session数据，从而使得Session机制在分布式环境下失效，因此在分布式集群中CSRF Token需要存储在Redis之类的公共存储空间。由于使用Session存储，读取和验证CSRF Token会引起比较大的复杂度和性能问题，目前很多网站采用Encrypted Token Pattern方式。这种方法的Token是一个计算出来的结果，而非随机生成的字符串。这样在校验时无需再去读取存储的Token，只用再次计算一次即可。这种Token的值通常是使用UserID、时间戳和随机数，通过加密的方法生成。这样既可以保证分布式服务的Token一致，又能保证Token不容易被破解。在token解密成功之后，服务器可以访问解析值，Token中包含的UserID和时间戳将会被拿来被验证有效性，将UserID与当前登录的UserID进行比较，并将时间戳与当前时间进行比较。总结Token是一个比较有效的CSRF防护方法，只要页面没有XSS漏洞泄露Token，那么接口的CSRF攻击就无法成功。但是此方法的实现比较复杂，需要给每一个页面都写入Token（前端无法使用纯静态页面），每一个Form及Ajax请求都携带这个Token，后端对每一个接口都进行校验，并保证页面Token及请求Token一致。这就使得这个防护策略不能在通用的拦截上统一拦截处理，而需要每一个页面和接口都添加对应的输出和校验。这种方法工作量巨大，且有可能遗漏。验证码和密码其实也可以起到CSRF Token的作用哦，而且更安全。为什么很多银行等网站会要求已经登录的用户在转账时再次输入密码，现在是不是有一定道理了？双重Cookie验证在会话中存储CSRF Token比较繁琐，而且不能在通用的拦截上统一处理所有的接口。那么另一种防御措施是使用双重提交Cookie。利用CSRF攻击不能获取到用户Cookie的特点，我们可以要求Ajax和表单请求携带一个Cookie中的值。双重Cookie采用以下流程：在用户访问网站页面时，向请求域名注入一个Cookie，内容为随机字符串（例如csrfcookie=v8g9e4ksfhw）。在前端向后端发起请求时，取出Cookie，并添加到URL的参数中（接上例POST https://www.a.com/comment?csrfcookie=v8g9e4ksfhw）。后端接口验证Cookie中的字段与URL参数中的字段是否一致，不一致则拒绝。此方法相对于CSRF Token就简单了许多。可以直接通过前后端拦截的的方法自动化实现。后端校验也更加方便，只需进行请求中字段的对比，而不需要再进行查询和存储Token。当然，此方法并没有大规模应用，其在大型网站上的安全性还是没有CSRF Token高，原因我们举例进行说明。由于任何跨域都会导致前端无法获取Cookie中的字段（包括子域名之间），于是发生了如下情况：如果用户访问的网站为www.a.com，而后端的api域名为api.a.com。那么在www.a.com下，前端拿不到api.a.com的Cookie，也就无法完成双重Cookie认证。于是这个认证Cookie必须被种在a.com下，这样每个子域都可以访问。任何一个子域都可以修改a.com下的Cookie。某个子域名存在漏洞被XSS攻击（例如upload.a.com）。虽然这个子域下并没有什么值得窃取的信息。但攻击者修改了a.com下的Cookie。攻击者可以直接使用自己配置的Cookie，对XSS中招的用户再向www.a.com下，发起CSRF攻击。总结用双重Cookie防御CSRF的优点：无需使用Session，适用面更广，易于实施。Token储存于客户端中，不会给服务器带来压力。相对于Token，实施成本更低，可以在前后端统一拦截校验，而不需要一个个接口和页面添加。缺点：Cookie中增加了额外的字段。如果有其他漏洞（例如XSS），攻击者可以注入Cookie，那么该防御方式失效。难以做到子域名的隔离。为了确保Cookie传输安全，采用这种防御方式的最好确保用整站HTTPS的方式，如果还没切HTTPS的使用这种方式也会有风险。Samesite Cookie属性防止CSRF攻击的办法已经有上面的预防措施。为了从源头上解决这个问题，Google起草了一份草案来改进HTTP协议，那就是为Set-Cookie响应头新增Samesite属性，它用来标明这个 Cookie是个“同站 Cookie”，同站Cookie只能作为第一方Cookie，不能作为第三方Cookie，Samesite 有两个属性值，分别是 Strict 和 Lax，下面分别讲解：Samesite=Strict这种称为严格模式，表明这个 Cookie 在任何情况下都不可能作为第三方 Cookie，绝无例外。比如说 b.com 设置了如下 Cookie：Set-Cookie: foo=1; Samesite=StrictSet-Cookie: bar=2; Samesite=LaxSet-Cookie: baz=3我们在 a.com 下发起对 b.com 的任意请求，foo 这个 Cookie 都不会被包含在 Cookie 请求头中，但 bar 会。举个实际的例子就是，假如淘宝网站用来识别用户登录与否的 Cookie 被设置成了 Samesite=Strict，那么用户从百度搜索页面甚至天猫页面的链接点击进入淘宝后，淘宝都不会是登录状态，因为淘宝的服务器不会接受到那个 Cookie，其它网站发起的对淘宝的任意请求都不会带上那个 Cookie。Samesite=Lax这种称为宽松模式，比 Strict 放宽了点限制：假如这个请求是这种请求（改变了当前页面或者打开了新页面）且同时是个GET请求，则这个Cookie可以作为第三方Cookie。比如说 b.com设置了如下Cookie：Set-Cookie: foo=1; Samesite=StrictSet-Cookie: bar=2; Samesite=LaxSet-Cookie: baz=3当用户从 a.com 点击链接进入 b.com 时，foo 这个 Cookie 不会被包含在 Cookie 请求头中，但 bar 和 baz 会，也就是说用户在不同网站之间通过链接跳转是不受影响了。但假如这个请求是从 a.com 发起的对 b.com 的异步请求，或者页面跳转是通过表单的 post 提交触发的，则bar也不会发送。生成Token放到Cookie中并且设置Cookie的Samesite，Java代码如下： private void addTokenCookieAndHeader(HttpServletRequest httpRequest, HttpServletResponse httpResponse) { //生成token String sToken = this.generateToken(); //手动添加Cookie实现支持“Samesite=strict” //Cookie添加双重验证 String CookieSpec = String.format("%s=%s; Path=%s; HttpOnly; Samesite=Strict”, this.determineCookieName(httpRequest), sToken, httpRequest.getRequestURI()); httpResponse.addHeader(“Set-Cookie”, CookieSpec); httpResponse.setHeader(CSRF_TOKEN_NAME, token); }代码源自OWASP Cross-Site_Request_Forgery #Implementation example我们应该如何使用SamesiteCookie如果SamesiteCookie被设置为Strict，浏览器在任何跨域请求中都不会携带Cookie，新标签重新打开也不携带，所以说CSRF攻击基本没有机会。但是跳转子域名或者是新标签重新打开刚登陆的网站，之前的Cookie都不会存在。尤其是有登录的网站，那么我们新打开一个标签进入，或者跳转到子域名的网站，都需要重新登录。对于用户来讲，可能体验不会很好。如果SamesiteCookie被设置为Lax，那么其他网站通过页面跳转过来的时候可以使用Cookie，可以保障外域连接打开页面时用户的登录状态。但相应的，其安全性也比较低。另外一个问题是Samesite的兼容性不是很好，现阶段除了从新版Chrome和Firefox支持以外，Safari以及iOS Safari都还不支持，现阶段看来暂时还不能普及。而且，SamesiteCookie目前有一个致命的缺陷：不支持子域。例如，种在topic.a.com下的Cookie，并不能使用a.com下种植的SamesiteCookie。这就导致了当我们网站有多个子域名时，不能使用SamesiteCookie在主域名存储用户登录信息。每个子域名都需要用户重新登录一次。总之，SamesiteCookie是一个可能替代同源验证的方案，但目前还并不成熟，其应用场景有待观望。防止网站被利用前面所说的，都是被攻击的网站如何做好防护。而非防止攻击的发生，CSRF的攻击可以来自：攻击者自己的网站。有文件上传漏洞的网站。第三方论坛等用户内容。被攻击网站自己的评论功能等。对于来自黑客自己的网站，我们无法防护。但对其他情况，那么如何防止自己的网站被利用成为攻击的源头呢？严格管理所有的上传接口，防止任何预期之外的上传内容（例如HTML）。添加Header X-Content-Type-Options: nosniff 防止黑客上传HTML内容的资源（例如图片）被解析为网页。对于用户上传的图片，进行转存或者校验。不要直接使用用户填写的图片链接。当前用户打开其他用户填写的链接时，需告知风险（这也是很多论坛不允许直接在内容中发布外域链接的原因之一，不仅仅是为了用户留存，也有安全考虑）。CSRF其他防范措施对于一线的程序员同学，我们可以通过各种防护策略来防御CSRF，对于QA、SRE、安全负责人等同学，我们可以做哪些事情来提升安全性呢？CSRF测试CSRFTester是一款CSRF漏洞的测试工具，CSRFTester工具的测试原理大概是这样的，使用代理抓取我们在浏览器中访问过的所有的连接以及所有的表单等信息，通过在CSRFTester中修改相应的表单等信息，重新提交，相当于一次伪造客户端请求，如果修改后的测试请求成功被网站服务器接受，则说明存在CSRF漏洞，当然此款工具也可以被用来进行CSRF攻击。CSRFTester使用方法大致分下面几个步骤：步骤1：设置浏览器代理CSRFTester默认使用Localhost上的端口8008作为其代理，如果代理配置成功，CSRFTester将为您的浏览器生成的所有后续HTTP请求生成调试消息。步骤2：使用合法账户访问网站开始测试我们需要找到一个我们想要为CSRF测试的特定业务Web页面。找到此页面后，选择CSRFTester中的“开始录制”按钮并执行业务功能；完成后，点击CSRFTester中的“停止录制”按钮；正常情况下，该软件会全部遍历一遍当前页面的所有请求。步骤3：通过CSRF修改并伪造请求之后，我们会发现软件上有一系列跑出来的记录请求，这些都是我们的浏览器在执行业务功能时生成的所有GET或者POST请求。通过选择列表中的某一行，我们现在可以修改用于执行业务功能的参数，可以通过点击对应的请求修改query和form的参数。当修改完所有我们希望诱导用户form最终的提交值，可以选择开始生成HTML报告。步骤4：拿到结果如有漏洞进行修复首先必须选择“报告类型”。报告类型决定了我们希望受害者浏览器如何提交先前记录的请求。目前有5种可能的报告：表单、iFrame、IMG、XHR和链接。一旦选择了报告类型，我们可以选择在浏览器中启动新生成的报告，最后根据报告的情况进行对应的排查和修复。CSRF监控对于一个比较复杂的网站系统，某些项目、页面、接口漏掉了CSRF防护措施是很可能的。一旦发生了CSRF攻击，我们如何及时的发现这些攻击呢？CSRF攻击有着比较明显的特征：跨域请求。GET类型请求Header的MIME类型大概率为图片，而实际返回Header的MIME类型为Text、JSON、HTML。我们可以在网站的代理层监控所有的接口请求，如果请求符合上面的特征，就可以认为请求有CSRF攻击嫌疑。我们可以提醒对应的页面和项目负责人，检查或者 Review其CSRF防护策略。个人用户CSRF安全的建议经常上网的个人用户，可以采用以下方法来保护自己：使用网页版邮件的浏览邮件或者新闻也会带来额外的风险，因为查看邮件或者新闻消息有可能导致恶意代码的攻击。尽量不要打开可疑的链接，一定要打开时，使用不常用的浏览器。总结简单总结一下上文的防护策略：CSRF自动防御策略：同源检测（Origin 和 Referer 验证）。CSRF主动防御措施：Token验证或者双重Cookie验证以及配合Samesite Cookie。保证页面的幂等性，后端接口不要在GET页面中做用户操作。为了更好的防御CSRF，最佳实践应该是结合上面总结的防御措施方式中的优缺点来综合考虑，结合当前Web应用程序自身的情况做合适的选择，才能更好的预防CSRF的发生。历史案例WordPress的CSRF漏洞2012年3月份，WordPress发现了一个CSRF漏洞，影响了WordPress 3.3.1版本，WordPress是众所周知的博客平台，该漏洞可以允许攻击者修改某个Post的标题，添加管理权限用户以及操作用户账户，包括但不限于删除评论、修改头像等等。具体的列表如下:Add Admin/UserDelete Admin/UserApprove commentUnapprove commentDelete commentChange background imageInsert custom header imageChange site titleChange administrator’s emailChange Wordpress AddressChange Site Address那么这个漏洞实际上就是攻击者引导用户先进入目标的WordPress，然后点击其钓鱼站点上的某个按钮，该按钮实际上是表单提交按钮，其会触发表单的提交工作，添加某个具有管理员权限的用户，实现的码如下：<html> <body onload=“javascript:document.forms[0].submit()"> <H2>CSRF Exploit to add Administrator</H2> <form method=“POST” name=“form0” action=“http://<wordpress_ip>:80/wp-admin/user-new.php”> <input type=“hidden” name=“action” value=“createuser”/> <input type=“hidden” name="_wpnonce_create-user” value="<sniffed_value>”/> <input type=“hidden” name="wp_http_referer” value="%2Fwordpress%2Fwp-admin%2Fuser-new.php”/> <input type=“hidden” name=“user_login” value=“admin2”/> <input type=“hidden” name=“email” value=“admin2@admin.com”/> <input type=“hidden” name=“first_name” value=“admin2@admin.com”/> <input type=“hidden” name=“last_name” value=""/> <input type=“hidden” name=“url” value=""/> <input type=“hidden” name=“pass1” value=“password”/> <input type=“hidden” name=“pass2” value=“password”/> <input type=“hidden” name=“role” value=“administrator”/> <input type=“hidden” name=“createuser” value=“Add+New+User+”/> </form> </body> </html> YouTube的CSRF漏洞2008年，有安全研究人员发现，YouTube上几乎所有用户可以操作的动作都存在CSRF漏洞。如果攻击者已经将视频添加到用户的“Favorites”，那么他就能将他自己添加到用户的“Friend”或者“Family”列表，以用户的身份发送任意的消息，将视频标记为不宜的，自动通过用户的联系人来共享一个视频。例如，要把视频添加到用户的“Favorites”，攻击者只需在任何站点上嵌入如下所示的IMG标签：<img src=“http://youtube.com/watch_ajax?action_add_favorite_playlist=1&video_id=[VIDEO ID]&playlist_id=&add_to_favorite=1&show=1&button=AddvideoasFavorite”/>攻击者也许已经利用了该漏洞来提高视频的流行度。例如，将一个视频添加到足够多用户的“Favorites”，YouTube就会把该视频作为“Top Favorites”来显示。除提高一个视频的流行度之外，攻击者还可以导致用户在毫不知情的情况下将一个视频标记为“不宜的”，从而导致YouTube删除该视频。这些攻击还可能已被用于侵犯用户隐私。YouTube允许用户只让朋友或亲属观看某些视频。这些攻击会导致攻击者将其添加为一个用户的“Friend”或“Family”列表，这样他们就能够访问所有原本只限于好友和亲属表中的用户观看的私人的视频。攻击者还可以通过用户的所有联系人名单（“Friends”、“Family”等等）来共享一个视频，“共享”就意味着发送一个视频的链接给他们，当然还可以选择附加消息。这条消息中的链接已经并不是真正意义上的视频链接，而是一个具有攻击性的网站链接，用户很有可能会点击这个链接，这便使得该种攻击能够进行病毒式的传播。参考文献Mozilla wiki.Security-OriginOWASP.Cross-Site_Request_Forgery(CSRF)_Prevention_Cheat_Sheet_Prevention_Cheat_Sheet).Gmail Security Hijack Case.Google-Gmail-Security-Hijack.Netsparker Blog.Same-Site-Cookie-Attribute-Prevent-Cross-site-Request-ForgeryMDN.Same-origin_policy#IE_Exceptions下期预告前端安全系列文章将对XSS、CSRF、网络劫持、Hybrid安全等安全议题展开论述。下期我们要讨论的是网络劫持，敬请期待。作者简介刘烨，美团点评前端开发工程师，负责外卖用户端前端业务。 ...