HTML5的安全风险详析
关于HTML5存在的安全风险你了解多少?下面YJBYS小编为大家详细解析一下HTML5的安全风险!希望对大家有所帮助!
一、CORS攻击
CORS-CrossOrigin Resources Sharing，也即跨源资源共享，它定义了一种浏览器和服务器交互的方式来确定是否允许跨域请求。它是一个妥协，有更大的灵活性，但比起简单地允许所有这些的要求来说更加安全。简言之，CORS就是为了让AJAX可以实现可控的跨域访问而生的。
一、从SOP到CORS
SOP就是Same Origin Policy同源策略，指一个域的文档或脚本，不能获取或修改另一个域的文档的属性。也就是Ajax不能跨域访问，我们之前的Web资源访问的根本策略都是建立在SOP上的。它导致很多web开发者很痛苦，后来搞出很多跨域方案，比如JSONP和flash socket。如下图所示：
后来出现了CORS-CrossOrigin Resources Sharing，也即跨源资源共享，它定义了一种浏览器和服务器交互的方式来确定是否允许跨域请求。它是一个妥协，有更大的灵活性，但比起简单地允许所有这些的要求来说更加安全。简言之，CORS就是为了让AJAX可以实现可控的跨域访问而生的。示意如下图所示：
现在W3C的官方文档目前还是工作草案，但是正在朝着W3C推荐的方向前进。不过目前许多现代浏览器都提供了对它的支持。
服务器端对于CORS的支持，主要就是通过设置Access-Control-Allow-Origin来进行的。如果浏览器检测到相应的设置，就可以允许Ajax进行跨域的访问。例如：
Access–Control-Allow-Origin
应用CORS的系统目前包括Face.com、GoogleCloudStorage API等，主要是为开放平台向第三方提供访问的能力。
二、CORS带来的风险
CORS非常有用，可以共享许多内容，不过这里存在风险。因为它完全是一个盲目的协议，只是通过HTTP头来控制。
它的风险包括：
1、HTTP头只能说明请求来自一个特定的域，但是并不能保证这个事实。因为HTTP头可以被伪造。
所以未经身份验证的跨域请求应该永远不会被信任。如果一些重要的功能需要暴露或者返回敏感信息，应该需要验证Session ID。
2、第三方有可能被入侵
举一个场景，FriendFeed通过跨域请求访问Twitter，FriendFeed请求tweets、提交tweets并且执行一些用户操作，Twitter提供响应。两者都互相相信对方，所以FriendFeed并不验证获取数据的有效性，Twitter也针对Twitter开放了大部分的功能。
但是当如果Twitter被入侵后：
FriendFeed总是从Twitter获取数据，没有经过编码或者验证就在页面上显示这些信息。但是Twitter被入侵后，这些数据就可能是有害的。
或者FriendFeed被入侵时：
Twitter响应FriendFeed的请求，例如发表Tweets、更换用户名甚至删除账户。当FriendFeed被入侵后，攻击者可以利用这些请求来篡改用户数据。
所以对于请求方来说验证接收的数据有效性和服务方仅暴露最少最必须的功能是非常重要的。
3、恶意跨域请求
即便页面只允许来自某个信任网站的请求，但是它也会收到大量来自其他域的跨域请求。.这些请求有时可能会被用于执行应用层面的DDOS攻击，并不应该被应用来处理。
例如，考虑一个搜索页面。当通过'%'参数请求时搜索服务器会返回所有的记录，这可能是一个计算繁重的要求。要击垮这个网站，攻击者可以利用XSS漏洞将JavaScript脚本注入某个公共论坛中，当用户访问这个论坛时，使用它的浏览器重复执行这个到服务器的搜索请求。或者即使不采用跨域请求，使用一个目标地址包含请求参数的图像元素也可以达到同样的目的。如果可能的话，攻击者甚至可以创建一个WebWorker执行这种攻击。这会消耗服务器大量的资源。
有效的解决办法是通过多种条件屏蔽掉非法的请求，例如HTTP头、参数等。
4、内部信息泄漏
假定一个内部站点开启了CORS，如果内部网络的用户访问了恶意网站，恶意网站可以通过COR(跨域请求)来获取到内部站点的内容。
5、针对用户的攻击
上面都是针对服务器的攻击，风险5则针对用户。比方说，攻击者已经确定了你可以全域访问的productsearch.php页面上存在SQL注入漏洞。 攻击者并不是直接从它们的系统数据库中获取数据，他们可能会编写一个JavaScript数据采集脚本，并在自己的网站或者存在XSS问题的网站上插入这段脚本。当受害者访问含有这种恶意JavaScript脚本的网站时，它的浏览器将执行针对“productsearch.php”的SQL注入攻击，采集所有的数据并发送给攻击者。检查服务器日志显示是受害人执行了攻击，因为除了来自Referrer的HTTP头一般没有其他日志记录。受害者并不能说他的`系统被攻破，因为没有任何任何恶意软件或系统泄漏的痕迹。
三、攻击工具
四、防御之道
1、不信任未经身份验证的跨域请求，应该首先验证Session ID或者Cookie。
2、对于请求方来说验证接收的数据有效性，服务方仅暴露最少最必须的功能。
3、通过多种条件屏蔽掉非法的请求，例如HTTP头、参数等。
二、Web Storage攻击
HTML5支持WebStorage，开发者可以为应用创建本地存储，存储一些有用的信息。例如LocalStorage可以长期存储，而且存放空间很大，一般是5M，极大的解决了之前只能用Cookie来存储数据的容量小、存取不便、容易被清除的问题。这个功能为客户端提供了极大的灵活性。
一、WebStorage简介
HTML5支持WebStorage，开发者可以为应用创建本地存储，存储一些有用的信息。例如LocalStorage可以长期存储，而且存放空间很大，一般是5M，极大的解决了之前只能用Cookie来存储数据的容量小、存取不便、容易被清除的问题。这个功能为客户端提供了极大的灵活性。
二、攻击方式
LocalStorage的API都是通过JavaScript提供的，这样攻击者可以通过XSS攻击窃取信息，例如用户token或者资料。攻击者可以用下面的脚本遍历本地存储。
if(localStorage.length){
for(I in localStorage) {
console.log(i);
console.log(localStorage.getItem(i));
}
}
同时要提一句，LocalStorage并不是唯一暴露本地信息的方式。我们现在很多开发者有一个不好的习惯，为了方便，把很多关键信息放在全局变量里，例如用户名、密码、邮箱等等。数据不放在合适的作用域里会带来严重的安全问题，例如我们可以用下面的脚本遍历全局变量来获取信息。
for(iin window) {
obj=window[i];
if(obj!=null||obj!=undefined)
var type =typeof(obj);
if(type=="object"||type=="string") {
console.log(“Name:”+i);
try {
my = JSON.stringify(obj);
console.log(my);
} catch(ex) {}
}
}
三、攻击工具
HTML5dump的定义是“JavaScriptthat dump all HTML5 local storage”，它也能输出HTML5 SessionStorage、全局变量、LocalStorage和本地数据库存储。
Shell of the Future是一个反向WebShell处理器，它利用HTML5的跨站请求来劫持会话。
四、防御之道
对于WebStorage攻击的防御措施是：
1、数据放在合适的作用域里
例如用户sessionID就不要用LocalStorage存储，而需要放在sessionStorage里。而用户数据不要储存在全局变量里，而应该放在临时变量或者局部变量里。
2、不要存储敏感的信息
因为我们总也无法知道页面上是否会存在一些安全性的问题，一定不要将重要的数据存储在WebStorage里。
三、WebSQL攻击
数据库安全一直是后端人员广泛关注和需要预防的问题。但是自从HTML5引入本地数据库和WebSQL之后，前端开发对于数据库的安全也必须要有所了解和警惕。WebSQL的安全问题通常表现为两个部分。
一、WebSQL安全风险简介
数据库安全一直是后端人员广泛关注和需要预防的问题。但是自从HTML5引入本地数据库和WebSQL之后，前端开发对于数据库的安全也必须要有所了解和警惕。WebSQL的安全问题通常表现为两个部分：
第一种是SQL注入：和本地数据库一样，攻击者可以通过SQL注入点来进行数据库攻击。
另外一方面，如果Web App有XSS漏洞，那么本地数据很容易泄漏，可以想想本地数据库里存储了用户最近交易记录或者私信的情况。
二、WebSQL安全风险详析
1、SQL注入
例如我们有一个URL为http:/blog.csdn.net/hfahe?id=1，它接收了一个id参数来进行本地数据库查询并输出，对应的SQL语句为“select name from user where id = 1”。
但是针对这个简单的SQL查询，攻击者可以构造一个虚假的输入数据“1 or 1 = 1”，那么我们的SQL语句将变为“select name from user where id = 1 or 1 = 1”。这就相当糟糕了，因为1=1这个条件总是成立的，那么这条语句将遍历数据库user表里的所有记录并进行输出。
利用这种方式，攻击者可以构造多种攻击的SQL语句，来操纵用户的本地数据库记录。
2、XSS与数据库操纵
在有XSS漏洞的情况下，攻击者获取本地数据需要如下几个步骤：
1)获取JavaScript数据库对象
2)获取SQLite上的表结构
3)获取数据表名
4)操作数据
例如如下脚本完整的实现了上面的步骤，我在Chrome控制台里运行即可得到用户本地数据库的表名，利用这个表名攻击者可以用任何SQL语句来完成攻击。
var dbo;
var table;
var usertable;
for(i in window) {
obj = window[i];
try {
if(obj.constructor.name=="Database"){
dbo = obj;
obj.transaction(function(tx){
tx.executeSql('SELECT name FROM sqlite_master WHERE type=\'table\'', [], function(tx,results) {
table = results;
},null);
});
}
} catch(ex) {}
}
if(table.rows.length > 1)
usertable = table.rows.item(1).name;
三、防御之道
针对WebSQL攻击，我们有如下方法预防：
1) 检查输入类型，过滤危险字符
我们需要保证输入类型符合预期，例如上面的id参数一定是数字类型;同时过滤掉危险的关键字和符号，像PHP里addslashes这个函数的作用一样。
2) 在SQL语句中使用参数形式
SQL语句是可以用参数形式的，例如
executeSql("SELECTname FROM stud WHERE id=" + input_id)
这种字符串拼接的形式并不安全，可以换为
executeSql("SELECTname FROM stud WHERE id=?“, [input_id]);)
这样能保证参数的输入符合设定的类型。
3)谨慎对待每一次SQL操作