一、身份认证安全
1、暴力破解
2、cookie&session
针对Session的攻击手段主要有会话劫持（Session hijacking）和会话固定（Session fixation）两种。
二、业务一致性安全
1、手机号篡改
抓包修改手机号码参数为其他号码尝试。例如：在办理查询页面，输入自己的号码然后抓包，修改手机号码参数为其他人号码，查看是否能查询其他人的业务。
2、邮箱和用户名更改
抓包修改用户或者邮箱参数为其他用户或者邮箱。例如：referer处和post数据里的有户名或邮箱修改。
3、用户、订单ID更改
通过删、改、查自己的“用户、订单”id，然后修改id（加减1）为他人的，查看是否能删、改、查为其它“用户、订单”信息。
场景：
（a）http://www.xxx.com.cn/users/der/roups.jsp?OrderId=订单号。
（b）post的数据里的id。
……
4、商品编号更改
例如：积分兑换处，100个积分只能换商品编号为001,1000个积分只能换商品编号005，在100积分换商品的时候抓包把换商品的编号修改为005，用低积分换区高积分商品。
场景：先获取需要高积分商品的ID，在提交低积分商品兑换时抓包并经ID修改为高积分商品的ID。
三、业务数据篡改
1、金额数据篡改
抓包修改金额等字段，例如在支付页面抓取请求中商品的金额字段，修改成任意数额的金额并提交，查看能否以修改后的金额数据完成业务流程。
场景：修改商品价格、邮费价格、优惠价格。在URL或POST数据里。若在支付过程中有多次交互，那就意念脑补吧！
2、商品数量篡改
抓包修改商品数量等字段，将请求中的商品数量修改成任意数额，如负数并提交，查看能否以修改后的数量完成业务流程。
3、最大数限制突破
很多商品限制用户购买数量时，服务器仅在页面通过js脚本限制，未在服务器端校验用户提交的数量，通过抓包修改商品最大数限制，将请求中的商品数量改为大于最大数限制的值，查看能否以修改后的数量完成业务流程。
4、本地JS参数修改
部分应用程序通过Javascript处理用户提交的请求，通过修改Javascript脚本，测试修改后的数据是否影响到用户。
总之，“总价=单价*数量+邮费+优惠”，都是篡改的对象，能够对价格有影响的参数都可以尝试篡改，比如：买-2个月或88888888888888888个月的会员，这类非正常的参数值。
在产生订单的时，点点商品的“数量”有为负数的可能，价格也就可能为负数了，可能会由向外支付变为向内充值或送给你积分。
如果价格不能不能篡改，可以试试篡改“邮费”、或“优惠”的参数。
请求重放，购买成功后，修改并重复发起某个http请求，竟然可以使购买商品一直增加。
四、密码找回漏洞
（1）用户凭证暴力破解，4-6位纯数字验证码。
验证码有效时间限制较长、允许多次重放。那就爆破吧，没商量。当限制重放次数时，可以奇思妙想，比如：在提交的纯数字后加入非数字字符试试。
（2）返回验证
a）URL返回验证码及token
场景：点击“忘记密码”>> 输入手机号 >> 提交 >> 抓包 >> 看看包中的URL中有没有verifycode。
b）密码找回凭证在页面中，通过密保问题找回密码。
场景：找回密码，提交了账号，密码提示问题和答案可能在源代码里及Hide表单里。
（3）邮箱弱token
a）时间戳的md5
找回密码URL：http://www.xxx.com/findpwd/setpwd?av=afdb77680182aa9d80b92b697551995f&u=[马赛克]%40gmail.com
仔细观察av的参数值酷似MD5，解一下为：1552533286用户取回密码时，产生一个精确的时间戳，与帐号绑定，记录在某个密码重置库内，那么修改这个用户密码必须得知道这个时间戳才可以，看似合理，但程序员忽略了一个细节，就是假如这个时间戳是新生成得，我在一定得时间段内进行暴力猜解，很快就可以获取到这个有效得链接！
b）用户名
c）服务器时间
A、B两个账号同时找回密码。然后，需要在账号绑定的邮箱里获取链接。发现，A账号的链接为：https://www.xxx.com/resetpwd.action? email=aaaaaa@163.com&startClickTime=2018110105689。B账号的邮箱里链接为：https://www.xxx.com/resetpwd.action?email=bbbbbb@163.com&startClickTime=2018110105685。随机token只相差4，token轻易被猜出来。接下来就是用构造的链接，找回别人的密码吧！
（4）用户凭证有效性
有效的用户凭证可以是短信验证码、邮箱token、重置密码token。
场景：在提交修改好的数据时，抓包改一下：org.apache.struts.taglib.html.TOKEN=83accc27d5178f832d9f22a1d02bdacf&org.apache.struts.taglib.html.TOKEN=83accc27d517nvghngkjcgjf453a1d02bdacf&rtPassword=123456&passwordw=123456&rtEmail=123@123.com&idtagCard=用户ID
虽有token，也可能是纸老虎。改成别人家的“用户ID”同样好使。
（5）重新绑定
通常绑定的是手机号和邮箱
场景：一个用户账号绑定能两个（或覆盖）手机号或邮箱的漏洞。通过注册账号，账号名：aabb，绑定手机号：138*****012（自己的），在提交表单的过程中抓包尝试将账号名改为目标账号名。
（6）服务器验证
a）最终提交步骤
在数据交互的过程中，标识身份的参数可能是“用户名”、“手机号”、“邮箱帐号”、“卡号”或者是系统给生成的某id中的之一。
b）服务器验证可控内容
c）服务器验证逻辑为空
（7）用户身份验证
账号与手机号（或邮箱）的绑定
第一步：填写手机号（邮箱）；第二步：填写要重置的密码；第三步：完成。在第二步的时尝试篡改为目标手机号（邮箱）
（8）找回步骤。跳过验证步骤，找回方式，直接到设置新密码页面
（9）本地验证
在本地验证服务器的返回信息，确定是否执行重置密码，但是其返回信息是可控的内容或者可以得到的内容，通常可通过修改响应包来实现。
发送短信等验证码的动作在本地进行，可以通过修改返回包进行控制。
（10）token生成。Token生成可控
在重置密码时，URL里可能有Token，其参数值可能是通过在cookie中传入的账号而生产的。通过修改cookie里的参数而生产token。
（11）session覆盖
A在通过邮箱找回密码时，当验证链接发到邮箱后，开始进行目标账号B找回密码，但不发送B的验证链接。此时访问邮箱里的验证链接，重置密码。B的密码就被成功更改。注意：一定要在同一浏览器操作！
