web应用安全交流及培训

上周三下午，应用安我坐在公司会议室最后一排，全交看着安全工程师老周演示一个SQL注入攻击。流及他只在登录框里输入了一串单引号和OR语句，培训后台的应用安用户表就像被掀了裙子一样，所有账号密码明文躺在那里。全交会议室里二十多个开发同事，流及有一半人下意识地坐直了身体。培训

那个场景比任何PPT都管用。应用安web应用安全从来不是全交安全部门单方面的事，它是流及开发、测试、培训运维和产品经理共同参与的应用安一场持续对抗。今天这个交流培训，全交我想说的流及核心就一句话：你们写的每一行代码，都可能成为攻击者眼中的一扇门，而关门这件事，大部分靠的是习惯，不是运气。

先说说最常见的漏洞类型。OWASP Top 10年年更新，但翻来覆去还是那几个老面孔——注入、失效的访问控制、XSS、不安全的反序列化。我见过一个电商项目，开发为了省事，直接把用户传入的JSON反序列化成对象，结果攻击者构造了一个恶意对象，远程执行了系统命令。事后复盘，那个开发委屈地说：“我根本不知道反序列化还能出问题。”这不是个例。很多漏洞不是技术难度高，而是开发者压根没意识到自己正在制造漏洞。

举个例子。你们写登录功能时，习惯怎么校验用户输入？我猜有人会写正则表达式过滤关键词，把“or”、“select”、“union”这些词直接替换成空字符串。但攻击者会变着法子绕过，比如用大小写混合、内联注释、URL编码。我见过一次真实攻击，攻击者把“UNION SELECT”写成“UnIoN/**/SeLeCt”，过滤器直接傻眼。与其费劲去黑名单，不如用参数化查询，从根上把数据和代码分开。这个道理说了无数次，但每次代码评审时，我依然能在新代码里看到字符串拼接SQL的写法。不是大家不懂，是急了就图快，图快就出事。

再聊一个容易忽略的点——身份验证和会话管理。很多应用用JWT做登录态，但不少人把密钥硬编码在配置文件里，甚至直接写在代码里提交到Git仓库。我有个朋友在甲方做渗透测试，他习惯先去GitHub上搜公司的仓库名，经常能搜到硬编码的密钥和数据库连接串。这算安全漏洞吗？当然算。攻击者拿到密钥，就能伪造任意用户的token，整个登录机制形同虚设。更讽刺的是，有些团队安全意识很强，密码设得很复杂，但密钥却随便乱放，就像家里装了防盗门，却把钥匙插在锁孔里。

XSS攻击也值得多说两句。存储型XSS特别阴险，攻击者把恶意脚本存在数据库里，任何用户打开页面都会中招。我见过一个论坛，用户头像字段没做转义，攻击者上传了一个带