浏览器安全策略安全策略有哪些同源策略沙盒框架Flash安全沙箱Cookie的安全策略内容安全策略(ContentSecu

安全策略有哪些

同源策略
沙盒框架
Flash安全沙箱
Cookie的安全策略
内容安全策略 (Content Security Polity, CSP)

同源策略：

同源：协议，端口，域名全都一样。不同源的客户端脚(javascript、ActionScript)本在没明确授权的情况下，不能读写对方的资源。

同源策略控制不同源之间的交互，例如在使用XMLHttpRequest 或 <img> 标签时则会受到同源策略的约束。这些交互通常分为三类：

跨域写操作（Cross-origin writes）一般是被允许的。例如链接（links），重定向以及表单提交。
跨域资源嵌入（Cross-origin embedding）一般是被允许。
跨域读操作（Cross-origin reads）一般是不被允许的，但常可以通过内嵌资源来巧妙的进行读取访问。例如，你可以读取嵌入图片的高度和宽度，调用内嵌脚本的方法。

不同源的 js 脚本无法读写当前页面的 DOM；不同源的 js 脚本无法读取当前页面的 Cookie、IndexDB、LocalStorage 等；不同源的 XMLHttpRequest 访问无法进行。

沙盒框架：

对常规<iframe>表现行为的扩展，它能让顶级页面对嵌入子页面即这个子页面的子资源设置一些额外额限制。

通过对<iframe>的参数sandbox实现限制：

<iframe sandbox="value">

sandbox属性值：

值	描述
""	应用以下所有的限制。
allow-same-origin	允许 iframe 内容被视为与包含文档有相同的来源。
allow-top-navigation	允许 iframe 内容从包含文档导航（加载）内容。
allow-forms	允许表单提交。
allow-scripts	允许脚本执行。

Flash安全沙箱

类似与同源策略：把同一域的资源放到一个安全组内，称安全沙箱。

web站点通过crossdomain.xml文件配置可以允许的域，跨域访问本站点的权限（放置于本站点根目录）

例：www.test.com/crossdomain…

<?xml version="1.0" encoding="UTF-8"?>
<cross-domain-policy>
    <allow-access-from domain="*.test.com" />
    <allow-access-from domain="test.com" />
</cross-domain-policy>

Cookie的安全策略

Domain 用于指定Cookie的有效域
Path 用于指定Cookie的有效URL路径
Secure 如果设置该属性，仅在HTTPS请求中提交Cookie
Http 其实是HttpOnly, 如果设置该属性，客户端javascript无法获取Cookie的值

内容安全策略 (Content Security Polity, CSP)

通过编码在HTTP响应头中的指令来实施策略

Content-Security-Polity:script-src 'self' https://baidu.com
CSP的一些指令
- default-src : 该指令在某种资源类型指定指令没有被定义的情况下制定了所有资源类型的加载策略(即默认的资源加载策略)
- script-src : 该指令指定了Web应用程序可以加载的脚本的域或URL
- object-src : 该指令制定了Web应用程序可以加载的插件，如Falsh
- style-src : 该指令制定了Web应用程序可以加载的CSS样式表的域或URL
- img-src : 该指令指定了Web应用程序可以加载的图片的域或URL
- media-src : 该指令指定了Web应用程序可以加载的音视频的域或URL
- frame-src : 该指令指定了Web应用程序可以加载的框架的域或URL
- font-src : 该指令指定了Web应用程序可以加载的字体的域或URL
- connect-src : 该指令指定了Web应用程序可以加载的像XHR, WebSockets, 以及EventSource等脚本接口的域或URL
- plugin-types : 该指令指定了哪些MIME类型的插件可以被加载(浏览器支持度不够)
- form-action : 该指令指定了HTML表单可以提交的URLS(浏览器支持度不够)
- reflected-xss : 该指令告诉浏览器开启或关闭任何用于过滤或组织反射跨站脚本攻击的启发式算法，这相当于X-XSS-Protection响应头的效果(浏览器支持度不够)

XSS攻击与防御

跨站脚本攻击(Cross Site Scripting)

常见的xss分类：

存储型（持久型）
反射型（非持久型）
DOM型

存储型：

如：留言板功能，用户通过页面输入框，将数据存储到数据库，下次页面渲染从数据库中读取数据库数据展示时，就会将恶意代码i按时到界面上。

反射型

恶意攻击者往Web页面里插入恶意代码，当用户浏览该页时，嵌入其中Web里面的html代码会被执行，从而达到恶意攻击用户的目的。

例：从给后端一个url,带参数的，后端通过解析参数然后直接返回结果。这样这个参数就可以被恶意操控，然后显示到界面上。

http://www.test.com/search.html?key_pro="<script>confirm(111)</script>"

后端直接返回key_pro的值显示到界面上（内容读取之后直接反射显示到界面上）

用户可以通过操作url上面的参数，然后执行某些恶意代码，叫做反射型（非持久型）

DOM型

也是反射型的一种。不过比较特殊,DOM型xss的实现过程都是在前端

介绍两种场景的DOM型xss：

场景一：innerHTML

<html>
    <head>
        <title> DOM-XSS TEST </title>
        <style>
            #box{width:250px;height:200px;border:1px solid #e5e5e5;background:#f1f1f1;}
        </style>
    </head>
    <body>
        <script>
            window.onload= function(){
                var oBox=document.getElementById("box");
                var oSpan=document.getElementById("span1");
                var oText=document.getElementById("text1");
                var oBtn=document.getElementById("Btn");
                oBtn.onclick = function(){
                    oBox.innerHTML = oBox.innerHTML + oSpan.innerHTML + oText.value + "<br/>";
                    // oBox.innerHTML += oSpan.innerHTML + oText.value +  "<br/>";//这是简便的写法，在js中 a=a+b ,那么也等同于 a+=b
                    oText.value=""
                };
            }
        </script>

        <div id="box"></div>
        <span id="span1">小明：</span>
        <input type="text" id="text1"/>
        <input id="Btn" type="button" value="发送消息" name=""/>
    </body>
</html>

用户可以修改box/span1/text 的内容然后让这个界面把用户为找的内容显示出来，

例如：将JavaScript代码作为参数写入值中：

<svg onload=alert(1)/>

图片来源

Cookie等未处理，恶意代码注入也可以获取到cookie的值

var cookies = document.cookie;
document.write(cookies);

CSRF攻击与防御

CSRF，全称：跨站伪造请求（Cross - site request forgery）, 也称为 one click attack/session riding 还可以缩写为XSRF.

原理：

攻击者盗用了你的身份，以你的名义发送恶意请求。CSRF能够做的事情包括：以你名义发送邮件，发消息，盗取你的账号，甚至于购买商品，虚拟货币转账......造成的问题包括：个人隐私泄露以及财产安全。

带上用户信息，伪造请求，用用户的身份做一些相关功能性的操作。

CSRF的防御

参考地址

后端防御CSRF：

后端防御主要是区分**哪些请求是恶意请求，哪些请求是自己网站的请求。**区分恶意请求的方式有很多。

第一种：CSRF Token 的方式。这种方式是**在表单页面生成一个随机数，这个随机数一定要后端生成，并且对这个随机数进行存储。**在前端页面中，对这个Token表单项进行隐藏。每次发送请求的时候都将随机数带上，由后端验证。
第二种：通过请求头中的**referer**字段判断请求的来源。每一个发送给后端的请求，在请求头中都会包含一个referer字段，这个字段标识着请求的来源。
第三种：设置验证码

前端防御CSRF

它是在原有的Cookie中，新添加了一个SameSite属性，它标识着在非同源的请求中，是否可以带上Cookie，它可以设置为3个值，分别为：

Strict：是最严格的，它完全禁止在跨站情况下，发送Cookie。只有在自己的网站内部发送请求，才会带上Cookie。
Lax：大部分跨站的请求也不会带上Cookie，但是一些导航的Get请求会带上Cookie。

请求类型	示例	Lax情况
链接	``	发送 Cookie
预加载	``	发送 Cookie
GET 表单	``	发送 Cookie
POST 表单	``	不发送
iframe	`frameLabelStart--frameLabelEnd`	不发送
AJAX	`$.get("...")`	不发送
Image	``	不发送

None：None就是关闭SameSite属性，所有的情况下都发送Cookie。不过SameSite设置None，还要同时设置Cookie的Secure属性，否则是不生效的。

注：如果一个cookie被设置了Secure=true，那么这个cookie只能用https协议发送给服务器，用http协议是不发送的。

secure设为false：不管在哪个页面设置的cookie，别的页面都可以看见。

基于安全的考虑，需要给cookie加上Secure和HttpOnly属性，HttpOnly比较好理解，设置HttpOnly=true的cookie不能被js获取到，无法用document.cookie打出cookie的内容。指示浏览器不要在除HTTP（和 HTTPS)请求之外暴露Cookie。一个有HttpOnly属性的Cookie，

cookie内容：

POST /transfer HTTP/1.1
Host: www.a-bank.com
Cookie: JSESSIONID=randomid;SameSite=Strict;