漏洞案例

SQL Injection Vulnerability in itsourcecode Courier Management System V1.0 BUG_Author: liuhanzhi Affected Version: V1.0 Vendor: itsourcecode Software: Courier Management System Vulnerability File: /manage_user.php Description 1. SQL Injection via id Parameter In the file /manage_user.php, the application directly concatenates the user-supplied id parameter into an SQL query without any sanitization or validation. Vulnerable code (line 5): $user = $conn->query("SELECT * FROM users where id =".$_GET['id']); 2. Exploiting the SQL Injection By injecting malicious SQL commands into the id parameter via a GET request, an attacker can manipulate the underlying SQL query to perform unauthorized database operations including data extraction, modification, and enumeration. ...

声明 本博客提供的思路和技术仅限于提升自身技术，不得用于非法活动，任何非法活动均与本博客的立场相违背，违法者将依法承担法律责任 我的看法 其实JS逆向在日常挖洞中不能算一种漏洞类型进行提交，而是一种技术，有了这个技术，就可以在数据包存在加密或者数据包存在签名防篡改的情况下，进行将密文解密或篡改数据包从而进行正常的渗透流程，甚至有些网站全站都存在数据包签名防篡改，那没有JS逆向的技术，你改不了数据包，连渗透的资格都没有，这还测个毛啊 案例介绍 漏洞名称 上海商米科技集团股份有限公司数字店铺存在任意用户登录漏洞（已修复） 漏洞发现 我在测试商米数字店铺中发现用户登录处使用手机验证码登录时验证码做了防爆破处理，但是 要实现用户登录是不是还可以修改原来的密码，用创建的新密码来实现密码登录，【修改密码】同样需要手机验证码验证，但是这里的验证接口并没有做验证码验证次数限制，而且为四位验证码，遍历次数只要10000次，可以进行爆破验证码操作 但是数据包中却没有找到验证码参数，甚至连像模像样的信息都没有，而且全站都是这样的，【重置密码】具体数据包内容如下 // 原始数据包如下 POST /api/user/resetPassword HTTP/2 Host: store.sunmi.com Cookie: _c_WBKFRo=Un76hKEAvdAOAfzCsQ4Nuu8fLxA8acVXkTUnQwIV; tfstk=gcYEw-gqtavsJCkDgIbru9lECVQdzakbLU65ZQAlO9XHODhraOR8AgOBAhWyIdWHUQhdZTvkUTtIfqOp9aQohgujlBUNBRwB8a2WswC70R4yZqOp95jEIwFil4loG21hELjhjOflI6Xu-LXGsOCRZJfu-fRGBOf3qgbuIGfcNuqkEacwsOClrTvlxfRGB_blEfodcgkVNMcHMw4-R5RNYtAhQrR976mG3qBarE8GTM8ktOoEYF5FYtjyczJ2uIAHk_8-iuWyMHvC6LuqQNYeLejNz4zORI-MLG-EUPS9jILlbhH4DIdHLnjD-VlFbedf-O8-wzBHAQY54eD0N9YpdFSvyJk1FnO6-GJmCPJR4Hxc-UkqSgy7e1DI_UKUEuSh61Wj_fllLRPKMf_nNuERvJ5NhXxu2uIhY1Wj_RE82MIl_tGnF; _gcl_au=1.1.1104070136.1769850985; Hm_lvt_2018effe9e50369b4410bd0af8ecb7c9=1769850985,1769861358; _ga=GA1.2.1449330925.1769850985; _ga_RQML024HYC=GS2.2.s1769861358$o2$g0$t1769861358$j60$l0$h0; _ga_NFBQZJS49V=GS2.1.s1769861358$o2$g0$t1769861516$j60$l0$h0; Hm_lvt_61990ad31961f1bde37194ad4f2f1285=1769851055,1771835131,1772108018,1772338958; HMACCOUNT=A87FED76FCB56CAB; Hm_lpvt_61990ad31961f1bde37194ad4f2f1285=1772339825 Content-Length: 902 Sec-Ch-Ua-Platform: "macOS" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/145.0.0.0 Safari/537.36 Sec-Ch-Ua: "Not:A-Brand";v="99", "Google Chrome";v="145", "Chromium";v="145" Content-Type: multipart/form-data; boundary=----WebKitFormBoundarybqbHAefRGJzTQbtQ Version: 2 Sec-Ch-Ua-Mobile: ?0 Accept: */* Origin: https://store.sunmi.com Sec-Fetch-Site: same-origin Sec-Fetch-Mode: cors Sec-Fetch-Dest: empty Referer: https://store.sunmi.com/user/login Accept-Encoding: gzip, deflate, br Accept-Language: zh-CN,zh;q=0.9,en-GB;q=0.8,en;q=0.7 Priority: u=1, i ------WebKitFormBoundarybqbHAefRGJzTQbtQ Content-Disposition: form-data; name="timeStamp" 1772339853 ------WebKitFormBoundarybqbHAefRGJzTQbtQ Content-Disposition: form-data; name="randomNum" 3gspVBCLxtglWdCw3agGHFtrQM0sdozs ------WebKitFormBoundarybqbHAefRGJzTQbtQ Content-Disposition: form-data; name="params" yXABToyr+0mTGR9u4Yf2WOq54mU+LzNTLIuQHi1TpZPCK0+NCLk72AYz55wC5Y5N70zuQnttWAzBDVEhUvnZukJ0HG3G3VSRvciKRXco7DnC/a77d1VLAdVRJJGsL5ghna4jP2BHjSjExrIrJcm5DWvHEwiH3JglZ7lJhbF7K3fADSE2nuW1K+jeze5Kmu/MBKUTrqlU1XIH/U2tdzcz6Q== ------WebKitFormBoundarybqbHAefRGJzTQbtQ Content-Disposition: form-data; name="isEncrypted" 1 ------WebKitFormBoundarybqbHAefRGJzTQbtQ Content-Disposition: form-data; name="sign" 42d6b0c68a4151e3c17cbdac1746a14a ------WebKitFormBoundarybqbHAefRGJzTQbtQ Content-Disposition: form-data; name="lang" zh ------WebKitFormBoundarybqbHAefRGJzTQbtQ-- HTTP/2 200 OK Content-Type: application/json; charset=utf-8 Content-Length: 42 X-B3-Traceid: 21a9270d9420e83719fcc3fe1074cb6e X-B3-Spanid: aee96733a3195d05 X-B3-Sampled: 1 Date: Sun, 01 Mar 2026 04:51:12 GMT Vary: Origin Access-Control-Allow-Origin: https://store.sunmi.com {"data":{},"code":2003,"msg":"code error"} //任意修改 POST 参数的返回包 HTTP/2 400 Bad Request Content-Type: application/json; charset=utf-8 Content-Length: 44 X-B3-Traceid: f062b32ce9f642ae0380d3ef32ff1dc4 X-B3-Spanid: a3dfa9c4f8bdf4c2 X-B3-Sampled: 1 Date: Sun, 01 Mar 2026 05:00:35 GMT Vary: Origin Access-Control-Allow-Origin: https://store.sunmi.com {"code":5026,"msg":"Invalid sign","data":{}} 有JS加解密经验的师傅并不会十分陌生，网站是通过POST multipart/form-data 类型进行传递数据，而且根据各个英文名，params是参数的意思，所以yXABToyr+0mTGR9u4Yf2WOq54mU+LzNTLIuQHi1TpZPCK0+NCLk72AYz55wC5Y5N70zuQnttWAzBDVEhUvnZukJ0HG3G3VSRvciKRXco7DnC/a77d1VLAdVRJJGsL5ghna4jP2BHjSjExrIrJcm5DWvHEwiH3JglZ7lJhbF7K3fADSE2nuW1K+jeze5Kmu/MBKUTrqlU1XIH/U2tdzcz6Q==就是所有要传递的参数，而且还是进行了加密处理，然后其他的timeStamp randomNum ... 就是起到了整体签名的作用，防止请求包POST部分进行任何篡改，而sign参数42d6b0c68a4151e3c17cbdac1746a14a就是整体进行签名后的结果，破解params参数加密算法和sign参数签名算法就是下一步需要做的，破解后才可以利用验证接口并没有做验证码验证次数限制进行爆破操作 ...

