从访问日志揪出SQL注入尝试：特征码就藏在URL里

多数站长以为自己的站没人盯上，实际上随便一台公网服务器每天都被自动扫描器过一遍。有没有人试过SQL注入，access.log里写得明明白白，只是你没去看。

注入尝试的特征很固定：URL或参数里出现单引号的编码%27、union select、and 1=1这类探测语句、sleep(或benchmark(这种时间盲注的延时函数。拿特征码扫一遍日志就有答案。

# 按常见注入特征扫日志
awk '$7 ~ /%27|union|select|sleep\(|benchmark\(|and.*=.*1/' \
 access.log | awk '{print $1, $7}' | sort | uniq -c | sort -rn | head -30
 
# 看响应码：大量200且URL带探测语句的才危险，
# 说明查询可能真被执行了；全是404/403则多为盲扫
awk '$7 ~ /union|%27/ {print $1, $7, $9}' access.log | head -20

结果分两种情况处理。全是404或403，路径根本不存在，属于背景噪音，IP拉黑即可；如果出现200，说明请求打进了真实存在的页面，这时候要立刻去查对应页面的代码：参数有没有进数据库、是不是拼SQL、数据库账号权限给多大。

根治手段老生常谈但必须说：参数一律走预处理，PHP端PDO的prepare加execute，拼接SQL这条路彻底封死；数据库账号按最小权限给，删表的权限不给Web账号，注入成功也点不了火；配合前面讲的limit_req限流，扫描器的效率会低到不值得继续。日志巡检加这两层，注入这事基本就翻篇了。