Web客户端数据存储环境安全状态分析

　　SQL注入是一种攻击数据库的行为，攻击者把恶意SQL命令插入到Web表单的输入域或页面请求的查询字符串中，从而欺骗Web应用执行恶意的SQL命令，达到窃取数据或破坏的目的[6]。以往的SQL注入只针对运行在Web服务器端的数据库，并且通过服务器端的SQL查询来控制它。

　　Web客户端数据是指由Web应用发起的、并由浏览器或浏览器插件执行和控制的、在Web用户的系统上保存的数据，这些数据大多与Web用户有关。自从采用简单的Cookies作为HTTP的状态管理机制以来，Web站点就开始在用户的系统上保存数据。

　　为了满足Web应用的需求，后来出现了新的Web客户端数据存储技术。这些新技术常常使用其他存储机制，比如数据库，并且一般提供比Cookies更多的存储容量。Web客户端数据存储技术的发展和广泛采用，给Web应用带来了新的安全风险。比如客户端数据损坏、客户端数据泄露、客户端XSS和SQL注入等。这些风险会影响到Web应用的安全与可靠运行。

　　1 Web客户端数据存储技术

　　目前存在多种Web客户端数据存储技术，除了Cookies，还有微软的IE UserData和Silverlight、Adobe的Flash、Oracle的Java，以及与HTML 5有关的Web SQL数据库(Web SQL Database)、Web存储(Web Storage)、索引数据库API(Indexed Database API)等。在这些存储技术中，Cookies被所有的浏览器支持。其他技术则仅在部分浏览器中得到支持，并且有的技术还需要安装相应的浏览器插件才可以使用，如Flash。

　　为了防止不同的Web应用读取彼此的数据，上述所有的存储技术都采用了同一来源策略机制。来源通常由主机名、端口号，以及传输协议等界定。浏览器会记录所有Web客户端数据的来源。当某个Web应用访问本地存储的数据(即Web客户端数据)的时候，浏览器将检查该Web应用的来源和被访问数据的来源，只有当二者匹配的时候才允许访问[1]。

　　大多数Web客户端数据存储技术并不指定数据在客户端的保存期限，因此数据将一直保存在用户系统上，除非主动删除它们。不过Cookies是一个例外，它允许指定数据的到期时间。另外，不同的存储技术采用不同的存储机制，如纯文本、XML、数据库或其他专有的格式。

　　Web客户端数据的使用方式依赖于特定的Web应用。大多数情况下，数据被用作Web应用的输入。有时候数据也在本地使用，由客户端脚本加载它们，用以创建动态网页。

　　表1给出了目前常见的Web客户端数据存储技术。

　　2 Web客户端数据存储的安全风险

　　2.1 客户端XSS

　　跨站脚本XSS(Cross-Site Scripting)是目前Web应用中非常流行的漏洞。不同类型的XSS具有相同的特征：允许恶意JavaScript脚本在用户浏览器中运行。由于脚本是在被攻击的Web站点的上下文中运行的，因此攻击者可以访问正常情况下不能访问的资源。

　　XSS的传统形式是反射XSS，其特点是恶意脚本被用户发送到Web服务器(比如用户无意中点击了一个恶意链接)，然后又被反射回给用户。比反射XSS危害性更大的是存储XSS。它把恶意脚本注入到Web站点所使用的库中。如果这个库用于显示信息给用户，那么，被注入的恶意脚本将被呈现给访问这个站点的每一个用户。

　　当Web应用使用Web客户端数据存储的时候，特别是采用数据库作为存储机制的时候，攻击者就可能把恶意脚本注入到客户端的本地存储中。这是一种新的XSS，我们称之为客户端XSS，它完全位于本地并且使用客户端的存储能力。客户端XSS一旦注入成功，每次当Web页面使用本地存储的信息的时候，恶意脚本都会运行。

　　2.2 客户端SQL注入

　　Web客户端数据存储技术对数据库的支持，使客户端SQL注入成为可能。然而，普通的客户端SQL注入并无多大危害，因为攻击者并不能获得查询结果，结果会反馈给用户而不是攻击者。不过，如果在SQL注入中使用堆栈查询的话，则危害性可能非常大，因为它允许攻击者在客户端数据库上执行任意的SQL命令。

　　2.3 Web客户端数据损坏

