渗透 sql

SQL注入这玩意儿，渗透说白了就是渗透跟数据库玩文字游戏。你往输入框里塞点特殊字符，渗透后端没过滤干净，渗透SQL语句就变了味儿。渗透去年我帮朋友排查一个电商站，渗透订单查询接口被人塞了`' OR 1=1 --`，渗透结果整个订单表全给拉出来了，渗透三万多条记录，渗透连用户住址都裸奔在响应包里。渗透

最讽刺的渗透是，那个站点的渗透程序员不是新手，他用了参数化查询——但只在主查询上用了。渗透分页用的渗透`LIMIT`子句是字符串拼接进去的，因为要动态排序。渗透攻击者直接在`sort`参数里写`1; DROP TABLE orders; --`，数据库是MySQL，多语句执行默认开着，表就这么没了。你说气不气？一个参数化查询救了九十九个漏洞，第一百个漏洞照样让你翻车。

真正的渗透测试不是拿sqlmap一把梭。工具扫不出业务逻辑里的注入点。比如那种JSON格式的登录接口，字段名是加密的，但值没加密。你把`password`字段的值改成`{ "$ne": null}`，MongoDB就能让你直接登进去——这算NoSQL注入，但思路跟SQL注入一模一样：你不信任用户输入，但数据库信任了。

我见过最骚的操作，是在一个搜索框里用`UNION SELECT`拼出管理员密码的MD5值，然后拿这个值去撞另一个站的弱口令库。那个搜索框明明有WAF，但WAF只拦`SELECT`开头的语句，人家把注释符`/*!50000SELECT*/`嵌进去，WAF直接放行。规则是死的，绕过规则的人脑子是活的。

防御这事，光靠预编译不够。你得把用户输入当核废料处理：白名单校验、类型强制转换、最小权限数据库账号。但最关键的还是别把SQL语句拼成人能读的字符串——你写代码的时候觉得`"WHERE id = " + userId`挺直观，攻击者看到这行代码能笑出声。

前阵子看日志，有个IP对着一个测试接口试了四百多次注入payload，从`'`到`;waitfor delay '0:0:10'--`全来了一遍。这哥们儿明显是脚本小子，但就是这种笨办法，照样能磨穿没打补丁的旧系统。安全这行当，懒人活该被薅。

说到底，SQL注入不是技术问题，是态度问题。你写每一条SQL的时候，都得默认用户是带着恶意来的。别信什么“内部系统没人攻击”的鬼话——内网穿透工具免费，社工库几块钱就能买，真有人想搞你，你连数据库日志都来不及删。