声明 本博客提供的思路和技术仅限于提升自身技术，不得用于非法活动，任何非法活动均与本博客的立场相违背，违法者将依法承担法律责任 某SRC数字店铺存在SQL注入漏洞 注册后登陆数字店铺后台查看“数字标签”页面，其中的查询框存在SQL报错注入 仔细观察请求数据包，我传递的查询参数只有一个1'，但是请求数据包中的内容却采用POSTmultipart/form-data类型进行传输，更具数据包分析很容易知道前端进行了加密签名处理，这个网站中的其他数据传输都采用这种方式，这样可以让你看不出传递的具体数据并防止篡改请求包，这就是为什么此站在无waf的情况下，挂着xray代理（以及任何多强大扫描SQL注入的工具）不可能扫描出此处存在SQL注入的原因，也就是说这里只能靠手动尝试才可以发现 查询参数输入1'时回显You have an error in your SQL syntax 查询参数输入1''时回显正常 查询参数输入1'''时回显You have an error in your SQL syntax 查询参数输入1''''时回显正常 通过4个单引号检测，明确确定存在SQL注入，接下来需要构造注入语句得到数据库名证明危害即可，不要拖库拿信息！！！不要拖库拿信息！！！不要拖库拿信息！！！ Tips：注释符号一般都是不起作用的，建议使用单引号闭合的方式闭合语句，这里注释符就不起作用 1' and updatexml(1,concat(0x7e,DATABASE(),0x7e),1) and '1'='1 用报错注入，成功得到数据库名😎 总结 要提升逻辑观察能力，随机应变，遇到只能手动测试的网站不要怕麻烦，万一出洞了呢 4个单引号检测SQL注入挺好用 实战尽量使用单引号闭合方式，不要用注释符打不成功就不打了 上述只是针对一般类型的SQL注入，还有好多类型的SQL注入