企业官网建设流程全解析

滴滴出行2017秋招安全岗的这套笔试真题，在当年安全圈里讨论度相当高，一方面是因为滴滴作为头部互联网公司，出题水准确实在线；另一方面是它的题目覆盖面很广，从传统Web攻防一直延伸到移动端和业务安全，基本把安全岗日常要碰的东西都串了一遍。到现在回看这套题，很多考点依然是面试和笔试的高频内容，对准备安全岗位的校招生来说，参考价值还是很高的。

这篇文章我就以这套真题为线索，逐题复盘考察的知识点，并尽量还原当时的答题思路和踩坑经历。我会把每道题背后的原理、常见的错误理解，以及延伸出来的实操经验都展开聊一聊，尽量让读者既能看懂题目本身，也能理解“为什么要这么考”。

1. 题目全貌：这份笔试到底在考什么

1.1 试卷结构与考察方向

2017年滴滴安全岗的笔试，整体分为客观题和主观题两大部分。客观题以选择题和判断题为主，考察基础知识的广度；主观题则是简答和场景分析，考察实际攻防中的分析能力和方案设计能力。

从考点分布来看，这套题非常典型地反映了当时互联网公司安全团队的日常关注点。Web安全占了最大比重，包括SQL注入、XSS、CSRF、SSRF、文件上传等经典漏洞；其次是加密与认证体系，比如对称加密与非对称加密的区别、哈希算法在密码存储中的应用、HTTPS握手过程；再就是移动安全，毕竟滴滴的核心业务在App端，APK逆向、组件暴露、数据存储安全这些都会被重点考察；最后还有一部分业务安全题目，比如撞库防护、验证码机制、支付逻辑漏洞等，这些和安全风控团队的实际工作息息相关。

我当时的直观感受是，这套题不是单纯考“会不会背漏洞原理”，而是考“有没有真正做过安全测试”。很多题目看似基础，但出题人会在选项或场景里埋一些坑，如果只是看过书而没有实际动手操作过，很容易选错。

1.2 从出题思路看滴滴安全团队的能力模型

透过题目反推团队的业务场景，你会发现滴滴安全团队关注的能力模型非常清晰。首先是渗透测试能力，这是安全岗的基本功，从信息收集到漏洞利用再到修复建议，整个流程都要熟悉；其次是代码审计和SDL能力，出题人明显希望候选人具备从源码层面发现问题的能力；然后是移动安全能力，这在网约车业务中尤为重要，因为App是核心入口，客户端加固、组件安全、通讯协议加密都是必考题。

值得关注的是，这套题还体现了对“业务安全”的重视。网约车平台的业务链条很复杂，涉及用户注册、登录、下单、支付、评价等多个环节，每一个环节都可能被黑产利用。所以笔试中出现“如何设计一个风控策略来防止恶意注册”这类题，背后反映的是滴滴对业务风控人才的真实需求。这部分内容在传统的安全教材里很少涉及，但对于想去大厂做安全的同学来说，恰恰是需要重点准备的方向。

2. 核心题目逐题拆解与知识点复盘

2.1 Web安全基础题：SQL注入与XSS

这套笔试题里，印象最深的一道题是关于SQL注入的类型判断。题目给了一段典型的登录绕过Payload，要求分析它是字符型注入还是数字型注入，以及为什么构造' or 1=1 --能绕过后端判断。

这道题的核心考点有两个。第一，要理解SQL注入的分类标准：数字型注入不需要闭合引号，字符型注入需要闭合引号并注释掉后面的SQL语句；第二，要理解登录逻辑中SQL语句的拼接方式，典型的有漏洞写法是SELECT * FROM users WHERE username = '$user' AND password = '$pass'，当我们输入用户名admin' or 1=1 --，整个SQL语句就变成SELECT * FROM users WHERE username = 'admin' or 1=1 -- ' AND password = 'xxx'，注释符把后面的密码判断直接去掉了。

深挖一层，这道题其实也在考察“为什么参数化查询能防住SQL注入”。原理在于参数化查询将SQL语句结构和数据分离，数据库在编译SQL语句时，先确定语法结构，再把参数值作为纯数据传入，所以用户输入无论怎么构造，都无法改变SQL的语义结构。这个知识点在笔试里很常见，但在实际写代码的时候，很多开发图省事用拼接字符串的方式，这时候安全人员就需要通过代码审计发现隐患，这道题本质上反映的就是这个真实场景。

另一道和XSS相关的题目也很有意思。题目要求判断“在输入框中输入<script>alert(document.cookie)</script>提交后，页面弹出cookie，这属于哪种XSS”，并进一步追问“如何防止存储型XSS”。

