前言 

搞安全的小伙纸面试的时候，面试官总是喜欢问一个问题，只有一个登录框你都能测试哪些漏洞？ 通常大家测试的都是测试关键，为了有更好的测试效果，会提供给你用户名密码；但是一些比较重要的企业，而这个环境却是正式环境，里面存放着一些数据不希望被你看到的时候，是不会提供给给你登录账号的。
这个时候，考验你基础知识是否扎实的时刻来临了。

用户名枚举

漏洞描述：存在于系统登录页面，利用登陆时输入系统存在的用户名错误密码和不存在的用户名密码，返回不同的信息（用户名不存在）可枚举出系统中存在的账号信息。

测试方法：

找到网站或者web系统登录页面。
在web系统登录页面，通过手工方式，利用系统中存在的用户名和不存在的用户名，密码随意，尝试登录，查看其返回的内容。例如：输入存在的用户名admin，回显如下：您输入的密码错误；输入不存在的用户名administrator，返回如下：用户名不存在。

示例：

1. 输入不存在的用户

2. 输入正确的用户名

风险分析：

攻击者根据Web应用程序返回的不同的提示信息即可枚举系统中存在的用户名信息，然后针对枚举出来的用户名，对其密码进行暴力破解。

修复方案：

建议对网站登录页面的判断回显信息修改为一致：用户名或密码错误。

弱口令

漏洞描述：认证登录环节存在弱口令
测试方法：
1.找到网站登录页面，尝试输入常见弱口令（admin 123456...）；
2.根据网站所使用的第三方组件(phpmyadmin/edtior/tomcat...)，寻找特定的弱口令或默认口令进行登录。
示例：
通常很多厂商后台默认账户为“admin”，密码为"admin"或“123456”，大家可以通过暴力破解去尝试

风险分析：攻击者可利用互联网公开的常见弱口令尝试登录管理后台，获取网站后台控制权限。
修复方案：禁止使用弱口令，口令应满足一定的复杂度。（大小写字母+数字+特殊符号）

空口令

漏洞描述：认证登录环节允许空口令
测试方法：
找到网站登录页面，尝试输入用用户名，不使用密码直接进行登录。
示例：
暂无，这个确实没遇到过，但是感觉最新出来的Apache shiro cve-2020-17523   Apache shiro认证绕过挺像的
**风险分析**：攻击者可利用该漏洞登录网站后台，获取后台控制权限。
**修复方案**：判断输入密码是否为空，禁止空口令登录。

登录认证绕过

漏洞描述：能够绕过应用认证，直接登录系统。
测试方法：
绕过认证主要有几下几种途径：
1.网络嗅探。通过网络嗅探工具探测局域网中传输的明文用户名和密码（http协议）。有些应用程序采用GET方式发送登录请求，可能导致GET的URL请求内容被缓存在代理服务器或者Web服务端（访问记录），导致用户名和密码泄漏。
2.默认或可猜测的用户账号。大多数开源软件或商业软件提供的基于网络配置和管理的接口，通常都会有一些默认的用户名和密码。例如，一般默认的用户名是：admin，administrator、root、system、guest等，而默认的秘密吗也根据硬件和软件的不同而不同，可尝试一下这些密码：password、admin、guest、123456、firewall等。
3.直接访问内部URL(未授权访问？)。使用Spider（御剑、dirb、dirsearch等）工具找到含有admin、manager、administrator、login等词语的路径，尝试使用普通的登录用户访问这些URL（越权？）。从而获得管理员的权限（sso登录认证绕过？）。
4.修改参数绕过认证（通常表现为前端校验）。应用程序可能会使用一个参数或一个隐藏的域表示一个用户是否经验证了，通过修改这些参数，从而欺骗服务器认为是这已经是认证过的用户。例如：http://www.demo.xom/userinfo.php?code=false，通过修改code参数为true，http://www.demo.xom/userinfo.php?code=true，然后就可以通过认证，直接访问后台页面。
5.可猜测的SessionID。利用规律（我见过某路由器的sessionid为用户名），猜测到一个有效的SessionID（可以使用K8工具进行sessionid枚举），然后通过修改response请求中的SessionID为一个预测到的有效的SessionID，从而冒充会话的真正拥有者（与会话固定有异曲同工之处），绕过认证环节。
6.注入问题。利用万能密码登录系统，绕过认证环节。（'+or+1=1#）
7.CSRF。利用CSRF漏洞在用户不知情的情况下，利用用户的会话进行敏感操作，从而绕过认证。(这有点太玄幻了)
示例：
Apache shiro cve-2020-17523   Apache shiro较新的登录认证绕过，大概的方式就是使用空字符绕过
www.xxx.com/admin/%20/
www.xxx.com/admin/%2e/
示例
用户名密码一顿瞎写

点击登陆按钮同时使用抓包工具进行数据包拦截

将数据包返回至当前页面，修改code值

登录成功

风险分析：

如果应用程序在认证上没有做好，可能导致恶意用户或者攻击者绕过认证，访问内部资源，这类漏洞通过防火墙和入侵检测系统很难预防。

修复方案：

