本文目录一览：
如何在JSON端点上利用CSRF漏洞
可以安装一个电脑管家在电脑上
然后打开工具箱，在里面找到修复漏洞功能
使用这个功能，去修复电脑所有检测出的高危漏洞即可
CSRF 攻击是什么
说明: 本文大部分借鉴 wiki-跨站请求伪造 , 另一部分来自文章 wiki-Cross-Site Request Forgery
csrf 全称 Cross-site request forgery, 通常缩写为CSRF 或者 XSRF, 中文名跨站请求伪造. 是一种挟制用户在当前已登录的Web应用程序上执行非本意的操作的攻击方法。 . CSRF 攻击手段是通过发起改变状态的请求, 而不是窃取用户的数据, 因为攻击者无法得到服务器返回的响应
攻击者通过一些技术手段欺骗用户的浏览器去访问一个自己曾经认证过的网站并执行一些操作（如发邮件，发消息，甚至财产操作如转账和购买商品）。由于浏览器曾经认证过，所以被访问的网站会认为是真正的用户操作而去执行。这利用了web中用户身份验证的一个漏洞： 简单的身份验证只能保证请求发自某个用户的浏览器，却不能保证请求本身是用户自愿发出的。 补充: 还可能更改账号所绑定的邮箱地址或者密码等.
假如 Alice 在 bank.com 向 Bob 汇款 10000, 那么攻击将会由以下两步骤组成:
如果 bank.com 把查询参数放到 URL 中, 那么 Alice 向 Bob 转账的操作可以简化为如下:
GET ;amount=100 HTTP/1.1
Maria 根据 bank.com 网站请求的结构, 将 Bob 名字替换为她自己的, 还把金额变大:
;amount=100000
那么这个充满恶意的 URL ,被 Maria 放到 a 标签中, 并且利用欺骗语言吸引 Alice 点击:
a href=";amount=100000"View my Pictures!/a
或者放到一个 长度和宽度都为0 的图片的src 中(图片不用用户点击, 自己就发起请求):
img src=";amount=100000" width="0" height="0" border="0"
如果这张图片放到邮件中, Alice 根本就不会发现什么. 然而浏览器还是会将请求提交到 bank.com 的后台中.
一个真实的事件是发生在2008 年的 uTorrent exploit
假设 bank.com 现在使用 post 请求来传递参数的, 那么这个请求可以简化为:
这种情况下, a 标签和 img 标签都无法发送 post 请求, 但是可以使用 FORM 来完成:
我们还可以利用 JavaScript 来让文档载入的时候就发送这个请求:
假设现在银行使用的是 PUT 将数据放到一个JSON 中发送到后台中:
那么我们可以利用内嵌的 JavaScript :
幸运的是这段 PUT 请求并不会发送, 因为 同源策略 的限制. 除非你的后台设置了
不论是 GET 请求还是 POST 请求, 如果有账户名为Alice的用户访问了恶意站点，而她之前刚访问过银行不久，登录信息尚未过期，那么她就会损失10000资金。
这种恶意的网址可以有很多种形式，藏身于网页中的许多地方。此外，攻击者也不需要控制放置恶意网址的网站。例如他可以将这种地址藏在论坛，博客等任何用户生成内容的网站中。这意味着 如果服务器端没有合适的防御措施的话，用户即使访问熟悉的可信网站也有受攻击的危险。
CSRF实例
CSRF攻击的主要目的是让用户在不知情的情况下攻击自己已登录的一个系统，类似于钓鱼。如用户当前已经登录了邮箱，或bbs，同时用户又在使用另外一个，已经被你控制的站点，我们姑且叫它钓鱼网站。这个网站上面可能因为某个图片吸引你，你去点击一下，此时可能就会触发一个js的点击事件，构造一个bbs发帖的请求，去往你的bbs发帖，由于当前你的浏览器状态已经是登陆状态，所以session登陆cookie信息都会跟正常的请求一样，纯天然的利用当前的登陆状态，让用户在不知情的情况下，帮你发帖或干其他事情。
一句话就是我们利用CSRF攻击就是借用用户的身份去执行用户的操作
先看一个例子（白帽子讲web安全），一个删除搜狐博客的例子，利用CSRF删除搜狐博客。
正常情况下，登陆搜狐博客后，只需请求这个url，就能把编号156713012的博客文章删除
我们尝试利用CSRF漏洞，删除编号为“156714243”的博客文章。这篇文章标题“test1”.
攻击者首先在自己的域构造一个页面：
其内容;
使用了一个img标签，其地址指向了删除博客文章的链接。
攻击者诱使目标用户，也就是博客主人“test1test”访问这个页面：
该用户会看到一张无法显示的图片，也就是img标签创造的图片，但无法显示，然后回头看搜狐博客：
发现原来存在的标题为‘’test1”的文章，已被删除。
这个删除博客攻击文章的请求，是攻击者伪造的，所以这种攻击就叫做“跨站点请求伪造”。
下面仿照以上做一个实例，这里利用自己的简单留言板实施一次CSRF攻击
前面我们已经讲过了，CSRF攻击是在用户登录状态下，利用用户身份执行操作，这里就用到了cookie,当用户正在访问留言板时，诱导用户去点开攻击者伪造的一个网页（有删除留言的指令），用户点开之后便带着原来的留言板cookie去执行删除留言这条指令，当用户返回之后发现原来留言信息没了。
这是登录界面，输入用户名进去后
看一下用户的cookie吧
当然这里是自己的cookie，已经能看到了。
可以看到是post请求以表单的形式提交到delete.php，执行删除操作找到表单提交的name="ids",也就是ids=1时，我们可以删除id=1的留言，因为是POST请求，不能用标签的src属性，所以需要构建一个POST请求。
攻击者在自己的服务器中建立一个HTML文件csrf.html，用JS自动提交POST请求的form表单
这个只是本地测试，现在删除第三条留言，这个时候只要诱导用户去访问 就会删除该留言，至于用什么方法，需要攻击者去精心构造了，只要想象力丰富，就能发挥CSRF强大的破坏力。
当用户在登录留言板状态下去访问该网页，，，，
原来的留言没了
这就是基本的CSRF攻击。。
json格式，CSRF如何防御？
关于防御方案，一般有如下几种：
1）用户操作验证，在提交数据时需要输入验证码
2）请求来源验证，验证请求来源的referer
3）表单token验证
现在业界对CSRF的防御，一致的做法是使用一个Token（Anti CSRF Token）。
这个Token的值必须是随机的，不可预测的。由于Token的存在，攻击者无法再构造一个带有合法Token的请求实施CSRF攻击。另外使用Token时应注意Token的保密性，尽量把敏感操作由GET改为POST，以form或AJAX形式提交，避免Token泄露。
例子：
第一步：用户访问某个表单页面。
第二步：服务端生成一个Token，放在用户的Session中，或者浏览器的Cookie中。
第三步：在页面表单附带上Token参数。
第四步：用户提交请求后，服务端验证表单中的Token是否与用户Session（或Cookies）中的Token一致， 一致为合法请求，不是则非法请求。
4) 在前后端分离的前提下（例如使用ajax提交数据）设置不了token，可以给 cookie 新增 SameSite 属性，通过这个属性可以标记哪个 cookie 只作为同站 cookie （即第一方 cookie，不能作为第三方 cookie），既然不能作为第三方 cookie ，那么别的网站发起第三方请求时，第三方网站是收不到这个被标记关键 cookie，后面的鉴权处理就好办了。这一切都不需要做 token 生命周期的管理，也不用担心 Referer 会丢失或被中途被篡改。
SameStie 有两个值：Strict 和 Lax:
SameSite=Strict 严格模式，使用 SameSite=Strict 标记的 cookie 在任何情况下（包括异步请求和同步请求），都不能作为第三方 cookie。
SameSite=Lax 宽松模式，使用 SameSite=Lax 标记的 cookie 在异步请求 和 form 提交跳转的情况下，都不能作为第三方 cookie。
JSON必知必会
1、JSON基于JavaScript对象字面量
所谓字面量，是对数据值的具体表示。它的字面意思与其想要表达的意思是完全一致的。
2、名称-值对
计算机世界里，名称-值对也被称为键-值对、属性-值对或字段-值对，它们都表示一个意思。
3、正确的JSON语法
示例：
4、JSON文件使用.json 拓展名
5、JSON媒体类型是application/json
1、对象数据类型
JSON中的对象数据类型非常简单。追根溯源，JSON本身就是对象，也就是被花括号包裹的名称-值对的列表。对象可以嵌套。
2、字符串类型
简单的字符串类型，比如前面提到的"cat"我就不多说了 ，下面重点讲一下稍微复杂一点的。在这之前，我觉得有必要说一下解析器是如何读JSON
的。对于解析器来说，当一个值以双引号（"）开始时，它希望接下来的字符串文本以另一个双引号结尾。这意味着这段字符串本身包含
双引号可能会出错。我不知道你是否理解我的意思，我们看一个例子吧：
3、数字类型
4、布尔类型
5、null类型
6、数组类型
JSON中的数组类型呢也是一个比较重要的类型，上面用的不多的我就不细说，你记住就好。废话不多说，先来看一个例子吧：
1、跨站请求伪造CSRF：
拓展一下：
顶层JSON数组指存在于JSON名称-至对之外的位于文档最顶层的JSON数组
2、跨站脚本攻击XSS
3、安全漏洞：决策上的失误