这道题表面上是考XSS分类，实际上是在考对“输入输出”关系的理解。XSS的核心问题不是“输入没过滤”，而是“输出没编码”。存储型XSS是因为用户输入被存进了数据库，在后端渲染页面时又没有对HTML特殊字符进行转义，导致浏览器把脚本当作HTML代码执行。正确的防护思路应该是：在服务端输出时进行上下文相关的编码，比如在HTML标签内输出就对<>编码，在JavaScript上下文输出就做JavaScript编码。现在主流的前端框架默认带有转义机制，这就是为什么用框架能大幅降低XSS风险的原因。但如果用模板引擎时不小心用了v-html或dangerouslySetInnerHTML之类的方法，等于手动关闭了框架的保护，该出事还是会出事。

2.2 加密与认证体系：不只靠背算法

加密相关的题在笔试里占了不小的比例，而且出题人明显不是在考“你会不会列出DES和AES的区别”这种死记硬背的题，而是把加密算法放到具体场景里，考察你是否真的理解每个算法的适用场景和局限性。

有一道题是关于密码存储方案的。题目列出了几种常见的密码存储方式，包括明文存储、MD5加密、加盐MD5、bcrypt哈希，要求选择推荐方案并解释原因。这道题在当年有不少人踩坑，因为很多初学者觉得“MD5加密”听起来很安全，但实际上MD5是哈希算法而不是加密算法，它的设计目标是快速计算，所以暴力破解和彩虹表攻击都非常成熟。更关键的是，即使用MD5加盐，如果盐值固定且算法简单，仍然可以被高速GPU并行破解。

正确做法是选择专为密码存储设计的慢哈希算法，比如bcrypt、scrypt或Argon2。这类算法自带随机盐，而且可以通过调整迭代次数来控制计算耗时，让暴力破解的成本指数级上升。我在实际项目里一般建议用bcrypt，它的默认成本因子是10，即2的10次方轮迭代，如果机器性能允许，可以调到12或更高。这里需要提醒的是，不要自己发明哈希算法，也不要用简单的“拼接固定盐”这种方案，因为安全设计最怕的就是“看起来安全实际上不安全”。

认证方面，有一道题考察HTTPS握手的核心流程，问“HTTPS握手过程中，客户端是如何确认服务器身份的，以及后续的数据加密是用公钥还是对称密钥”。这道题的坑在于很多人会把“非对称加密”和“HTTPS全程使用非对称加密”划等号。实际上HTTPS是混合加密，握手时用非对称加密协商出一个对称会话密钥，后续业务数据用对称加密传输。如此设计的根本原因是性能：非对称加密比对称加密慢几个数量级，如果每个HTTP请求都用RSA加密数据，服务器根本扛不住。

深入一层，这道题还涉及证书链验证机制。服务器返回证书后，客户端要用系统内置的根证书公钥去验证服务器证书的签名链，确认证书是由受信任的CA签发的，并且域名匹配、证书未过期，这才能确认服务器的身份。很多安全测试工具（比如Burp Suite）做HTTPS中间人抓包时，就是通过在客户端安装自己的根证书来欺骗客户端，让客户端信任Burp伪造的服务器证书，这也是面试中常考的原理题。

2.3 移动端与业务安全：网约车场景的独特考题

移动安全和业务安全是滴滴笔试里最有行业特色的部分。因为滴滴的主体业务在App端，所以这部分题目非常贴近真实业务，和纯Web安全题目形成了明显差异。

有一道APK安全的题目问的是“Android APK文件中，assets和res目录的区别是什么，以及为什么存放在assets目录下的资源不适合存放敏感数据”。这道题的考点是Android资源打包机制。res目录下的资源会被编译并生成资源ID，在R文件中可以找到对应引用；而assets目录下的文件不会被编译，以原始文件形式打包进入APK。由于APK本质上是zip压缩包，任何拿到APK的人都可以直接解压查看assets目录里的内容，所以如果把密钥、证书、加密的配置文件放在assets目录里，等于直接把机密材料送到攻击者面前。

APK的防逆向在2017年左右还主要集中在代码混淆和加固层面，但我印象很深的是，这道题其实还暗示了一个更深的考点——即使代码做了混淆，客户端的敏感逻辑（尤其是加密算法和密钥）依然可以被攻击者通过动态调试、Hook技术（如Frida）提取出来。所以真正安全的做法是把关键逻辑放到服务端，客户端只做展示和简单校验，不要把核心密钥放在客户端里。

另一道业务安全题目是典型的风控场景设计题：假设一个网约车平台的注册接口被黑产批量调用，导致大量垃圾账号被创建，请设计一个有效的风控方案。这种题没有标准答案，但考察的思维模式是：先限制攻击入口，再分析攻击路径，最后持续优化策略。