1.对于每一个访问的URL都首先检查是否已经登录（不需要认证的URL除外，例如，帮助页面、免费下载页面等），如果没有登录，则跳转到登录页面。对于已经登录的用户，在退出的时候或者在会话很长时间处于怠机状态的时候，需要保证原来的会话被正确的销毁并且不会再被重利用（会话重用漏洞）。
2.规定密码强度要求，防止弱口令。
3.对于用户是否已经认证，禁止依赖客户端传过来的参数标识（不使用前端校验），而应将是否登录的标识保存在服务器端的会话中（使用后台校验），当接收到该会话的请求时，从会话保存的状态判断是否登录。
4.对于SessionID一定要使用安全的随机数生成算法，使得SessionID不可预测。
5.对于暴力破解攻击，建议在尝试3次左右失败之后，使用图形验证码（等保二不强求）。

存在暴力破解风险

漏洞描述：通常来讲，若是没有对用户的自动化破解攻击进行防护，即无校验码，无会话失效（用户锁定）导致该页面失效（需重新访问页面），未限定用户登陆次数都可进行暴力破解尝试。通常配合明文传送漏洞以及用户名枚举漏洞进行攻击尝试。
测试方法：
1. 找到网站登录页面。
2. 利用burpsuite对登录页面进行数据包拦截，将其发送到Intruder模块,并设置其密码参数，如password=$1$，添加payload（字典），进行攻击，攻击过程中查看其返回的字节长度，来判断是否成功。
一般情况下，暴力破解有三种形式：
1) 固定账号对密码暴力破解(单一型)。
2) 在得知账号具有规律性，或者通过某种方式获取到大量账号的前提下，固定密码对账号暴力破解。
3) 使用网上流传的账号密码库进行撞库攻击（社工库泄露）。

示例：

风险分析：攻击者一般会使用自动化工具组合出常见的用户名和密码，再结合软件burpsuite的intruder功能进行暴力破解。
修复方案：防止暴力攻击的一些方法如下：
1、账户锁定
账户锁定是很有效的方法，因为暴力破解程序在5-6次的探测中猜出密码的可能性很小。但是同时也拒绝了正常用户的使用（恶意用户锁定）。如果攻击者的探测是建立在用户名探测成功之后的行为，那么会造成严重的拒绝服务攻击。对于对大量用户名只用一个密码的探测攻击账户锁定无效。如果对已经锁定的账户并不返回任何信息，可能迷惑攻击者（返回字段长度一致，使其无法观察length）。
2、返回信息
如果不管结果如何都返回成功的信息，破解软件就会停止攻击（破解软解不会停止，而是人无法从大量数据中筛选正确的数据）
3、页面跳转
产生登录错的的时候就跳到另一个页面要求重新登录（302）。局限性在于不能总是跳转页面，一般只在第一次错误的时候跳转，但是第一次之后又可以继续暴力探测了（可以进行弹框事件）。
4、适当的延时
检查密码的时候适当的插入一些暂停，可以减缓攻击，但是可能对用户造成一定的影响。（自欺欺人）
5、封锁多次登录的IP地址
这种方法也是有缺点的，因为攻击者可以定时更换自己的IP。（xff更换，伪造ip地址）
6、验证码
验证码是阻止暴力攻击的好方法，但设计不好的验证码是可以绕过的，而且对于特定目标的手工探测来说验证码是没有作用的（现在的验证码很难绕过，识别的工具会很麻烦）。

图形验证码不失效

漏洞描述：有些网站登录框存在图形验证码，防止暴力破解攻击，但是正常的逻辑是前端输入验证码之后进行校验图形验证码的正确性，而后若是为真则进行登录操作，为假则返回验证码输入错误，而使用一次的验证码应该立即失效。然而有些网站验证码可能是可控的，输入一些特殊字符可能就能达到欺骗服务器或验证码使用一次之后并没有及时刷新（所谓的验证码可以被自动识别这个问题，我个人觉得没啥卵用，就不写了）特殊验证码000000
测试方法：
输入用户名、密码、验证码后，点击登陆按钮同时将数据包使用burpsuite进行拦截，并使用Repeater模块或Intruder模块进行数据重放，重新发送数次观察页面变化，是否会提示验证码输入错误等信息
示例：

某查询页面需要输入验证码才可以查询成功

通过多次请求发现验证码并未及时失效，导致可重复利用，修改agentCode为其他数据依然可以查询成功

风险分析：图形验证码一般是防止使用程序恶意注册、暴力破解用户名密码或者批量发帖而设置的。在页面初始化时服务器向页面发送一个随机字符串，同时在Session里也保存一份，当用户提交时将随机数一起到后台，通过与Session中保存的值对比，如果不相同，则会报错。
修复方案：
1、系统在开发时注意验证识别后销毁session中的验证码。
2、限制用户提交的验证码不能为空
3、判断提交的验证码与服务器上存储的是否一致

短信验证码绕过

漏洞描述：一些网站使用手机短信登录，短信验证码可被绕过，执行其他操作。
测试方法：
1.请求发送短信，填写任意验证码，然后提交请求，将验证码参数置空或删除，测试是否可绕过检测；
2.尝试特权验证码，如000000、111111等；
3.同一个短信验证码是否能使用多次；

