下载文档原格式
HTML5Web Storage攻击平安风险详解HTML5Web Storage攻击平安风险详解HTML5支持WebStorage，开发者可以为应用创建本地存储，存储一些有用的信息。
例如LocalStorage可以长期存储，而且存放空间很大，一般是5M，极大的解决了之前只能用Cookie来存储数据的容量小、存取不便、简单被清除的问题。
这个功能为客户端供应了极大的敏捷性。
下面跟一起来了解一下吧!一、WebStorage简介HTML5支持WebStorage，开发者可以为应用创建本地存储，存储一些有用的信息。
例如LocalStorage 可以长期存储，而且存放空间很大，一般是5M，极大的解决了之前只能用Cookie来存储数据的容量小、存取不便、简单被清除的问题。
这个功能为客户端供应了极大的敏捷性。
二、攻击方式LocalStorage的API都是通过Javascript供应的.，这样攻击者可以通过XSS攻击窃取信息，例如用户token或者资料。
攻击者可以用下面的脚本遍历本地存储。
同时要提一句，LocalStorage并不是唯一暴露本地信息的方式。
我们现在许多开发者有一个不好的习惯，为了便利，把许多关键信息放在全局变量里，例如用户名、密码、邮箱等等。
数据不放在合适的作用域里会带来严峻的平安问题，例如我们可以用下面的脚本遍历全局变量来获得信息。
三、攻击工具HTML5dump的定义是“JavaScriptthat dump all HTML5 local storage”，它也能输出HTML5 SessionStorage、全局变量、LocalStorage和本地数据库存储。
四、防备之道对于WebStorage攻击的防备措施是：1、数据放在合适的作用域里例如用户sessionID就不要用LocalStorage存储，而须要放在sessionStorage里。
而用户数据不要储存在全局变量里，而应当放在临时变量或者局部变量里。
HTML5安全分析：本地存储在上一篇文章《HTML5跨域消息发送安全性分析》中，我们讨论了在HTML5下的跨域消息传递。
本文将带你去了解另外一个特性——本地存储。
本地存储本地存储也是HTML5的新特性之一，最开始是在Mozilla 1.5上的，后来渐渐被HTML5规范接受。
通过JavaScript的localStorage和sessionStorage对象，我们可以使用HTML5的这个新特性。
基于键值值匹配，这些JavaScript对象允许我们存储，检索和删除数据。
在HTML5中，本地存储是一个window的属性，包括localStorage和sessionStorage，从名字应该可以很清楚的辨认二者的区别，前者是一直存在本地的，后者只是伴随着session，窗口一旦关闭就没了，二者用法完全相同。
下面是一个HTML5应用程序示例，使用HTML5新的本地存储特性，我们可以使用“Show Data”按钮检索存储在数据库中的数据。
我们先来看看这个站点的源，假设http://localhost:8383/为“应用程序A”，整理一下：Name: Application AOrigin: http://localhost:8383/单击“Show Data”按钮预期结果：我们能够访问应用程序A存储在数据库中的数据。
现在尝试通过不同源来访问应用程序A存储在数据库中的数据。
假设这是应用程序B，下面为详情：Name: Application BOrigin: http://localhost/注意了，应用程序B与应用程序A端口号不同，属于不同源。
点击“Show Data”按钮。
当我点击“Show Data”按钮的时候，明显感觉到网页没有反应，这是因为应用程序不同源。
为了实验准确，我们再次进行确认。
我们运行与应用程序A同源的应用程序CName: Application COrigin: http://localhost:8383/点击“Show Data”按钮，观察结果很好，我们能够从应用程序C访问到数据，因为它与应用程序A同源。
开发人员需要牢记的HTML 5安全问题
应用程序平安专家表示，HTML5给开发人员带来了新的平安挑战。
苹果公司与Adobe公司之间的口水战带来对HTML 5命运的诸多猜想，尽管HTML 5的实现还有很长的路要走，但可以绝对的一点是，运用HTML 5的开发人员将需要为应用程序平安开发生命周期部署新的平安功能以应对HTML5带来的平安挑战。
那么HTML5将会对我们需要笼罩的袭击面带来怎样的影响？本文将探讨关于HTML 5几个重要平安问题。
客户端存储
早期版本的HTML仅允许网站将cookies作为本地信息存储，而这些空间相对较小，仅适用于存储容易的档案信息或者作为存储在其他位置的数据(例如会话ID)的标识符，Denim集团应用程序平安讨论部门的主管Dan Cornell表示。
然而，HTML5 LocalStorage则允许扫瞄器本地存储大量据库，允许用法新类型应用程序。
随之而来的风险就是，敏感数据可能被存储在本地用户工作站，而物理拜访或者破坏该工作站的袭击者，就能够轻松获得敏感数据，
第1页共4页。
H5 APP安全风险及解决方案目录一.HTML5 概述 (3)二.HTML5 应用开发模式 (4)三.H5 应用架构分析 (5)四.H5 应用安全风险 (6)4.1H5 应用面临的安全风险 (6)4.2针对移动应用的攻击 (6)4.2.1静态攻击 (6)4.2.2动态攻击 (7)4.3个人信息违规收集 (7)4.4安全建设目标 (8)五.H5 应用安全解决方案 SDK (9)5.1SDK 授权安全 (9)5.2客户端程序安全 (10)5.2.1客户端程序保护 (10)5.2.2客户端程序签名 (10)5.2.3移动客户端运行环境安全 (11)5.2.4数据存储安全 (11)5.2.5数据交互安全 (12)5.2.6资源管理 (13)5.3通信安全 (13)5.3.1SSL/TLS 安全配置 (13)5.3.2客户端证书有效性校验 (14)5.3.3数据传输安全 (14)5.4服务器端安全 (15)5.4.1SDK 授权 (15)5.4.2身份安全认证 (15)5.4.3短信验证码安全 (18)5.4.4访问控制 (18)5.4.5应用接口安全 (19)5.4.6数据交互安全 (19)5.4.7数据存储安全 (22)5.5个人信息安全 (23)5.5.1个人信息安全 (23)5.5.2运营者对用户权利的保障 (24)- I -一. HTML5 概述网页技术（B/S）是互联网技术在各个行业业务应用的广泛和重要的技术领域，HTML5 是基于兼容性、实用性、互通性以及通用访问性的理念设计而成的，随着 HTML5（以下简称“H5”）的发布和应用，H5 已经成为了互联网全新的框架和平台，包括提供免插件的音视频、图像动画、本地存储以及更多酷炫而且重要的功能，并使这些应用标准化和开放化，从而能够轻松实现类似桌面的应用体验，并且，H5 的最显著的优势在于跨平台性，用 H5 搭建的站点应用可以兼容 PC 端与移动端、windows 与 Linux、安卓和 iOS，它可以轻易地嵌入到各种不同的开放平台、应用平台上。
HTML5的安全风险详析HTML5的安全风险详析关于HTML5存在的安全风险你了解多少?下面YJBYS店铺为大家详细解析一下HTML5的安全风险!希望对大家有所帮助!一、CORS攻击CORS-CrossOrigin Resources Sharing，也即跨源资源共享，它定义了一种浏览器和服务器交互的方式来确定是否允许跨域请求。
它是一个妥协，有更大的灵活性，但比起简单地允许所有这些的要求来说更加安全。
简言之，CORS就是为了让AJAX可以实现可控的跨域访问而生的。
一、从SOP到CORSSOP就是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的系统目前包括、GoogleCloudStorage API等，主要是为开放平台向第三方提供访问的能力。
二、CORS带来的风险CORS非常有用，可以共享许多内容，不过这里存在风险。
避免常见的六种HTML5错误用法一、不要使用section作为div的替代品人们在标签使用中最常见到的错误之一就是随意将HTML5的<section>等价于<div>——具体地说，就是直接用作替代品(用于样式)。
在XHTML或者HTML4中，我们常看到这样的代码：<!-- HTML 4-style code --><div id="wrapper"><div id="header"><h1>My super duper page</h1><!-- Header content --></div><div id="main"><!-- Page content --></div><div id="secondary"><!-- Secondary content --></div><div id="footer"><!-- Footer content --></div></div>而现在在HTML5中，会是这样：<!-- 请不要复制这些代码！这是错误的！ --><section id="wrapper"><header><h1>My super duper page</h1><!-- Header content --></header><section id="main"><!-- Page content --></section><section id="secondary"><!-- Secondary content --></section><footer><!-- Footer content --></footer></section>这样使用并不正确：<section>并不是样式容器。
HTML5 App的代码注入攻击与防范一、代码注入攻击Web技术有一个广为人知的危险特性：它允许数据和代码混杂到一起，比如当一个字符串包含数据和代码时，代码会被识别出来并且被JavaScript引擎执行。
这是一种功能设计，这样可以让JavaScript代码很方便的嵌入到 HTML 页面中执行。
不幸的是，这个功能的后果是，如果开发商只想处理数据，但使用了错误的API，字符串中的代码会自动和错误的触发。
如果这样的数据和代码混合字符串来自不可信的输入，恶意代码就可以被注入到应用程序中执行，这就是JavaScript代码注入攻击。
其中一种典型代表就是被我们称为跨站点脚本（XSS）的，根据OWASP top10［11］，这是目前Web应用程序中的第三常见的安全风险。
3.1 概述使用Web技术开发的手机app将制造一种新的蠕虫，它可以将针对特定的手机应用程序注入恶意代码。
这种攻击破坏性比Web应用程序的XSS攻击要大很多，不仅仅因为我们给手机上安装的app授予了很多权限，更因为在XSS攻击中恶意代码的注入大多数都需要通过Web应用服务器，这是恶意数据到达他们攻击目标的唯一通道，而在手机应用场景下有非常多可利用的攻击通道。
这些通道的一个共同的特点是，他们都是连接移动设备和外界的通道，实质上是遭受从另一个设备（不一定是一个手机设备）进行攻击的通道。
图2（a）说明了攻击的基本思路。
由于智能手机实时地与外面的世界交互，和传统的网络通道相比有更多新的通道可以输入不可信的数据到手机设备。
例如，二维码、RFID标签、媒体文件、Bluetooth设备和Wi-Fi接入点等，恶意代码可以嵌入在这些通道数据里面。
如果数据混合的代码没有机会被触发，就不会有代码执行造成的风险。
这就是natvie语言开发的手机app能够免疫这种代码注入攻击的原因。
例如，即使攻击者可以嵌入Java代码到二维码里面，也没有机会误触发执行这些代码。
但由于web技术的危险特性，这不适用于HTML5 app。
基于HTML5的Web前端安全性研究摘要：Web安全的重点正从服务器端转移到Web前端。
伴随着HTML5新技术的兴起，Web前端的安全问题更为突出。
对传统的Web前端安全问题XSS、CSRF、界面操作劫持进行了阐述，对由HTML5中的新标签属性、Web Workers、Web Storage、postMessage、CSS3等新技术所带来的安全问题进行了全面细致的分析，给出了一系列安全策略。
关键词：Web前端；XSS；CSRF；界面操作劫持；HTML5DOIDOI：10.11907/rjdk.161088中图分类号：TP309文献标识码：A 文章编号：1672-7800（2016）005-0185-030 引言网络安全总是随着时代的变迁而变化的。
早期的互联网，Web并非主流应用，因为功能很弱，黑客们往往不屑攻击。
随着互联网的发展，Web功能日渐强大，防火墙等技术的应用，使得非Web服务很难被攻击，于是黑客们将攻击重点转向了Web应用。
如果说早期Web1.0时代的安全性问题主要体现在操作系统、缓冲区溢出、数据库SQL注入等Web服务器端的话，那么到了Web2.0时代，安全问题就集中在XSS、CSRF、ClickJacking等Web前端。
伴随着移动互联的发展，HTML5技术成为大量黑客的目标。
所以，本文对于传统的Web前端以及HTML5出现后所带来的安全问题进行了研究和探讨。
1 传统的Web前端安全性问题1.1 XSSXSS全称Cross Site Script，中文名跨站脚本攻击，它是指由于黑客往网页中注入了恶意的脚本，从而导致浏览器在呈现页面时执行了非预期的恶意功能。
XSS分为3种类型：①反射型XSS，是黑客利用一些社会工程学诱骗用户点击一个恶意链接，服务器直接将这个带有恶意脚本的内容反射给用户的浏览器，从而攻击成功；②存储型XSS，是黑客在自己的浏览器中提交一段带有恶意脚本的留言，这个留言会被服务器保存到数据库中，下次其它用户查看这段留言时就会被攻击；③DOM Base XSS，属于一种特殊的反射型XSS，不需要被服务器端解析响应，直接在浏览器客户端被JavaScript 代码解析。
0 引言对于Web平台来说HTML5技术是重要的基础,HTML5技术开发是经过苹果、谷歌等诸多公司一同酝酿出来的技术成果,主要的好处是HTML5技术是公开性的,同时HTML5技术开发也有诸多的有点存在,比如在页面优化以及处理等,HTML5技术都是有非常明显的应用优势。
1 HTML5技术概述HTML5技术,是超文本语言的信号版本,也是建立网络应用的一种基准。
借助对HTML5技术有效应用,可以让终端浏览器得到一定程度上的强化,同时在跨平台上HTML5技术也是可以起到提升交互能力的作用,对设备也有一定的适应力。
HTML5技术本身是有一定高效性的,在图形处理方面展现出非常明显的优势,所以当下HTML5技术被用到网络开发以及云技术等方面。
2 HTML5技术的特性及安全性2.1 HTML5技术的新特性(1)本地存储。
过去在客户端要进行品质以及登录信息存储,要借助cookie,容量小,还需要额外库。
而HTML5技术的帮助下,则是可以让更多应用得当终端存储,最大存储量谓5M。
在读写方面也是更加便捷,因此HTML5技术适应了终端运行诸多的要求。
让本地计算机具备更强的存储性能,减轻服务器的运行压力[1]。
(2)双工通信。
HTML5技术可以支持双工通信,以往在HTML中,浏览器可以实现单项通信,因此开发人员提供长轮询技术,便于在端口进行信息推送。
而对反向AJAX进行借鉴的情况下,可以实现双工通信。
该技术是在建立连接之后,可以在两端口间借助双工模式,实现对协议数据的传输,并且这种特性有强大以及双向的特点。
(3)WEBWORK ERS功能。
该功能是多线程解决的一种方案,启动性能非常良好,在长期持续运行的情况下,消耗也是非常理想的。
这种特性是在脚本的主线程中开辟出多个新线程,实现对数据的交换,相互之间不会阻塞效果。
避免了负载高的情况下,页面出现假死的情况。
2.2 HTML5技术的安全性HTML5技术具备这些良好的优势,促进Web应用更加丰富,但是因为架构不成熟,导致很多的漏洞是容易被黑客攻击的,还是会造成诸多的安全威胁。
HTML5安全风险详析之一：CORS攻击
收集自21天 一、从SOP到CORS
SOP就是Same Origin Policy同源策略，指一个域的文档或脚本，不能获取或修改另一个域的文档的属性。
也就是Ajax不能跨域访问，我们之前的Web资源访问的根本策略都是建立在SOP上的。
它导致很多web开发者很痛苦，后来搞出很多跨域方案，比如JSONP和flash socket。
如下图所示：
后来出现了CORS-CrossOrigin Resources Sharing，也即跨源资源共享，它定义了一种浏览器和服务器交互的方式来确定是否允许跨域请求。
它是一个妥协，有更大的灵活性，但比起简单地允许所有这些的要求来说更加安全。
简言之，CORS就是为了让AJAX可以实现可控的跨域访问而生的。
具体可以参见我的这篇文章《HTML5安全：CORS（跨域资源共享）简介》。
示意如下图所示：
现在W3C的官方文档目前还是工作草案，但是正在朝着W3C推荐的方向前进。
不过目前许多现代浏览器都提供了对它的支持。
服务器端对于CORS的支持，主要就是通过设置Access-Control-Allow-Origin来进行的。
如果浏览器检测到相应的设置，就可以允许Ajax进行跨域的访问。
例如：
[html]view plaincopyprint?
1.Access–Control-Allow-Origin:
应用CORS的系统目前包括、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头一般没有其他日志记录。
受害者并不能说他的系统被攻破，因为没有任何任何恶意软件或系统泄漏的痕迹。
三、攻击工具
Shell of the Future是一个反向WebShell处理器，它利用HTML5的跨站请求来劫持会话。
四、防御之道
1、不信任未经身份验证的跨域请求，应该首先验证Session ID或者Cookie。
2、对于请求方来说验证接收的数据有效性，服务方仅暴露最少最必须的功能。
3、通过多种条件屏蔽掉非法的请求，例如HTTP头、参数等。
来自蒋宇捷的博客。
