标签：party 允许 info 请求 构造 浏览器 知情 因此 防御
host (域名或IP地址, 如果是IP地址则可以看做是一个根域名), 子域名, 端口, 协议 (http, https)
比如，mail.example.com和calendar.example.com是example.com的两个子域，子域名也被包含在同源策略中.
在浏览器中 <script>, <img>, <iframe>, <link> 等标签都可以跨域加载资源, 而不受同源策略的限制. 这些带 "src"属性的标签每次加载时，实际上由浏览器发起了一次 GET 请求, 不同于 XMLHttpRequest 的是，通过 src 属性加载的资源，浏览器限制了 JavaScript 的权限，使其不能读，写返回的内容。
对于浏览器来说, 除了 DOM, Cookie, XMLHttpRequest 会受到同源策略的限制.
跨站脚本攻击(XSS) 是客户端脚本安全中的头号大敌. Cross Site Script. 书中有一些详细的介绍, 用到时在说把
防御: HttpOnly 属性, 输入检查 validation
CSRF : Cross Site Request Forgery
浏览器所持有的 Cookie 分为两种: 一种是"session Cookie", 又称为临时Cookie, 另一种是 Third-party Cookie 也称为本地 Cookie.
两者的区别在于, Third-party Cookie 是服务器在 set-Cookie 时指定了 expire 时间，只有到了expire时间后Cookie才会失效, 所以这种cookie保存在本地.
而session cookie 则没有指定 expire 时间, 所以浏览器关闭后, session cookie 就失效了.
比如访问 www.a.com, 会给浏览器写入两个cookie, 分别是 session cookie 和 third-party cookie，这时再打开一个新的浏览器tab页, 访问同一个域中的不同页面, 因为是在同一个域中的不同页面(可以理解, 比如你输入用户名/密码登录系统, 继续打开tab页使用, 不需要再次输入用户名/密码)，因为Tab页在同一个浏览器中, 因此session cookie 被发送. 此时, 另外一个域中, 有一个页面http://www.b.com/csrf-test.html, 构造页面 CSRF 以访问 www.a.com
<iframe src="http://www.a.com"></iframe> 这时会发现, 只能发送出 session cookie, 而 third-party cookie 被禁止了。这是因为 IE 出于安全考虑，默认禁止了浏览器在 <img>, <iframe>, <script>, <link> 等标签中发送第三方 cookie. 但是较低版本的 firefox 之前是允许的. 估计现在肯定所有的浏览器都不允许了，所以，先不考虑了。
CSRF 本质：重要操作的所有参数都是可以被攻击者猜测的。攻击者只有预测出 URL 的所有参数和参数值，才能成功的构造一个伪造的请求。出于这个原因，可以把参数加密，或者使用一些随机数，比较好的解决方案是: 增加一个参数 Token, 这个 token 是随机的，不可预测的.
由于 Token 的存在，攻击者无法再构造出一个完整的 URL 实施 CSRF 攻击.
攻击者使用一个透明的, 不可见的 iframe, 覆盖在一个网页上, 然后诱使用户在该网页上进行操作，此时用户将在不知情下点击透明的 iframe页面. 可以诱使用户恰好点击在 iframe 页面的一些功能性按钮.
手机上也会存在这个问题.
标签：party 允许 info 请求 构造 浏览器 知情 因此 防御
原文地址：https://www.cnblogs.com/moveofgod/p/12373414.html
