Web安全性测试总结
一、工具扫描
目前web安全扫描器针对 XSS、SQL injection 、OPEN redirect 、PHP File Include漏洞的检测技术已经比较成熟。
商业软件web安全扫描器:有IBM Rational Appscan、WebInspect、Acunetix WVS
免费的扫描器:W3af 、Skipfish 等等
可以考虑购买商业扫描软件,也可以使用免费的,各有各的好处。
首先可以对网站进行大规模的扫描操作,工具扫描确认没有漏洞或者漏洞已经修复后,再进行以下手工检测。
二、手工检测
1. 目录遍历
目录遍历产生的原因是:程序中没有过滤用户输入的“../”和“./”之类的目录跳转符, 导致恶意用户可以通过提交目录跳转来遍历服务器上的任意文件。
测试方法:在URL中输入一定数量的“../”和“./”,验证系统是否ESCAPE掉了这些目录跳转符。
2. 登陆
(1) 是否正确登陆
(2) 密码复杂度
(3) ...
3. 用户权限
(1) 用户权限控制
1) 用户权限控制主要是对一些有权限控制的功能进行验证
2) 用户A才能进行的操作,B是否能够进行操作(可通过窜session,将在下面介绍) 3)只能有A条件的用户才能查看的页面,是否B能够查看(可直接敲URL访问)
(2) 页面权限控制
1) 必须有登陆权限的页面,是否能够在不登陆情况下进行访问
2)必须经过A——B——C的页面,是否能够直接由A——C?
(3) ...
4. Cookie安全
(1) 屏蔽或删除所有Cookie
(2) 有选择性地屏蔽Cookie
(3) 篡改Cookie
(4) Cookie加密测试
(5) Cookie安全内容检查
1) Cookie过期日期设置的合理性:检查是否把Cookie的过期日期设置得过长。
2) HttpOnly属性的设置:把Cookie的HttpOnly属性设置为True有助于缓解跨站点脚本威胁,防止Cookie被窃取。?
3) Secure属性的设置:把Cookie的Secure属性设置为True,在传输Cookie时使用SSL连接,能保护数据在传输过程中不被篡改。 对于这些设置,可以利用Cookie?Editor来查看是否正确地被设置。
(6) ...
5. 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页执行退出操作,马上在另外一个页面进行要验证的操作,查看是能继续到下一步还是到登录页面。
3) ...
6. URL安全
(1) URL参数检查
A: 对URL中参数信息检查是否正确 如:URL中的订单号、金额允许显示出来的话,需要验证其是否正确
B: 对于一些重要的参数信息,不应该在URL中显示出来 如:用户登陆时登录名、密码是否被显示出来了.
(2) URL参数值篡改
修改URL中的数据,看程序是否能识别: 如:对于以下URL,修改其中planId,看是程序是否可以识别: http://pay.daily.taobao.net/mysub/plan/subplan/confirmSubPlanInfo.htm?planId=878 又如:对于URL中包含金额参数的,修改金额看是否能够提交成功(可能导致用户把2元金额改成1元金额能提交),还有修改订单号等重要信息看是否会报错
(3) URL中参数进行XSS注入
什么是XSS? XSS的全称是Cross Site Script(跨站点脚本) XSS的原理很简单,即进行脚本注入,URL执行时即把此脚本进行了执行,一般都是JavaScript脚本,如<script>alter(“abc”)<script> 在URL中进行XSS注入,也就是把URL中的参数改成JS脚本。
(4) URL参数中进行SQL 注入
什么是SQL注入? SQL注入全称是SQL Injection ,当应用程序使用输入内容来构造动态sql语句以访问数据库时,会发生sql注入攻击,如查询、插入数据时。
测试方法: URL中写入SQL注入语句,看是否被执行,如:’or 1=1;shutdown
一般情况下要进行SQL注入攻击,需要对数据库类型、表名、判断逻辑、查询语句等比较清楚才能够写出有效的SQL注入语句。
(5) ...
7. 表单提交安全
(1) 表单中注入XSS脚本
测试方法:即在表单填写框中直接注入JS脚本 如在表单中输入XSS脚本,程序是不应该让脚本执行的。
(2) 表单中注入SQL 脚本
(3) ...
8. 上传文件安全
分析:上传文件最好要有格式的限制;上传文件还要有大小的限制。
9. Email Header Injection(邮件标头注入)
Email Header Injection:如果表单用于发送email, 表单中可能包括“subject”输入项(邮件标题), 我们要验证subject中应能escape掉“\n”标识。
<!--[if !supportLists]--><!--[endif]-->因为“\n”是新行,如果在subject中输入“hello\ncc:spamvictim@example.com”,可能会形成以下
Subject: hello
cc: spamvictim@example.com
<!--[if !supportLists]--><!--[endif]-->如果允许用户使用这样的subject,那他可能会给利用这个缺陷通过我们的平台给其它用 户发送垃圾邮件。
10. 不恰当的异常处理
分析:程序在抛出异常的时候给出了比较详细的内部错误信息,暴露了不应该显示的执行细节,网站存在潜在漏洞;
11. ...
作者:Agoly 出处:https://www.cnblogs.com/qmfsun/ 本文版权归作者和博客园共有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出原文连接,否则保留追究法律责任的权利。 如果文中有什么错误,欢迎指出。以免更多的人被误导。 |