【Web渗透】业务逻辑漏洞
当前位置：点晴教程→知识管理交流
→『 技术文档交流 』
身份验证漏洞暴力破解漏洞漏洞介绍：攻击者可以通过该漏洞获取用户名和对应弱口令密码，并进行登录操作 漏洞原理：由于没有设置登录失败次数限制，导致攻击者可以通过口令字典进行特定用户的密码爆破或通过用户名字典进行特定弱口令的用户枚举 漏洞点：系统登录点 漏洞修复：对于固定用户名爆破密码 可以针对用户名进行错误次数计算，高于一定阈值账号锁定一段时间，或者添加验证码 但是不能永久锁定，可能被用来进行账户恶意锁定 对于固定密码枚举用户名、 需要计算IP对URL的请求情况，某个IP短时间大量请求登录应该加入黑名单 进行传输数据加密有一定的防护效果 Session固定攻击漏洞介绍：会话固定攻击是利用服务器的session不变机制，借他人之手获得认证和授权，然后冒充他人 漏洞原理：在请求登录过程时候，URL带有一个session，登录成功之后会将登录成功的信息绑定到这个session中，攻击者可以发送带有session的URL给相关工作人员诱导其登录，相当于获取了其身份信息 漏洞点：在GET方法请求登录时候带有session值 修复思路： 只要避免在URL中带入session信息即可比较有效的防御 另外也要注意POST请求中带有sessionid进行session固定攻击，虽然可利用性比较低，但是建议修复 Cookie欺骗漏洞漏洞介绍：通过伪造cookie信息能够伪造其他用户进行登录。漏洞原理：开发者为了方便将身份信息/登录信息明文或者只是简单编码、哈希之后存放在cookies中，网站通过获取得到的cookies进行授权或者身份验证 漏洞点：cookie中有明显或者只是简单编码、哈希的字段时候 修改lsLogin值为1可以判定为用户已经登录 修改cookie为asp163=UserName=admin 漏洞修复：Cookie不应该存储可理解的身份信息和登录信息 按照规定，cookie对身份信息和登录信息的存储只能通过存储足够长度的随机字符串进行，避免篡改 权限类逻辑漏洞权限相关逻辑漏洞是逻辑漏洞中出现的最多的漏洞 平行权限跨越漏洞介绍：即普通用户/管理员能访问其他普通用户/管理员才能够访问的系统信息或者系统功能 形成原因：在进行方法调用时候未进行请求用户和目标信息拥有者是否匹配一致，直接用userid/email之类的容易遍历的参数进行数据库查询 漏洞点：在普通用户/管理员登录后的能访问的链接或者功能中都可能存在 漏洞修复： 在权限管理中，平行越权的权限管理颗粒度最小 修复思路 需要在方法中进行相关的获取请求request 再利用getAttribute("userid")获取其userid 直接使用该userid作为参数进行数据增删查改，避免userid参数传输 垂直权限跨越漏洞介绍：即普通用户能够访问管理员甚至超级管理员才能够访问的系统信息或者系统功能 形成原因：程序再方法调用时候，缺少角色等级校验 漏洞点：在任何用户登录后才能访问的链接或者功能中都可能存在 对每一个传输的参数都要了解参数的目的，尝试将用户名改为admin尝试绕过 漏洞修复： 需要校验用户是否有权限访问这个方法 修复思路 获取请求request 再利用getAuttribute("roleid")获取其角色等级 检查角色等级是否合法，错误则直接返回错误跳转，返回页面必须仍然从Attribute中获取userid再进一步查询相关信息 值得注意的是切勿将错误跳转写到Javascript里面，还返回目标URL页面的相关信息。 未经授权访问漏洞介绍：即游客能够访问普通用户甚至超级管理员才能访问的系统信息或者系统功能 形成原因：主要是系统设计期间没有进行全局用户身份校验；或者校验存在缺陷 漏洞点：在任何用户登录后才能访问的链接或者功能中都可能存在 漏洞修复： J2EE中存在filter，可以获取用户的cookie等信息 修复思路： 建立LoginList，值是当前在线用户的id 对所有需要登录访问到URL，获取请求request 再利用 getAttribute("userid") 获取其userid 检查userid是否存在于LoginList中，不存在则直接返回错误跳转 值得注意的是切勿将错误跳转写到Javascript里面，还返回目标URL页面的相关信息 图形验证码漏洞图形验证码突破漏洞介绍：攻击者通过突破图形验证码的验证，可以实现如登录爆破、验证码绕过等攻击 漏洞原理： 图形验证码在错误后未失效 返回验证码信息 分步验证验证码 漏洞点：任何存在图形验证码的功能中 漏洞修复 一旦验证码使用过了，必须要进行删除，重新生成验证码，可以梵高attribute中 验证码需要设置超时，时间一到立即删除旧验证码，用户需要获取新的验证码 验证码只需要返回图片，切勿将生成验证码的字符串也一并返回 验证码不应该进行分布校验，应该连同请求数据一起发送到目标服务器进行校验，服务器校验通过则返回合法数据，否则返回错误 找回密码逻辑漏洞密码找回漏洞漏洞介绍：攻击者通过密码找回逻辑漏洞，可以重置他人账号密码，危害他人账号安全 漏洞原理：其实是验证码漏洞的一种： 验证码时间长可爆破 返回重置密码凭证 若加密的重置密码凭证 漏洞点：任何密码找回处（可延伸至相似具有验证功能） 修改接受校验码目标 漏洞修复 一旦验证码使用过了，必须要进行删除，重新生成验证码，可以放到attribute中 验证码需要设置超时，时间一到立即删除旧验证码，用户需要获取新的验证码 校验凭证不能够随着返回包进行返回 验证码不应该进行分布校验，应该连同请求数据一起发送到目标服务器进行校验，服务器校验通过则返回合法数据，否则返回错误 校验凭证的生成需要进行随机生成，防止凭证破解 用户身份凭证和权限类漏洞修复一样，需要从attribute中获取 业务数据篡改漏洞业务数据篡改（赋值反冲）漏洞介绍：攻击者通过进行数值篡改进行攻击，从而获利 漏洞原理： 没有对传输数据添加相关的校验参数 后台未对参数值进行校验并直接使用数据包中的参数 漏洞点：抽奖、购买、转账、返现等功能 漏洞修复： 对于软件来说，需要保护好内存数据，防止内存数据篡改 计算传输数据的哈希，并将哈希附加在传输数据中作为校验值，避免被篡改 先校验数值，防止大整数和负数；接着利用传输的商品ID从数据库中获取商品单价重新进行价格计算；最后生成订单（订单号应为随机值） 执行顺序逻辑漏洞执行顺序篡改漏洞介绍：攻击者通过篡改分步逻辑中的步骤数字，达到绕过支付、校验等效果 漏洞原理：程序逻辑分布进行，但是对步骤、验证信息、支付信息没有做好严格校验，导致修改步骤就直接绕过验证或者支付 漏洞点：任何分布逻辑且带步骤数字，或者利用JS进行步骤控制的功能中 漏洞修复 在请求最后一步时候需要带入前面的验证信息，服务端再进行一次校验信息的验证，验证正确方能继续执行数据操作 也可以及通过getAttributr("userid")获取userid进行userid和验证结果绑定，最后一步不带入验证信息，但是仍然要获取userid进行校验 再最后一步通过验证之后或者服务器收到支付信息后再生成相应的数据交给用户 其他类型逻辑漏洞条件竞争漏洞漏洞介绍：可以通过同时重放大量数据包进行漏洞利用，通常用于突破限量、限额的问题都有奇效 漏洞原理：由于目标函数中，判断与数据修复两个步骤之间，或者两个数据修改步骤之间存在时间差，且函数未进行同步锁定，则可以造成漏洞 漏洞点：程序中存在限制，可以猜测到后台有判断与修改操作的方法 漏洞修复 -修复思路：使用synchronized关键字，可以限制同一时间内访问方法的只有单一线程 并不是每个条件竞争都必须修复 数据包重放漏洞漏洞介绍：通过数据包重放，可以造成短信轰炸、邮件轰炸、重复提交订单等 漏洞原理：后台未进行相关操作的技术导致数据包重放 漏洞点：短信验证码、邮件校验、提交订单等功能。 修复方案： 修复思路（针对短信、邮件） 构造一个Hashmap<String，short>，存放邮箱或电话号码及对应次数 只要某个邮箱或者电话号码次数够了，就不能继续发送了 或者计算两次发送的时间间隔，时间过短就不继续发送了 通用修复方案 需要建立token机制或验证码机制，一次有效 参数绑定漏洞漏洞介绍：通过添加对象字段相关参数进行数据篡改 漏洞原理：对象自动绑定被许多框架支持，它允许将HTTP请求参数自动的绑定到对象，开发者没有对其进行安全校验则容易导致数据篡改 漏洞点：常见的所有输入的地方都会出现这个漏洞，特别是金融、用户、缓存等。 漏洞修复：Spring MVC中可以使用@InitBinder注释，通过WebDataBinder的方法setAllowedFields、setDisallowedFields设置允许或不允许绑定的参数 SRC中的逻辑漏洞总结注册： 短信轰炸 验证码安全问题 密码爆破 邮箱轰炸 用户任意注册、批量注册 用户名枚举 XSS（有框的地方就可以尝试插XSS） 登录： 短信轰炸、验证码安全问题、密码爆破、邮箱轰炸 SQL注入 撞库 抓包把password字段修改为空值发送 认证凭证替换、比如返回的数据包中包含账号，修改账号就能登录到其他账号 Cookie仿冒 修改返回包的相关数据，可能会登陆到其他的用户 找回密码： 短信邮箱轰炸、短信邮箱劫持 重置任意用户账户密码、验证码手机用户未统一验证 直接跳过验证步骤 购买支付、充值（要利用抓包去仔细查看每一个可用的参数） 交易金额、数量修改、更换支付模块（比如更换支付的模块金额） 交易信息订单编码/导致信息泄露 整数溢出，int最大值为2147483647，超过最大值 修改充值账户 支付绕过 抽奖活动 刷奖品、积分 并发 优惠卷、代金卷 并发逻辑漏洞（burp批量获取优惠券） 修改优惠券金额、数量 订单信息 订单信息遍历、泄露 订单信息泄露导致用户信息泄露 删出他人订单 会员系统 修改个人信息上传文件，上传带弹窗的html 如遇上上传xlsx、docx，可能存在XXE，上传恶意的文档盲测 图片上传也可能遇到imagereagick命令执行，上传恶意图片 视频上传如果使用ffmpeg<3.2.4（视频按帧分割成图片），上传恶意avi盲测ssrf 用户横向越权访问、遍历、导致用户信息泄露 SQL注入、个人简历处存储XSS个人信息注册的名称也可以插入XSS 传输过程 明文传输账户密码 修改信息处无session/token导致csrf POST/COOKIE注入 评论 POST注入 存储型XSS 无session/token导致CSRF 验证码问题 万能验证码 返回包中存在验证码 删除验证码或者cookie中的值可以爆破账号密码 短信轰炸 一直重放 删除修改cookie，重放数据包 遍历参数发送数据包 手机号后面加空格或者前面加其他的比如+86或者逗号分号等，然后重发数据包 请求参数修改大小写，或者添加请求参数比如&id=1 一个站的登录处可能做了防护，但是再找回密码处可能没有安全防护，或者在注册流程中没有安全防护，所以说多测试接口 如果对手机号一天的次数进行了限制，还可以再发一次短信，DO intercept之后修改为成功回显 水平越权 主要登陆后还是修改参数，主要找到多个接口不断测试 关注网页源代码，有时候会有表单，但被bidden（隐藏标签）给隐藏起来了，可以修改返回包然后尝试获取数据检测 多个账号，主要分析请求参数 数据泄露 再找回密码处，填写数据后抓包查看返回信息，有可能存在敏感数据返回 任意用户密码重置 目前大部分都是在修改密码处参数修改 有些是前端验证 支付逻辑漏洞 边界值问题 : 正常的逻辑是用户购买商品，然后价格累加得到一个总价进行扣款。这个时候就会产生逻辑问题：如果说用户购买的商品是负数了，那么计算的总数就是负数。反过来钱给用户 顺序执行缺陷：正常的逻辑是a-b-c-d 循环渐进的进行流程操作。这个时候就会产生逻辑问题：可以直接从中绕过某一个过程进入到下一步操作。如果说有一项是支付的操作，那么也就会产生支付绕过，如果说有一项是验证机制，就会绕过验证直接进入下一步。 金额直接传输导致篡改：直接对下单的金额进行修改值，这里可以使用fd或者burp抓包 确定支付之后还可以加入购物车：把商品放入购物车点击下单支付，会跳转到微信，支付宝等第三方支付平台。这个时候还可以继续在购物车中加入商品，支付结束之后，商家发放的商品是现在的购物车里面的东西。 请求重放：购买成功之后，继续重放请求，可以让购买的商品一直增加。购买成功之后，会有一个银行对商户网站跳转的过程，如果反复进行操作，有几率会导致商品反复购买和增加，但是不需要付更多的钱。 请求参数干扰：金钱做了签名认证之后，修改后不通过，但是在里面仍然会有一个参数对金额产生影响导致问题产生。 订单替换：订单替换发生在支付之后的事件处理，同时向服务器发起二次支付请求一个多一个少，支付金额少的，然后支付之后进行替换，告知服务器订单支付完成，并且过程可以反复的回放。 欺诈:需要两个收款人，一个是正常的商家，一个是伪造的商家 单位替换：产生在paypal类似的国际支付的场景。 用户替换：在支付过程中发生用户替换现象，首先登陆自己的账户，然后取得另外一个人的账户名等有效信息，在业务流程中用对方的用户名替换自己的用户名，用对方的余额购买完成后，再替换自己的账户名，这样就形成别人的钱买自己的东西 强制攻击：强制攻击发生在暴力破解的情况下，如果一个商家运用一个自己的网店，接入第三方支付接口，由于设计上的不当导致商家与第三方支付约定的密钥Key可以单独被MD5加密，导致可以使用MD5碰撞技术对密钥进行破解，攻击者可以设计简单的密钥加密信息使得MD5加密是可以用MD5碰撞技术进行暴力破解。 秘钥泄漏：内置支付功能的app为了设计上的方便有可能会把Md5或者是RSA的私钥泄漏导致攻击者反编译apk之后获取密钥信息使得交易信息可以被篡改。 函数修改：apk反编译之后的函数修改，可能导致商家在最后一步向支付方提交订单时未验证信息的准确性，仍然被篡改。 heart bleed：SSL（安全套接层）协议是使用最为普遍网站加密技术，而OpenSSL则是开源的 SSL 套件，为全球成千上万的web服务器所使用。Web服务器正是通过它来将密钥发送给访客然后在双方的连接之间对信息进行加密。URL中使用 https打头的连接都采用了SSL加密技术。在线购物、网银等活动均采用SSL技术来防止窃密及避免中间人攻击。 该漏洞被归为缓冲过度读取。缓冲过度读取错误是软件可以读取比应该被允许还多的数据。漏洞让特定版本的openSSL成为无需钥匙即可开启的“废锁”，入侵者每次可以翻检户主的64K信息，只要有足够的耐心和时间，就可以翻检足够多的数据，拼凑出户主的银行密码、私信等敏感数据。产生原因：数据在传输的两端是不加密的。一些数据如果在传输过程中不加密则会泄露个人数据等信息。 修改返回包的越权 修改手机号 一般的逻辑为：认证原手机号-> 填写新手机号-> 提交修改 如果在下一步操作时，没有校验上一步的认证是否成功时，就会存在逻辑缺陷绕过 比如在进行第一步认证原手机号时，随意输入验证码，将response包中的相关字段进行修改，比如0改成1，false改成true，即可绕过第一步验证，进入填写新手机号界面，如果第三步提交修改时没有验证第一步的结果，就会造成逻辑漏洞 登录绕过 部分网站的身份验证放在了前端，因此只需要将response包中的相关字段进行修改，比如0改成1，false改成true，就可以登录任意用户账号 水平越权 遍历ID 在一些请求中，GET和POST中有明显的ID数字参数（手机号、员工号、账单号、银行卡号、订单号等等），可以尝试进行遍历，如果程序没有对当前权限进行判断，就会存在水平越权问题 ID替换 如果程序对用户标识进行了hash或者加密，而无法破解用的什么方式的话，就无法通过遍历ID来获取其它用户的信息了，此时可以尝试注册两个账号，通过替换两个ID加密后的值，判断程序是否对权限进行了验证，如果没有，也会存在越权问题 垂直越权 观察cookie中的session字段，可能某些字段或者参数代表身份，尝试修改 该文章在 2023/12/13 19:02:19 编辑过 |
关键字查询
相关文章
正在查询... 
|
400 186 1886
