一、请求的截获与篡改
1.隐藏域攻击——查看元素中"display"：none的即为隐藏域（用户不可见，但会随表单一起提交）
可以直接在elements中修改，删去 "display"：none 页面上就能看见之前隐藏的元素了（但是一刷新就会又全部显示出来）
例如下单页面将“会员优惠”做成隐藏域，用户自己打开并输入金额后，在后端没有校验的情况下就较少了支付的金额。
避免的方式：1.在可以动态生成元素的情况下，不使用隐藏域提前创建元素；2.在提交表单时，使用js对隐藏域的值做判断 3.对于关键参数，后台服务端接口需要做独立判断（验证用户是否是会员，能否使用会员优惠）——2+3也称为双端验证
2.修改关键业务参数（js代码在source中查看）
例如限购商品，前端element修改数量再提交
避免的方式：1.在提交表单时，使用js对关键字段的值做判断 2.对于关键参数，后端服务端接口做独立判断——双端验证
3.找回密码存在的漏洞
输入用户名——回显绑定的手机号（隐藏部分位数）——发送验证码——校验验证码
——可能存在的问题，后端直接返回验证码
——隐藏部分位数的手机号不加密或者只进行了单层MD5加密(泛指可以被知道的简单加密规则)，用burpsuite拦截发送验证码的请求，将原本手机号的加密传参改成自己的手机号加密进行传参，此时验证码会发送到修改后的手机上
——加密的操作尽量在服务器端进行（js代码是本地的，可以被用户看到）
4.js验证策略
例如校验优惠码，部分应用的实现逻辑是用户输入优惠码后，前端并没有将优惠码发给服务端，而是直接在本地进行校验是否有效（或者是向服务端发请求，服务端会返回所有有效的优惠码）这些情况都容易被截获
避免的方式：
——结果数据，接口不回传，不做本地js校验
——服务端只返回验证结果，避免数据泄漏
5.修改请求参数，平行越权
越权：获取了别的用户的权限——分为垂直越权和水平越权
例如通过修改传参uid获取其他用户的订单信息，或者通过修改cookie中的uid值来获取其他用户的订单信息（根据接口具体实现判断方式都可能出现）
避免的方式：
——对于核心操作请求，要验证用户登录状态
——验证登录状态，不能依赖于单一数据（除了传uid 还要验证cookie中的用户名、密码等信息）
二、完善接口的防刷机制——例如限制输入密码的次数
1.暴力破解短信验证码
解决方式：
1.增加密码复杂程度
2.增加验证码（图片验证码），请求失败更换验证码
3.增加失败控制策略，同一ip尝试N次后，禁止3小时内操作
4.增加手机或邮箱接受信息的验证（例如主动点击邮箱内的链接，用手机主动发送一串数字等）
BurpSuite攻击演示：
截获提交验证码的登录请求，右键复制到Intruder中，然后在Intruder的Position tab页中对验证码参数进行穷举（其他Clear$，只有password（代表4位数的验证码）需要 Add$），再到Payload中进行穷举（load一个所有4位数字组合的文件），再到Options中设置匹配的条件（此例中如果验证码正确，头信息中返回长度会变化，所以去掉了“排除 Header”前的勾），设置完之后，到Target Tab页中开始攻击
查看攻击结果，发现6666这个验证码的头信息长度会跟其他的有差别，在截获的请求中修改password 的值为6666进行测试，发现真的是这个验证码。
2.找回密码，枚举破解安全问题
例如喜欢的水果：可以用枚举暴力破解常用的水果
3.暴力利用短信接口
标签：用户,验证,验证码,接口,js,安全,隐藏,服务端 来源： https://blog.csdn.net/qq_42080759/article/details/121319893
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。