HTML5客户端存储的安全性探析

张 坤，吕义正

（黄山学院 信息工程学院，安徽 黄山245041）

1 引 言

当前随着各浏览器对HTML5 支持程度的不断增加，HTML5 正在逐步被各大主流网站所接受，HTML5 的相应新特性也逐步被使用在一些最新的网站当中，这其中就包含了本文所要探讨的内容—Web 客户端存储。HTML5 标准定义了可以在浏览器端使用Javascript 脚本存取数据的客户端存储及客户端数据库，随着HTML5 标准的逐步确立，该技术的使用场景也越来越广泛。

2 技术与分析背景

客户端数据存储在网页初始阶段就已经存在，以Coolies，Flash 和Google Gears 客户端数据库作为主要的存储方式，但是这几项又都有各自的不足之处，比如Cookies 和Flash 支持的数据量太小，Flash 和Google Gears 需要安装插件等等，给数据的分布式存放造成了很大的困扰[1]。

现如今随着HTML5 标准的逐渐明确，其客户端存储技术出现了Web Storage, File System,IndexedDB 和Web SQL 4 大分类[2]，而由于大浏览器厂商技术方向的不同也造成了以上存储方式被各浏览器的支持程度不尽相同。但是无论是哪种存储方式，都已经大大增加了客户端可存储数据的容量。表1为各浏览器对此4 类文件的支持情况列表。

客户端存储的快速发展也带来了一系列关于数据安全性上的疑问，诚然新的客户端存储技术给了程序设计人员更多的数据存放的方法与手段，但由于所有数据存放于客户端，并不能完全被服务器端掌控，并且在客户端可以被脚本存取，很有可能存在数据丢失、泄露等问题，增加了数据的风险性。

3 安全性分析

如今新标准允许将大量的数据存放于客户端，在搜索上可以大大缩减服务端的压力，同时甚至可以完成数据的离线浏览和计算。但技术带来便利的同时也带来了数据的风险性。在对几大主流网站进行的正常使用分析测试的过程中发现，基本上所有的主流网站都已经开始使用Web Storage来存放某些特定的数据，部分网站甚至已经开始使用IndexedDB 作为本地数据库。而在离线存储部分，大量的阅读性网站开始使用File System 技术作为手机端的本地数据存放手段。

表1 本地存储技术浏览器支持情况列表

3.1 客户端数据不可信

由于前端数据尤其是离线数据可能因为很多的原因出现被更改甚至丢失的情况，因此在程序的设计过程中始终要牢记的一点就是保存在前端缓存中的数据是不可信的。不能够根据其中的不可信数据做重要的决策，并且将其不经验证直接保存在数据库之中[3]。

3.2 数据存放的选择

对于一个小说网站来说，由于小说数据不存在敏感性问题，站点可以一次性将小说的几个章节甚至整本小说存放在客户端而无需担心数据泄露，这样可以很好的提高用户在网站浏览时的流畅度，并且减少客户发送请求的次数从而降低服务器端的压力。

正确的使用可以给网站带来很好的阅读体验，但是危险往往出现在对新兴技术的滥用上。在早期客户端存储的使用过程中就曾经出现过，客户的邮箱信息，个人信息甚至银行卡信息被随意的存放在前端的情况，从而导致数据的泄露以致经济上的损失[4]。因此在选择存放内容的时候一定要慎重。这里的存放建议是，不要把数据库中都不是明文存放的数据放在前端，是明文存放的内容一定也要选择其中敏感度较低的内容，必要时采取相应的加密技术。

3.3 敏感数据的存放方式

有些时候为达到某种效果或要求，系统不得不在前台存放一些敏感数据，很显然这种情况下数据和系统的风险性就会变得很大，为了规避这种情况下的数据风险，可以在系统中做如下的配置。

1.使用Https 协议。以用于测试的Http 网站为例，当使用Imposter 工具模拟了DNS 欺骗性攻击时，攻击成功并可以由此获得了客户端存放的信息内容；然而由于在https 协议下存放的客户端数据是不可以被http 的访问所读取的，这样的配置可以在很大程度上防御此类型攻击。

2.使用具有唯一性的数据ID 或数据库名称。黑客在获取信息性时常会使用一些试探性的攻击方式，如果在客户端存储数据时使用常用的或者固定的id 或数据库名称，在遭受到跨域攻击（XSS）时，往往可能会导致数据被脚本截获，导致数据的泄露。同时如果系统使用一些随机名称的话，当用户使用离线数据的时候，又会给系统获取数据信息带来很大的麻烦[5]。所以如果网站不使用离线数据的话，可以直接使用随机名称，并且把名称存放在服务器端，如果网站需要使用离线数据的情况下，站点可以在启用离线数据的同时要求用户提供一个离线密码，id或数据库名称就可以使用用户名+离线密码的形式，这样的方式可以有效提高黑客攻击的难度。

