一、跨域
①、广义的跨域?
跨域是指一个域下的文档或脚本试图去请求另一个域下的资源,这里跨域是广义的。
广义的跨域:
1、资源跳转:A链接、重定向、表单提交
2、资源嵌入: <link>、<script>、<img>、<frame>等dom标签,还有样式中background:url()、@font-face()等文件外链
3、脚本请求: js发起的ajax请求、dom和js对象的跨域操作等
②、
狭义的跨域?
其实我们通常所说的跨域是狭义的,是由浏览器同源策略限制的一类请求场景。
③、什么是同源策略?
同源策略/SOP(Same origin policy)是一种约定,由Netscape公司1995年引入浏览器,它是浏览器最核心也最基本的安全功能,如果缺少了同源策略,浏览器很容易受到XSS、CSFR等攻击。所谓同源是指"协议+域名+端口"三者相同,即便两个不同的域名指向同一个ip地址,也非同源。
同源策略限制以下几种行为:
1、Cookie、LocalStorage 和 IndexDB 无法读取
2、 DOM 和 Js对象无法获得
3、 AJAX 请求不能发送
④、常见跨域场景?
URL 说明 是否允许通信 http://www.demo.com/a.js http://www.demo.com/b.js 同一域名,不同文件或路径 允许 http://www.demo.com/lab/c.js http://www.demo.com:8000/a.js http://www.demo.com/b.js 同一域名,不同端口 不允许 http://www.demo.com/a.js https://www.demo.com/b.js 同一域名,不同协议 不允许 http://www.demo.com/a.js http://127.0.0.1/b.js 域名和域名对应相同ip 不允许 http://www.demo.com/a.js http://x.demo.com/b.js 主域相同,子域不同 不允许 http://demo.com/c.js http://www.demo1.com/a.js http://www.demo2.com/b.js 不同域名 不允许
⑤、跨域解决方案?
1、 通过jsonp跨域
2、 document.domain + iframe跨域
3、 location.hash + iframe
4、 window.name + iframe跨域
5、 postMessage跨域
6、 跨域资源共享(CORS)
7、 nginx代理跨域
8、 nodejs中间件代理跨域
9、 WebSocket协议跨域
原文链接:
https://www.cnblogs.com/sdcs/p/8484905.html
二、csrf攻击
①、什么是csrf攻击?
csrf 全称 Cross-site request forgery, 通常缩写为CSRF 或者 XSRF, 中文名跨站请求伪造,是一种挟制用户在当前已登录的Web应用程序上执行非本意的操作的攻击方法。CSRF 攻击手段是通过发起改变状态的请求, 而不是窃取用户的数据, 因为攻击者无法得到服务器返回的响应
②、如何攻击?
攻击者通过一些技术手段欺骗用户的浏览器去访问一个自己曾经认证过的网站并执行一些操作(如发邮件,发信息,甚至财产操作如转账和购买商品)。由于浏览器曾经认证过,所以被访问的网站会认为是真正的用户操作而去执行。这利用了web中用户身份验证的一个漏洞:简单的身份验证只能保证请求发自某个用户的浏览器,却不能保证请求本身是用户自愿发出的。
补充:还可能更改账号所绑定的邮箱地址或者密码等。
例子
假如 Alice 在 bank.com 向 Bob 汇款100,这时攻击者Maria想要欺骗Alice,让她给自己汇款10000, 那么攻击将会由以下两步骤组成:
- 创建一个 URL 或者 script
- 利用社交工程欺骗 Alice 执行代码
GET 场景
如果 bank.com 把查询参数放到 URL 中, 那么 Alice 向 Bob 转账的操作可以简化为如下:GET http://bank.com/transfer.do?acct=BOB&amount=100 HTTP/1.1
Maria 根据 bank.com 网站请求的结构, 将 Bob 名字替换为她自己的, 还把金额变大:http://bank.com/transfer.do?acct=MARIA&amount=100000
那么这个充满恶意的 URL ,被 Maria 放到 a 标签中, 并且利用欺骗语言吸引 Alice 点击:<a href="http://bank.com/transfer.do?acct=MARIA&amount=100000">View my Pictures!</a>
或者放到一个 长度和宽度都为0 的图片的src 中(图片不用用户点击, 自己就发起请求):<img src="http://bank.com/transfer.do?acct=MARIA&amount=100000" width="0" height="0" border="0">
如果这张图片放到邮件中, Alice 根本就不会发现什么. 然而浏览器还是会将请求提交到 bank.com 的后台中.
一个真实的事件是发生在2008 年的uTorrent exploit。
POST 场景
假设 bank.com 现在使用 post 请求来传递参数的, 那么这个请求可以简化为:
POST http://bank.com/transfer.do HTTP/1.1
...
acct=BOB&amount=100
这种情况下, a 标签和 img 标签都无法发送 post 请求, 但是可以使用 FORM 来完成:
<form action="<nowiki>http://bank.com/transfer.do</nowiki>" method="POST">
<input type="hidden" name="acct" value="MARIA"/>
<input type="hidden" name="amount" value="100000"/>
<input type="submit" value="View my pictures"/>
</form>
我们还可以利用 JavaScript 来让文档载入的时候就发送这个请求:
<body onload="document.forms[0].submit()">
<form action="..." method="POST">
.....
</form>
其他的 HTTP 请求方法场景
假设现在银行使用的是 PUT 将数据放到一个JSON 中发送到后台中:
PUT http://bank.com/transfer.do HTTP/1.1
{ "acct":"BOB", "amount":100 }
那么我们可以利用内嵌的 JavaScript :
<script>
function put() {
var x = new XMLHttpRequest();
x.open("PUT","http://bank.com/transfer.do",true);
x.setRequestHeader("Content-Type", "application/json");
x.send(JSON.stringify({"acct":"BOB", "amount":100}));
}
</script>
<body onload="put()">
幸运的是这段 PUT 请求并不会发送, 因为 同源策略 的限制. 除非你的后台设置了
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: PUT
总结
不论是 GET 请求还是 POST 请求, 如果有账户名为Alice的用户访问了恶意站点,而她之前刚访问过银行不久,登录信息尚未过期,那么她就会损失10000资金。
原文链接:https://www.jianshu.com/p/d08f4b9f8271