一、CSRF| XSRF
跨站请求伪造（英语：Cross-site request forgery），也被称为 one-click attack 或者 session riding，通常缩写为 CSRF 或者 XSRF， 是一种挟制用户在当前已登录的Web应用程序上执行非本意的操作的攻击方法。跟跨网站脚本（XSS）相比，XSS利用的是用户对指定网站的信任，CSRF 利用的是网站对用户网页浏览器的信任。
攻击细节
跨站请求攻击，简单地说，是攻击者通过一些技术手段欺骗用户的浏览器去访问一个自己曾经认证过的网站并运行一些操作（如发邮件，发消息，甚至财产操作如转账和购买商品）。由于浏览器曾经认证过，所以被访问的网站会认为是真正的用户操作而去运行。这利用了web中用户身份验证的一个漏洞：简单的身份验证只能保证请求发自某个用户的浏览器，却不能保证请求本身是用户自愿发出的。
例子
假如一家银行用以运行转账操作的URL地址如下：http://www.examplebank.com/withdraw?account=AccoutName&amount=1000&for=PayeeName
那么，一个恶意攻击者可以在另一个网站上放置如下代码： <img src="http://www.examplebank.com/withdraw?account=Alice&amount=1000&for=Badman">
如果有账户名为Alice的用户访问了恶意站点，而她之前刚访问过银行不久，登录信息尚未过期，那么她就会损失1000资金。
这种恶意的网址可以有很多种形式，藏身于网页中的许多地方。此外，攻击者也不需要控制放置恶意网址的网站。例如他可以将这种地址藏在论坛，博客等任何用户生成内容的网站中。这意味着如果服务端没有合适的防御措施的话，用户即使访问熟悉的可信网站也有受攻击的危险。
透过例子能够看出，攻击者并不能通过CSRF攻击来直接获取用户的账户控制权，也不能直接窃取用户的任何信息。他们能做到的，是欺骗用户浏览器，让其以用户的名义运行操作。
防御措施
检查Referer字段
HTTP头中有一个Referer字段，这个字段用以标明请求来源于哪个地址。在处理敏感数据请求时，通常来说，Referer字段应和请求的地址位于同一域名下。以上文银行操作为例，Referer字段地址通常应该是转账按钮所在的网页地址，应该也位于www.examplebank.com之下。而如果是CSRF攻击传来的请求，Referer字段会是包含恶意网址的地址，不会位于www.examplebank.com之下，这时候服务器就能识别出恶意的访问。
这种办法简单易行，工作量低，仅需要在关键访问处增加一步校验。但这种办法也有其局限性，因其完全依赖浏览器发送正确的Referer字段。虽然http协议对此字段的内容有明确的规定，但并无法保证来访的浏览器的具体实现，亦无法保证浏览器没有安全漏洞影响到此字段。并且也存在攻击者攻击某些浏览器，篡改其Referer字段的可能。
添加校验token
由于CSRF的本质在于攻击者欺骗用户去访问自己设置的地址，所以如果要求在访问敏感数据请求时，要求用户浏览器提供不保存在cookie中，并且攻击者无法伪造的数据作为校验，那么攻击者就无法再运行CSRF攻击。这种数据通常是窗体中的一个数据项。服务器将其生成并附加在窗体中，其内容是一个伪随机数。当客户端通过窗体提交请求时，这个伪随机数也一并提交上去以供校验。正常的访问时，客户端浏览器能够正确得到并传回这个伪随机数，而通过CSRF传来的欺骗性攻击中，攻击者无从事先得知这个伪随机数的值，服务端就会因为校验token的值为空或者错误，拒绝这个可疑请求。
二、JSON劫持攻击
JSON 劫持又为“ JSON Hijacking ”，最开始提出这个概念大概是在 2008 年国外有安全研究人员提到这个 JSONP 带来的风险。其实这个问题属于 CSRF（ Cross-site request forgery 跨站请求伪造）攻击范畴。当某网站听过 JSONP 的方式来快域（一般为子域）传递用户认证后的敏感信息时，攻击者可以构造恶意的 JSONP 调用页面，诱导被攻击者访问来达到截取用户敏感信息的目的。
漏洞原理
JSON实际应用的时候会有两种传输数据的方式：
xmlhttp获取数据方式：
{"username":"wooyun","password":"wooyun"}
当在前端获取数据的时候，由于数据获取方和数据提供方属于同一个域下面，所以可以使用 xmlhttp的方式来获取数据，然后再用xmlhttp获取到的数据传入自己的js逻辑如eval。
script获取数据方式：
userinfo={"username":"wooyun","password":"wooyun"}
如果传输的数据在两个不同的域，由于在javascript里无法跨域获取数据，所以一般采取script标签的方式获取数据，传入一些callback来获取最终的数据，这就有可能造成敏感信息被劫持。
所以，总的来说就是网站以JSON形式输出数据，且其中包含用户敏感信息，攻击者通过第三方站点以CSRF手段使用户浏览器请求目标站点得到包含敏感信息的JSON数据，进而劫持到敏感信息。
json劫持
json劫持攻击又为”JSON Hijacking”，攻击过程有点类似于csrf，只不过csrf只管发送http请求，但是json-hijack的目的是获取敏感数据。
一些web应用会把一些敏感数据以json的形式返回到前端，如果仅仅通过cookie来判断请求是否合法，那么就可以利用类似csrf的手段，向目标服务器发送请求，以获得敏感数据。
比如下面的链接在已登录的情况下会返回json格式的用户信息：
攻击者可以在自己的虚假页面中，加入如下标签：
如果当前浏览器已经登录了www.test.com，并且cookie未过期，然后访问了攻击者的虚假页面，那么该页面就可以拿到json形式的用户敏感信息，因为script标签会自动解析json数据，生成对应的js对象。然后再通过
Object.prototype.defineSetter
这个函数来触发自己的恶意代码。
但是这个函数在当前的新版本chrome和firefox中都已经失效了。
jsonp劫持
Jsonp（json with padding）是基于 JSON 格式的为处理跨域请求资源而产生的处理方案，远程调使用 JSON 文件来实现数据传递。利用script元素的开放策略，网页可以得到从其他来源动态产生的json数据，因此可以用来实现跨域。
举一个例子
_GET['callback'];
print $callback . '({"id" : "1","name" : "小明"});';
?>
这里出现了callback他的作使用就是回调我们的json。
web程序如果通过这种方式跨域之后，攻击者完全可以在自己的虚假页面中发起恶意的jsonp请求，这就引来了安全问题。比如：
function useUserInfo(v){
alert(v.username);
}
如果服务器端的userinfo接口支持jsonp，那就会使虚假页面成功执行useUserInfo函数，从而导致安全问题。
json劫持的挖掘过程的referer绕过机制。
正则不严谨
如正常请求的referer：www.123.com
我们修改为referer
只要要攻击者利使用时注册相应的域名即可以绕过
空referer
这里直接删去referer是最简单的一个
jsonp接口漏洞挖掘
相关的介绍就不细细道来了，其实原理也就是JSONP实际上是使用script方式获取Javascript代码，进而执行，因此可以在我们自己的页面中，使用JSONP获取数据，并使用Javascript Hook的方式，让其执行我们自定义的回调函数，获取敏感信息。
需要满足的条件：
使用JSONP获取数据；
未检测 referer或者验证了 referer，但是验证方式不严谨，如需要验证的 referer 为 www.xxx.com 域，但是 www.xxx.com.mydomain.com 同样能够绕过；
GET请求中不包含token相关的参数
如何挖掘这样的接口呢？我们可以使用工具Fiddler、burpsuite。具体请看:https://www.jianshu.com/p/0217ca8bc081
三、XSS
XSS(Cross Site Scripting跨站脚本)。XSS定义的主语是“脚本”，是一种跨站执行的脚本，也就是javascript脚本，指的是在网站上注入我们的javascript脚本，执行非法操作。
XSS攻击发生的条件是可以执行javascript脚本，一般在站点中总会有发表文章、留言等信息的表单，这种表单一般是写入到数据库中，然后在某个页面进行展示。我们可以在这些表单中直接编写javascript代码（<script>alert("哈哈哈哈，你被攻击了!");</script>）进行测试，看是否可以执行。如果在信息展示页面js代码可以执行，XSS攻击就成功了。
网友评论