示例：
正确的逻辑应当是，短信验证码获取后，服务器校验短信验证码的来源以及有效性，使用一次后应该立即失效。但是我遇到的这个就是使用验证码登录后，注销用户登录后再一次使用验证码发现依然登陆成功，也就是短信验证码没有被删除

输入手机号码，而后获取验证码，随意输入即可

response返回如下

修改state值为200

风险分析：修改／重置密码、交易操作等功能通常需要短信验证码，若验证码可绕过，攻击者可利用该漏洞进行重置他人密码或转账等危险操作。
修复方案：
1.若存在特权验证码，建议将其删除；
2.应用服务端应严格校验验证码参数是否为空，格式是否正确；
3.关键操作每提交一次请求，应发送新的短信验证码，并且不可继续使用旧的验证码。（后端校验！！！）

短信验证码可暴力破解

漏洞描述：短信验证码位数太短或有效期太长导致可暴力破解（或者干脆不过期）
测试方法：
点击发送短信验证码，输入任意验证码，提交请求，使用burpsuite拦截请求，在intruder模块设置验证码参数为枚举变量，这时的payload类型为brute forcer（数字0-9，长度为6），对验证码进行暴力破解。

示例：
这里的短信验证码可被暴力破解，是因为并没有设置短信验证码使用错误几次后失效，故可被暴力破解

风险分析：修改／重置密码、交易操作等功能通常需要短信验证码，若验证码可暴力破解，攻击者可利用该漏洞进行重置他人密码或转账等危险操作。
修复方案：
1.短信验证码不少于6位；
2.有效期不超过2分钟；
3.验证码错误次数超过上限应采取账户锁定策略（建议验证码错误三次失效）。

短信验证码可预测

漏洞描述：短信验证码随系统返回，可预览
测试方法：
点击发送短信验证码，获取验证码的同时拦截数据，发送至repeater模块进行查看
示例：
1.点击登陆，选择手机登录，获取验证码的同时拦截数据，如下图所示

2. 拦截数据包，将response数据包返回至当前页面

3. 成功获取验证码，使用该验证码进行登录

4.使用该六位验证码进行登录，登录成功，查看手机验证码，一致

风险分析：验证码可预测大致分为两种，一种是可以构造数据请求，提前将构造好的验证码发送至后台而后达到欺骗服务器的目的；第二种为验证码随系统返回到前端或js页面内，可达到直接预览的效果，直接使用验证码即可达到登录任意用户、修改任意用户密码的功能
修复方案：
不要将验证码发送至客户端

短信轰炸

漏洞描述：短信轰炸是常见的一种攻击，攻击者通过网站页面中所提供的发送短信验证码的功能处，通过对其发送数据包的获取后，进行重放，如果服务器短信平台未做校验的情况时（不校验当前用户是否在规定时限内发送短信成功的次数），系统会一直去发送短信，这样就造成了短信轰炸的漏洞（消耗系统资源，造成用户困扰）。
测试方法：
1、手工找到有关网站注册页面（登录、支付等页面）
2、通过利用burpsuite进行数据包拦截，抓取发送验证码的数据包，并且进行重放攻击，查看手机是否在短时间内连续收到5条以上短信，如果收到大量短信，则说明存在该漏洞。

示例：
点击获取验证码同时拦截数据包

使用burpsuite进行数据重放

风险分析：攻击者通过填写他人的手机号，使用软件burpsuite的intruder功能重复提交发送短信的请求包，达到短时间内向他人的手机上发送大量垃圾短信的目的（同时消耗服务器大量资源，短信要钱的，我发一千万条估计也不少钱吧）。
修复方案：
1、合理配置后台短信服务器的功能，对于同一手机号码，一定时间内发送次数不超过3-5次，并且可对发送的时间间隔做限制（一分钟内检测时间戳对用户的sessionid进行识别，一天之内不能超过数条）。
2、页面前台代码编写时，加入禁止针对同一手机号进行的次数大于N次的发送，或者在页面中加入验证码功能，并且限制发送的时间间隔。

恶意锁定问题

漏洞描述：通过不断的输入错误的密码可恶意锁定任意账号
测试方法：
针对测试账户，不断输入错误的密码，直至将其锁定（一般会提示再输入几次就锁定账户，或直接锁定不提醒）
示例：

风险分析：若系统认证功能无防自动化处理模块（即用户锁定后当前会话失效，需要重新加载页面），攻击者可编写脚本批量锁定系统账号。
修复方案：
1.账户锁定之后应不能继续使用认证功能
2.认证功能防自动化操作，如添加图形验证码。

密码明文传输

漏洞描述：认证过程中传输未加密（用户名密码等敏感数据明文传输）。
测试方法：
通过对网站登录页面的请求进行抓包，工具可用burpsuite、wireshark、filder、等等，分析其数据包中相关password（密码）参数的值是否为明文。如图利用wireshark抓包分析的密码

示例：
1. 输入用户名密码

2. 使用burpsuite进行数据包拦截

