HTML5安全

HTML5安全

1. H5新标签

1.1 iframe的sandbox

<iframe>标签一直受人诟病。浏览器也在想办法限制<iframe>执行脚本的权限。
而H5中专门为<iframe>设置了sandbox属性，<iframe>将被视为一个独立的源，可以通过属性参数来支持更加精准的控制：

• allow-same-origin：同源访问
• allow-top-navigation：访问顶层窗口
• allow-forms：提交表单
• allow-scripts：执行脚本

诸如‘弹出窗口’这种行为，即使设置了allow-scripts，也不会被允许

1.2 Link Types: noreferrer

这是H5中，为<a> and <area>标签定义的新的Link Types，指定后，浏览器在请求该标签时，不在发送referer，因为通过referer可能会泄漏一下敏感信息

<a href=“xxx” rel=“noreferrer”>xxx</a>

1.3 Canvas的妙用

<Canvas> 不同于<img>标签只是远程加载一张图片，而是可以让js可以在页面中直接操作图片对象，也可以通过操作像素来构造出图片区域。开发者甚至可以在<canvas>中写一个小游戏。

<Canvas>甚至可以用来破解验证码。详细:《白帽子》p142.

2. 其他安全问题

2.1 Cross-Origin Resource Sharing

浏览器同源策略通过限制脚本的跨域请求，虽然解决了一定的安全问题，但是互联网的发展趋势是越来越开放的，而同源策略给web开发者带来了很多困扰。

W3C委员会制定了一个新的标准来解决日益迫切的跨域访问的问题：
简单来说，就是当www.a.com的一个页面发起一个跨域请求，请求地址为www.b.com的一个页面，如果www.b.com返回一个包含允许a网站访问的HTTP Header，那么这个跨域请求就会被通过。

具体细节和抓包分析:《白帽子》P145

Origin Header用于标记HTTP的“源”，来判断浏览器的请求是否来自一个合法的“源”。可以用于防范CSRF，它不像referer那么容易被伪造和清空。

2.2 postMessage —— 跨窗口传递消息

window这个对象几乎是不受同源策略限制的，可以利用window.name跨窗口、跨域来传递消息。
在H5中，为了丰富web开发者的能力，指定了postMessage这一新的API，postMessage允许每一个window(包括当前窗口、弹出窗口、iframe等)对象往其他窗口发送文本消息，从而实现跨窗口的消息传递

发送窗口：

<iframe src=“xxx” id=“iframe”></iframe>
<form id=“form”>
    <input type=”text” id=“msg” value=”Message to send“/>
    <input type=“submit />
</form>
<script>
    window.onload= function(){
        var win= document.getElementById(“iframe”).contentWindow;
        document.getElementById(”form“).onsubmit=function(e){
            win.postMessage(document.getElementById(”msg“).value);
            e.preventDefault();
        };
    };
</script>

接收窗口:

<b>this iframe is located on xxx</b>
<script>
    document.addEventlistener(“message”, function(e){
        document.getElementById(“test”).textContent = e.domain + “said: ” + e.data;
    }, false);
</script>

在这个例子中：
发送窗口负责发送消息；
在接收窗口中，需要绑定一个message事件，监听其他窗口发来的消息。
这是两个窗口之间的一个“约定”，如果没有监听这个事件，则无法接收到消息。

在使用postMessage时，有两个安全问题需要注意。

1. 在必要时,可以在接收窗口验证 Domain，甚至验证URL，以防止来自非法页面的消息。代码中实现一次同源策略的验证过程。
2. 在本例中,接收的消息写入textContent，但在实际应用中,如果将消息写入innerHTML，甚至直接写入 script中，则可能会导致DOM based XSS的产生。根据“Secure By Default”原则，在接收窗口不应该信任接收到的消息,而需要对消息进行安全检查。

2.3 Web Storage

[暂略]