我当时从三个层面回答了这个问题。第一层是入口限制，增加注册时的验证码校验，同时限制同一IP、同一设备的注册频率；第二层是行为识别，通过设备指纹识别批量注册的模拟器、改机工具，并对注册后的行为进行监控——比如新账号在短时间内频繁下单或更换登录设备，就会触发风控规则；第三层是数据建模，通过聚类分析发现异常注册群体，将高危特征加入黑名单库。这个回答框架在往后的面试中也被我多次使用，核心思路就是“事前限制、事中感知、事后追溯”。

2.4 协议与网络安全：从握手到抓包

协议解析相关的题目主要围绕TCP/IP、HTTP/DNS等基础协议展开。考查方式往往很灵活，比如给一段tcpdump抓包结果，要求分析TCP三次握手的过程，或者给一个HTTP请求报文，要求分析Host头、User-Agent、Cookie等字段的含义和安全意义。

有一道题考察的是HTTP和HTTPS的对比，要求至少说出三点区别。这道题的常规答法是：HTTP明文传输，HTTPS加密传输；HTTP默认80端口，HTTPS默认443端口；HTTPS需要申请CA证书。但如果想拿高分，还需要补充更深入的点：HTTPS通过混合加密机制保障数据的机密性，通过MAC（消息认证码）保障完整性，通过数字证书保障通信双方的身份真实性。这里比较容易忽略的点是“完整性”与“机密性”的区别——很多人以为加密就够了，但如果没有完整性校验，攻击者仍然可以通过篡改密文内容来实施一定程度的攻击。

还有一道和SSRF相关的题也很有代表性。题干描述了一个功能：用户可以提交一个URL，服务器抓取该URL的内容并展示。题目问“这个功能可能存在什么漏洞，攻击者能利用它做什么”。SSRF（服务端请求伪造）在2017年已经是热门考点，核心危害在于服务器会替攻击者去访问内网资源。攻击者可以把URL改为http://127.0.0.1:8080/admin去探测本机端口，或者http://192.168.1.1/去探测内网IP段。

这个漏洞的修复思路也是面试高频。基础做法是做白名单限制，只允许访问指定的域名或IP；进一步还要解析URL后对IP做校验，防止通过DNS重绑定绕过，并禁用重定向跟随；最重要的是，根本办法是尽量避免让用户控制服务端发起的请求地址。这个问题放在网约车场景里很现实，因为很多业务功能（比如分享链接预览、图片代理、Webhook回调）都需要服务端发起请求，一不注意就会引入SSRF风险。

3. 从笔试到实战：这套题的答题思路与实操延伸

3.1 信息收集题的答题逻辑

这套真题里，有一道开放式题目非常能体现安全工程师的基本功：给出一个目标域名www.example.com，要求列出至少五种信息收集的方法，并说明这些信息能帮助后续渗透测试的哪个阶段。

这道题的考察核心是信息收集的完整性和条理性。我当时是按这个思路回答的：首先通过DNS解析获取IP和子域名，用子域名爆破工具挖掘未收录的资产，往往能发现测试环境或后台系统；然后对开放的端口和服务进行指纹识别，判断操作系统、Web容器、中间件版本；接着搜索目标在GitHub上的泄露代码，关注是否存在硬编码的API密钥和数据库连接串；再对Web站点做目录扫描，寻找敏感路径和备份文件；最后用搜索引擎收集目标在技术论坛、招聘网站上的信息，比如招聘信息里提到的技术栈就可以反推目标使用的框架和组件。

这个答题逻辑其实和实际渗透测试中的思路高度一致。2017年的笔试题目现在看可能略显传统，但信息收集的底层逻辑并没有变。现在做渗透测试，前期信息收集还是决定成败的关键。目标资产范围厘清、攻击面梳理清楚、指纹信息准确，后面的漏洞利用才会有方向。大量真实渗透测试项目，前期信息收集至少要占40%的时间。

3.2 代码审计题如何快速定位漏洞

有一道代码审计相关的题给出了一个简化后的登录接口代码，要求找出其中的安全漏洞。这道题设计得非常典型，里面至少埋了三个问题：SQL注入、硬编码密钥、不安全的随机数生成。

快速定位代码漏洞的能力，在安全岗面试中比笔试更常被考察，但笔试的作用在于筛选候选人是否具备基本的代码敏感度。我当时做题时总结了一个套路，先看用户输入从哪里进来（GET/POST参数、Header、文件上传），再看数据流向哪里（SQL查询、文件操作、命令执行、HTML输出），这是“污点追踪”的思路。然后是搜索敏感函数，比如SQL相关函数、命令执行函数、文件操作函数，审查是否有过滤或校验；再就是搜索密钥和硬编码信息，比如判断是否存在源码中写死的管理员口令、API密钥、数据库密码。