风险分析：攻击者通过在局域网中嗅探网络流量，获取明文传输的认证凭证，如用户名密码、SESSIONID等敏感信息(关于明文传输问题涉及两个问题，一个是当web使用http传输时，存在局域网嗅探的可能，由于http采取非加密传输，导致局域网内的嗅探数据是明文的；而当此网站是https传输的时候，由于数据是加密的，所以就不存在嗅探风险，但是当系统不存在验证码保护时，便成为了暴力破解风险。所以我理解为，当网站采取https加密传输方式，且存在校验码的时候，明文问题便不存在任何问题了)。
修复方案：
建议按照网站的密级要求，需要对密码传输过程中进行加密，使用加密的方式传输，如使用HTTPS，  但加密的方式增加成本，或许会影响用户体验。如果不用 HTTPS，可以在网站前端用 Javascript 做密码加密，加密后再进行传输。

反射型跨站脚本攻击

漏洞描述：跨站脚本攻击的英文全称是Cross Site Script，为了和样式表区分， XSS又称CSS，是web程序常见的漏洞，属于被动式且用于客户端的供给方式。
其原理是攻击者向有Xss漏洞的网站中输入恶意HTML代码，当它被用户浏览该网站时，这段HTML代码就会自动执行达到攻击目的。如，盗取用户Cookie，破坏页面结构，重定向到其它网站等。

测试方法：
1)在输入的参数后逐条添加以下语句，以第一条为例，输入http://www.demo.com/user?id=<script>alert(1)</script>，提交请求后，只要页面弹出显示1的弹框，就说明存在反射型跨站脚本攻击
2、由于有些HTML元素（比如<textarea>或”）会影响脚本的执行，所以不一定能够正确弹出1告警框，需要根据返回网页源文件的内容，构造value的值，（提前闭合）比如
多行文本输入框：
</textarea><script>alert(1)</script>
文本输入框：
</td><script>alert(1)</script>  
'><script>alert(1)</script>
"><script>alert(1)</script>
</title><script>alert(1)</script>
需要对页面上所有可以提交参数的地方进行测试。具体跨站脚本的测试语句根据实际情况的不同而不同，可自行构造，以及触发事件等切换（实测有些黑名单过滤，过滤了绝大多数的事件，但是可以使用颜色标签更改字体颜色），这里只列出了一些最常见构造语句。

示例：
1. 登录窗口用户名处存在反射型XSS注入

2. 点击登陆，成功弹出内容

1.盗取各类用户账号，如机器登录账号，用户网银账号，各类管理员账号
2.控制企业数据，包括读取、篡改、添加、删除企业敏感数据的能力
3.盗取企业重要的更具有价值性的资料
4.非法转账
5.强制发送电子邮件
6.网站挂马
7.控制受害者机器向其它网站发起攻击
修复方案：
1、总体修复方式：验证所有输入数据，有效检测攻击；对所有输出数据进行适当的编码，以防止任何已成功注入的脚本在浏览器端运行。具体如下 ：
1)输入过滤：某个数据被接受为可被显示或存储之前，使用标准输入验证机制，验证所有输入数据的长度、类型、语法以及业务规则。
2)输出编码控制：数据输出前，确保用户提交的数据已被正确进行entity编码，建议对所有字符进行编码而不仅局限于某个子集。
3)明确指定输出的编码方式：不要允许攻击者为你的用户选择编码方式(如ISO 8859-1或 UTF 8)。
4)注意黑名单验证方式的局限性：仅仅查找或替换一些字符(如"<" ">"或类似"script"的关键字)，很容易被XSS变种攻击绕过验证机制。
警惕规范化错误：验证输入之前，必须进行解码及规范化以符合应用程序当前的内部表示方法。请确定应用程序对同一输入不做两次解码。对客户端提交的数据进行过滤，一般建议过滤掉双引号（”）、尖括号（<、>）等特殊字符，或者对客户端提交的数据中包含的特殊字符进行实体转换，比如将双引号（”）转换成其实体形式&quot;，<对应的实体形式是&lt;，<对应的实体形式是&gt;以下为需过滤的常见字符

万能密码

漏洞描述：其实我觉得万能密码和sql注入应当区分开来，所以我就分开写了。
众所周知，登录处是一条查询操作，一些程序可能是没有注意到，就写成了

