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 则能够拿到钱后绳之以法。 ...