程序员都会涉及渗透安全吗

上周跟一个做后端的朋友吃饭，他忽然问我：“你们写代码的员都是不是都得会点黑客那套？我看招聘要求里老写‘熟悉常见Web漏洞’。”我差点把嘴里的及渗毛血旺笑出来。这问题就跟“医生是透安不是都得会做开颅手术”一样——分科室的。

但话说回来，程序程序员和渗透安全的员都交集，远比外行想象的及渗要深，也比很多程序员自己意识到的透安要浅。浅的程序地方在于，绝大多数业务开发每天就是员都写CRUD、调API、及渗改UI，透安你让他去挖个SQL注入，程序他可能连Burp Suite都没装过。员都深的及渗地方在于，你写的每一行代码，都可能在不经意间变成渗透测试报告里的一个“高危漏洞”。

我第一份工作是在一家电商公司做订单系统。有次安全团队丢过来一个漏洞报告，说我们的优惠券接口可以越权查询别人的券码。原因很简单：接口参数里传了userId，而我在代码里只校验了用户是否登录，没校验这个userId是不是当前登录用户。就这么一行疏忽，渗透测试的人用Burp改个包就拿到了全站用户的券信息。我当时冷汗就下来了——我压根没想过“安全”这回事，但我的代码直接构成了一个渗透入口。

所以你看，程序员“涉及”渗透安全，往往不是主动去渗透别人，而是被动地成为被渗透的对象。你写的每一个接口、每一次数据库查询、每一处文件上传逻辑，都是攻击面的一部分。有些公司会把安全左移，让开发自己跑SAST工具、做威胁建模，甚至要求通过安全编码考试。但更多中小厂呢？安全是上线前扫一遍漏洞扫描器，扫出啥算啥。我见过一个团队，后端小哥为了赶进度，直接用了String sql = "select * from users where name = '" + name + "'"，结果被一个刚毕业的实习生用单引号就测出了注入。那小哥还一脸懵：“我测试的时候没报错啊。”

那是不是所有程序员都得去学渗透测试？真不是。这就像不是所有司机都得会修发动机。但你至少得知道发动机故障灯亮了是什么意思。对应到开发，就是理解OWASP Top 10里跟你技术栈相关的那几条：写Java的得懂反序列化，写前端的得防XSS，搞API的得会配CORS和鉴权。这些不是渗透测试，这是基本的安全素养。渗透测试是主动去模拟攻击、找漏洞链，而程序员更多是在防御侧——你不需要会造炸弹，但得知道怎么不把炸弹引线接到自己家门口。

我观察到一个挺有意思的现象：那些对渗透安全了解比较深的程序员，往往不是被公司培训出来的，而是自己折腾出来的。比如自己搭个靶场打CTF，或者在GitHub上跟过几个漏洞复现的仓库。有个做Go的朋友，因为好奇JWT的none算法漏洞，自己写了个demo去试，结果发现公司内部系统的token校验真的没防住。他后来跟我说：“我不是想当黑客，我就是想知道我写的代码到底有多脆。”这种心态其实挺健康的——带着攻击者视角写代码，比背一百条安全规范都管用。

但别走极端。我见过一些程序员学了点渗透皮毛，就开始在代码里到处加“安全校验”，结果把业务逻辑搞得无比复杂，性能还掉了一大截。安全是个权衡，不是洁癖。你给一个内部管理后台加CSRF token、加二次认证、加IP白名单，可能没问题；但你给一个公开的、高并发的查询接口加一堆同步锁和审计日志，那就是自己找罪受。渗透思维是让你知道“哪里可能被捅”，而不是让你把所有地方都焊死。

回到标题那个问题。程序员都会涉及渗透安全吗？我的答案是：你不需要成为渗透测试工程师，但你的代码每天都在被渗透测试。区别只在于，是你自己先发现漏洞，还是等别人拿着报告来找你。前者叫专业，后者叫事故。至于那些完全没碰过安全、也没出过事的程序员，要么是运气好，要么是系统还没被盯上。这行干久了你就知道，运气这东西，靠不住。

(责任编辑：休闲)