Web安全测试之攻击验证机制

一、 Web安全测试的定义

一般而言，Web的安全就是要让软件在面对恶意输入或敌意的情况下，依然能够充分满足使用需求。而针对Web的安全性测试是验证Web应用的安全服务和识别潜在安全性缺陷的过程。

安全测试通常要求测试人员制定详细的测试策略，并模拟成攻击者，对软件系统不同的模块进行恶意的攻击或渗透，查看系统是否能正常工作，还原软件中存在的安全漏洞。安全测试人员一般会使用手动工具或自动工具，根据漏洞原理来模拟和激发Web应用。

二、 Web安全测试流程

通常情况下，Web安全测试开展于性能测试前。对于大多数Web项目，测试开始前需要首先要充分解析和分析应用。然后针对各个模块制定相应的安全测试策略。接着进入手工安全测试阶段，验证基于安全测试的各种漏洞是否存在，包括验证机制、会话管理、访问控制、SQL注入、XSS、逻辑缺陷等多方面的漏洞验证。验证后整理所有测试过程中发现的安全问题，以报告的形式提交给研发。最后待验证结束后进行回归测试，直至所有安全问题全部解决。

三、 攻击验证机制

验证机制是Web应用中最常见的，也是最重要的一种安全机制。通常而言， Web应用必须验证用户所提交的用户名和密码是否正确。正确则允许登录，错误则禁止进入。验证机制常常被看做是防御Web恶意攻击的核心机制。如果攻击者可以轻松突破验证机制，那么系统的所有功能、数据、私密信息都会被攻击者控制。验证机制是其他所有安全机制的前提，如果验证机制都无法阻止攻击，那么其他安全机制也大多无法实施。

验证机制常见的漏洞有以下几种。

1．密码保密性不强（弱口令）

一些Web应用程序没有或很少对用户密码强度进行控制。常见的弱口令有：

?  非常短或空白密码。

?  常用字典词汇为密码（password、123456）。

?  密码与用户名完全相同。

?  长时间使用默认密码。

2. 暴力攻击登录

登录功能往往是完全公开的，这样的机制可能会诱使攻击者利用枚举来猜测用户名和密码，从而获得访问应用程序的权利。如果应用程序允许攻击者用不同的密码暴力尝试，直到他找到正确的密码，这个程序就非常容易遭受攻击。

应对暴力破解，很多Web应用采取了不同的安全措施：

A．验证码

验证码是最常见且有效的应对方式，但需要注意以下几个问题。

?  验证码是否真实有效。

?  验证码的复杂度。

?  为应对盛行的“打码”接口。

由于这些问题，验证码这种方式也许不能完全避免暴力破解，但实际情况是即使这种方式无法完全生效，也可以使多数随意的攻击者停止攻击行动，转而攻击较容易的应用程序。

B. cookie检测

例如，一些应用程序会设置一个cookie，如failedlogin=O；登录尝试失败，递增该值，达到某个上限，检测到这个值并拒绝再次处理登录。这种客户端防御方式只可以防止使用浏览器手动攻击。

C. 会话检测

与cookie检测类似，将失败计数器保存在会话中，虽然在客户端没有标明该漏洞存在的迹象，但是只要攻击者获得一个新的会话，就可以继续实施暴力攻击。

D．失败锁定账户

有些应用程序会采取登录尝试达到一定次数后锁定目标账户的方式。但是有可能通过分析其响应，在锁定账户的状态下仍可以进行密码猜测攻击。

3 双因子认证

它是指结合密码以及实物（信用卡、SMS手机、令牌或指纹等生物标志）两种条件对用户进行认证的方法。其核心是综合个人密码和通常为手机来达到双重认证效果。很多电商、银行都采用了该认证方式。它最大的缺点就是构建双因子认证的成本较高，服务器压力也较大。

4. 详细的失败信息

经典的登录表单会要求用户输入两组信息：用户名和密码。如果登录尝试失败，则可以得出结论，至少有一组信息出错。

但是如果应用程序通知用户是哪一组信息无效，就可以利用该信息来降低登录机制的防御效能。

