常见Web安全漏洞测试指南

Posted 2022-11-24 再认真点

任意文件下载

漏洞描述

一些网站由于业务需求，可能提供文件查看或下载的功能，如果对用户查看或下载的文件不做限制，则恶意用户就能够查看或下载任意的文件，可以是源代码文件、敏感文件等。

测试指南

使用 BurpSuite、或者手工抓取所有的url，以及寻找相关敏感的功能点，比如文件查看处，文件下载处等功能点，手工发送一系列 “…/” “./” 等字符来遍历高层目录，并且尝试找到系统的配置文件（/etc/passwd，win.ini等）或者该web站点相关系统中存在的敏感文件（如：java应用中的…/…/…/WEB-INF/web.xml）。

测试结论

若发送的相关敏感文件的payload能够成功执行，返回相关报文，则存在文件下载漏洞。

安全建议

• 指定下载目录，下载路径不允许超过当前下载目录。

• 过滤 “…/” “./” 等特殊字符。

跨站脚本攻击

漏洞描述

当应用程序的新网页中包含不受信任的、未经恰当验证或转义的数据时，或者使用可以创建 html 或 javascript 的浏览器API更新现有的网页时，就会出现XSS缺陷。XSS让攻击者能够在受害者的浏览器中执行脚本，并劫持用户会话、破坏网站或将用户重定向到恶意站点。

已知的跨站脚本攻击漏洞有三种：存储型；反射型；基于DOM。

1. 存储型跨站脚本攻击涉及的功能点：用户输入的文本信息保存到数据库中，并能够在页面展示的功能点，如用户留言、发送站内消息、个人信息修改等功能点。
2. 反射型跨站脚本攻击涉及的功能点：URL参数需要在页面显示的功能点都可能存在反射型跨站脚本攻击，例如站内搜索、查询功能点。
3. 基于DOM跨站脚本攻击涉及的功能点：涉及DOM对象的页面程序，包括（不限）：document.URL 、document.URLUnencoded 、document.locatio 、document.referer、 window.location

测试指南

针对 get/post 形式的请求，右键查看源码看相关参数在页面的显示位置，然后对相关参数发送相关特殊字符（比如’ " > </某闭合标签 > ）及相关xss payload 尝试闭合相关标签执行恶意代码，看xss payload 能够执行，标签能够被闭合，如果相关标签能够被正确被我们的控制的参数闭合、相关xss payload 能够被执行，那么就存在xss 跨站脚本漏洞。

测试结论

若发送的相关xss payload 能够正确执行、相关标签能够被闭合，那么存在XSS 跨站脚本漏洞。

安全建议

• 对提交的输入内容进行可靠的输入验证过滤。内容包括URL、查询关键字、HTTP头、post数据等。
• 不信任用户提交的任何内容，代码中对用户输入的地方和变量都需要仔细检查长度和对 “<” “>” “;” “,” " ’ "等字符做过滤；任何内容写到页面之前都必须加以encode
• Cookie中设置HTTPOnly参数，防止XSS会话劫持攻击。
• 特殊字符采用HTML实体编码。在输出和二次调用的时候进行HTML实体一类的转码，防止脚本注入。
• 标签事件属性黑名单。特殊字符容易被绕过，所以需要加标签事件白名单或者黑名单，推荐白名单，实现规则使用正则表达式来匹配，若匹配到的事件不在白名单列表，就直接拦截，而不是过滤为空。

修复建议

1. 使用严格的过滤方法，过滤危险的字符

text = request.get("text")
filter = "\\<(script/img/href)/i\\>"
if regexp(text, filter)
	return error
else
	savetext(text)

2. 根据数据输出的内容类型进行转义

text = request.get("text")
if type == "html"
	return htmlescape(text)
else if type == "js"
	return javascriptescape(text)
else if type == "css"
	return cssescape(text)
else ...

SQL注入

漏洞描述

目标网站未对用户输入的字符进行特殊字符过滤或合法性校验，且后台SQL语句拼接了用户的输入，导致允许用户输入特殊语句查询后台数据库相关信息。一般意义上的注入漏洞包括SQL注入，Xpath注入，LDAP注入，代码注入以及操作系统命令注入等。

测试指南

fuzz：使用 BurpSuite 针对url、各个参数使用相关sql注入、命令注入等字典进行fuzz，然后根据返回 http 状态码的异常（500状态等）、返回参数的异常、返回字节的异常等情况，综合分析。

手工判断注入点，使用SQLmap，nosqlattack等系列半自动化工具获取数据。

数字型：

?id=11 and 1=1 返回成功；

?id=11 and 1=2 返回失败

字符型：

?name=mark’ and ‘1’='1 返回成功；

?name=mark’ and ‘1’='2 返回失败

搜索型：

搜索( ’ )，出错，90%

搜索( % )，正常返回，95%

搜索(2006)，正常返回所有2006相关的信息

再搜索 ( 2006%’ and 1=1 and ‘%’=’ ) 和 ( 2006%’ and 1=2 and ‘%’=’ )

绕过验证：