$result=mysqli_query($link,'select * from user');        #执行$sql命令,查询user列表行内容
$row=mysqli_fetch_assoc($result);       #解析，通过用户名判断 里面行的内容密码是否正确
if ( $username===$row['username'] && $password === $row['password']) {
    echo '登陆成功';
	$_SESSION['uid'] = $row['id'] ;
    header("Location:3.php?id=".$row['id']);
 } else{
    echo '请重新填写账户或密码';

这个时候就可以构造特殊的sql语句进行截断，造成永真，这样的话就可以越过查询完成登录

$username===$row['username']+or+1=1# && $password === $row['password'])

**测试方法**：
用户名输入： ‘ or 1=1 # 密码：任意
(2)Admin’ - -（或‘ or 1=1 or ‘ - -）(admin or 1=1 --) (MS SQL)(直接输入用户名，不进行密码验证)
(3)用户名输入：admin   密码输入：’ or  ‘1’=’1 也可以
(4) 用户名输入：admin' or 'a'='a    密码输入：任意
(5) 用户名输入：‘ or 1=1 - -
(6) 用户名输入：admin‘ or 1=1 - -  密码输入：任意
(7) 用户名输入：1'or'1'='1'or'1'='1   密码输入：任意
示例：
1. 这里的案例与上述的不太相同，他的查询多了一个判断动作，就是先判断用户名是否存在，存在的 时候才会进行下一步判断，判断用户名密码是否匹配，所以这里必须输入正确的用户名才行
admin' or 1 #

2.  点击登陆，成功登录

风险分析：攻击者可通过万能密码直接登录后台，获取后台权限
修复方案：
1)对用户输入的特殊字符进行严格过滤，如’、”、<、>、/、*、;、+、-、&、|、(、)、and、or、select、union(注释符过滤 # /*  --+- ` ;%00)。
2)使用参数化查询（PreparedStatement），避免将未经过滤的输入直接拼接到SQL查询语句中。
3)Web应用中用于连接数据库的用户与数据库的系统管理员用户的权限有严格的区分（如不能执行drop等），并设置Web应用中用于连接数据库的用户不允许操作其他数据库。
4)设置Web应用中用于连接数据库的用户对Web目录不允许有写权限。
使用Web应用防火墙。

sql注入

漏洞描述：
所谓SQL注入，就是通过把SQL语句插入到Web表单提交或输入域名或页面请求的查询字符串，最终达到欺骗服务器执行恶意的SQL命令。具体来说，它是利用现有应用程序，将（恶意）SQL命令注入到后台数据库引擎执行的能力，它可以通过在Web表单中输入（恶意）SQL语句得到一个存在安全漏洞的网站上的数据库，而不是按照设计者意图去执行SQL语句。 造成SQL注入漏洞原因有两个：一个是没有对输入的数据进行过滤（过滤输入），还有一个是没有对发送到数据库的数据进行转义（转义输出）。
测试方法：
1.通过web漏洞扫描工具进行对网站爬虫后得到的所有链接进行检测，或者手工判断是否存在注入点，一旦确认存在漏洞，可利用自动化工具sqlmap去尝试注入。几种常见的判断方法：
1)数字型（int-布尔型真假注入）。
http://host/test.php?id=100 and 1=1 --+-  返回成功
http://host/test.php?id=100 and 1=2 --+-  返回失败
2)字符型（str型-布尔型真假注入）。
http://host/test.php?name=rainman  ’  and ‘1’=‘1 返回成功 
http://host/test.php?name=rainman ’  and ‘1’=‘2   返回失败
3)盲注类型。

根据mysql版本不同，5.0以上有sleep函数，5.0版本是benchmark函数，通过时间函数来观察页面响应时间来判断是否存在时间盲注
4)不同的SQL服务器连结字符串的语法不同，比如MS SQL Server使用符号+来连结字符串，而Oracle使用符号||来连结：
http://host/test.jsp?ProdName=Book’     返回错误
http://host/test.jsp?ProdName=B’+’ook  返回正常
http://host/test.jsp?ProdName=B’||’ook  返回正常说明有SQL注入
2.如果应用程序已经过滤了’和+等特殊字符，我们仍然可以在输入时过把字符转换成URL编码（即字符ASCII码的16进制）来绕过检查。

示例：

安鸾实战平台有，不掩饰了，大家可以去看一下博客，有很详细的讲解如何进行sql注入

https://blog.csdn.net/weixin_48421613/article/details/107488560

https://blog.csdn.net/weixin_48421613/article/details/107491562

https://blog.csdn.net/weixin_48421613/article/details/108298670

风险分析：在输入URL和表单处，攻击者通过输入精心构造的SQL语句，对数据库记录进行增删改查，或直接获取服务器权限。攻击者实施SQL注入攻击时大多借助自动化注入工具，如穿山甲、明小子、sqlmap、Havij等。
修复方案：
SQL注入的主要原因是程序没有严格过滤用户输入的数据，导致非法数据侵入系统。
1)对用户输入的特殊字符进行严格过滤，如’、”、<、>、/、*、;、+、-、&、|、(、)、and、or、select、union。
2)使用参数化查询（PreparedStatement），避免将未经过滤的输入直接拼接到SQL查询语句中。
3)Web应用中用于连接数据库的用户与数据库的系统管理员用户的权限有严格的区分（如不能执行drop等），并设置Web应用中用于连接数据库的用户不允许操作其他数据库。
4)设置Web应用中用于连接数据库的用户对Web目录不允许有写权限。
5)使用Web应用防火墙。

任意用户密码修改/重置 