3.敏感数据的加密。对于某些无需在前台读取，但需要保存在前台以备后台调用的数据，可以后台生成数据时直接进行加密处理，避免出现明文直接存放的情况。

3.4 存放数据的时机

通常如果需要在客户端存放大量数据，尤其是其中包含敏感数据的时候，客户需要有相应的知情权和选择权，因此设计上需要在网站上有所提示并提供相应选择，并且通常这样的授权都是针对于某一客户端的。例如人们通常在安全网络环境（家里）使用个人网站时通常会允许更高的权限，但是在办公室又会为了保护隐私而放弃该功能，因此需要有一种方式来鉴别不同的客户端。

如果仅仅在客户端保存相应的许可信息的话，很有可能被黑客复制并利用，导致数据的泄露，所以需要的鉴别方式应该能够有效的防止这一可能性。因此建议在数据中存放MD5 加密过的最近一次的用户Session ID，并将此信息同步保存在服务器端，当用户登录时，可以通过信息的比对确认该用户是否存在。数据只有在用户同意存放之后才会被保存在客户端，否则需要通过其他方式来达到同一效果[6]。

3.5 防范跨域攻击（XSS）的方法

由于数据信息保存在客户端，因此很有可能遭受XSS 攻击而被篡改。往常为了防范此类攻击，网站会在数据存放前在客户端对数据进行编码操作以避免可执行代码的运行，然而如果将传统的客户端存储转为使用HTML5 客户端存储，所有信息可以被前台脚本读写的情况下，前台数据很有可能被黑客攻击并篡改，导致数据库中信息直接被保存为XSS 恶意脚本[7]。因此在HTML5 时代除了对存放数据需要进行编码操作外，在读取信息的同时也需要进行编码操作以避免恶意脚本的攻击。

3.6 前端SQL 注入风险

目前来说支持前端SQL 的只有Web SQL，但由于SQL 语言本身并没有一个固定的标准，所以此项功能已经被制定HTML5 标准的W3C 团队所否定，虽然有一些浏览器已经对Web SQL 进行支持，但是为了产品的跨平台使用能力，一般不建议使用前端SQL 的功能，当然也就能够避免由客户端数据库带来的SQL 注入风险。

4 总 结

随着各不同平台浏览器的支持，HTML5 的技术标准正在逐渐走向成熟，使用该技术网站的不断增加，其暴露的风险也将越来越多，目前国内网站在使用HTML5 存储技术的时候主要关注的是功能和性能，并且存在新功能的滥用现象，在安全性上并没有做很大的修正，以至于不少网站存在数据风险，尤其是在应对跨域攻击这方面的设定相对薄弱。不少站点还在致力于保护服务器端的安全，却往往忽略的了前端数据带来的风险，可以预见不久的将来，随着各种客户端存储的使用，网站暴露的风险也会越来越多，对于HTML5 的安全性研究也会随之逐步深入。

[1]Stuttard D，Pinto M． The Web Application Hacker's Handbook: Finding and Exploiting Security Flaws ［M］．2nd ed．Wiley，2012：20-23．

[2]Lubbers P，Smith R，Sali F．HTML5 高级程序设计［M］．北京:人民邮电出版社，2011：77-78．

[3]Hannax S，Shinz E C R，Akhawe D，et al． The Emperor’s New API:On the ( In) Secure Usage of New Client Side Primitives ［M］． IEEE Web 2.0 Security and Privacy Workshop，2010：23-25．

[4]Schmidt M，Rthlisberger T．HTML5 web,security ［EB/OL］.http://media.hacking-lab.com/hlnews/HTML5_Web_Security_v1.0.pdf,Compass Security AG, December 6th,2011-05-08.

[5]McArdle R． HTML5 OVERVIEW: A LOOK AT HTML5 ATTACK SCENARIOS ［EB/OL］．

http://www.trendmicro.com/cloud-content/us/pdfs/security-intelligence/reports/rpt_html5-attack-scenarios.pdf, Trend Micro Research Paper, 2011-04-10.

[6]Kuppan L． Attacking with HTML5［EB/OL］．https://media.blackhat.com/bh-ad-10/Kuppan/Blackhat-AD-2010-Kuppan-Attacking -with -HTML5 -slides.pdf, Blackhat -AD,2010-06-02．

[7]董霁,杨丁宁,史德年.基于HTML5 技术的移动智能终端应用及安全问题研究[J].现代电信科技,2012，(12)：1-7.