代码渗透测试

去年帮一个做电商的代码朋友看代码，他跟我说网站绝对安全，渗透用了某知名框架，测试还买了WAF。代码我扫了一眼登录接口，渗透发现返回包里的测试错误信息把SQL语句直接吐出来了。就这一下，代码后面的渗透事不用多说了。

代码渗透测试跟黑盒扫描是测试两码事。扫描器跑一遍，代码报告里几百个中危，渗透真正能打的测试没几个。你得看代码怎么写的代码，数据怎么流的渗透，权限怎么判的测试。不看代码的渗透测试，就像蒙着眼睛拆炸弹。

先找入口，再看过滤

拿到一份代码，我习惯先翻路由文件和控制器。哪里接收用户输入，哪里就是突破口。有个项目，所有参数都走了统一的过滤函数，看起来挺规范。但那个过滤函数只处理了GET和POST，没管Cookie。登录逻辑里恰好用Cookie里的一个字段拼了SQL。开发觉得Cookie用户改不了，实际上抓包工具一改就完事。

过滤逻辑最怕“以为”。以为前端校验过了后端就不用管，以为框架自带防注入就万事大吉。框架防的是框架层面的问题，业务逻辑里的洞它管不了。

SQL注入没死，只是藏得深

预处理语句确实能挡掉大部分注入，但有些地方用不了预处理。比如order by后面的字段名，比如表名动态拼接。有个CMS，搜索功能用了预处理，但排序参数直接拼进SQL。开发觉得排序参数是前端下拉框传的，用户只能选那几个值。抓包改成id,(select sleep(5))，数据库直接卡住。

这种地方扫描器扫不出来，因为payload得根据上下文构造。你得读代码，知道哪个参数进了SQL的哪个位置，才能判断能不能注入、怎么注入。

文件上传的坑不在后缀名

很多开发者把上传安全等同于检查后缀名。黑名单、白名单、MIME类型，一套组合拳打完觉得稳了。但有个项目，上传后的文件路径是/upload/用户ID/文件名，用户ID从session取，文件名做了随机化。看起来没问题。问题是文件内容没检查，上传了一个.htaccess文件到自己的目录，把该目录下所有.jpg当PHP解析。然后传个图片马，直接getshell。

代码渗透测试要关注的是文件最终落在哪、以什么权限执行、能不能被访问到。光看上传那几行代码不够。

越权才是重灾区

SQL注入和文件上传现在越来越难找，但越权漏洞一抓一大把。改个订单ID就能看别人的订单，改个用户ID就能重置别人的密码。开发在写接口的时候，经常忘了加where user_id = 当前用户这个条件。

有个SaaS系统，删除项目的接口只校验了项目ID是否存在，没校验当前用户有没有权限删这个项目。遍历项目ID，能把整个平台的项目全删了。这种漏洞扫描器很难发现，因为返回包都是200，没有报错信息。得手工测，或者读代码看权限校验逻辑。

读代码比跑工具累，但值

跑一遍自动化扫描，半小时出报告。读一遍代码，可能得花两天。但真正的高危漏洞，往往就藏在那些自动化工具看不懂的业务逻辑里。工具告诉你这里有个XSS，你一看，反射型，还得用户点链接，中危都算给面子了。你读代码发现某个接口没鉴权，一测，直接接管管理员账号，这才是要命的东西。

代码渗透测试的核心就一句话：顺着数据流走，看它在每个环节被怎么处理。输入、传输、存储、输出，哪个环节少了校验，哪里就是洞。别迷信工具，别迷信框架，代码是人写的，人就会犯错。