企业官网建设流程全解析

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加密。但正确的理解应该是：传输层安全优先靠HTTPS（TLS）保证，密码字段本身再做一次加密属于纵深防御，如果只对密码做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 最后一点个人小心得

我当年给朋友复盘这套笔试题的时候说过一句话：滴滴安全岗的笔试题，表面考安全，本质上考的是你能不能站在业务方的角度思考问题。

很多人在笔试时只想着“这道题漏洞原理我背过”，却忽略了题目给出的业务场景信息。比如越权题里特意强调了“行程信息可以定位到家庭住址”，支付题里特意写了“司机端是高频使用场景”，这些都不是废话，而是引导你把答案往业务方向上写。

我的建议是，做这种场景题，先花几分钟把业务角色梳理清楚：谁能访问什么数据、什么操作会触发什么风险、风险发生之后用户和平台各自的损失是什么。把这三件事想明白了，答案自然就有层次了。真正在工作里做安全也是这样——先搞懂业务，再去设计防御，方案才能落到地上。