漏洞描述：可通过篡改用户名或ID、暴力破解验证码等方式修改/重置任意账户的密码（区别于下面的密码重置，此处密码重置本质为需要知道自己的密码，而后利用自己的身份信息去替换别人的密码）。
测试方法：
密码修改的步骤一般是先校验用户原始密码是否正确，再让用户输入新密码。修改密码机制绕过方式大概有以下三种：
1.如果输入新密码的接口可以直接访问，那么在未知原始密码的的情况下即可直接修改密码，只需知道了他人的用户名即可任意修改他人的密码。
2.如果系统未校验修改密码的用户身份，那么在提交修改密码请求时，攻击者通过输入密码，将用户名或者用户ID修改为其他人的，即可成功修改他人的密码。
3.当修改密码时系统需要电子邮件或者手机短信确认，而应用程序未校验用户输入的邮箱和手机号，那么攻击者通过填写自己的邮箱或手机号接收修改密码的链接和验证码，以此修改他人的密码。
密码重置机制绕过攻击方式主要有以下两种：
1.通过正常手段获取重置密码的链接，猜解链接的组成结构和内容（如用户名或者时间戳的MD5值）。在得知他人邮箱的情况下，构造重置他人密码的链接（使用nc接收重置连接）。
2.在得知他人手机号的情况下，通过穷举手机验证码重置他人的密码。
示例：
我遇到的密码重置漏洞，是忘记密码的时候会自动发送一条手机短信至绑定用户的手机中，而我做的则是在他发送之前拦截，而后修改手机号码为我自己的，成功的接受到了手机短信，而后重置用户密码。
还有一种是手机短信验证成功后，重新设置密码时拦截数据包，通过修改类似username、userid等方式修改他人的账户密码。
风险分析：密码修改功能常采用分步骤方式来实现，攻击者在未知原始密码的情况下绕过某些检验步骤修改用户密码。
重置密码过程一般是首先验证注册的邮箱或者手机号，获取重置密码的链接（一般会包含一串唯一的字符串）或者验证码，然后访问重置密码链接或者输入验证码，最后输入新密码。密码重置机制绕过攻击是指在未知他人的重置密码链接或手机验证码的情况下，通过构造重置密码链接或穷举手机验证码的方式直接重置他人的密码。
修复方案：
1.一次性填写校验信息（原始密码、新密码等）后再提交修改密码请求。
2.对客户端提交的修改密码请求，应对请求的用户身份与当前登录的用户身份进行校验，判断是否有权修改用户的密码并对原始密码是否正确也进行判断。
3.不应将用于接收验证信息的手机、邮箱等信息全部明文传到客户端，应对手机、邮箱等信息进行屏蔽处理，或不将此类信息返回到客户端。
4.对原始密码进行了验证的情况下，限制输入原始密码的错误次数，防止攻击者暴力破解原始密码。
5.重置密码链接中的关键信息应随机化，不可预测（例如token机制），且禁止将关键信息返回到客户端。

目录遍历

漏洞描述：目录浏览漏洞是由于网站存在配置缺陷，存在目录可浏览漏洞，这会导致网站很多隐私文件与目录泄露，比如数据库备份文件、配置文件等，攻击者利用该信息可以更容易得到网站权限，导致网站被黑。
测试方法：
可以利用web漏洞扫描器扫描web应用进行检测，也可通过搜索，网站标题包含“index of”关键词的网站进行访问。
示例：
一般目录遍历都是输入../../这种，或者通过御剑进行目录扫描，有的时候会有一些路径可以遍历里面的目录内容

