其他漏洞原理及防御(2) -逻辑漏洞
逻辑漏洞：
区别与其他常见漏洞往往与程序有关，逻辑漏洞的成因是由于工作人员所设计编写的代码有一定逻辑上的不足，遭到攻击者的恶意利用。而攻击逻辑漏洞的流量或是请求往往都是合法的，所以逻辑漏洞比传统漏洞更难检测发现。
常见的逻辑漏洞：
1.订单金额的非法修改：
一些中小型的购物网站在支付页面没有对支付金额的隐藏或者是审核，导致攻击者可以抓包修改金额再提交，或者是直接再浏览器端修改代码中的金额，再传入服务器操作。
此处的逻辑问题是没有对支付金额或是其他重要数据做二次审核。
解决方法也比较简单，利用密码学中的消息认证码mac的原理，保证数据完整性即可。
具体操作为：申请时，计算订单金额，数量，用户，等重要信息的hash值。而当订单发起提交时，服务器再次审核，计算此次提交数据的hash值，比对两次的hash，相同则通过，不同则丢弃。
需要注意的是，为了防止哈希构造欺骗，最好使用成熟的抗强碰撞的hash函数，例如md5。
特别的，如果金额过大或是订单数据异常，可以跳转入人工审核步骤。
2.验证码回传的逻辑盗取：
一些开发人员在需要验证的界面，为了更简单的实现验证码比对，可能会在提交验证码请求时，向用户邮箱和手机发送验证码的同时，从服务器发送一个响应到本地浏览器，其中存储着验证码。将验证码比对这一步操作内置在浏览器端或是客户端。攻击者针对这种逻辑上不安全的设计，可以截获响应包，在其中查看到验证码，从而实现验证码的盗取。
解决方法也不难：很多针对这个漏洞的解决参考是，不将验证码响应给浏览器端，而等待用户输入验证码，在服务器端做验证。这样做毫无疑问是从根源上解决了这个逻辑问题，但是这显然会加大服务器的负荷，而且比对发生在服务器端，更增加了ddos攻击的可能性，因为如果多个客户同时请求，那么服务器端需要进行的运算就比较巨大了，资源占用显著。
我认为有更好的解决办法，同样还是将比对放置在浏览器端，这样可以保证服务器不过载，但是服务器回送的不是验证码，而是验证码的hash值，由于好的hash算法具有不可逆性，攻击者无法从hash值得到验证码，而用户输入验证码后，浏览器端做一个hash运算，得到hash值再与服务器回送的相比对，相同则放行，不相同则限制输入。有效的防止了服务器过载和验证码盗取，同时可以利用限制输入次数防止dos攻击。
3.重要路径的猜测绕过：
有些常规网站的后台采用常用的路径，例如url里admin/main.php或是user.php。看似是隐藏的很好，但是由于其常见性，恶意用户可能会尝试猜测路径，访问没有权限的页面，甚至进入后台。
解决方法是：一方面避免后台路径的常规化，二是在重要页面加上认证，可以是cookie，可以是口令。需要注意防止admin等弱口令。
4.cookie的重放攻击：
众所周知浏览器的cookie信息，有时会用作认证，以代表用户权限。而一个好的cookie，往往以用户参数做变量的函数。也就是根据用户参数变化而变化。
有些网站的cookie与用户的密码就没有关系，如果用户的cookie被盗取了，然后用户发现自己的账户被盗，他迅速的修改了密码，但是，由于网站cookie不随密码变化而变化，这就导致攻击者继续使用老的cookie值，依旧可以伪装用户身份。
解决方法：将cookie值设计成相关参数的变量，不要使其一成不变。
5.验证次数无限制导致的暴力破解：
有些接口对输入验证的次数不做限制，导致攻击者利用枚举破入系统。
解决：关键地点设置验证次数。如果是验证码或者cookie，及时过期避免重放。
6.用户凭证的不当设计：
有的网站采用内存密钥，当用户注册完成之后，本地会生成一个备份，存储用户身份的相关信息。用户登陆时，则针对内存中的这些值做审核，从而判断用户身份。
攻击者如果猜测到本地存储的相关信息，则读取后可能造成身份伪造。
解决方案：如果利用本地存储验证的，需要存储加密数据。而且验证最好使用其他方法，而不是内存中的值。
【推荐】国内首个AI IDE，深度理解中文开发场景，立即下载体验Trae
【推荐】编程新体验，更懂你的AI，立即体验豆包MarsCode编程助手
【推荐】抖音旗下AI助手豆包，你的智能百科全书，全免费不限次数
【推荐】轻量又高性能的 SSH 工具 IShell：AI 加持，快人一步
· 阿里最新开源QwQ-32B，效果媲美deepseek-r1满血版，部署成本又又又降低了！
· SQL Server 2025 AI相关能力初探
· 单线程的Redis速度为什么快？
· AI编程工具终极对决：字节Trae VS Cursor，谁才是开发者新宠？
· 开源Multi-agent AI智能体框架aevatar.ai，欢迎大家贡献代码