原文 by 自娱
在没有验证码限制或者一次验证码可以多次使用的地方，使用已知用户对密码进行暴力破解或者用一个通用密码对用户进行暴力破解。
一些工具及脚本
-
Burpsuite
-
htpwdScan 撞库爆破必备 URL: https://github.com/lijiejie/htpwdScan
-
hydra 源码安装xhydra支持更多的协议去爆破 (可破WEB，其他协议不属于业务安全的范畴)
会话固定攻击：利用服务器的session不变机制，借他人之手获得认证和授权，冒充他人。
Cookie仿冒：修改cookie中的某个参数可以登录其他用户。
未使用https，是功能测试点，不好利用。
前端加密，用密文去后台校验，并利用smart decode可解
a) 抓包修改手机号码参数为其他号码尝试，例如在办理查询页面，输入自己的号码然后抓包，修改手机号码参数为其他人号码，查看是否能查询其他人的业务。
a) 抓包修改用户或者邮箱参数为其他用户或者邮箱
a) 查看自己的订单id，然后修改id（加减一）查看是否能查看其它订单信息。
a) 例如积分兑换处，100个积分只能换商品编号为001,1000个积分只能换商品编号005，在100积分换商品的时候抓包把换商品的编号修改为005，用低积分换区高积分商品。
a) 抓包查看自己的用户id，然后修改id（加减1）查看是否能查看其它用户id信息。
a) 抓包修改金额等字段，例如在支付页面抓取请求中商品的金额字段，修改成任意数额的金额并提交，查看能否以修改后的金额数据完成业务流程。
a) 抓包修改商品数量等字段，将请求中的商品数量修改成任意数额，如负数并提交，查看能否以修改后的数量完成业务流程。
a) 很多商品限制用户购买数量时，服务器仅在页面通过js脚本限制，未在服务器端校验用户提交的数量，通过抓包修改商品最大数限制，将请求中的商品数量改为大于最大数限制的值，查看能否以修改后的数量完成业务流程。
a) 部分应用程序通过Javascript处理用户提交的请求，通过修改Javascript脚本，测试修改后的数据是否影响到用户。
a) 功能测试用的多一些，有可能一个超长特殊字符串导致系统拒绝服务或者功能缺失。（当然fuzz不单单这点用途。）
b) 可能会用的工具 —— spike
a) 密码找回逻辑测试一般流程
i. 首先尝试正常密码找回流程，选择不同找回方式，记录所有数据包
ii. 分析数据包，找到敏感部分
iii. 分析后台找回机制所采用的验证手段
iv. 修改数据包验证推测
验证码不单单在登录、找密码应用，提交敏感数据的地方也有类似应用，故单独分类，并进一步详情说明。
a) 使用burp对特定的验证码进行暴力破解
a) 抓取携带验证码的数据包不断重复提交，例如：在投诉建议处输入要投诉的内容信息，及验证码参数，此时抓包重复提交数据包，查看历史投诉中是否存在重复提交的参数信息。
a 当客户端有需要和服务器进行交互，发送验证码时，即可使用firefox按F12调出firebug就可看到客户端与服务器进行交互的详细信息
a) 当第一步向第二步跳转时，抓取数据包，对验证码进行篡改清空测试，验证该步骤验证码是否可以绕过。
a) 短信验证码验证程序逻辑存在缺陷，业务流程的第一步、第二部、第三步都是放在同一个页面里，验证第一步验证码是通过js来判断的，可以修改验证码在没有获取验证码的情况下可以填写实名信息，并且提交成功。
a) 非授权访问是指用户在没有通过认证授权的情况下能够直接访问需要通过认证才能访问到的页面或文本信息。可以尝试在登录某网站前台或后台之后，将相关的页面链接复制于其他浏览器或其他电脑上进行访问，看是否能访问成功。
在web应用中，根据访问客体的不同，常见的访问控制可以分为"基于URL的访问控制"、"基于方法（method）的访问控制"和"基于数据的访问控制"。前两者都是RBAC模型的实现，即验证用户所属的角色，以决定是否授权--"垂直权限管理"；最后一个解决的是"水平权限管理"的问题，即需要有一个同角色用户到数据之间的对应关系。
- 水平权限越权
用户1--> 用户2
比如 bbs 回帖时修改用户id，可以用他人身份回帖，如果还存在 csrf 漏洞的话，就等于可以控制任意调查+广告利器。
比如修改 cookie 中的 uin 值为其他qq号，可以越权登录。
- 垂直权限越权
普通用户--> 管理员
分析方法：
- 用两个浏览器登录不同账户，抓包修改如 uid/cookie 中的uin 等标识用户的参数，看能否互相影响或者获取到敏感数据。
从越权获取敏感数据的角度来看，自动化扫描可以这样实现：
将cookie 中的 uin 替换成另外一个测试uin，发起请求，判断返回内容格式是否是 json or csv，且内容字段个数与原始请求一致，且返回页面除了含有测试 uin 的值，还满足含有 (email and mobilephone) or idcard or passport or account_and_passwd or uin_and_skey or app_and_secret_account 时可判断存在敏感信息泄露漏洞。
注意：如果鉴权是使用前端js 做的，可以修改请求的响应包，看是否会造成越权。
参数或者路径中的uin 测试同理。
-
A 发出带用户名参数之类的请求，截获请求，把cookie 替换为 B 的cookie，如果可以修改 A 的数据则存在越权。
-
修改如 user=default/admin 等标识用户权限的参数看返回页面。
-
扫描后台页面做一些越权操作，看是否有权限验证。
a) 部分网站逻辑可能是先A过程后B过程然后C过程最后D过程
b) 用户控制着他们给应用程序发送的每一个请求，因此能够按照任何顺序进行访问。于是，用户就从B直接进入了D过程，就绕过了C。如果C是支付过程，那么用户就绕过了支付过程而买到了一件商品。如果C是验证过程，就会绕过验证直接进入网站程序了。
在短信、邮件调用业务或生成业务数据环节中（类：短信验证码，邮件验证码，订单生成，评论提交等），对其业务环节进行调用（重放）测试。如果业务经过调用（重放）后被多次生成有效的业务或数据结果
a) 恶意注册
b) 短信炸弹
在测试的过程中，我们发现众多的金融交易平台仅在前端通过JS校验时间来控制短信发送按钮，但后台并未对发送做任何限制，导致可通过重放包的方式大量发送恶意短信
类似案例如下：
随便输入一个手机号，点击“获取短信验证码”，并抓取数据包内容。通过分析数据包，可以发现参数sendData/insrotxt的内容有客户端控制，可以修改为攻击者想要发送的内容。
将内容修改“恭喜你获得由xx银行所提供的iphone6一部，请登录http://www.xxx.com 领取，验证码为236694”并发送该数据包，手机可收到修改后的短信内容。
大多有利用的案例发生在验证码以及业务数据的时效范围上，在之前的总结也有人将12306的作为典型，故单独分类。
12306网站的买票业务是每隔5s，票会刷新一次。但是这个时间确是在本地设置的间隔。于是，在控制台就可以将这个时间的关联变量重新设置成1s或者更小，这样刷新的时间就会大幅度缩短（主要更改autoSearchTime本地参数）。
针对某些带有时间限制的业务，修改其时间限制范围，例如在某项时间限制范围内查询的业务，修改含有时间明文字段的请求并提交，查看能否绕过时间限制完成业务流程。例如通过更改查询手机网厅的受理记录的month范围，可以突破默认只能查询六个月的记录。