　　Web应用无法控制用户对客户端数据的修改或删除。这会给Web应用带来影响，这种影响依赖于Web应用对数据的使用。比如，如果视频网站把用户调整后的音量保存在Flash的LSO文件中，则对LSO数据的修改或是损坏只能导致音量恢复到默认值。而如果某个网站利用Cookie中的某个值来表示用户的类型(普通用户或者管理员)，对这个值的修改则可以让普通用户变成管理员，从而拥有更大的权限。

　　2.4 Web客户端数据泄露

　　Web应用对存储在客户端的数据并没有多少控制，所以它无法保证数据的完整性。当存储的数据需要保密，或者能够用来访问敏感信息时，数据泄露就成为一个严重问题。像XSS和SQL注入攻击会让Web客户端数据处于危险中。另外，当攻击者能够访问用户的文件系统时，数据泄露也会发生。让Web客户端数据泄露更加复杂的一个因素是大部分这类数据并没有生命期(Cookies是一个例外)，可以长期保存在用户的计算机上，这增加了数据泄露的可能性。

　　2.5 绕过同一来源策略

　　同一来源策略对于保护Web客户端数据是极为重要的，绕过该策略会导致严重的后果。那么，攻击者如何绕过同一来源策略呢?首先，XSS的所有变种都允许攻击者绕过同一来源策略，因为它能够让脚本在被攻击的域的上下文中运行;其次，Web浏览器中的某些漏洞也会导致无法正常实施该策略。此类漏洞在许多浏览器上都存在。还有，DNS服务器的DNS缓存污染也可以用来绕过该策略。

　　另外，当Web应用没有恰当地定义来源的时候，也会出现绕过同一来源策略的问题。比如，Cookie机制允许开发者使用“domain”属性设置来源。假如站点good.enjoy.com所指定的域是.enjoy.com。当域enjoy.com下的不同(虚拟)主机的所有权分散的时候，攻击者可以建立一个域名为devil.enjoy.com的网站，然后他就可以访问站点good.enjoy.com保存的cookie信息。在博客和社交网站上，这是一个典型的问题，因为此时每个用户在相同的主域下都有自己的虚拟主机名。相似的问题也存在于共享服务器上——几个用户共享同一个主机上的Web空间。

　　3 Web客户端数据存储安全风险对策

　　3.1 不要信任本地存储的数据

　　由于Web应用无法控制客户端数据的完整性，Web应用开发者永远不应该信任本地存储的数据。如果你的Web应用确实需要在客户端存储数据，而你又希望数据是完整可靠的，则可以使用数字签名技术来保证数据的完整性。

　　3.2 使用加密技术

　　加密Web客户端数据可以在一定程度上阻止恶意程序读取明文数据。在客户端解密数据会泄漏明文，加密和解密操作必须在Web服务器上进行。不过，加密技术并不能保证客户端数据总是安全的。如果服务器解密数据后又把明文信息返回给浏览器，攻击者仍然有可能利用XSS来获得信息。

　　3.3 防止XSS

　　对于传统的XSS，可以通过在服务器端脚本中引入适当的输出编码机制来解决。不过，如果使用Web客户端数据，服务器可能无法看到它们，因此无法重新编码。当信息存储在客户端并由客户端的脚本检索的时候，这种情况就可能发生。为了防止客户端XSS，开发者需要在客户端以JavaScript函数的形式引入输出编码机制。这种编码机制主要是在输出的数据中重新编码不安全的字符，比如，把小于号“<”编码成“<;”。这会让攻击者在Web应用的输出中注入标签(这样就可以执行恶意JavaScript脚本)的行为变得非常困难。

　　3.4 使用参数化的查询

　　如果在Web应用中使用客户端数据库，同时使用SQL接口(如HTML 5 Web SQL Database)，应该使用参数化的查询而不是动态串方式。

　　3.5 指定的数据来源应尽可能窄

　　如果指定的数据来源过于宽松，存储在用户端的数据可能会被其他Web应用读取。在共享域中，这个问题更加严重。如果采用Cookies技术，可以使用“path”属性来进一步缩小允许读写数据的来源。然而，较新的存储技术如HTML 5客户端存储技术并不支持类似的机制[7]，这意味着在共享服务器上不应该使用这类存储技术。

　　3.6 及时删除不再使用的客户端数据

　　除了Cookies，其他Web客户端数据存储技术并不支持数据的自动删除。为了防止这种情况的发生，Web应用应负责删除不再需要的数据。

期刊VIP网，您身边的高端学术顾问

文章名称： Web客户端数据存储环境安全状态分析

文章地址： http://www.qikanvip.com/jisuanjixinxiguanli/14288.html