所谓跨域
1.就是跨域名，跨端口，跨协议
例如：如果有两个服务器，服务器A和服务器B,服务器A上存储了php数据，script,甚至是css这些文件，而你在服务器B上只写了html，然后你所在的服务器B上动态创建script，css，php数据(使用ajax请求),向服务器A上请求你想要的script,css，php数请求据(使用ajax)这些文件，请求这些文件后，你再在服务器B上运行你的html，虽然你的地址是在服务器B上，但是你还是可以运行效果与在服务器A上运行的效果是一样的，这样就是跨域名，跨端口，跨协议，实现了跨域。
简单来说，就是你请求的文件，只要含有“src”,“href”这些属性，你就能在其他服务器上，请求你所需要的文件，然后在自己的服务器上运行，就实现了跨域（跨域名，跨端口，跨协议）。
为什么会出现跨域？
跨域问题来源于JavaScript的同源策略
什么是同源策略？
同源策略/SOP（Same origin policy）是一种约定，由Netscape公司1995年引入浏览器，它是浏览器最核心也最基本的安全功能，如果缺少了同源策略，浏览器很容易受到XSS、CSFR等攻击。所谓同源是指”协议+域名+端口”三者相同，即便两个不同的域名指向同一个ip地址，也非同源。
(
如果没有同源策略的限制，假设您进入一个银行网站A，输入了账号密码进行登录，服务器端验证通过后会在响应头中添加Set-Cookie字段，在下次访问时，浏览器就会将cookie附加在http请求头字段Cookie中，服务器就知道您已经登录过，便不再验证了，如果在cookie信息还存在的情况下，您访问另一个网站B，如果它是一个恶意网站，在您不知情的情况下向网站A发起了请求，这就相当于不法网站B登录了您的账户，可以为所欲为了！
又比如一个钓鱼网站，模仿银行网站A（没有了同源策略的限制，钓鱼网站就可以很轻松的网站A的DOM），诱导您输入账户密码信息，然后就可想而知了......
)
同源策略限制以下几种行为：
1.) Cookie、LocalStorage 和 IndexDB 无法读取
2.) DOM 和 Js对象无法获得
3.) AJAX 请求不能发送
常见跨域场景
URL 说明 是否允许通信
http://www.domain.com/a.js
http://www.domain.com/b.js 同一域名，不同文件或路径 允许
http://www.domain.com/lab/c.js
http://www.domain.com:8000/a.js
http://www.domain.com/b.js 同一域名，不同端口 不允许
http://www.domain.com/a.js
https://www.domain.com/b.js 同一域名，不同协议 不允许
http://www.domain.com/a.js
http://192.168.4.12/b.js 域名和域名对应相同ip 不允许
http://www.domain.com/a.js
http://x.domain.com/b.js 主域相同，子域不同 不允许
http://domain.com/c.js
http://www.domain1.com/a.js
http://www.domain2.com/b.js 不同域名 不允许
你可以理解为两个域名之间不能跨过域名来发送请求或者请求数据，否则就是不安全的，这种不安全也就是CSRF（Cross-site request forgery），中文名称：跨站请求伪造，也被称为：one click attack/session riding，缩写为：CSRF/XSRF。
CSRF能干嘛？
你这可以这么理解CSRF攻击：攻击者盗用了你的身份，以你的名义发送恶意请求。CSRF能够做的事情包括：以你名义发送邮件，发消息，盗取你的账号，甚至于购买商品，虚拟货币转账......造成的问题包括：个人隐私泄露以及财产安全。
CSRF特性？
依靠用户标识危害网站
利用网站对用户标识的信任
欺骗用户的浏览器发送HTTP请求给目标站点
另外可以通过IMG标签会触发一个GET请求，可以利用它来实现CSRF攻击。
image.png
简单来说，CSRF必须经过两个步骤：
1、用户访问可信任站点A，并产生了相关的cookie；
2、用户在访问A站点时没有退出，同时访问了危险站点B；
大家同时访问多个网站是很正常的事情，所以也很容易遭到CSRF的攻击。
举个栗子：
某电商网站A，你购买时候支付的操作是：http://www.market.com/Transfer.php?bankId=11&money=1000;
某危险网站B，他有段代码是 <img src=http://www.market.com/Transfer.php?bankId=11&money=1000>
访问A支付后你会发现银行卡里面多扣了1000块钱，why？通过get方式，你在访问A网站进行支付操作时，A网站保存了你的cookie信息，如果B网站拿到了你的cookie或者他伪造的数据刚好就是cookie里的，就能伪造你的请求，进行同样的支付操作。
也许你会说，我换成post请求不就行了，但是如果你的server代码没有处理，一样可以进行伪造。
So，如何进行防御？
1、服务器端表单hash认证
在所有的表单里面随机生成一个hash，server在表单处理时去验证这个hash值是否正确，这样工作量比较大，我们之前所有的表单都没添加！！！，好几十个页面，这个当前处境不切实际
2、验证http Referer字段
根据HTTP协议，在HTTP头中有一个字段叫Referer，它记录了该HTTP请求的来源地址。在通常情况下，访问一个安全受限页面的请求必须来自于同一个网站。比如某银行的转账是通过用户访问http://bank.test/test?page=10&userID=101&money=10000页面完成，用户必须先登录bank.test，然后通过点击页面上的按钮来触发转账事件。当用户提交请求时，该转账请求的Referer值就会是转账按钮所在页面的URL(本例中，通常是以bank. test域名开头的地址)。而如果攻击者要对银行网站实施CSRF攻击，他只能在自己的网站构造请求，当用户通过攻击者的网站发送请求到银行时，该请求的Referer是指向攻击者的网站。因此，要防御CSRF攻击，银行网站只需要对于每一个转账请求验证其Referer值，如果是以bank. test开头的域名，则说明该请求是来自银行网站自己的请求，是合法的。如果Referer是其他网站的话，就有可能是CSRF攻击，则拒绝该请求。
3、在HTTP头中自定义属性并验证
自定义属性的方法也是使用token并进行验证，和前一种方法不同的是，这里并不是把token以参数的形式置于HTTP请求之中，而是把它放到HTTP头中自定义的属性里。通过XMLHttpRequest这个类，可以一次性给所有该类请求加上csrftoken这个HTTP头属性，并把token值放入其中。这样解决了前一种方法在请求中加入token的不便，同时，通过这个类请求的地址不会被记录到浏览器的地址栏，也不用担心token会通过Referer泄露到其他网站。
我们就是采用的这种方法，因为基本上所有的请求都是通过ajax，我们通过重新封装ajax，在ajax头部添加一个token，server去识别这个token，如果请求没有这个token或者错误就拒绝。
4、CSRF攻击是有条件的，当用户访问恶意链接时，认证的cookie仍然有效，所以当用户关闭页面时要及时清除认证cookie，对支持TAB模式(新标签打开网页)的浏览器尤为重要。
5、尽量少用或不要用request()类变量，获取参数指定request.form()还是request. querystring ()，这样有利于阻止CSRF漏洞攻击，此方法只不能完全防御CSRF攻击，只是一定程度上增加了攻击的难度。
6、通过图形验证码
相对来说图形验证码应该是最安全的，但是我们不可能在所有的API上去加上这么个玩意儿，一般是在表单，比如注册，登录等，当用户频繁操作时出现，避免影响用户体验
网友评论