金融行业安全漏洞分析报告-k8凯发游戏

报告介绍

互联网 时代的到来，人们充分享受新时代科技创新成果的便利同时，万物互联带来的信息安全风险也日渐提高，信息泄密事件层出不穷，在资金体量庞大、 用户信息集中、安全隐患影响深远的金融领域，所面临的安全问题尤为凸显。人们真切地感知到，原有的金融服务模式被颠覆，网银、第三方支付、互联网金融等新 兴模式异军突起。用户也在这些新的业务模式下，将自身姓名、身份证号码、手机号码等身份认证信息与业务紧密绑定关联。所以说，互联网的发展为传统的信息防 御体系划开了一道口子，打破看似牢不可破的安全防护状态，直逼用户核心数据。在这样的背景下，本次安华金和数据库攻防实验室选择以近三个月金融行业数据安 全高危漏洞为分析样本，就金融行业安全漏洞的分布状态、原因分析及对应的安全防御办法详尽描述。

本次报告核心观点

金融行业漏洞细分状况分析

金融数据泄露原因分析

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

报告正文

2015年9月至11月三个月的时间里，安华金和在乌云漏洞平台上汇总金融行业已被客户确认的安全漏洞共206个。其中高危漏洞195个，中危漏洞9个，低危漏洞2个。而这206个漏洞中，直接与数据泄露相关的漏洞110个，占漏洞总量的的53%。

金融行业漏洞细分状况分析

近几年来随着行业政策和市场需求的推动，金融行业已经开始尝试服务互联网化，普通业务以及更深层次的业务也会逐渐互联网化，逐渐促进整个金融行业向 互联网全面迁移。由于金融业多金的本质，各类不法分子一直对这个行业虎视眈眈；一些内部从业人员，也会因为利益的驱使，放下道德底线，从内部窃取数据，导 致安全堡垒从内部被攻破，内外安全问题集中，使得金融业的安全更加危机四伏。金融行业多年沉淀的边界安全防御机制应面对互联网带来的新问题往往显得力不从 心。

安华金和本次将金融行业安全漏洞进行了细分，以银行、保险、互联网金融、金融机构（包括证券、基金、期货、支付和与金融相关的其他机构）四类进行漏 洞划分。近三个月时间在乌云已经确认的金融行业206个漏洞中，其中银行42个，保险和互联网金融各47个，其余来自证券、基金、期货、支付等金融机构。 平均每月各细分领域曝出的漏洞在10个到20个之间。

 2015年9至11月 金融细分行业漏洞分布

金融机构由于包含业务种类繁多，漏洞数量最高、新兴互联网金融，由于对业务的追赶速度和要求远高于安全需求，虽然业务发展不长，但暴露的安全数量和威胁却名列前茅。截至2015年11月底，全国范围内近100家互联网金融平台被爆出存在漏洞。

金融数据泄露原因分析

安华金和通过对大量金融行业安全漏洞进行统计分析，发现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%20union/**/select ，数据库得到的 id.php?id=1 union/**/select。如果只解码一次得到的是id.php?id=1 union/**/select，很有可能绕过waf入侵数据库。 针对这一问题可以采用多次循环解码来应对。其中unicode编码种类很多，如果只是基于黑名单过滤，无法处理全部情况，其中utf-32曾经实现过对 google的绕过。

（2）注释绕过

不但可以采用编码改写关键字，还可以采用注释改写关键字，避免正则匹配。例如z.com/index.php?page_id=- 15 union/**/select 1,2,3,4 'union�select 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=1or1=1

id=1--s or--s 1=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而不是密码本身）、使用加密的传输协议。

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