2017年秋招季安全圈里不少人都盯上了滴滴出行安全岗的笔试。那会儿网约车业务正处在高速扩张期司乘安全、账号安全、支付风控全都在关键位置上所以这场笔试的题库和市面上那种“背完OWASP TOP 10就能过”的通用安全笔试很不一样——它更像一场“带着业务场景做安全设计”的综合测试。我当年和几个一起笔试的同学对过题大家都觉得考得偏实战、偏业务很多人挂在场景分析题上。这篇文章把这套笔试的考点和题目做一次完整的复盘逐个题目讲清楚考察点、答题思路、常见的失分原因给后来想冲出行领域安全岗的朋友做个参考。1. 笔试科目构成2017年滴滴安全岗到底考什么1.1 整体题型分布与答题节奏先说说整张卷子的观感。笔试时长大概两小时题量不算少主要包括三类题型一类是选择题考察安全基础知识的覆盖面一类是简答题要求你把某个漏洞的原理讲清楚还有一类是综合分析题直接给一个和网约车相关的场景让你写防护方案。选择题大致覆盖了Web安全、密码学基础、操作系统安全、网络协议安全这些常规方向。简答题重点集中在Web漏洞原理与修复、Android客户端安全、数据加密这几个模块。综合分析题则基本围绕“账号安全”“支付安全”“反作弊防刷单”三个方向出。这里有个很重要的节奏问题选择题千万别恋战。2017年那会儿不少同学刚考完一些大厂的笔试习惯性地在一道选择题上纠结很久结果后面的综合分析题来不及写。综合分析题分值占比往往超过40%而且答案相对开放只要思路清晰、方案完整基本都能拿不错的分。我当时给朋友的建议是选择题控制在30到40分钟内简答题控制在40分钟内剩下时间全部留给综合分析题并且做综合分析题时一定要先搭框架再写细节别想到哪写到哪。1.2 那一年出行场景的特殊考察倾向2017年滴滴的安全笔试有一个特点特别明显安全能力必须和业务场景绑定。这个倾向在简答题和综合分析题里表现得很突出。同样是考“越权漏洞”有些公司就考“商品订单越权”而滴滴考的是“查看他人行程”。“行程”这个信息在出行场景里的敏感性极高不只是手机号、姓名这种个人信息还包括实时轨迹、出发地、目的地、常去的家与公司地点。这些信息一旦泄露不仅能定位到具体的人还能分析出生活习惯所以考这道题的时候不能只答“加上权限校验”就完事还得考虑脱敏、风控、告警等一整套机制。再比如“验证码安全”通用考法是问“图形验证码和短信验证码有什么区别”滴滴则倾向于问“如果司机端登录接口被短信轰炸怎么办”。这背后其实是对业务敏锐度的考查司机端是高频使用场景不能像普通用户端那样做太复杂的验证流程否则会影响司机接单但司机账号价值高又必须做足够强的防护。合理的设计往往是在“验证码校验”之外加入设备指纹、行为特征、频控策略等多维风控。1.3 一道开场必答题谈谈你对安全的理解这套卷子里有一个让我印象很深的必答题问法大概是这样“作为一个安全从业者谈谈你对出行行业安全的理解以及安全团队的价值在哪里。”很多人觉得这种题是送分题随便写写就行。但按照那年的判分情况来看这题反而是拉开差距的地方。只写“安全就是防护黑客攻击”这类空话肯定不行面题人想看的是你有没有把安全当成一个体系来理解。当时我身边一个拿到面试机会的同学他的答题思路大致是这样的第一层是基础安全包括网络、主机、应用、客户端这些基础设施的安全防护第二层是业务安全包括账号安全、支付安全、反作弊、风控策略第三层是数据安全与隐私保护包括敏感数据的分级分类、脱敏、权限管控最后一层是安全运营包括威胁情报、监控告警、应急响应。这四层构成一个闭环并且每一层都要结合出行场景来落地。这个答题框架很值得借鉴。它体现出答题者不只是一个会打漏洞的人而是能从全局视角设计安全体系的人。而2017年滴滴安全团队恰恰处在快速扩充期需要的就是这种能搭体系、能落地的综合性安全人才。2. Web安全与业务逻辑类真题还原2.1 SQL注入不只是“能用就注入”Web安全部分必考SQL注入这基本是当时所有大厂安全岗的约定俗成。滴滴这年的考法不算偏但有个细节很值得注意它给了一段带有过滤逻辑的代码要求分析过滤是否能被绕过并说明修复方案。考察点可以拆成三层第一层是SQL注入的基础原理第二层是绕过过滤的思路第三层是修复方案的完整性。先说基础原理。SQL注入的本质是程序把用户输入当作SQL语句的一部分拼接执行攻击者可以通过闭合语句、注入子查询等方式改变原有SQL语义。常见的注入类型包括字符型注入和数字型注入以及基于报错、布尔盲注、时间盲注、联合查询的利用方式。代码里的过滤如果没有做“二次过滤”或者“黑名单覆盖不全”通常都有绕过空间。比如过滤了空格可以用注释符、Tab或URL编码代替过滤了单引号可以尝试宽字节注入这样只要拼接时编码不当单引号就能逃逸出来。关键的固定写法是无论输入是什么都必须用预编译语句PreparedStatement加参数化查询来拼接这是最底层、最稳妥的防御。不能只做黑名单过滤因为黑名单永远跟不上攻击手法。输出层面还要限制异常信息回显防止基于报错的注入被利用。这题想拿高分就一定要答出“纵深防御”预编译是核心但前面要加WAF、输入校验等前置拦截后面要加权限最小化、数据库账号分离、日志审计来兜底。2.2 越权漏洞凭什么用别人的账号查行程越权漏洞在出行场景里出得很自然。题目给出一个场景一个用户订单查询接口前端通过接口传入订单ID后端直接拿着这个ID去数据库里查并返回订单详情没有校验这个订单是否属于当前登录用户。问存在什么漏洞可能造成什么危害如何修复。这是典型的水平越权问题——攻击者可以通过遍历订单ID看到其他用户的订单信息。在出行行业订单信息里包含真实姓名、手机号、上下车地点、行程轨迹数据泄露的后果比普通电商订单严重得多。所以危害分析要分层写个人隐私泄露、人身安全风险可以实时掌握某个人的出行规律、合规风险违反个人信息保护相关要求。修复方案也要分层。最直接的是加权限校验查询前判断订单的userId和当前登录用户的userId是否一致。这是“对象级授权”的标准做法。但仅仅如此还不足以应对复杂场景比如客服系统、司机端等不同的角色访问同一个订单数据时需要的权限边界是不同的这就要引入基于角色的访问控制模型来统一管理。从笔试角度还能加点分的是答出“对ID做不可预测化处理”——把自增ID替换成带随机性的业务单号降低枚举风险。同时接口要做风控和审计发现某个用户短时间内大量查询他人订单要能自动触发告警。2.3 支付金额篡改与“0元打车”支付安全在滴滴这类交易型平台里是重中之重。这年的简答题里有一道“支付金额篡改”题给了一个场景客户端发起支付请求时把订单金额传给服务端服务端按客户端传的金额扣款攻击者可以把金额改成0.01元甚至0元实现“低价打车”。这类题的套路性很强但很多没接触过支付系统的人容易踩坑只答“服务端要校验金额”就结束了。实际上要从两个层面理解。第一层是服务端信任边界。任何从客户端传来的数据都不可信金额必须由服务端根据订单信息计算不能以客户端传参为准。这道题的关键修复点就在这服务端要做到“应付金额以服务端订单快照为准客户端只负责展示和发起支付”。更严谨的做法是下单成功时服务端生成订单快照并签名支付时校验签名和金额。第二层是防重放与防篡改。即使服务端算好了金额攻击者也可以把同一个合法请求重放多次所以要有幂等控制。当时的答题里如果能提到“每笔订单生成唯一的业务流水号支付回调时按流水号做幂等校验”这题基本就是满分水平。还有个容易被忽略的点是支付回调的安全。支付成功后第三方支付平台会回调通知服务端这个回调必须验签、验金额、验商户订单号否则攻击者可以伪造支付成功通知。把这个点答进去能明显体现你的真实业务经验。2.4 验证码与短信轰炸的攻防博弈短信轰炸题也是那年的高频题出题角度很实际“注册和登录接口都接了短信验证码现在攻击者用脚本调用接口给任意手机号发短信导致大量用户被骚扰怎么防护”这道题考察的不只是验证码本身而是对“人机对抗”的理解。回答时要区分“验证码防机器”和“频控防滥用”两个维度。验证码层面短信接口前面一定要挂行为验证码。用户要先完成滑块或者点选验证证明自己是真人再触发短信下发。这在2017年算比较成熟的方案了到今天也是标配。频控层面要分多个维度做限制同一手机号在单位时间内的发送次数上限、同一IP的调用频率限制、同一设备指纹的调用频率限制、同一账号的每日发送上限。这四个维度缺一不可单纯限制手机号很容易被攻击者换号绕过单纯限制IP则防不住代理池。更高级的答法是把“陌生号码”和“高频异常”判断加进去比如对未注册的手机号做更严格的验证或是在夜间等非正常时段加大频控力度。这也是业务场景里的实际需要。3. 移动端逆向与客户端安全真题还原3.1 APK静态分析从反编译到定位关键代码2017年是移动互联网安全岗考察Android安全的巅峰期滴滴的App天然是重点目标所以笔试卷子里有一道APK静态分析的题。题目会给你一个场景拿到一个APK需要分析它的某个关键逻辑比如签名校验、加密算法问用什么工具、走什么流程。常规工具链要写全先是apktool解包拿到资源文件和smali代码再用jadx或者jeb做反编译从DEX字节码还原出可读性更好的Java代码如果App用了加固可能还涉及脱壳那就要用到Frida或者Xposed来做运行时dump。定位关键代码的方式也很重要。最快的方式是全局搜索字符串比如搜索“sign”“token”“secret”“signature”这些关键词能迅速把分析范围缩小到几个关键类上。如果是找签名校验可以搜索包名、Signature类的getSignatures方法调用或者搜索PackageManager相关的API。从笔试判分的角度来看这题想拿高分的核心是“分析思路完整”拿到APK之后先看权限申请和组件暴露情况再看有没有加壳、有没有Native层最后才是具体的业务逻辑分析。这反映出分析者有完整的方法论而不是瞎猜。3.2 签名校验与重打包一道送分题和它的坑签名校验是移动端安全的传统考点滴滴那套卷子里也出现在了简答题中。题目问的是APK重打包后无法安装或运行可能是什么原因如何分析如何绕过。核心原因就是签名变了。APK的签名相当于应用的身份证重打包后即使代码逻辑改了签名也和新版不一致系统安装时就会校验失败。而很多App还会在代码里做自校验签名不对直接闪退。分析方法是先把原APK和重打包APK的签名信息都导出来对比一下MD5。如果App里做了自校验就要找到校验点看它是在Java层还是Native层做的。这道题的难点在于绕过。纯Java层的签名校验相对好处理用Frida hook住PackageManager的getPackageInfo方法让它返回原始签名就行。但如果有Native层的校验事情就变得复杂了需要动态调试Native代码找到校验逻辑后patch掉或者把正确的签名信息传给Native层校验函数。这里笔试答题时一定要强调“重打包防护”的对抗思路而不是只讲怎么绕过。一个完整的修复方案应该是在Java层和Native层分别做签名校验并加反调试让攻击者定位校验点的成本大幅提升。这才能体现你既会攻也知道怎么防。3.3 动态调试与反调试so层的攻防拉锯动态调试那题更进阶考的是Native层的反调试对抗。场景大概是一个Android应用把核心算法放在so文件里你在动态调试时发现进程一挂上调试器就退出问为什么如何绕过。核心知识点是先答出几种常见的反调试手段一是ptrace自跟踪。Linux的ptrace有一个特性同一个进程同一时刻只能被一个进程跟踪。App自己ptrace(PTRACE_TRACEME)调试器就无法再attach上来。这是最常见、也最经典的反调试手段。二是检测调试器状态。通过读取/proc/self/status文件里的TracerPid字段如果非零说明有进程在跟踪自己直接退出。此外android:debuggable标志、Debug.isDebuggerConnected()、检测daemons进程里的jdwp线程都是在Java层常见的手断。三是对关键so文件做完整性校验。用CRC或者哈希算法实时计算so文件在内存中的哈希值和原始值比对不一致就退出。这种方式专门针对内存patch型绕过。绕过反调试的常规思路也有几个方向一是让ptrace失败比如先于App对自身做一次ptrace或者用gdb的set follow-fork-mode child这类操作躲开反调试二是hook住反调试函数直接让检测函数返回“正常”三是patch关键跳转指令把“检测到调试器就退出”改成“检测到调试器也继续执行”。其实这类题在笔试里考的不是你真的现场把so调通了而是你有没有真正调过、知不知道常见的对抗点在哪。能答出几种反调试原理和对应的绕过思路就已经是很好的答案了。4. 密码学与安全基础知识真题还原4.1 加密算法选择题AES、RSA、哈希该怎么选密码学这块的选择题考的通常不是让你手算密钥而是考察算法选型能力和基础概念辨析。滴滴那次笔试里就有一道很经典的选型题给出几个场景让你选合适的算法。第一个场景是“登录密码传输”问用RSA加密还是用HTTPS。这道题的坑在于有些同学会认为密码传输必须用RSA加密。但正确的理解应该是传输层安全优先靠HTTPSTLS保证密码字段本身再做一次加密属于纵深防御如果只对密码做RSA加密而不用HTTPS中间人依然可以替换整个请求加密强度再高也没用。第二个场景是“用户密码存储”选项里有MD5、SHA-1、加盐哈希。正确答案是加盐哈希最好用bcrypt、scrypt这类慢哈希算法。MD5和SHA-1都不是为密码存储设计的算得太快暴力破解效率太高这是2017年已经反复被验证过的教训。第三个场景是“数据完整性校验”选项里有AES、RSA、哈希。正确思路是使用哈希或者在传输场景里用MAC消息认证码特别是带密钥的HMAC这样才能防止攻击者同时篡改数据和数据对应的哈希值。4.2 密码存储为什么“加盐”不是可选项简答题里有一道关于密码存储的题题目直白得像送分“数据库里用户的密码应该怎么存为什么不能直接存MD5加盐是什么意思盐值应该怎么处理”直接存MD5的问题在于用户的密码往往强度不高攻击者拿到哈希之后可以做彩虹表查表或者直接用常见密码字典批量跑。MD5算得太快一个GPU每秒可以算几十亿次即使不用彩虹表穷举弱密码也很快。“加盐”的意思就是在原始密码后面拼接一段随机字符串再做哈希。这样即使两个用户密码一样加盐后的哈希值也不一样。更重要的是盐值增大了彩虹表的构建成本——攻击者没办法提前为所有可能的“密码盐”组合预计算彩虹表。盐值的设计有几个关键点盐值必须每个用户独立、随机生成不能全局共用一个盐盐值长度要足够长一般16字节以上盐值本身不需要保密可以明文存储因为它的作用是增加破解成本而不是隐藏信息。这时候用bcrypt、scrypt、PBKDF2这类慢哈希算法效果更好它们通过增加计算轮数把每次撞库的时间成本放大到“不可接受”的量级。答题时要能把这个逻辑链说完整为什么不能直接存MD5因为算得快、有彩虹表加盐解决了什么解决了同一密码同样哈希、彩虹表预计算为什么用慢哈希因为进一步拖慢离线破解速度。4.3 数字签名从网约车夜间出行资质谈起这套卷子里还有一道关于数字签名的题出题角度很巧妙——它没有让你直接解释“什么是数字签名”而是结合了一个和出行服务相关的场景平台和司机之间需要建立一种信任机制确保某些关键指令比如夜间出行资质审核结果、紧急状态下的报文确实来自平台且未被篡改问你怎么设计。其实这就是数字签名在真实业务里的典型应用。用平台的私钥对报文内容做签名司机端拿到报文后用平台公钥验签。验签通过就能同时证明两件事第一报文确实来自平台身份认证第二报文内容没有被中间人篡改过数据完整性。要强调私钥只能保存在服务端公钥分发到客户端。如果私钥泄露整个信任体系就崩塌了。在移动App场景里通常还会把公钥固化到客户端代码里甚至放到Native层防止攻击者直接替换公钥做中间人攻击。这道题想拿高分还可以结合“防重放”来答数字签名本身能防篡改但防不了攻击者把合法报文保存下来再次发送所以业务报文里要加入时间戳、随机数或单调递增的序列号服务端校验这些信息来防止重放攻击。5. 业务风控与安全运营场景题5.1 刷单问题的风控方案设计综合分析题里最典型的一道是刷单反作弊网约车平台存在司机刷单行为比如司机和乘客勾结制造虚假行程骗取平台补贴问你怎么从安全角度设计风控方案。这道题拼的不是单一漏洞利用能力而是方案设计能力。一个完整的反刷单体系至少要覆盖“事前、事中、事后”三个环节。事前环节要做准入风控。新司机注册时要做实名认证、人脸核验、设备指纹采集。同时要建立关系图谱识别司机和乘客之间是否存在异常关联——比如某个乘客长期只打同一个司机的车社交关系异常紧密这种单子的风险就偏高。事中环节要做实时监控。要在订单流转的关键节点埋点包括下单、接单、行程开始、行程结束、支付完成。每个节点都采集设备信息、GPS信息、操作行为、时间分布。通过特征工程提取异常指标比如司机接单后长时间低速怠速行驶、同一批司机经常在同一时间同一区域接单、司机端和乘客端的操作间隔异常短暂等。事后环节要做处置与举证。确认风控模型命中之后不是简单封号就完事要能提供完整的证据链用于人工审核和可能的申诉流程。这就要做好日志留存、轨迹回放和数据快照。这个答题框架比单纯列举某一种风控策略要完整得多也更能体现出你做过反作弊或风控相关的工作。5.2 撞库与撞库之后账号安全三道防线账号安全是出行平台的重灾区因为用户经常用手机号注册而手机号在其他平台泄露的概率极高。笔试里有一道综合分析题给出的场景是发现大量账号在短时间内被异地登录并且部分账号出现了异常行程要求分析攻击方式并提出解决方案。答案的核心是“撞库”——攻击者拿着从其他平台泄露的账号密码拿到滴滴的登录接口上批量尝试。因为大量用户习惯在不同平台使用相同密码撞库的成功率相当可观。这个问题要从三道防线来设计第一道防线是登录入口。要能识别“批量自动化登录”的行为特征比如登录频率异常、IP集中但分布分散、User-Agent异常等。常用的手段包括设备指纹、行为验证码、IP信誉库、频率限制。第二道防线是风险登录后的二次验证。当账号在异地、新设备上登录时强制要求短信验证码或人脸验证。这个策略在2017年已经有不少应用核心逻辑是“低频正常用户无感知高风险登录才触发额外认证”。第三道防线是登录后的行为监控。即使攻击者突破了前两道防线也不应该畅通无阻。要用风控模型监测账号的异常行为比如短时间内大量叫车、连续修改支付方式、查看陌生人行程等。一旦触发自动冻结或限制账号部分功能。答题时如果能补充“撞库之后的数据泄露闭环”加分很多——不仅要防撞库还要假设撞库已经成功做好账号异常后的通知、快速申诉、证据固定等措施。5.3 数据安全视角轨迹、手机号这些敏感数据怎么管数据安全题在2017年的安全岗笔试里出现频率还不算特别高但滴滴这张卷子已经把它放进来了。题目很直接用户行程数据中包含GPS轨迹、手机号、常用地址问这些数据在存储、传输、使用环节分别要做哪些安全措施。存储环节要强调分级分类与加密。GPS轨迹和手机号的敏感度不同要分开管理。手机号属于直接个人敏感信息必须加密存储GPS轨迹属于高敏位置数据不仅要加密还要做权限管控只有特定角色才能解密访问。建议用独立的密钥管理系统对不同级别数据使用不同密钥并且定期轮换。传输环节要全程走加密通道内部服务之间用mTLS双向认证。同时要防止日志侧漏很多数据泄露不是数据库被拖而是开发调试时把敏感字段直接打到日志里了。所以还要做日志脱敏手机号、身份证号这类字段在日志里必须打码。使用环节要强调脱敏与审计。数据给到业务方使用之前能脱敏就脱敏比如手机号显示前三后四不能脱敏的场景要有严格的审批流程和操作留痕谁在什么时间查看了哪段轨迹都要有完整审计。这是数据安全里比加密更难落地的一环。这道题要想拿高分还要点出“数据最小化”原则不该采集的不采集该删除的定期删除。行程轨迹在完成了安全事件溯源、客服仲裁等用途之后应当按生命周期策略自动清理。6. 考完复盘这种笔试题型背后的安全观6.1 从真题倒推岗位画像滴滴安全团队想要什么人整套卷子做下来对“滴滴安全团队想要什么人”这件事会越来越清晰。它要的不是只会挖洞的“漏洞猎人”而是能够把安全能力植入业务链路的安全工程师。从题型占比能看出来纯漏洞原理题并不是重点重点在于“业务场景安全方案”。越权漏洞不是考你“什么是水平越权”而是考你在“订单查询”场景里怎么防反作弊不是考你“什么叫风控”而是考你在“司机刷单”场景里怎么设计策略。这说明团队在选人时最看重的是候选人能不能把安全技术转化成对业务的保护能力。Android安全题的占比高也映射出当时客户端安全在出行领域的重点地位。网约车的核心操作都在App上司机端、乘客端、管理端都是攻击面所以团队需要既懂逆向又懂业务的人而不只是会做渗透测试。6.2 针对出行场景的备考路线建议如果你现在准备投这类出行领域的安全岗可以考虑把复习重点放在几条主线上。Web安全方面SQL注入、XSS、CSRF、SSRF、越权这些常见漏洞的“原理修复”都要滚瓜烂熟尤其是越权和业务逻辑漏洞建议在本地搭个靶场实际跑一遍把漏洞从发现到利用再到修复的完整链路走通。移动端安全方面至少要能独立完成一个APK的静态分析和动态调试流程。熟悉apktool、jadx、Frida的常见用法知道签名校验、反调试、so层加固的基本原理这些都是2017年那场笔试的高频考点也是移动安全岗的基础功。业务风控方面建议多看一些反作弊、反欺诈的案例重点理解设备指纹、关系图谱、行为序列这些概念。不要只停留在概念层面最好能结合平时接触的产品想想某个业务环节如果被攻击攻击面在哪里、防御点在哪里。数据安全方面要建立“生命周期”视角从数据采集、传输、存储、使用到销毁每个环节的安全措施分别是什么。这套思路在出行行业尤其受用。6.3 最后一点个人小心得我当年给朋友复盘这套笔试题的时候说过一句话滴滴安全岗的笔试题表面考安全本质上考的是你能不能站在业务方的角度思考问题。很多人在笔试时只想着“这道题漏洞原理我背过”却忽略了题目给出的业务场景信息。比如越权题里特意强调了“行程信息可以定位到家庭住址”支付题里特意写了“司机端是高频使用场景”这些都不是废话而是引导你把答案往业务方向上写。我的建议是做这种场景题先花几分钟把业务角色梳理清楚谁能访问什么数据、什么操作会触发什么风险、风险发生之后用户和平台各自的损失是什么。把这三件事想明白了答案自然就有层次了。真正在工作里做安全也是这样——先搞懂业务再去设计防御方案才能落到地上。