金融数据泄露原因分析

　　安华金和通过对大量金融行业安全漏洞进行统计分析，发现SQL注入依然是金融业最大威胁。命令执行(框架漏洞)紧随其后占据了13%的比例。而其中越权类漏洞数量占比明显高于其他行业。

　　▲2015年9至11月金融行业安全漏洞类型

　　按照各行业深入探查不难发现：

　　1.银行行业中民营银行安全漏洞数量明显高于国有银行。

　　2.金融业漏洞威胁大，高危漏洞占到总漏洞数的94.56%

　　3.银行的APP业务成为隐含漏洞的重灾区

　　4.应用系统权限绕过漏洞五花八门

　　5.虽然有WAF，但SQl注入依然强劲。

　　整个金融行业中漏洞种类最全的就是互联网金融。下面我们着重介绍一下互联网金融业中的漏洞。

　　▲互联网金融安全漏洞类型

　　互联网金融业的漏洞数量虽然不是最多，但种类最全，分布也较为平衡。因为简单易用，用户对互联网金融的接受度普遍比较高。从各种宝到名目繁杂的P2P，互联网金融是金融业界的新宠儿。但由于该行业缺乏严格的政策管理和代码审计，业务发展的速度又远超安全可提供的支撑能力，前台代码质量较低，导致出现大量设计逻辑错误、SQL注入、跨站脚本攻击;从业人员安全意识低，管理不到位，导致出现大量弱口令、框架漏洞、配置错误、敏感信息泄露;软件更新缓慢，导致框架错误。

　　其中最为严重的是系统设计逻辑安全威胁。这些设计错误多体现在失败的权限约束上，形成一系列越权漏洞和SQL注入。越权本质并不复杂，例如平行越权查询、平行越权修改、垂直越权操作、批量注册、人以用户密码修改、密码暴力破解、平行越权下载、身份伪造漏洞、退出功能失效、任意邮箱注册漏洞、邮箱激活功能漏洞、刷积分漏洞、邀请码暴力破解、一号多户问题等等。

　　其中越权类查询在设计错误中占到了29%左右。举个简单的例子比如A用户的订单是111。B用户的订单号是112。A原本不能查询B的订单，但A用户可以通过修改订单号来越权查询B的订单，这就是一个平行越权漏洞。这类问题主要就是程序代码自身逻辑错误导致。这和很多互联网企业过度注重扩展速度，不关注自身安全的行为很相似，需要加强代码审计来规避这种风险。

　　例如乌云上爆出的 wuyun-2015-147026漏洞是一个标准的因为设计权限导致可充值任意用户密码的漏洞。按照流程在网站上注册一个用户，选择忘记密码。去邮箱打开链接。重新输入密码和确认密码。点击发送，劫持客户端的网络包。

　　在包中把当前用户名替换成目标用户名再发送给服务器，达到修改目标用户密码的目的。至此入侵者获得一组被人的账号，为入侵者可进一步实施入侵奠定基础。

　　面对SQL注入虽然有WAF的辅助，但WAF难免有关键字过滤不到的时候。于是在金融业界出现了大量的SQL注入漏洞。由于WAF采用的是正则匹配的方式，于是出现了以下3种常见绕过WAF的手段：

　　(1)编码绕过

　　在大小写绕过的基础上开始出现编码绕过，主要出现了三种：URL编码、十六进制编码、Unicode编码。在浏览器中输入URL会进行一次URL编码，黑客会通过多次编码来进行WAF绕过，例如：Id.php?id=1%2520union/**/select ，数据库得到的Id.php?id=1 union/**/select。如果只解码一次得到的是Id.php?id=1%20union/**/select，很有可能绕过WAF入侵数据库。针对这一问题可以采用多次循环解码来应对。其中Unicode编码种类很多，如果只是基于黑名单过滤，无法处理全部情况，其中UTF-32曾经实现过对GOOGLE的绕过。

　　(2)注释绕过

