内容摘要：SQL注入能直接拿下服务器root权限？这种说法在安全圈里流传很广，但实际情况是——SQL注入攻击的破坏半径，几乎被死死限制在数据库这一层。它碰不到操作系统的内核，动不了系统文件，更不可能直接操控硬件

SQL注入能直接拿下服务器root权限？入攻这种说法在安全圈里流传很广，但实际情况是胁到系统——SQL注入攻击的破坏半径，几乎被死死限制在数据库这一层。操作它碰不到操作系统的入攻内核，动不了系统文件，胁到系统更不可能直接操控硬件。操作我见过太多人把数据库被拖库和服务器被入侵混为一谈，入攻这两件事之间隔着一道相当结实的胁到系统墙。

先看SQL注入到底干了什么。操作攻击者往输入框里塞一段精心构造的入攻SQL语句，比如经典的胁到系统 ' OR '1'='1，让后端的操作数据库查询逻辑跑偏。数据库老老实实执行了这条被篡改的入攻指令，把不该给的胁到系统数据吐了出来。整个过程发生在数据库进程内部，操作用的是数据库自己的权限体系。MySQL的 SELECT 语句再怎么写，也变不成 rm -rf /。数据库引擎没这个功能，它压根不负责执行系统命令。

有人会提 LOAD_FILE() 或者 INTO OUTFILE 这类函数，说能读系统文件、写webshell。没错，MySQL的 LOAD_FILE('/etc/passwd') 确实能读取文件内容，但前提是数据库进程有读这个文件的权限。Linux下MySQL通常以 mysql 用户运行，这个用户连 /etc/shadow 都读不了，更别说 /root 目录下的东西。写文件也一样，secure_file_priv 这个参数在MySQL 5.7之后默认限制了可写目录，很多生产环境直接设成 NULL，连写都不让写。

真正能把数据库权限升级成系统权限的，是另一类漏洞。比如数据库提权漏洞（CVE-2016-6662这种）、UDF提权、或者数据库服务以root身份运行还配置不当。这些跟SQL注入是两码事。SQL注入只是拿到了数据库的查询能力，要跨到操作系统层面，得再找一个独立的提权漏洞来配合。这中间的每一步都有硬性条件，不是注入成功就自动通关。

我去年帮一个电商客户做应急响应，他们的订单查询接口存在SQL注入，攻击者用 sqlmap 跑出了全库数据。但当我检查服务器时，系统日志干干净净，没有异常进程，没有新增用户，/tmp 目录下也没有可疑文件。攻击者拿到的就是数据库里的那点东西，服务器本身毫发无损。这个案例很典型——数据泄露很严重，但操作系统安全没被突破。

当然，不是说SQL注入可以轻视。数据被拖走本身就是重大事故，用户隐私、商业机密全在里面。但把它的危害无限拔高到“威胁操作系统安全”，反而会让人误判风险优先级。该打补丁打补丁，该做参数化查询做参数化查询，数据库权限该收紧收紧。操作系统那层的安全，有它自己的防护体系在管。

换个角度想，如果SQL注入真能随便威胁操作系统，那云厂商的数据库服务早就没人敢用了。RDS这类托管数据库，用户连系统文件都看不到，注入进去也只能在数据库里打转。隔离机制摆在那里，不是一条SQL语句能穿透的。