风险分析：攻击者通过访问网站某一目录时，该目录没有默认首页文件或没有正确设置默认首页文件，将会把整个目录结构列出来，将网站结构完全暴露给攻击者； 攻击者可能通过浏览目录结构，访问到某些隐秘文件（如PHPINFO文件、服务器探针文件、网站管理员后台访问地址、数据库连接文件等）。
修复方案：
目前存在该漏洞的常见中间件为apache和IIS,以下列出其相关的修复方式：
1、 IIS中关闭目录浏览功能：在IIS的网站属性中，勾去“目录浏览”选项，重启IIS。 
2、 Apache中关闭目录浏览功能：打开Apache配置文件httpd.conf，查找“Options Indexes FollowSymLinks”，修改为“ Options -Indexes”(减号表示取消，保存退出，重启Apache。 
3、 Nginx中默认不会开启目录浏览功能，若您发现当前已开启该功能，可以编辑nginx.conf文件，删除如下两行：autoindex on;autoindex_exact_size on;重启Nginx。

敏感文件信息泄漏

漏洞描述：敏感数据包括但不限于：口令、密钥、证书、会话标识、License、隐私数据（如短消息的内容）、授权凭据、个人数据（如姓名、住址、电话等）等，在程序文件、配置文件、日志文件、备份文件及数据库中都有可能包含敏感数据。（这里的信息泄露，我包含了常见的已经类似于robots文件等等，包括入侵痕迹残留、打包备份文件遗留等等）
测试方法：
1、检测形式多样，工具爬虫扫描得到敏感文件的路径，从而找到敏感数据，
2、手工挖掘，根据web容器或者网页源代码的查看，找到敏感信息。
示例：
这里我给大家带来了最近比较火的某捷信息泄露，在源代码中泄露了用户名密码信息

泄露了用户名以及MD5加密的密码
当然了还有一些奇葩的，会直接弹出来测试用户名密码、甚至是用户名密码自动填充等等
我觉得只有这些才配成为信息泄露，剩下的泄露个什么加密方式、中间件版本信息啥的太边缘了，懒得测

风险分析：攻击者可通过上述方式获取网站敏感文件，收集网站敏感信息，从而有针对性的进行利用。
修复方案：
1、禁止在代码中存储敏感数据：禁止在代码中存储如数据库连接字符串、口令和密钥之类的敏感数据，这样容易导致泄密。用于加密密钥的密钥可以硬编码在代码中。
2、禁止密钥或帐号的口令以明文形式存储在数据库或者文件中：密钥或帐号的口令必须经过加密存储。例外情况，如果Web容器的配置文件中只能以明文方式配置连接数据库的用户名和口令，那么就不用强制遵循该规则，将该配置文件的属性改为只有属主可读写。
3、禁止在 cookie 中以明文形式存储敏感数据：cookie信息容易被窃取，尽量不要在cookie中存储敏感数据；如果条件限制必须使用cookie存储敏感信息时，必须先对敏感信息加密再存储到cookie。
4、禁止在隐藏域中存放明文形式的敏感数据。
5、禁止用自己开发的加密算法，必须使用公开、安全的标准加密算法。
6、禁止在日志中记录明文的敏感数据：禁止在日志中记录明文的敏感数据（如口令、会话标识jsessionid等）， 防止敏感信息泄漏。
禁止带有敏感数据的Web页面缓存：带有敏感数据的Web页面都应该禁止缓存，以防止敏感信息泄漏或通过代理服务器上网的用户数据互窜问题。

框架漏洞

漏洞描述：开发框架存在的漏洞，如Struts2框架漏洞、shiro等（weblogic反序列化中间件的就不写了）
测试方法：
以Struts2远程命令执行为例：
1.在了解网站所采用的结构框架后，除去伪静态页面，抓包或者读取页面源代码方式，查找到网站系统url为.do和.action结尾类型后，添加相应的远程命令执行代码进行判断。
例如用户可以在http://host.com/X.action?后添加相对应struts2 漏洞的远程命令执行代码，或者直接利用工具K8 Struts2 Exploit.exe进行检测
或使用shiro检测工具进行检测
示例：
使用burp插件进行被动检测（关于shiro反序列化请看上篇文章->https://blog.csdn.net/weixin_48421613/article/details/111398612）

s2-001示例

%{#a=(new java.lang.ProcessBuilder(new java.lang.String[]{"ls",})).redirectErrorStream(true).start(),#b=#a.getInputStream(),#c=new java.io.InputStreamReader(#b),#d=new java.io.BufferedReader(#c),#e=new char[50000],#d.read(#e),#f=#context.get("com.opensymphony.xwork2.dispatcher.HttpServletResponse"),#f.getWriter().println(new java.lang.String(#e)),#f.getWriter().flush(),#f.getWriter().close()}

风险分析：Struts 2是在struts 和WebWork的技术基础上进行了合并的全新的框架。Struts2漏洞类型分为两种，一种是使用缩写的导航参数前缀时的远程代码执行漏洞，另一种是使用缩写的重定向参数前缀时的开放式重定向漏洞。Struts2远程命令执行，属于高危安全漏洞，可使黑客取得网站服务器的权限。这里我们重点描述相关远程命令执行漏洞。Struts2的DefaultActionMapper支持一种方法，可以使用”action:”, “redirect:”, “redirectAction:”对输入信息进行处理，从而改变前缀参数，这样操作的目的是方便表单中的操作。在2.3.15.1版本以前的struts2中，没有对”action:”, “redirect:” , “redirectAction:”等进行处理，导致ongl表达式可以被执行，如s2-020的漏洞中，利用ognl的class.xx这种方式来遍历属性

修复方案：
建议及时更新struts2的版本到最新

SSO认证缺陷

漏洞描述：SSO认证存在缺陷，可越权登录他人账户。
测试方法：
1.信息传输缺乏安全保证
SSO认证通信过程中大多数采用明文形式传送敏感信息，这些信息很容易被窃取，致使重要信息泄露。另外，在通信过程中大多数方案也没有对关键信息进行签名，容易遭到伪装攻击。
2.Web服务的安全缺陷
由于单点登录基本上是基于Web服务实现的，所以也不可避免的存在Web服务的安全缺陷，如跨站脚本攻击、越权攻击等。
示例：
首先访问某达登录页面

某路由器后台普通用户权限如下

退出登录，而后重新使用guest用户登录，同时拦截数据包，如下图所示

将user参数更改为admin，并且将后续所有的数据包user参数（cookie）皆更改为admin

风险分析：因为只需要登录一次，所有的授权的应用系统都可以访问，可能导致一些很重要的信息泄露。
修复方案：
建议从以下几个方面进行防御：
1.建议在不影响业务的前提下，使用HTTPS协议传输(吐槽一下，请问sso越权登录和明文传输有啥太大的关系吗)
2.严格校验SSO认证过程中的用户身份
3.过滤用户传入的参数，对特殊符号进行转义或屏蔽。

密码重置漏洞

漏洞描述：找回密码可进行验证绕过，通过修改返回数据参数即可成功重置任意用户密码并成功登录（这里的重置漏洞归其原因是因为校验状态马仅使用前端js校验）
测试方法：
密码修改的步骤一般是先校验用户原始密码是否正确，再让用户输入新密码。修改密码机制绕过方式大概有以下三种：
1.如果输入新密码的接口可以直接访问，那么在未知原始密码的的情况下即可直接修改密码，通常知道了他人的用户名即可任意修改他人的密码。
2.如果系统未校验修改密码的用户身份，那么在提交修改密码请求时，攻击者通过输入密码，将用户名或者用户ID修改为其他人的，即可成功修改他人的密码。
3.当修改密码时系统需要电子邮件或者手机短信确认，而应用程序未校验用户输入的邮箱和手机号，那么攻击者通过填写自己的邮箱或手机号接收修改密码的链接和验证码，以此修改他人的密码。
密码重置机制绕过攻击方式主要有以下两种：
1.通过正常手段获取重置密码的链接，猜解链接的组成结构和内容（如用户名或者时间戳的MD5值）。在得知他人邮箱的情况下，构造重置他人密码的链接。
2.在得知他人手机号的情况下，通过穷举手机验证码重置他人的密码。
示例：
1.点击普通用户找回密码，输入用户名

2.修改返回数据值

3.完成第一次绕过，输入任意验证码，如法炮制

4.输入新的密码

5.输入用户名admin 密码 ******登录成功

风险分析：密码修改功能常采用分步骤方式来实现，攻击者在未知原始密码的情况下绕过某些检验步骤修改用户密码。
重置密码过程一般是首先验证注册的邮箱或者手机号，获取重置密码的链接（一般会包含一串唯一的字符串）或者验证码，然后访问重置密码链接或者输入验证码，最后输入新密码。密码重置机制绕过攻击是指在未知他人的重置密码链接或手机验证码的情况下，通过构造重置密码链接或穷举手机验证码的方式直接重置他人的密码。
修复方案：
1.一次性填写校验信息（原始密码、新密码等）后再提交修改密码请求。
2.对客户端提交的修改密码请求，应对请求的用户身份与当前登录的用户身份进行校验，判断是否有权修改用户的密码并对原始密码是否正确也进行判断。
3.不应将用于接收验证信息的手机、邮箱等信息全部明文传到客户端，应对手机、邮箱等信息进行屏蔽处理，或不将此类信息返回到客户端。
4.对原始密码进行了验证的情况下，限制输入原始密码的错误次数，防止攻击者暴力破解原始密码。
5.重置密码链接中的关键信息应随机化，不可预测（例如token机制），且禁止将关键信息返回到客户端。

命令执行漏洞

漏洞描述：Command Injection，即命令注入攻击，是指由于Web应用程序对用户提交的数据过 滤不严格，导致黑客可以通过构造特殊命令字符串的方式，将数据提交至Web应用程 序中，并利用该方式执行外部程序或系统命令实施攻击，非法获取数据或者网络资源等。 在命令注入的漏洞中，最为常见的是PHP的命令注入。PHP命令注入攻击存在的主要 原因是Web应用程序员在应用PHP语言中一些具有命令执行功能的函数时，对用户 提交的数据内容没有进行严格的过滤就带入函数中执行而造成的。例如，当黑客提交的 数据内容为向网站目录写入PHP文件时，就可以通过该命令注入攻击漏洞写入一个 PHP后门文件，进而实施下一步渗透攻击。
测试方法：
通过web扫描工具进行扫描，也可以通过手工进行验证：打开网站，在URL中传入命令的参数输入所要执行的命令，看到command就试一下没毛病
示例：
1.访问某捷路由器web管理系统登录页面，如下图所示，点击登录按钮

2. 这里若是不输入正确的密码仅能执行show version命令，此处通过弱口令进行致命打稽

3.当然了我找到了一个不用密码就能执行任意命令的，但是我不写，诶，就是玩

风险分析：执行任意系统命令，直接就可以删库写shell了
修复方案：
与系统进行交互的时候注意封闭其他命令，禁用外部命令

未授权访问

漏洞描述：未授权访问漏洞，是在攻击者没有获取到登录权限或未授权的情况下，或者不需要输入密码，即可通过直接输入网站控制台主页面地址，或者不允许查看的链接便可进行访问，同时进行操作。
测试方法：
1.通过对登录后的页面进行抓包，将抓取到的功能链接，在其他浏览器进行打开。
2. 也可以通过web扫描工具进行扫描，爬虫得到相关地址链接，进行直接访问，如果未进行跳转到登录页面，则可判断为存在未授权访问漏洞。
示例：
访问某路由器后台，不需要输入用户名密码即可直接进行访问后台

风险分析：攻击者猜测管理后台地址或利用已知的访问地址，尝试在未登录的情况下直接访问，常见的后台登录地址有：admin.jsp、index.jsp、main.jsp、left.jsp、right.jsp、top.jsp等。攻击者进入管理后台后可修改Web应用程序设置，利用后台对上传文件过滤不严的缺陷，上传webshell等实施恶意操作。
修复方案：
常见的修复方法：在系统中，加入用户身份认证机制或者tonken验证，防止可被直接通过连接就可访问到用户的功能进行操作，简而言之，一定对系统重要功能点增加权限控制，对用户操作进行合法性验证。