　　不但可以采用编码改写关键字，还可以采用注释改写关键字，避免正则匹配。例如z.com/index.php?page_id=-15 %55nION/**/%53ElecT 1,2,3,4 'union%a0select pass from users# 。就是用符号编码代替一部分字母和判定的空格来逃避正则匹配。(selectxxx不会被拦截，因为可能是函数名等。select 空格xxx则一定会被拦截，去掉空格成为绕过的关键)。同样还有针对MYSQL版本的/*!5000union*/系列。

　　(3)等价替换

　　等价替换是个比较大的分类，主要可以分为等价函数、等价符号、特殊符号、比较符号等4类。

　　等价函数，就是同功能函数替换。WAF禁止了一些函数，但对另外一些函数没有禁止例如 Substring()可以用mid()，substr()这些函数来替换。还将可以采用生僻函数迂回完成原函数的功能，进行WAF关键字绕过。and or 这种关键字在PHP中可以用|| 和&&代替。于是语句id=1 or 1=1就可以写成id=1 || 1=来进行绕过。同样!= 、>、<等都可以代替等号进行绕过。

　　除去绕过关键字和关键符号外，最关键的是绕过空格。想各种方式避免空格出现。

　　例如 原句 id=1 or 1=1

　　可以写成 id=1+or+1=1

　　id=1%0bor%0b1=1

　　id=1--s%0aor--s%0a1=1

　　id=1/*!or*/1=1

　　id=1()or(1=1) 等多种形式进行尝试绕过

　　金融行业漏洞入侵防御建议

　　金融行业除去人为因素造成的漏洞外，最主要的两大类漏洞分别是SQL注入和程序逻辑错误。

　　1.解决人为因素

　　人为因素会造成弱口令、错误配置等。人为因素只能从人的角度进行规范。通过加强安全团队建设、人员安全意识培训等方式应该可以解决人为因素造成的问题。

　　2.解决SQL注入

　　SQL注入是金融行业数据安全面临的最大威胁。只依赖WAF不足以完全保障程序免收SQL注入的困扰。这是由于WAF擅长解析过滤http协议，不能对SQL进行解析过滤。针对这个缺陷，可以在WEB应用和数据库之间加入数据库防火墙进行SQL部分的解析和过滤。数据库防火墙对从WEB应用发向数据库的SQL语句进行语法解析，可以理解SQL语句的真实含义，并做以下四点判断：

　　1. 语句是否含有明显的SQL注入特征;

　　2. 语句访问的对象是否属于该用户访问权限;

　　3. 语句的关键谓词是否被禁用;

　　4. 限制语句的返回行数，把危险控制在最低限。

　　加入数据库防火墙后，数据库防火墙会在WEB应用和数据库之间获取WEB应用发送给数据库的SQL语句。通过拿到的SQL语句，按照不同数据库进行SQL协议解析，通过协议解析把应用发送的SQL语句还原成标准模式(去掉各种加入的符号，转译码等)，防止黑客利用上述绕过WAF的手法绕过数据库防火墙进行SQL注入。

　　首先还原后的SQL语句和黑名单中的禁止语句结构进行匹配，如果认为是威胁语句，则禁止该语句发送到数据库端，并通过发送短信、邮件等方式及时通知管理员进行处理;语句结构判断没有问题后防火墙接下来会对语句中的操作对象和谓词进行判断，如果对象或谓词有控制，则依旧禁止该语句发送到数据库端;最后即便规则全部符合，SQL语句被发送到数据库端，数据库防火墙还可以通过行数控制来限制数据库每次的返回行数把威胁减到最小。

　　3.解决程序逻辑错误

　　程序逻辑错误主要指每个用户权限的划分时存在逻辑问题。这需要对业务系统中逻辑错误进行代码修改，并加强关键部分的逻辑防守。特别需要注意加强防守的功能点有购物车、支付功能、提现功能、用户数据查询、订单数据查询、API接口、密码设置/重置等。同时要注重重要业务系统的运维管理、遵循安全开发非常好的实践、对密码本身进行可靠的存储(数据库中只存储加盐的HASH而不是密码本身)、使用加密的传输协议。

　　安全其实就是这样一种形态，平时不出状况看不到安全的效果，一旦爆发数据泄露事件，无论对于企业还是用户本身，甚至国家信息安全，其损失不可估量。业务在发展，安全领域攻与防的对抗将长期持续。