web安全基础教程

上个月帮一个做外贸的全基朋友看站点，打开后台日志我愣了几秒——有人用 sqlmap 对着他的础教程产品页扫了整整四个小时，请求参数里塞满了 UNION SELECT。全基他的础教程站点是个小商城，跑了三年，全基后台密码还是础教程 admin123。万幸那次没被拖库，全基但这件事说明一个很朴素的础教程事实：绝大多数 Web 攻击并不高明，它们只是全基精准地踩中了开发者懒得处理的那几个点。

先聊注入。础教程它的全基本质就一句话：你把用户输入当代码执行了。比如登录接口写 SELECT * FROM users WHERE name='$name' AND pwd='$pwd'，础教程攻击者把 name 填成 ' OR '1'='1，全基整条语句的础教程逻辑就被改写了，密码验证直接绕过。全基防御方式不复杂，参数化查询（预编译）能解决九成问题，别再用字符串拼接去凑 SQL。PHP 里用 PDO 的 bindParam，Java 里用 PreparedStatement，Node 里用占位符。剩下的那一成，靠最小权限原则兜底——数据库账号别给 root。

XSS 是另一条高频路径。它和注入的区别在于，注入打的是数据库，XSS 打的是浏览器里的其他用户。存储型 XSS 最阴，攻击者把 <script> 塞进评论区，每个访问该页面的用户都会中招，cookie 被悄悄发到攻击者服务器。我见过一个论坛，过滤只做了前端 JS 校验，用户关掉 JavaScript 直接 POST，payload 照样入库。真正的防御必须落在输出端：根据上下文做 HTML 实体编码，能不用 innerHTML 就别用，加个 CSP 头限制脚本来源，成本很低。

CSRF 容易被忽略，因为它的请求看起来完全合法。你在银行网站登录着，另一个标签页里打开攻击者页面，页面里藏了一个自动提交的表单往银行发转账请求，浏览器会自动带上你的 cookie。服务端光看 cookie 根本分不清这是你本人还是被诱导的请求。对策是给每个表单加一个随机 token，服务端校验 token 是否匹配。SameSite Cookie 属性也能挡掉大部分场景，设成 Lax 或 Strict 就行，现代浏览器都支持。

文件上传是另一个重灾区。有人把 .php 文件改成 .jpg 上传，服务端如果只看扩展名就放行，再配合路径穿越访问到那个文件，直接拿到 webshell。我见过最离谱的配置是上传目录和站点根目录同一层，且目录有执行权限。正确做法：白名单校验扩展名、重命名文件、上传目录禁用脚本执行、存到 Web 根目录之外。

还有一类问题不来自代码，来自配置。默认口令、目录列表没关、错误信息把堆栈直接吐给用户、生产环境开着 debug 模式——这些在扫描器眼里全是敞开的门。我习惯在部署后跑一遍 curl -I 看看响应头，Server 字段暴露版本号就顺手关掉，X-Powered-By 也一样。花五分钟，省掉后面很多麻烦。

安全这件事没有一劳永逸。框架会出漏洞，依赖库会爆 CVE，今天安全的配置明天可能就过时了。能做的就是把输入校验、输出编码、参数化查询、权限最小化这几件事变成肌肉记忆，写代码的时候顺手就做了。剩下的，定期看看日志，发现异常请求别当没看见。攻击者往往比你想象的更有耐心，但也没那么聪明。