Web或者移动的客户端应用程序的安全

一个面向终端用户的区块链项目都会有Web或者移动的客户端应用程序。对于这些客户端的应用程序，我们需要了解由于编程不小心引起的安全风险。我们这里需要介绍一下开放式Web应用程序安全项目（Open Web Application Security Project，OWASP）。开放式Web应用程序安全项目是一个开源组织，它提供有关计算机和互联网应用程序的安全信息。其目的是协助个人、企业和机构来发现和和使用安全可信的应用软件。OWASP 有一个Top 10的项目。这个项目的目标是找出Web应用系统所面临的最严重的风险来提高人们对应用程序安全的关注度。Top 10项目被众多标准、书籍、工具和相关组织引用，包括MITRE、PCI DSS、DISA、 FTC等。OWASP Top 10最初于2003 年发布，并于2004年和2007年相继做了少许的修改更新。2010版做了修改以对风险进行排序，而不仅仅对于流行程度。这种模式在2013版和最新的2017版得到了延续。下面介绍OWASP 的Top 10 安全漏洞。

Web或者移动的客户端应用程序的安全

注入

注入，注入缺陷，例如SQL注入、OS命令注入、LDAP注入等，会在攻击者向应用服务端发送以分隔符作为命令或者查询的一部分时就会发生。攻击者的有害数据中分隔符造成的陷阱，会执行攻击构造的未预知的命令或者访问未授权数据。

（1）我是否存在注入漏洞

检测应用程序是否存在注入漏洞的最好的办法就是确认所有解释器的使用都明确地将不可信数据从命令语句或查询语句中区分出来。在许多情况下，建议避免解释器或禁用它（例如XXE）。对于SQL调用，这就意味着在所有准备语句（prepared statements）和存储过程（stored procedures） 中使用绑定变量（bind variables），并避免使用动态查询语句。

检查应用程序是否安全使用解释器的最快最有效的方法是代码审查。代码分析工具能帮助安全分析者找到使用解释器的代码并追踪应用的数据流。渗透测试者通过创建攻击的方法来确认这些漏洞。

可以执行应用程序的自动动态扫描器能够提供一些信息，帮助确认一些可利用的注入漏洞是否存在。然而，扫描器并非总能达到解释器，所以不容易检测到一个攻击是否成功。不恰当的错误处理使得注入漏洞更容易被发现。

（2）我如何防止注入漏洞

防止注入漏洞需要将不可信数据从命令及查询中区分开。

1）最佳选择是使用安全的API，完全避免使用解释器或提供参数化界面的API。但要注意有些参数化的API，比如存储过程（stored procedures），如果使用不当，仍然可以引入注入漏洞。

2）如果没法使用一个参数化的API，那么你应该使用解释器具体的escape语法来避免特殊字符。 OWASP的ESAPI就有一些escape例程。

3）使用正面的或“白名单”的具有恰当的规范化的输入验证方法同样会有助于防止注入攻击。但由于很多应用在输入中需要特殊字符，这一方法不是完整的防护方法。OWASP的ESAPI中包含一个白名单输入验证例程的扩展库。

4）在区块链项目的Web端，应该避免动态调用智能合约。现在大部分区块链的数据是用键和值（Key/Value)形式存储，应该避免区块链项目的Web端的不可信数据。也有一些区块链有SQL作为数据的存储。因此SQL注入也是这些区块链项目需要关注的问题。

（3）攻击案例

案例 #1：应用程序在下面存在漏洞的SQL语句的构造中使用不可信数据：

String query = "SELECT * FROM accounts WHERE

custID='" + request.getParameter("id") + "'";

案例 #2：同样的，框架应用的盲目信任，仍然可能导致查 询语句的漏洞。（例如：Hibernate查询语言（HQL））：

Query HQLQuery = session.createQuery("FROM accounts

WHERE custID='" + request.getParameter("id") + "'");

在这两个案例中，攻击者在浏览器中将“id”参数的值修改 成 ’ or’1’=’1。如：

http://example.com/app/accountView?id=' or '1'='1

这样查询语句的意义就变成了从accounts表中返回所有的 记录。更危险的攻击可能导致数据被篡改甚至是存储过程被调用。

失效的身份认证和会话管理

与身份认证和会话管理相关的应用功能经常实现的不正确，允许攻击者可以构造密码、密钥、或者会话令牌或者利用Web系统的实现缺陷，假冒其他用户的身份。

（1） 我存在会话劫持漏洞么?

以下情况可能产生漏洞：

1）用户身份验证凭证没有使用哈希或加密保护。 详见“敏感数据泄露”部分。

2）认证凭证可猜测，或者能够通过薄弱的的帐户管理功能（例如账户创建、密码修改、密码恢复, 弱会话ID）重写。

3）会话ID暴露在URL里（例如，URL重写）。

4）会话ID容易受到会话固定（session fixation）的攻击。

5）会话ID没有超时限制，或者用户会话或身份验证令牌特别是单点登录令牌在用户注销时没有失效。

6）成功注册后，会话ID没有轮转。

7）密码、会话ID和其他认证凭据使用未加密连接传输。详见“敏感数据泄露”部分。

（2） 我如何防止

我们的建议是让开发人员使用如下资源。

1）一套单一的强大的认证和会话管理系统。这套控制系统应该做下面的事情。

第一，满足OWASP的应用程序安全验证标准（ASVS） 中V2（认证）和V3（会话管理）中制定的所有认证和会话管理的要求。

第二，具有简单的开发界面ESAPI认证器和用户 API 是可以仿照、使用或扩展的好范例。

2）企业同样也要做出巨大努力来避免跨站漏洞，因为这 一漏洞可以用来盗窃用户会话ID。 详见“跨站脚本”。

3）有关区块链的身份管理，我们会在本书其他地方详细介绍。

（3）攻击案例

案例 #1：机票预订应用程序支持URL重写，把会话ID放在 URL里。

http://example.com/sale/saleitems;jsessionid=

2P0OC2JSNDLPSKHCJUN2JV?dest=Hawaii

该网站一个经过认证的用户希望让他朋友知道这个机票打折信息。他将上面链接通过邮件发给他朋友们，并不知道 自己已经泄漏了自己的会话ID。 当他的朋友们使用上面的链接时，他们将会使用他的会话和信用卡。

案例#2：应用程序超时设置不当。用户使用公共计算机访问网站。离开时，该用户没有点击退出，而是直接关闭浏览器。攻击者在一个小时后能使用相同浏览器通过身份认证。

案例#3：内部或外部攻击者进入系统的密码数据库。存储在数据库中的用户密码没有被加密，所有用户的密码都被攻击者获得。

下一章我们将介绍跨站脚本漏洞及不安全的直接对象引用

感谢机械工业出版社华章分社的投稿，本文来自于华章出版的著作《区块链安全技术指南》。

作者简介：

黄连金

硅谷Dynamic Fintech Group管理合伙人

吴思进

33复杂美创始人及CEO

曹锋

PCHAIN发起人，中物联区块链协会首席科学家

季宙栋

Onchain分布科技首席战略官，本体联合创始人，

马臣云

北京信任度科技CEO、信息安全专家、产品管理专家

李恩典

美国分布式商业应用公司董事与中国区总裁

徐浩铭

CyberVein数脉链项目技术负责人

翁俊杰

IBM 10余年开发及解决方案经验，批Fabric应用开发者，NEO核心开发者之一

扫描上方微信

备注“入群”，小助手拉你进群

活动多多，交流多多

矩阵财经出品

转载请注明：矩阵财经（矩阵数字经济智库）