这种漏洞有可能以更隐蔽的方式出现。例如，用户名无效和密码错误的错误消息表面看起来完全相同，但它们之间仍有可能存在着细微的差别，可以通过拦截其response来观察是否有细微的差别。

5. 密码修改功能

成熟的系统除了用户登录，往往还会提供密码修改功能，但是在编码过程中， 往往忘记了这个功能中也会存在一些安全隐患。

密码修改功能中常见的安全漏洞有：

1）密码修改功能是否拥有隐藏的后台接口，如不通过登录直接可以访问该功能；

2）是否可以使用不符合标准的密码，如弱密码等；

3）密码修改的请求提交时，是否用户名也随之提交？如果提交，是否可以通过修改用户名来达到修改非当前登录用户密码的目的？

6．忘记密码功能

网站大多提供“忘记密码”功能，但是其中往往会存在一些典型的安全问题，其核心问题就是忘记密码的流程跳过了身份验证。

如不考虑通过客服找回密码，通常网站设计有三种方式来认证用户。

1）用户设定的安全问题。

2）用户注册时留下的安全邮箱。

3）给预留手机号发送验证码短信。

基于以上3点，会有以下几种可能。

1 ）需要确认应用程序中是否有隐含的忘记密码功能或不通过用户名查询即可访问的情况。

2）如果恢复机制使用质询方式，则确定用户能否枚举用户名来得到质询信息，与猜测密码相比，响应质询更容易。

3）如果在忘记密码的请求响应中生成一封包含恢复URL的电子邮件，获取大量此类URL并试图分析和预测其发送URL的模式，是否可以得到其他未知用户的恢复URL。

4）无论是使用邮件，还是发送手机验证码，查看是否可以拦截请求以修改目标邮箱或手机号，从而达到绕过的目的。

7. 用户伪装功能

应用程序有时可能会允许特权用户伪装成其他用户，例如某电商网站拥有类似OOB(on order behalf）的功能，超级管理员可以伪装成任意用户来帮助其执行某些操作。

伪装功能可能存在以下设计漏洞。

1）如上述提到的OOB类功能，网站可能通过严格的权限控制（只有超级管理员才可访问的功能模块）或是隐藏的链接（只有超级管理员才知道）的方式执行，例如在网站中有一个特殊的URL可以链接到一个不需要核对用户身份的页面执行部分操作。这时攻击者可以尝试使用枚举URL或者使用爬虫，从而拦截到该功能，劫持所有用户。

2）有些伪装功能以后门密码形式执行，也就是说，对于一个普通用户， 除去该用户设置的密码外，还拥有一个“万能密码”。这种设计可能招致暴力破解， 攻击者一次攻击获得两个“触点”，从而便可揭示出后台密码。

8. 多阶段登录

在日常网络应用中，经常发现一些多阶段登录的功能，如在输入用户名、 密码后，可能会要求你验证一个私密问题，通过方可登录。这样的设计毫无疑问会增加验证机制的安全性，但这样的过程也可能产生更多的执行缺陷。

下面以两阶段登录验证机制为例，说明多阶段登录可能存在的设计缺陷。

1）程序可能会认为，用户一旦访问到第二阶段，就已经完成第一阶段的验证，那么可能会允许攻击者直接进入第二阶段。

2）程序可能会认为，在两个阶段的执行过程中，用户身份不会发生任何变化，于是并没有在每个阶段都确认用户身份。例如，第一阶段提交用户名和密码， 第二阶段可能需要重新提交某个私密问题答案和一些个人信息。如果攻击者在进行第二个阶段时提供了有效数据，但是不同于第一阶段时的用户，那么程序可能会允许用户通过验证。

联系我们

电话：400-108-9880 

网址：www.svtest.cn

  邮箱：kj-sv@svtest.cn

传真：020-31707367

网址：www.svtest.cn

联系地址
广州：广州开发区科学城玉树创新园 J 栋 103 房
北京：北京市海淀区永定路 15 号院南门 208 室
长沙：长沙市雨花区保利东郡 8 栋 1803 房
深圳：深圳市南山区西丽深圳大学城学苑大道 1068 号（深圳先进院内）
石家庄：石家庄市鹿泉区山尹村镇滨海路19号2号楼