一个实用的技巧是可以把代码中出现的字符串直接丢进搜索引擎里搜，如果能搜出来，说明是公开代码或者网上有用户讨论，大概率存在已知漏洞。这个技巧在笔试中可能用不上，但实际工作中很管用。

3.3 安全架构设计题的回答框架

主观题的最后一道是安全架构设计类的开放题：给一个简单的Web应用架构（负载均衡、应用服务器、数据库服务器），要求设计一个全面的安全加固方案。

这道题没有标准答案，但评分点往往很明确：是否覆盖了网络层、主机层、应用层、数据层等各个层面；是否给出了具体措施而只停留在概念层面。回答这题时，我按照“纵深防御”的思路来组织答案。

网络层面，核心做法是配置防火墙策略，只开放必要的端口，Web应用前加WAF，对恶意流量进行过滤；主机层面，重点是操作系统安全基线加固，包括关闭不必要的服务、修改默认口令、配置SSH密钥登录、定期补丁更新；应用层面，则需要回到前面提到的那几类经典漏洞，通过代码审计和渗透测试尽可能消除Web层风险；数据层面，关键在于敏感数据的加密存储、传输加密和脱敏，同时要做好数据库的访问控制和审计日志。还有一个容易被忽略的层面是运维安全，比如堡垒机统一登录入口、双人复核机制、敏感操作审批流程。这套“五层防护”框架后来在我参加其他安全岗位面试时也反复用到，沉淀下来就是一套非常实用的安全体系设计方法论。

4. 笔试现场常见翻车点与备赛心得

4.1 时间分配与答题顺序

滴滴这个笔试的题量不算小，我记得当时做完整套题大概花了90分钟到120分钟。不少同学挂在时间分配上面，主要原因是前面客观题花的时间太多，导致后面的大分值主观题写得匆忙。

我的建议是先花5分钟快速浏览全部题目，标出简单题和困难题，优先把确定能拿分的题做完，把有把握的主观题框架先列出来，最后再攻坚难题。尤其是开放性的设计题，本质上考察的是结构性思维，不需要面面俱到，但逻辑一定要清晰。先用一句话亮明观点，再分层展开，最后补充一两个具体的落地细节，这种答案在阅卷时往往比洋洋洒洒却逻辑混乱的答案拿分更高。

4.2 阅卷角度：什么样的答案能拿高分

站在阅卷人的角度，安全岗笔试的评分标准主要看三点。第一是准确，原理性知识不能出错，比如哈希和加密不能混为一谈，对称加密和非对称加密的适用场景不能搞反；第二是落地，给出的方案必须是可以实际执行的，而不是空洞的“加强安全防护”这类套话；第三是视野，对同一个问题如果能从多个层面（比如同时从技术层面和管理层面）给出方案，会比单点回答更有优势。

这里有一个容易被忽视的技巧：回答问题时可以结合目标公司的业务场景。比如题目问“如何防止恶意注册”，如果你能结合网约车的业务场景，提到“设备指纹识别”“注册后行为监控”“新用户首单优惠被撸羊毛”等具有业务特色的细节，会让阅卷人觉得你做过功课，比干巴巴地罗列几个传统安全手段更有亮点。

4.3 备考路线建议

以2017年滴滴这套真题为参照，如果你是现在准备安全岗笔试，我的建议是从三条线同步推进。第一条是基础线，把OWASP Top 10中的漏洞原理、利用方式和修复方案吃透，同时过一遍《白帽子讲Web安全》这类经典书；第二条是动手线，在本地搭一个漏洞靶场，亲手复现SQL注入、XSS、SSRF、文件上传绕过等漏洞，通过实测建立更直观的理解，而不是死记硬背；第三条是行业线，关注目标公司所在行业的业务特点，想一想这个业务里哪些环节最容易成为攻击目标，提前准备几个业务安全的分析框架。

安全这个行业，面试笔试考察的内容更新迭代很快。2017年的很多技术和工具现在可能已经被淘汰了，但这套真题背后所体现的能力要求——扎实的漏洞原理功底、灵活的攻防思维、贴合业务的安全设计能力——到今天依然适用。从备考的第一天起，就要有意识地按这个标准来要求自己，而不是为了应付笔试背一堆概念。

最后分享一个小经验：拿到一套真题，别只做一遍就丢到一边。隔一两周后再回头重做一遍，你会发现第一遍很多“以为理解了”的知识点，其实存在理解偏差。用这种“二刷”的方式，把每一道题的知识点拆开、揉碎、再组装起来，效果比盲目多刷十套新题要好得多。我在准备安全岗的时候，就是把这套真题里的每一个考点都延伸成了一个小的知识专题，并对应在本地靶场里做了验证，后期再遇到类似的笔试题基本都能稳定拿分。