Web安全测试指南-CSDN博客

本文链接：https://blog.csdn.net/huazhongkejidaxuezpp/article/details/48711477

1. 安全测试目的

(1).提升IT产品的安全质量；
(2).尽量在发布前找到安全问题予以修补降低成本；
(3).度量安全。
(4).验证安装在系统内的保护机制能否在实际应用中对系统进行保护，使之不被非法入侵，不受各种因素的干扰。

2. 与功能测试区别

区别点	功能测试	安全测试
目标不同	以发现BUG为目标	以发现安全隐患为目标
假设条件不同	假设导致问题的数据是用户不小心造成的，接口一般只考虑用户界面	假设导致问题的数据是攻击者处心积虑构造的，需要考虑所有可能的攻击途径
思考域不同	以系统所具有的功能为思考域	不但包括系统的功能，还有系统的机制、外部环境、应用与数据自身安全风险与安全属性等
问题发现方式不同	以违反功能定义为判断依据	以违反权限与能力的约束为判断依据

3. 与渗透测试区别

区别点	渗透测试	安全测试
出发点	以成功入侵系统，证明系统存在安全问题为出发点	以发现系统所有可能的安全隐患为出发点
角度	以攻击者的角度来看待和思考问题	站在防护者角度思考问题，尽量发现所有可能被攻击者利用的安全隐患，并指导其进行修复
覆盖性	只选取几个点作为测试的目标	在分析系统架构并找出系统所有可能的攻击界面后进行的具有完备性的测试
成本		需要对系统的功能、系统所采用的技术以及系统的架构等进行分析，所以较渗透测试需要投入更多的时间和人力
解决方案	无法提供有针对性的解决方案	站在开发者的角度分析问题的成因，提供更有效的解决方案

4. web安全测试思考点

测试思考点	思考点	备注
用户权限测试	（1）用户权限控制　　1）用户权限控制主要是对一些有权限控制的功能进行验证　　2）用户A才能进行的操作，B是否能够进行操作（可通过窜session）　　3）只能有A条件的用户才能查看的页面，是否B能够查看（可直接敲URL访问）（2）页面权限控制　　1）必须有登陆权限的页面，是否能够在不登陆情况下进行访问　　2）必须经过A——B——C的页面，是否能够直接由A——C
URL安全测试	（1）适用范围： URL中含有参数，也就是通过GET方式传递的HTTP请求（2）GET只能传输比较少的数据，安全性较低，POST传输数据较多，安全性也比GET高（3）测试关注点：　　1） URL 参数检查：　　A：对URL中参数信息检查是否正确　　如：URL中的订单号、金额允许显示出来的话，需要验证其是否正确　　B：对于一些重要的参数信息，不应该在URL中显示出来　　如：用户登陆时登录名、密码是否被显示出来了，　2） URL参数值篡改　　修改URL中的数据，看程序是否能识别：又如：对于URL中包含金额参数的，修改金额看是否能够提交成功（可能导致用户把2元金额改成1元金额能提交），还有修改订单号等重要信息看是否会报错 3） URL中参数修改进行XSS注入（跨站点脚本，也就是把URL中的参数改成JS脚本）例如：http:xxx?a=2 改成：http:xxx?a=2<script>alert("hello");<script> 4） URL参数中进行SQL 注入原因：当应用程序使用输入内容来构造动态sql语句以访问数据库时，会发生sql注入攻击，如查询、插入数据时。测试方法： URL中写入SQL注入语句，看是否被执行，如：http://demo.testfire.net这个网站中，选择sign in 设置用户名为 admin ' or '1'='1 密码为任意数字，点击登录就可以登陆。
表单提交安全测试	（1）适用范围：有表单提交的地方、有HTTP请求的地方（包括GET、POST请求）（2）测试关注点：　　1）表单中注入XSS脚本　　测试方法：即在表单填写框中直接注入JS脚本　　如在表单中输入XSS脚本，程序是不应该让脚本执行的　　2）表单中注入SQL 脚本　　与URL中参数进行SQL注入类似，就是在表单中写入SQL注入脚本提交看是否会有问题
Session测试	（1）Session是客户端与服务器端建立的会话，总是放在服务器上的，服务器会为每次会话建立一个sessionId，每个客户会跟一个sessionID对应。　　并不是关闭浏览器就结束了本次会话，通常是用户执行“退出”操作或者会话超时时才会结束。（2）测试关注点： 1）Session互窜　　Session互窜即是用户A的操作被用户B执行了。　　验证Session互窜，其原理还是基于权限控制，如某笔订单只能是A进行操作，或者只能是A才能看到的页面，但是B的session窜进来却能够获得A的订单详情等。　　Session互窜方法：多TAB浏览器，在两个TAB页中都保留的是用户A的session记录，然后在其中一个TAB页执行退出操作，登陆用户B，此时两个TAB页都是B的session，然后在另一个A的页面执行操作，查看是否能成功。预期结果：有权限控制的操作，B不能执行A页面的操作，应该报错，没有权限控制的操作，B执行了A页面操作后，数据记录是B的而不是A的。 2）Session超时基于Session原理，需要验证系统session是否有超时机制，还需要验证session超时后功能是否还能继续走下去。　　测试方法： 1、打开一个页面，等着10分钟session超时时间到了，然后对页面进行操作，查看效果。 2、多TAB浏览器，在两个TAB页中都保留的是用户A的session记录，然后在其中一个TAB页执行退出操作，马上在另外一个页面进行要验证的操作，查看是能继续到下一步还是到登录页面。
数据验证	（1）server, web ,app三者对数据长度和类型的定义一致（2）server端对sql的验证。防止将提交的sql语句分割，后面加一个delete all或drop database的之类语句

数据加密	日志，数据库，页面等对敏感信息加密注：敏感信息如：手机号，身份证号等

5. web安全常见bug

1)、 SQL INJETION

2)、对文件操作相关的模块的漏洞

3)、COOKIES的欺骗

4)、本地提交的漏洞

6. SQL INJETION的测试方法

（1）原理

当应用程序使用输入内容来构造动态sql语句以访问数据库时，会发生sql注入攻击，如查询、插入数据时。

（2）例子

http://www.xxx.com/news.asp?id=1这一类网站程序来用参数读取数据库里的新闻。

如果直接用

　　rs.open "select * from news where id=" &

　　cstr(request("id")),conn,1,1

　　数据库进行查询的话即上面的URL所读取的文章是这样读取的

　　select * from news where id=1

　　懂得SQL语言的就知道这条语言的意思是在news读取id为1的文章内容。

　　但是在SQL SERVER里select是支持子查询和多句执行的。如果这样提交URL的话

　　http://www.xxx.com/news.asp?id=1and 1=(select count(*) from admin

　　where left(name,1)=a)

　　SQL语句就变成了

　　select * news where id=1 and 1=(select count(*)

　　from admin where left(name,1)=a)

　　意思是admin表里如果存在字段字为name里左边第一个字符是a的就查询news表里id为1的内容，news表里id为1是有内容的，从逻辑上的角度来说就是1&P。只要P为真，表达式就为真，页面会返回一个正确的页面。如果为假页面就会报错或者会提示该id的文章不存在。黑客利用这点就可以慢慢得试用后台管理员的用户和密码。