常见的为管理登录，也称万能密码。

（1）用户名：’ or 1=1 or ’ 密码：任意

（2）Admin’ – (或 'or 1=1 or ’ --) ( admin or 1=1 – ) ( MSSQL )（直接输入用户名，不进行密码验证。）

（3）用户名：admin 密码：’ or ‘1’='1

（4）用户名：admin’ or ‘a’='a 密码：任意

（5）用户名：'or 1=1 – 密码：任意

（6）用户名：admin ’ or 1=1 – 密码：任意

（7）用户名：1’ or ‘1’=‘1’ or ‘1’='1 密码：任意

不同的SQL服务器连结字符串的语法不同，比如MSSQL Server使用符合+来连结字符串，而Oracle使用符合||来连接。

?Name=Book’ 返回错误

?Name=B’+'ook 返回正常

?Name=B’||'ook 返回正常说明有SQL注入

如果应用程序已经过滤了 ’ 和 + 等特殊字符，需要使用SQL所支持的特性和对应的防护规则的差异性来进行绕过。

安全建议

• 将查询的逻辑与数据分离，SQL注入源于攻击者控制查询数据以修改查询逻辑。
• 预编译，PreparedStatement（JSP）、PDO(php)；SQL注入对SQL语句的编译过程有破坏作用，预编译好之后，执行阶段只是把输入串作为数据处理，不再对SQL语句进行解析。
• 使用正则表达式过滤，对用户输入的数据进行严格的检查；使用正则表达式对危险字符串进行过滤，基于黑名单。
• 使用Web应用防火墙（WAF）

修复建议

1. 使用参数化的查询方式，避免SQL注入隐患，预编译

id = request.get("id") #获取请求的查询字符串值
sql = "select * from table where id=? " #构造查询语句
prepSql = prepareStatement(sql) #使用预编译加载查询语句
prepSql.add(id) #插入数据
prepSql.run() #执行SQL

#PHP
1、通过使用预编译语句（prepared statements）
使用PDO对象（对于任何数据库驱动都好用）
$stmt = $pdo->prepare('SELECT * FROM employees WHERE name = :name');
$stmt->execute(array('name' => $name));
foreach ($stmt as $row) 
　　// do something with $row

2、参数化查询（parameterized queries）
使用mysqli
$stmt = $dbConnection->prepare('SELECT * FROM employees WHERE name = ?');
$stmt->bind_param('s', $name);
$stmt->execute();

2. 转义特殊字符，如：

' -> \\'
id = request.get("id") #获取请求的查询字符串值
id = escape.escapeSql(id) #使用当前开发语言的escape库
sql = "select * from table where id= " + id #构造查询语句
conn.exec(sql) #调用数据库连接执行SQL

3. 使用白名单规范输入

id = request.get("id") #获取请求的查询字符串值
whiteList = "^[a-zA-Z0-9]+$" #设置仅接收英文字母和数字的白名单
if regex.match(id, whiteList) #正则匹配测试
	execSql(id) #匹配成功，执行SQL语句
else
	return error #匹配失败，返回错误。

对于排序方法不应该直接拼接客户端输入的字符，彻底避免SQL注入隐患；

ordername = request.get["ordername"]
sort = request.get["sort"]
sql = "select * from products"
switch(ordername)：
    case "Id":
    	sql += "order by Id"
    case "Name":
    	sql += "order by Name"
    ...
        break;
    default:
        return error
if sort=="desc":
	sql += "desc"
	conn.execute(sql)

命令注入

漏洞描述

目标网站未对用户输入的字符进行特殊字符过滤或合法性校验，允许用户输入特殊语句，导致利用各种调用系统命令的web应用，通过命令拼接、绕过黑名单等方式实现在服务端实现想要实现的系统命令。

测试指南

自己一台机器(ip:192.168.1.123)，监听 ping 的请求，如 tcpdump -i eth0 icmp；或者使用dnslog

使用 ` | || 等字符进行fuzz ，ping自己监听 icmp 请求的那台机器。

`ping 192.168.1.123` 
| ping 192.168.1.123
|| ping 192.168.1.123
或使用 net user,cat /etc/passwd,id 等命令字符进行fuzz

测试结论

若自己的机器收到了来自目标机器的请求，那么则存在命令注入漏洞；看返回报文，看是否存在执行相关命令的相关信息，如果存在，那么则存在命令注入漏洞。

安全建议

• 拒绝使用拼接语句的方式进行参数传递
• 使用白名单的方式
• 过滤危险方法、特殊字符

如下：
|
&
;
$
%
'
"
\\'
\\"
<>
()
+
CR（回车符，ASCII 0x0d）
LF（换行符，ASCII 0x0a）
,
\\
.

XML外部实体注入

漏洞描述

目标网站在检测过程中被发现部分文件在对非安全的外部实体数据进行处理时未过滤，导致XXE漏洞的出现。外部实体攻击，利用 <!Entity name SYSTEM “URI”> XML文件的解析依赖 libxml 库，而 libxml2.9 以前的版本默认支持并开启了外部实体的引用，服务端解析用户提交的XML文件时，未对XML文件引用的外部实体（含外部普通实体和外部参数实体）做合适的处理。

测试指南

一般该问题出现在XML 进行交付的功能点，通过手工篡改网站中XML实体中的头部，加入相关payload，进行读取文件或者是命令执行等，如：

file:///path/to/file.ext
http://url/file.ext
php://filter/read=convert.base64-encode/resource=conf.php

测试结论

若相关payload，比如读取文件，命令执行（同样也可使用 ping或者是其他命令）能够执行，那么就存在该漏洞。

安全建议

• 严格检查用户输入的字符。

• 检查使用的底层XML解析库，使用 JAVA 语言提供的禁用外部实体的方法：DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();

  dbf.setExpandEntityReferences(false);

• 操作 XML 时对格式字符进行转义处理，常见的格式字符如：

&lt;	<
&gt;	>
&amp;	&
&apos;	'
&quot;	"

弱口令

漏洞描述

目标网站管理入口（或数据库外部连接）使用了容易被猜测的口令、或者使用的是默认系统账号口令，能够被攻击中很容易的猜测到。

测试指南

看是否存在验证码，如果不存在验证码，则直接使用相对应的弱口令字典使用BurpSuite进行爆破；如果存在验证码，则看验证码是否存在绕过、以及看验证码是否存在容易识别，然后根据返回的报文，进行观察，看是否能成功使用弱密码字典进行成功爆破进入。

测试结论

如果使用的密码是简单、容易识别、易被猜测的，有规律性的，那么存在弱口令漏洞。

安全建议

• 网站管理入口紧张使用弱口令账号，建议使用复杂口令，比如：大小写字母与数字的组合，口令长度不小于8位等。
• 定期检查和更换网站管理口令。

任意文件上传

漏洞描述

目标网站允许用户向网站直接上传文件，但未对所上传文件的类型和内容进行严格的过滤。

测试指南

测试上传功能点时，先搜集，相关使用了什么组件、什么语言的应用系统等信息，方便上传绕过。

相关绕过：

1、 客户端 javascript 校验（一般只校验后缀名）

可以利用 BurpSuite 抓包改包，先上传一个 gif 类型的木马，然后通过 Burp 将其改为 asp/php/jsp 后缀名。

2、 服务端校验

文件头 content-type 字段校验（image/gif）：抓包，将content-type字段改为image/gif

文件内容头校验（GIF89a）：在木马内容基础上再加了一些文件信息，比如

GIF89a 
<?php phpinfo(); ?>

3、后缀名黑名单校验

前提：黑名单校验

黑名单检测：一般有个专门的 blacklist 文件，里面会包含常见的危险脚本文件。

绕过方法：

（1）找黑名单扩展名的漏网之鱼 - 比如 asa 和 cer 之类

（2）可能存在大小写绕过漏洞 - 比如 aSp 和 pHp 之类

（3）能被解析的文件扩展名列表

jsp jspx jspf
asp asa cer aspx
php php php3 php4
exe exee

4、后缀名白名单校验

（1）0x00 截断：基于一个组合逻辑漏洞造成的，通常存在于构造上传文件路径的时候

test.php(0x00).jpg
test.php%00.jpg
路径/upload/1.php(0x00)，文件名1.jpg，结合即为：/upload/1.php(0x00)/1.jpg

（2）寻找利用文件包含等漏洞，包含上传含有webshell 的正常文件等。

（3）中间件解析漏洞。

5、配合操作系统文件命令规则绕过

（1）上传不符合windows文件命名规则的文件名

test.asp.
test.asp(空格)
test.php:1.jpg
test.php::$DATA
shell.php::$DATA……

#会被windows系统自动去掉不符合规则符号后面的内容。

（2）linux下后缀名大小写

在linux下，如果上传php不被解析，可以试试上传pHp大小写的后缀的文件名。

测试结论

如果能够绕过正常的文件上传类型，上传我们的恶意webshell ，那么存在任意文件上传漏洞。

安全建议

• 对上传文件做有效文件类型判断，采用白名单控制的方法，开放只允许上传的文件型式，其中文件类型判断应对上传文件的后缀、文件头、图片类的预览图等做检测来判断文件类型，同时注意重命名上传文件的文件名避免攻击者利用WEB服务的缺陷构造畸形文件名实现攻击目的。
• 禁止上传目录有执行权限。
• 使用随机数改写文件名和文件路径，使得用户不能轻易访问自己上传的文件。

目录浏览

漏洞描述

目录浏览漏洞主要是由于配置不当，当访问到某一目录中没有索引文件时（或是手工开启了目录浏览功能）即把当前目录中的所有文件及相关下层目录一一在页面中显示出来，通过该漏洞攻击者可获得服务器上的文件目录结构，从而下载敏感文件（数据文件、数据库文件、源代码文件等）。

测试指南

直接访问相关应用目录。

测试结论

若能够直接浏览相关目录，则存在该漏洞。

安全建议

对于 Windows 来说，只需要进入IIS管理器，选择对应的网站，然后在功能视图中的IIS项双击【目录浏览】，然后在操作的地方点击【禁用】。另外也可以在网站目录下找到web.config文件，将 中的true修改为false！ 对于linux来说，找到相关配置文件，将Options Indexs FollowSymLinks中的Indexs 删除，有些也可以在Index的前面添加 - ，推荐是删除！。

跨站请求伪造

漏洞描述

CSRF，全称为Cross-Site Request Forgery，跨站请求伪造，是一种网络攻击方式，它可以在用户毫不知情的情况下，以用户的名义伪造请求发送给被攻击站点，从而在未授权的情况下进行权限保护内的操作。也就是说攻击者借用用户的名义，向某一服务器发送恶意请求，对服务器来讲，这一请求是完全合法的，但攻击者确完成了一个恶意操作，比如以用户的名义发送邮件，盗取账号，购买商品等。

测试指南

一般来说，重要功能会添加token ，防止被他人伪造请求，或添加随机的token，当发现重要功能处未添加token 的话， 那么存在被他人发送伪造的请求。

1. 设置页面test.html中，页面中有一个表单，和一段脚本，脚本的作用是，当页面加载时，浏览器会自动提交请求。页面代码如下（添加相关提交的参数）

<form id="modify" action="http://www.test.com/servlet/modify" method="POST">
<input name="email">
<input name="tel">
<input name="realname">
<input name="userid">
<input type="submit">
</form>
<script>
  document.getElementById("modify").submit();
</script>

2. 诱使用户在登录目标系统后访问 URL链接http://xx.x.xx.xxx/test.html

3. 用户打开 test.html 后，会自动提交表单，发送给www.test.com下的那个存在CSRF漏洞的web应用，用户信息被篡改。

4. 在整个攻击过程中，受害者用户仅看到了一个空白页面（可以伪造成其他无关页面），并且不知道自己的信息已经被修改。

测试结论

若成功伪造提交相关参数、那么存在跨站请求伪造漏洞。

安全建议

• 使用一次性令牌：用户登录后产生随机Session并赋值给页面中的某个Hidden标签，提交表单时候同时提交这个Hidden标签并验证,验证后销毁标签,只要用户不离开页面就不停产生随机Session赋值给Hidden标签；
• 验证码，每次的用户提交都需要用户在表单中填写一个图片上的随机字符串。
• 用户自身可以通过在浏览其它站点前登出站点或者在浏览器会话结束后清理浏览器的cookie。
• 验证 referer 字段，查看其请求来源是否合法。
• 在请求地址中添加 token 字段，并验证。

信息泄露

漏洞描述

备份信息泄露漏洞：目标网站未及时删除编辑器或者人员在编辑文件时，产生的临时文件，或者相关备份信息未及时删除导致信息泄露 。

测试页面信息泄露漏洞：测试界面未及时删除，导致测试界面暴露，被他人访问。

源码信息泄露漏洞：目标网站文件访问控制设置不当，WEB服务器开启源码下载功能，允许用户访问网站源码。

错误信息泄露漏洞：目标网站WEB程序和服务器未屏蔽错误信息回显，页面含有CGI处理错误的代码级别的详细信息，例如SQL语句执行错误原因，PHP的错误行数等。

接口信息泄露漏洞：目标网站接口访问控制不严，导致网站内部敏感信息泄露。

测试指南

1、 备份信息泄露漏洞、测试页面信息泄露漏洞、源码信息泄露漏洞

测试方法： 使用字典，爆破相关目录，看是否存在相关敏感文件

2、 错误信息泄露漏洞

测试方法：发送畸形的数据报文、非正常的报文进行fuzz ，看是否对错误参数处理妥当。

3、 接口信息泄露漏洞

使用爬虫或者扫描器爬取获取接口相关信息，看目标网站对接口权限是否合理。

测试结论

如果能获取到相关敏感信息、备份信息、测试界面信息、错误信息、源码信息那么存在相关漏洞。

安全建议

• 备份信息泄露漏洞：删除相关备份信息/做好权限控制
• 测试页面信息泄露漏洞：删除相关测试界面/做好权限控制
• 源码信息泄露漏洞：做好权限控制
• 错误信息泄露漏洞：将错误信息对用户透明化，在CGI处理错误后可以返回友好的提示语以及返回码。但是不可以提示用户出错的代码级别的详细原因
• 接口信息泄露漏洞：接口权限严格对外控制好

失效的身份认证

漏洞描述

通过错误使用应用程序的身份认证和会话管理功能，攻击者能够破译密码、密钥或会话令牌， 或者利用其它开发缺陷来暂时性或永久性冒充其他用户的身份。

测试指南

1. 从网站登入处开始查看分析，一步步看登入到成功登入后的，身份识别的参数，一般身份识别的会加在 Http 头中的cookie里，或者自定义的 Http 头信息。着重分析，看身份识别的是否使用的弱加密、以及简单被破解，甚至能够易被遍历的参数身份识别信息。
2. 登入成功后，查看服务端的 response 包，一般 response 包会包含 set-cookie，返回相关身份识别的信息。
3. 访问需要身份识别的功能点，然后对 cookie 或者 http 里身份识别的一个个去掉，确定具体的身份识别的参数，然后进行分析，看身份识别的参数是否属于弱身份识别。

测试结论

若身份识别是弱加密的，那么存在该漏洞。

安全建议

• 使用强身份识别，不使用简单加密方式进行身份识别。
• 使用服务器端安全的会话管理器，在登录后生成高度复杂的新随机会话ID。会话ID不能在URL中，可以安全地存储和当登出、闲置、绝对超时后使其失效。

修复建议

针对于撞库攻击主要的解决方法是提高攻击复杂度。例如：加入额外的验证码、限制登录请求频率等。

1. 在登录接口加入验证码验证；

code = request.get["code"];
if code != session.get["code"] && code != null
	session.set["code"] = null
	return
eles
	authentication(username, password)

2. 限制登录请求频率：

ip = request.get["IP"];
count,expire_time = db.get[ip]
if expire_time < nowtime()
	if count < 5
			authentication(username, password)
			db.set[ip] = count+1,expire_time
	else if count == 5
			db.set[ip] = 0,nowtime()+15min
	else
			return error
else
	return error

注解：

撞库漏洞是非常普遍的安全漏洞，结合社工库撞库可获取大量用户名密码。解决方法一般有两种：

1）在登录处加入安全的图片验证码，增加撞库的难度。 安全的图片验证码必须满足：

生成过程安全：图片验证码必须在服务器端进行产生与校验；

使用过程安全：单次有效，且以用户的验证请求为准；

验证码自身安全：不易被识别工具识别，能有效防止暴力破解。

2）在服务器端进行登录限制，针对同一ip的登陆验证加以限制。使用了图片验证码后，能防止攻击者有效进行“动态短信”功能的自动化调用；但若攻击者忽略图片验证码验证错误的情况，大量执行请求会给服务器带来额外负担，影响业务使用。建议在服务器端限制单个 IP 在单位时间内的请求次数，一旦用户请求次数（包括失败请求次数）超出设定的阈值，则暂停对该 IP一段时间的请求；若情节特别严重，可以将 IP 加入黑名单，禁止该 IP 的访问请求。该措施能限制一个 IP 地址的大量请求，避免攻击者通过同一个 IP 对大量用户进行攻击，增加了攻击难度，保障了业务的正常开展。该阈值设定可依据业务的不同执行设定，一般情况下建议不超过 200 个/分钟。

失效的访问控制

漏洞描述

未对通过身份验证的用户实施恰当的访问控制。攻击者可以利用这些缺陷访问未经授权的功能或数据，例如：访问其他用户的账户、查看敏感文件、修改其它用户的数据、更改访问权限等。

测试指南

登入后，通过burpsuite 爬取相关url 链接，获取到url 链接之后，在另一个浏览器打开相关链接，看能够通过另一个未登入的浏览器直接访问该功能点。

测试结论

如果未登入，也能访问相关功能点，那么存在该漏洞。

安全建议

除公有资源外，默认情况下拒绝访问；

2、对API和控制器的访问进行速率限制，以最大限度地降低自动化攻击工具的危害；

3、当用户注销后，服务器上的 JWT 令牌应失效；

4、对每一个业务请求，都进行权限校验。

安全配置错误

漏洞描述

1. 应用程序栈堆的任何部分都缺少适当的安全加固，或者云服务的权限配置错误。

2. 应用程序启用或安装了不必要的功能（例如：不必要的端口、服务、网页、帐户或权限）。

3. 默认账户的密码仍然可用且没有更改。

4. 错误处理机制向用户披露堆栈跟踪或其他大量错误信息。

5. 对于更新的系统，禁用或不安全地配置最新的安全功能。

6. 应用程序服务器、应用程序框架（如：Struts、Spring、ASP.NET）、库文件、数据库等没有进行相关安全配置。

测试指南

前期先对应用、IP，应用指纹等进行信息搜集，然后针对搜集的信息，看相关应用默认配置是否有更改，是否有加固过；IP 端口开放情况，端口是否开放了多余的端口。

测试结论

若发现相关应用使用了默认的配置等未进行加固，那么存在漏洞。

安全建议

• 搭建最小化平台，该平台不包含任何不必要的功能、组件、文档和示例。移除或不安装不适用的功能和框架
• 在所有环境中按照标准的加固流程进行正确安全配置

使用含有已知漏洞的组件

漏洞描述

使用了不再支持或者过时的组件。这包括：OS、Web服务器、应用程序服务器、数据库管理系统（DBMS）、应用程序、API和所有的组件、运行环境和库。

测试指南

根据前期信息搜集的信息，查看相关组件的版本，看是否使用了不在支持或者过时的组件。一般来说，信息搜集，都可通过http返回头、以及相关错误信息，应用指纹等手段搜集。

测试结论

当发现使用了不在支持或者过时的组件，那么存在相关漏洞。

安全建议

• 移除不使用的依赖、不需要的功能、组件、文件和文档；
• 从官方渠道安全的获取组件，并使用签名机制来降低组件被篡改或加入恶意漏洞的风险；
• 监控那些不再维护或者不发布安全补丁的库和组件。如果不能打补丁，可以考虑部署虚拟补丁来监控、检测或保护。

业务逻辑漏洞

短信炸弹

漏洞描述

短信轰炸攻击时常见的一种攻击，攻击者通过网站页面中所提供的发送短信验证码的功能处，通过对其发送数据包的获取后，进行重放，如果服务器短信平台未做校验的情况时，系统会一直去发送短信，这样就造成了短信轰炸的漏洞。

测试指南

1、手工找到有关网站注册页面，认证页面，是否具有短信发送页面，如果有，则进行下一步。

2、通过利用 Burp 或者其它抓包截断工具，抓取发送验证码的数据包，并且进行重放攻击，查看手机是否在短时间内连续收到10条以上短信，如果收到大量短信，则说明存在该漏洞。

风险分析

攻击者通过填写他人的手机号，使用软件 BurpSuite 的intruder功能重复提交发送短信的请求包，达到短时间内向他人的手机上发送大量垃圾短信的目的。

安全建议

• 合理配置后台短信服务器的功能，对于同一手机号码，发送次数不超过3-5次，并且可对发送的时间间隔做限制。
• 页面前台代码编写时，加入禁止针对同一手机号进行的次数大于N次的发送，或者在页面中加入验证码功能，并且限制发送的时间间隔。

修复建议

该漏洞的产生通常是由于服务端对验证码发送未做限制或限制不完善导致。

1. 限制每个手机号可接收验证码的频率

mobile = request.get["mobile"];
count = db.get[mobile]
if count > 10
	return error
sendmail(mobile)

2. 限制每个IP请求手机号的验证码的频率

ip = request.getClientIP()
mobile = request.get["mobile"]
count = db.get[ip]
if count > 10
	return error
sendcaptcha(mobile)

邮件炸弹

漏洞描述

应用系统未限制邮件的发送次数和频率，造成短时间内大量邮件发送至接收者邮箱，造成大量垃圾邮件。

测试指南

1、 手工找到有关网站注册页面，认证页面，是否具有邮件发送页面，如果有，则进行下一步。

2、 通过利用burp或者其它抓包截断工具，抓取发送邮件的数据包，并且进行重放攻击，查看邮箱是否在短时间内连续收到10封以上邮件，如果收到大量邮件，则说明存在该漏洞。

风险分析

攻击者通过填写他人的邮箱地址，使用软件burpsuite的intruder功能重复提交发送邮件的请求包，达到短时间内向他人的邮箱中发送大量垃圾邮件的目的。

安全建议

• 合理配置后台邮件服务器的功能，对于同一邮箱，发送次数不超过3-5次，并且可对发送的时间间隔做限制。
• 页面前台代码编写时，加入禁止针对同一邮箱进行的次数大于N次的发送，或者在页面中加入验证码功能，并且限制发送的时间间隔。

修复建议

该漏洞的产生通常是由于服务端对验证码发送未做限制或限制不完善导致。

1. 限制每个邮箱可接收验证码的频率

email = request.get("email");
count = db.get(email)
if count > 10
	return error
sendmail(email)
db.set(ip) = count + 1

2. 限制每个IP请求邮箱的验证码的频率

ip = request.getClientIP()
email = request.get("email")
count = db.get(ip)
if count > 10
	return error
sendmail(email)
db.set(ip) = count + 1

验证码设计缺陷

漏洞描述

攻击者可以利用该漏洞，对验证接口处的参数进行暴力破解、单个验证码反复利用，导致验证策略形同虚设，从而造成任意用户注册、登录等危害。

修复建议

针对验证码设计缺陷漏洞通常的解决方法有以下几种：

• 在服务器端限制每个IP的请求频率；
• 在接收到请求中的验证码后，都应在进行比较后立刻销毁；
• 杜绝将验证码在前端输出或判断其正确性；
• 增强验证码的健壮性，增加扭曲、变形、干扰线条、干扰背景以及字体变换，防止AI识别；

短信定向转发

漏洞描述

短信接收人可任意指定

测试指南

拦截发送短信的请求，将手机号改为测试人员的手机号，测试是否可接收短信验证码。

风险分析

攻击者可利用该漏洞将验证码发送到自己的手机号上，重置他人密码或转账。

安全建议

发送短信时手机号从当前会话中获取，避免从前端传入。

邮件可定向转发

漏洞描述

应用系统发送邮件的接收人可由客户端任意指定

测试指南

拦截发送邮件的请求，将接收人邮箱改为测试人员的邮箱地址，测试是否可接收邮件。

风险分析

攻击者可利用该漏洞将邮件发送到自己的邮箱中，重置他人密码。

安全建议

发送邮件时邮箱从当前会话中获取，避免从前端传入。

任意用户密码修改/重置

漏洞描述

可通过篡改用户名或ID、暴力破解验证码等方式修改/重置任意账户的密码。

测试指南

密码修改的步骤一般是先校验用户原始密码是否正确，再让用户输入新密码。

修改密码机制绕过方式大概有以下三种：

• 如果输入新密码的接口可以直接访问，那么在未知原始密码的的情况下即可直接修改密码，通常知道了他人的用户名即可任意修改他人的密码。
• 如果系统未校验修改密码的用户身份，那么在提交修改密码请求时，攻击者通过输入密码，将用户名或者用户ID修改为其他人的，即可成功修改他人的密码。
• 当修改密码时系统需要电子邮件或者手机短信确认，而应用程序未校验用户输入的邮箱和手机号，那么攻击者通过填写自己的邮箱或手机号接收修改密码的链接和验证码，以此修改他人的密码。

密码重置机制绕过攻击方式主要有以下两种：

• 通过正常手段获取重置密码的链接，猜解链接的组成结构和内容（如用户名或者时间戳的MD5值）。在得知他人邮箱的情况下，构造重置他人密码的链接。
• 在得知他人手机号的情况下，通过穷举手机验证码重置他人的密码。

风险分析

密码修改功能常采用分步骤方式来实现，攻击者在未知原始密码的情况下绕过某些检验步骤修改用户密码。

重置密码过程一般是首先验证注册的邮箱或者手机号，获取重置密码的链接（一般会包含一串唯一的字符串）或者验证码，然后访问重置密码链接或者输入验证码，最后输入新密码。密码重置机制绕过攻击是指在未知他人的重置密码链接或手机验证码的情况下，通过构造重置密码链接或穷举手机验证码的方式直接重置他人的密码。

安全建议

• 一次性填写校验信息（原始密码、新密码等）后再提交修改密码请求。
• 对客户端提交的修改密码请求，应对请求的用户身份与当前登录的用户身份进行校验，判断是否有权修改用户的密码并对原始密码是否正确也进行判断。
• 不应将用于接收验证信息的手机、邮箱等信息全部明文传到客户端，应对手机、邮箱等信息进行屏蔽处理，或不将此类信息返回到客户端。
• 对原始密码进行了验证的情况下，限制输入原始密码的错误次数，防止攻击者暴力破解原始密码。
• 重置密码链接中的关键信息应随机化，不可预测（例如token机制），且禁止将关键信息返回到客户端。

修复建议

1） 针对于爆破类型的密码重置漏洞，需要设置健壮的验证码信息，严格限制验证码的使用次数并提高验证码的强度，防止无限爆破和猜解；

2） 针对修改用户uid、邮箱等的密码重置漏洞，需要验证uid和验证身份的加密字符串的关联校验，防止产生万能的身份验证字符串；其次，要对用户身份进行持续性验证，防止在通过初步验证后再最终步骤中修改uid而重置其他用户的密码；

3）针对验证身份字符串泄露的密码重置漏洞，杜绝在前端或返回包中将验证身份的字符串明文输出或仅使用简单的加密算法，如 md5 或 base64

SSO认证缺陷

漏洞描述

SSO认证存在缺陷，可越权登录他人账户。

测试指南

从以下两个方向测试：

1、信息传输缺乏安全保证。

SSO认证通信过程中大多数采用明文形式传送敏感信息，这些信息很容易被窃取，致使重要信息泄露。另外，在通信过程中大多数方案也没有对关键信息进行签名，容易遭到伪装攻击。

2、Web服务的安全缺陷

由于单点登录基本上是基于Web服务实现的，所以也不可避免的存在Web服务的安全缺陷，如跨站脚本攻击、越权攻击等。

风险分析

因为只需要登录一次，所有的授权的应用系统都可以访问，可能导致一些很重要的信息泄露。

安全建议

• 建议在不影响业务的前提下，使用HTTPS协议传输。
• 严格校验SSO认证过程中的用户身份。
• 过滤用户传入的参数，对特殊符号进行转义或屏蔽。

越权

漏洞描述

越权访问，这类漏洞是指应用在检查授权（Authorization）时存在纰漏，使得攻击者在获得低权限用户帐后后，可以利用一些方式绕过权限检查，访问或者操作到原本无权访问的高权限功能。在实际的代码安全审查中，这类漏洞往往很难通过工具进行自动化检测，因此在实际应用中危害很大。其与未授权访问有一定差别。

测试指南

1. 以超管 admin（高权限用户） 身份登录系统。
2. 找到一个只有超管（高权限）才有的功能的链接，比如：“http://localhost/mywebappname/userManage/userList.do” , 显示出所有的user，并复制此链接。
3. 以普通用户登陆进系统,在地址栏输入： userManage/userList.do，如果可以查看到其所有的user，则就造成了，普通用户的越权访问。

**检测说明：**权限管理测试更多的是进行人工分析，自动化工具无法了解页面的具体应用场景以及逻辑判断过程。因此这里的测试需要首先测试人员理解测试业务系统的逻辑处理流程，并在此基础上进行如下测试：

参考依据：

• 页面是否进行权限判断。
• 页面提交的资源标志是否与已登陆的用户身份进行匹配比对。
• 用户登陆后，服务器端不应再以客户端提交的用户身份信息为依据，而应以会话中保存的已登陆的用户身份信息为准。
• 必须在服务器端对每个请求URL进行鉴权，而不能仅仅通过客户端的菜单屏蔽或者按钮Disable来限制。

风险分析

目前存在着两种越权操作类型：横向越权操作和纵向越权操作。前者指的是攻击者尝试访问与他拥有相同权限的用户的资源；而后者指的是一个低级别攻击者尝试访问高级别用户的资源,如图所示的情况

安全建议

对用户操作进行权限校验，防止通过修改参数进入未授权页面及进行非法操作，建议在服务端对请求的数据和当前用户身份做一个校验检查。

流程描述：在服务器接收到用户发送的页面访问请求时，根据预设的识别策略，从用户的页面访问请求中提取该用户对应的用户唯一标识信息，同时提取所述页面访问请求对应的应答页面中的表单及该表单中不可修改参数，将所述表单及不可修改参数与所述用户唯一标识信息绑定后记录到参数列表中；检测到用户提交请求页面的表单时，将所述请求页面的表单及不可修改参数与该用户对应的所述参数列表中记录的表单及不可修改参数进行比对，控制该用户的访问。例如：

登陆时将用户名存入session 
session.setAttribute("username",username);
在相关页面判断
if((String)session.getAttribute("username")!=admin)
(response.sendRedirect("XXX.jsp"));
注意： xxx.jsp为自定义的错误页面

恶意锁定问题

漏洞描述

通过不断的输入错误的密码可恶意锁定任意账号。

测试指南

针对测试账户，不断输入错误的密码，直至将其锁定。

风险分析

若系统认证功能无防自动化处理模块，攻击者可编写脚本批量锁定系统账号。

安全建议

• 账户锁定之后应不能继续使用认证功能。
• 认证功能防自动化操作，如添加图形验证码。

密码修改/重置流程跨越

漏洞描述

密码修改功能常采用分步骤方式来实现，攻击者在未知原始密码的情况下绕过某些检验步骤修改用户密码。

测试指南

完成修改/重置密码的正常流程；

绕过检验原密码等步骤，直接访问输入新密码页面，输入新密码，修改／重置密码。

风险分析

有些密码修改/重置流程采用step=1、step=2类似的方式实现，如果应用校验不全面，攻击者可绕过前面的步骤，直接访问最后一步，输入新密码进行修改/重置。

安全建议

一次性填写校验信息（原始密码、新密码等）后再提交修改／重置密码请求。

负值反冲

漏洞描述

应用程序未校验订单数据的取值范围，交易存在负值反冲。

测试指南

提交订单时拦截请求，修改订单参数为负数，如商品单价、数量、总价等。

风险分析

通过篡改订单参数，使得订单金额为负值，在使用余额支付时余额反而增加。

安全建议

• 服务器端在生成交易订单时，商品的价格从数据库中取出，禁止使用客户端发送的商品价格。
• 服务器端对客户端提交的交易数据（如商品ID、商品数量、商品价格等）的取值范围进行校验，将商品ID和商品价格与数据库中的数据对比校验，商品数量为大于零的整型数。
• 服务器端在生成支付订单时，对支付订单中影响支付金额的所有因素（比如商品ID、商品数量、商品价格、订单编号等）进行签名，对客户端提交的支付订单进行校验。

正负值对冲

漏洞描述

应用程序未校验订单数据的取值范围，交易存在正负值对冲。

测试指南

提交订单（包含多种商品）时拦截请求，修改部分商品的单价或数量，保证订单总金额为正数。

风险分析

由于应用会校验订单总金额的取值范围，所以在保证该条件满足的前提下，修改个别商品的数量，达到正负值对冲。

安全建议

• 服务器端在生成交易订单时，商品的价格从数据库中取出，禁止使用客户端发送的商品价格。
• 服务器端对客户端提交的交易数据（如商品ID、商品数量、商品价格等）的取值范围进行校验，将商品ID和商品价格与数据库中的数据对比校验，商品数量为大于零的整型数。
• 服务器端在生成支付订单时，对支付订单中影响支付金额的所有因素（比如商品ID、商品数量、商品价格、订单编号等）进行签名，对客户端提交的支付订单进行校验。

业务流程跳跃

漏洞描述

业务逻辑流程分步骤进行且能越过中间校验步骤直接进行后续操作，导致中间校验等步骤失效。

测试指南

• 首先完成正常的业务逻辑步骤，获取每一个步骤的请求。
• 绕过中间步骤，直接访问最后一个或几个验证请求，看是否可绕过。

风险分析

攻击者可利用该漏洞绕过业务流程检测，进行非法修改他人密码等危险操作。

安全建议

建议在不影响业务的前提下，在Session中添加对每一步流程页面的校验标志位，在新步骤页面浏览过程中，仅能够顺序执行页面校验，不可进行跳步操作，例如：页面二完成后，应更新Flag=3，则仅能够打开页面三。