0x04 字节跳动-安全研究实习生

来源：https://github.com/vvmdx/Sec-Interview-4-2023

说明：本文件按原面经问题整理答题要点，答案为面试复习口径。

一面

1. 你投的岗位是安全研究实习生，你了解我们这边主要是做什么的吗

参考完整回答（项目/实习经历）：

项目经历我会用 STAR 讲完整，而不是只列技术名词。先说项目背景：这是一个什么系统、业务价值是什么、我负责哪块安全工作；再说任务：比如接口鉴权、代码审计、漏洞验证、应急处置或安全工具开发；然后讲行动：我如何定位入口、使用了哪些工具、验证了哪些风险、如何推动修复；最后讲结果：修复了什么漏洞、减少了什么暴露面、沉淀了什么规则或文档。

如果面试官深挖，我会准备一个具体案例。例如“我在某系统审计中发现订单详情接口只校验登录态，没有校验订单 owner，导致水平越权。我用两个普通账号互换订单 ID 复现，确认能读取他人数据。修复方案是在服务端统一鉴权中间件里加入用户、租户和资源归属校验，并补充异常访问日志。复测时原越权请求返回 403，正常用户访问不受影响。”

2. 自我介绍

参考完整回答（自我介绍）：

可以按“背景、方向、项目、工具、优势、求职动机”来讲。示例：我主要学习网络安全方向，熟悉 Web 漏洞、渗透测试、Linux 安全、日志分析和代码审计；项目中做过资产收集、漏洞验证、权限控制或应急处置，常用 Burp、Nmap、sqlmap、Wireshark、Linux 等工具。最后强调自己能从漏洞原理、利用条件和修复方案三个层面分析问题。

3. 现在有什么比较想做的方向吗，比如你写的代码审计、攻防演练、你在学校的研究方向（密码学）其实是三个大方向，现在有什么比较想做的吗

参考完整回答（Java代码审计）：

Java 审计我会从路由和鉴权开始，看 Controller、Filter、Interceptor、Spring Security/Shiro 配置和权限注解是否覆盖所有接口。数据访问层重点看 MyBatis 的 ${} 拼接、JPA 原生 SQL、排序字段拼接和多租户条件缺失。危险能力方面看反序列化、Fastjson/Jackson、SpEL/OGNL、模板引擎、文件上传下载、SSRF、XXE 和第三方依赖 CVE。

举例来说，审 SQL 注入时我会搜索 MyBatis XML 里的 ${}，确认参数是否来自请求；如果是 order by，我会要求白名单字段映射。审越权时会看接口是否从 token 中取用户身份，并校验资源 owner，而不是直接使用请求里的 userId。

4. 说了代码审计、安全研究

参考完整回答（Java代码审计）：

5. 有没有审过开源框架、cms、中间件之类的

参考完整回答（中间件漏洞）：

中间件漏洞复现我会按版本确认、环境搭建、漏洞入口、触发条件、影响验证、修复验证来做。比如 Tomcat、WebLogic、Shiro、Struts2、Nginx、Apache、Fastjson、Log4j 等，不能只跑 PoC，要理解漏洞触发点和依赖条件。

修复建议通常包括升级版本、关闭危险功能、修改默认口令、限制管理后台来源、最小权限运行、删除示例应用、加固反序列化和文件上传路径，并在资产系统里持续跟踪版本。

6. 我看你简历上有几段实习经历和项目经历，先聊一下实习经历吧，在A主要做什么的

参考完整回答（项目/实习经历）：

7. 详细聊聊入侵检测主要在做什么，遇到的问题

参考完整回答（项目/实习经历）：

8. 关于入侵检测产生大量误报的原因，有没有分析过，有没有比较好的解决方法

参考完整回答（WAF/IDS/误报）：

WAF/IDS 误报多来自规则只看单个关键字、缺少业务上下文、参数位置不同、编码变化、正常运维脚本触发和资产类型差异。比如 mysql 执行 powershell 可能是运维脚本，也可能是入侵后的横向行为，不能只看一个命中点。

优化时我会做分层：高危明确攻击特征可以阻断；中低危先告警并结合频率、来源信誉、参数位置、响应码、命中规则数、登录态和资产重要性打分；对确定的正常业务加精确白名单，而不是大范围放行；持续把处置结果反馈到规则，形成闭环。

9. 和A比起来，B的应该就比较偏攻击方对吧，有打仗（雾，面试官好像确实是这么说的）有代码审计，聊一下在B主要做了些什么

参考完整回答（Java代码审计）：

10. 审表达式引擎的步骤和思路

参考完整回答（表达式引擎审计）：

审表达式引擎时，我会先看表达式来源是否用户可控，再看引擎支持哪些能力：属性访问、方法调用、反射、类加载、静态方法、文件/网络访问等。接着追踪解析、编译、执行的调用链，确认是否有沙箱、白名单、黑名单和上下文对象暴露。

危险点通常是把用户输入直接作为表达式执行，或在上下文中放入 request、applicationContext、classLoader 等高危对象。修复是表达式白名单化，只允许业务需要的运算和变量；禁用方法调用、反射和类访问；上下文最小化；执行超时和资源限制。

11. 刚刚你说的审计听起来好像和普通开发的审计差不多，都是通过程序流、文档去做，有没有从安全方面入手审计一些项目

参考完整回答（项目/实习经历）：

12. xxe是怎么造成的，从代码层面来看

参考完整回答（XXE）：

XXE 是 XML 外部实体注入。服务端解析用户上传或提交的 XML 时，如果允许 DTD 和外部实体，攻击者就可以定义实体读取本地文件，或者让服务器请求内网地址形成 SSRF。典型场景包括 SOAP、Office 文档解析、SAML、接口 XML 入参和文件导入。

修复必须在 XML 解析器层关闭 DTD、外部实体、XInclude 和外部 schema 加载。不同语言配置不同，但原则一致：不解析外部实体，不允许访问外部资源。还要限制错误回显，避免文件内容通过报错带出。

13. 我看你简历有很多攻防演练经历对吧，这几段攻防演练经历有没有哪一次印象比较深刻的，挑一个聊一聊

参考完整回答（项目/实习经历）：

14. 你的这次攻击好像更多的是利用弱口令，有没有一些更有技巧的方法

参考完整回答（弱口令突破）：

如果资产收集后要找突破口，我会优先看高价值、低成本和暴露明显的点：管理后台、VPN、堡垒机、OA、GitLab、Jenkins、Nexus、Swagger、测试环境、默认口令服务、历史漏洞组件和云存储暴露。弱口令只是入口之一，不会盲目大规模爆破，而是结合口令策略、默认账号、泄露字典和授权范围做低频验证。

拿到入口后要验证影响，比如是否能访问后台、上传文件、执行任务或读取敏感配置。防护上是 MFA、强密码策略、登录限速、默认账号治理、暴露面收敛和异常登录告警。

15. 这个头像上传的webshell是怎么上传的

参考完整回答（文件上传/WebShell）：

文件上传漏洞的风险在于攻击者上传脚本文件或伪装文件，最终让服务器解析执行。绕过方式可能包括双后缀、大小写、MIME 伪造、图片马、解析漏洞、条件竞争和上传路径可控。

完整修复我会这样做：后端使用扩展名白名单，只允许业务需要的类型；校验文件头和真实内容，不信任 Content-Type；上传后随机重命名，文件名不使用用户输入；上传目录放到静态资源域或对象存储，禁止脚本执行；图片类文件做二次处理；限制大小和数量；最后配合杀毒/内容检测和日志审计。Nginx/Apache/PHP-FPM 也要避免把非脚本目录交给解释器解析。

16. 还有什么其他的检验方式?要怎么绕过?

参考完整回答（SQL注入绕过）：

SQL 注入绕过通常是因为防护用了黑名单，比如只过滤空格、逗号、select、union 这类关键字。攻击者可以用大小写混淆、注释符、URL 编码、宽字节、换行、括号、函数等价替代、布尔盲注、时间盲注、二次注入等方式绕过。例如过滤空格时可能用 /**/、换行或括号替代；过滤逗号时，MySQL 某些场景可以用 join、from for 或子查询改写。

但我在面试中会强调：绕过技巧说明黑名单不可靠，修复不能继续堆规则。正确做法还是参数化查询、白名单映射、最小权限和统一 ORM/DAO 层封装。安全设备如 WAF 可以作为辅助，但不能代替代码层修复。

17. 这两天log4j漏洞很火，有没有去了解一下

参考完整回答（Log4j/JNDI）：

Log4j2 的 Log4Shell 漏洞是因为日志内容中的 ${jndi:...} 会触发 JNDI Lookup。攻击者只要能控制被记录到日志里的内容，比如 User-Agent、用户名、请求参数，就可能让服务器访问恶意 LDAP/RMI 地址，进而触发远程类加载或本地 gadget，造成 RCE。

完整修复是升级 Log4j 到安全版本；临时措施包括删除 JndiLookup 类、关闭 lookup、设置相关安全参数，但最终仍应升级。还要排查传递依赖，因为很多应用不是直接引入 Log4j；网络层限制服务器访问外部 LDAP/RMI；日志侧检索 ${jndi:、lower、upper、::- 等混淆特征，确认是否被探测或利用。

18. 反问环节

参考完整回答（反问）：

反问可以围绕岗位职责、团队方向、技术栈、培养机制、实习生预期、日常工作比例和后续流程。不要只问薪资和作息，可以问“这个岗位更偏漏洞研究、工程建设还是应急响应？”来体现目标感。

一面plus-安全研发实习生

19. 自我介绍

参考完整回答（自我介绍）：

20. A护网做了什么

参考完整回答（护网）：

护网如果是蓝队角色，我会说主要工作包括资产梳理、暴露面收敛、弱口令治理、基线加固、WAF/IDS/EDR 告警监控、流量研判、应急处置和复盘报告。遇到告警时先确认资产和攻击链，再判断是否成功入侵，最后做封禁、隔离、修复和溯源。

如果是红队角色，则按目标画像、信息收集、漏洞验证、权限获取、内网横向和目标达成讲。无论红蓝，都要说清自己实际负责的动作，例如分析了哪些日志、处置了什么告警、发现了什么入口、如何推动修复。

21. 做哪一层的处置，waf?ids?

参考完整回答（WAF/IDS/误报）：

22. 遇到的问题是什么，有什么印象深刻的处置

参考完整回答（项目/实习经历）：

23. 怎么解决误报过多的情况，有做过什么规则能解决这个情况的

参考完整回答（WAF/IDS/误报）：

24. 他的内网误报是在办公网还是生产网

参考完整回答（内网渗透/横向）：

内网渗透我会先确认当前落点的权限、网段、路由、DNS、域环境和出网情况。然后做低噪声主机发现和端口识别，重点关注域控、文件共享、数据库、中间件、运维平台和代码仓库。接着收集凭证线索，例如配置文件、历史命令、浏览器缓存、数据库连接串、共享目录和内存凭证；如果授权允许，再验证横向移动和权限提升路径。

防守视角我会补充：内网安全不能只靠边界防火墙，要做分区分域、最小权限、凭证隔离、禁用明文密码和本地管理员复用、开启 EDR、监控东西向流量、审计异常登录和远程执行行为。

25. 比如mysql也会执行powershell，怎么做防护（前面说了很多内网误报是因为有人写了ps脚本触发的）

参考完整回答（内网渗透/横向）：

26. 有没有挖过src

参考完整回答（漏洞挖掘经验）：

漏洞挖掘我不会说成纯工具扫描。我的流程是先确定授权范围和资产清单，再根据资产类型选择策略：后台类系统重点看弱口令、越权、文件上传和接口泄露；API 类系统重点看鉴权、签名、重放和参数污染；老旧系统重点看组件版本和历史 CVE；云资产重点看对象存储、密钥泄露和安全组。

举例回答可以说：我曾在测试环境中通过 JS 文件和接口文档定位到一个未在页面展示的管理接口，用低权限账号访问后发现只校验登录态，没有校验角色，最终形成垂直越权。提交报告时我写了复现步骤、影响范围、截图证据、修复建议和复测结果。

27. 在做攻防的时候，资产收集这块有没有什么经验介绍的

参考完整回答（信息收集/资产收集）：

信息收集我会先确定主体范围，避免把非授权资产扫进去。外部资产方面，我会收集根域名、子域名、历史解析、证书透明度记录、备案信息、公众号/小程序、APP、GitHub 代码泄露、云存储桶、供应商系统和招聘/文档中暴露的系统入口。随后做存活探测、端口扫描、服务指纹识别和 Web 指纹识别，把资产按业务系统、管理后台、测试环境、第三方组件和高危服务分类。

具体工具上，域名可用 OneForAll、subfinder、ksubdomain，空间测绘可用 FOFA、Shodan、ZoomEye，端口识别用 Nmap/Masscan，Web 目录和指纹用 httpx、dirsearch、nuclei。最后我会做去重和归属确认，优先关注登录后台、老旧中间件、暴露数据库、未授权接口、测试环境和存在历史漏洞的组件。

28. 一个单位的一级域名可能不止一个，怎么收集某个单位的所有域名，注意不是子域名

参考完整回答（信息收集/资产收集）：

29. 还有没有其他的资产收集的经验

参考完整回答（信息收集/资产收集）：

30. 除了信息收集，有没有什么漏洞方面的攻击案例

参考完整回答（信息收集/资产收集）：

31. 聊一下sql注入

参考完整回答（SQL注入绕过）：

32. 怎么防御

参考完整回答（怎么防御）：

这类修复题我会按代码层、配置层和监控层回答。代码层首先找到用户输入进入危险操作的位置，优先用安全 API 或参数化方式替代拼接；如果涉及 URL、文件路径、SQL 字段、命令参数等不能直接参数化的位置，就使用白名单映射和规范化校验。配置层要关闭危险功能、降低运行权限、收敛网络访问和补丁升级。监控层要补日志和告警，记录异常参数、失败请求和高危操作。最后一定要复测：用原来的 payload 验证不能再触发，同时确认正常业务不受影响。

33. 遇到order by时怎么防御

参考完整回答（遇到orderby时怎么防御）：

34. 用转义字符防御时，如果遇到数据库的列名或是表名本身就带着特殊字符，应该怎么做

参考完整回答（用转义字符防御时如果遇到数据库的列名或是表名本身就带着特殊字符应该怎么做）：

这题我会这样完整回答：针对“用转义字符防御时，如果遇到数据库的列名或是表名本身就带着特殊字符，应该怎么做”，我会先说明它对应的安全场景和要解决的问题，再给出一个具体例子。比如在真实测试或审计中，我会先确认入口在哪里、用户输入是否可控、数据经过哪些处理、最终进入哪个敏感操作；验证时尽量使用低风险方式证明影响，例如观察响应差异、日志、时间延迟、回连记录或权限边界，而不是破坏数据。修复时从代码、配置和权限三方面处理：代码层使用安全 API、参数化、白名单和输出编码；配置层关闭危险功能、升级组件、限制网络和文件权限；权限层坚持最小权限，避免单点漏洞扩大影响。最后我会补充复测方法，用原触发条件验证漏洞不可再利用，并确认正常业务流程仍然可用。

35. 宽字节注入

参考完整回答（宽字节注入）：

宽字节注入常见于 GBK/Big5 等多字节编码环境。应用为了防 SQL 注入会给引号加反斜杠转义，但攻击者构造特定前导字节后，反斜杠可能和前一个字节组合成合法汉字，导致引号逃逸，SQL 语义被改变。

修复不能只靠 addslashes。应该统一使用 UTF-8，正确设置客户端、连接和数据库字符集，例如 set names utf8mb4；最重要的是使用预编译参数化查询，让输入不参与 SQL 语法解析。

36. ssrf了解吗

参考完整回答（SSRF）：

SSRF 是服务端请求伪造，攻击者控制 URL 参数，让服务器代替攻击者去访问目标。因为请求从服务端发出，所以可以访问攻击者本来访问不到的内网服务，比如 127.0.0.1、Redis、Consul、Kubernetes API、云厂商元数据地址 169.254.169.254 等。常见入口是图片抓取、URL 预览、文件下载、Webhook、PDF 生成和远程资源导入。

修复时我会做“解析后校验”而不是简单字符串判断。首先限制协议，只允许 http/https；其次使用白名单域名或固定资源代理；再次 DNS 解析后校验 IP，禁止私有地址、回环地址、链路本地地址、IPv6 本地地址和保留地址；还要处理重定向，每次跳转后重新校验；最后限制端口、超时时间、响应大小，并通过网络层让业务容器无法直连内网敏感服务和云元数据。

37. 怎么修复

参考完整回答（怎么修复）：

38. 基于黑白名单的修复，现在的生产基本都是用的docker，ip是随时变的，而且docker重启后可能什么都不一样了，怎么做一个修复

参考完整回答（容器安全）：

容器安全要从镜像、运行时、编排和宿主机四层看。镜像层要避免使用高危基础镜像、硬编码密钥和 root 用户；运行时要限制特权容器、hostPath、hostNetwork、SYS_ADMIN 等危险能力；Kubernetes 层要控制 RBAC、ServiceAccount token、API Server 暴露、etcd 访问和网络策略；宿主机层要及时更新内核和容器运行时。

容器逃逸通常依赖特权配置、危险挂载、内核漏洞、Docker socket 暴露或 K8s 权限过大。防护是最小权限、只读文件系统、seccomp/AppArmor、禁止特权容器、镜像扫描、网络隔离和审计异常容器行为。

39. fastjson反序列化

参考完整回答（Fastjson）：

Fastjson 的典型问题和 autoType 反序列化有关。攻击者提交带 @type 的 JSON，让 Fastjson 实例化攻击者指定的类；如果目标环境存在可利用 gadget，就可能触发 JNDI、setter、副作用方法或反序列化链，造成远程命令执行、SSRF 或敏感操作。

回答时可以说利用条件包括：目标使用受影响版本、开启或绕过 autoType、类路径中存在可利用类、输入 JSON 可控。修复是升级到安全版本，关闭 autoType，使用白名单而不是黑名单，避免对外部输入做任意类型反序列化；同时限制应用出网，减少 JNDI 类漏洞的利用成功率，并在日志中监控 @type、JdbcRowSetImpl、TemplatesImpl 等高危特征。

40. redis的漏洞

参考完整回答（Redis漏洞）：

Redis 常见安全问题是未授权访问和弱口令。如果 Redis 暴露在公网或内网可被攻击者访问，攻击者可能写入 SSH 公钥、写 WebShell、写计划任务，或者通过主从复制和模块加载达到命令执行。它本质上不是 Redis 单点漏洞，而是配置和网络暴露问题。

修复应包括：Redis 只监听内网或本机地址，不暴露公网；设置强密码和 Redis 6 ACL；rename 或禁用高危命令只是辅助；使用低权限用户运行 Redis；限制工作目录写权限；防火墙只允许业务主机访问；开启日志审计和异常命令监控。业务侧还要避免 SSRF 能直接访问 Redis。

41. mysql的提权

参考完整回答（MySQL提权）：

MySQL 提权常见思路包括 UDF 提权、FILE 权限写文件、弱口令登录、利用高权限账号读取敏感数据或写 WebShell。UDF 提权通常需要数据库账号具备写文件能力，并且能把恶意动态库写到 plugin_dir，再创建函数调用系统命令。

防护上要坚持最小权限，业务账号不应有 FILE、SUPER、CREATE FUNCTION 等高危权限；plugin_dir 不允许数据库进程随意写入；MySQL 进程使用低权限系统用户；数据库不要暴露公网；强密码和访问控制必须到位；同时审计 create function、select into outfile、load_file 等高危行为。

42. shiro反序列化

参考完整回答（Shiro反序列化）：

Shiro 经典反序列化漏洞通常出现在 rememberMe 功能。Shiro 会把序列化对象加密后放进 rememberMe Cookie，如果密钥是默认值或泄露，攻击者就能用这个密钥加密恶意序列化数据发给服务端，服务端解密后反序列化，触发 CommonsCollections 等 gadget 链。

我会回答形成原因是：客户端可控 Cookie、服务端自动解密反序列化、密钥弱或默认、环境中存在可用 gadget。修复包括升级 Shiro，使用随机强密钥，禁用不必要的 rememberMe，减少危险依赖，开启出网限制，并监控异常 rememberMe Cookie 长度、特征和反序列化异常。

43. 最近很火的log4j，聊一下原理

参考完整回答（Log4j/JNDI）：

44. jndi的解析流程和原理

参考完整回答（JNDI）：

JNDI 是 Java 命名和目录接口，可以通过 LDAP、RMI、DNS 等方式查找资源。安全问题出现在攻击者能控制 lookup 的名字时，服务端可能访问攻击者控制的 LDAP/RMI，并触发远程类加载、本地 gadget 或反序列化链。

以 Log4j 为例，可控日志内容触发 ${jndi:ldap://...}，服务器发起 JNDI 查询，最终导致 RCE。防护是禁用危险 lookup、升级组件、限制 JNDI 协议和出网访问，并监控异常 LDAP/RMI 请求。

45. 有没有什么你做的比较好的地方我没有问到的，可以聊一聊

参考完整回答（有没有什么你做的比较好的地方我没有问到的可以聊一聊）：

这题我会这样完整回答：针对“有没有什么你做的比较好的地方我没有问到的，可以聊一聊”，我会先说明它对应的安全场景和要解决的问题，再给出一个具体例子。比如在真实测试或审计中，我会先确认入口在哪里、用户输入是否可控、数据经过哪些处理、最终进入哪个敏感操作；验证时尽量使用低风险方式证明影响，例如观察响应差异、日志、时间延迟、回连记录或权限边界，而不是破坏数据。修复时从代码、配置和权限三方面处理：代码层使用安全 API、参数化、白名单和输出编码；配置层关闭危险功能、升级组件、限制网络和文件权限；权限层坚持最小权限，避免单点漏洞扩大影响。最后我会补充复测方法，用原触发条件验证漏洞不可再利用，并确认正常业务流程仍然可用。

46. 惯例介绍部门的主要业务

参考完整回答（惯例介绍部门的主要业务）：

这题我会这样完整回答：针对“惯例介绍部门的主要业务”，我会先说明它对应的安全场景和要解决的问题，再给出一个具体例子。比如在真实测试或审计中，我会先确认入口在哪里、用户输入是否可控、数据经过哪些处理、最终进入哪个敏感操作；验证时尽量使用低风险方式证明影响，例如观察响应差异、日志、时间延迟、回连记录或权限边界，而不是破坏数据。修复时从代码、配置和权限三方面处理：代码层使用安全 API、参数化、白名单和输出编码；配置层关闭危险功能、升级组件、限制网络和文件权限；权限层坚持最小权限，避免单点漏洞扩大影响。最后我会补充复测方法，用原触发条件验证漏洞不可再利用，并确认正常业务流程仍然可用。

47. 惯例反问

参考完整回答（反问）：

二面

48. 聊攻防演练中比较得意、印象深刻的一次经历

参考完整回答（项目/实习经历）：

49. 安全领域比较擅长什么

参考完整回答（职业方向）：

职业方向我会结合岗位回答。如果投漏洞研究/代码审计，我会说自己更喜欢从漏洞原理、源码调用链和补丁差异里分析问题，希望后续能沉淀漏洞模式、检测规则和工具；如果投安全工程/安全研发，我会强调希望把安全能力产品化，比如扫描器、风控、检测平台和自动化运营；如果投攻防，我会强调攻击链思维和实战复盘。

完整回答可以是：短期我希望把 Web 安全、代码审计和应急基础打牢，能独立完成漏洞分析和修复推动；中期希望在某个方向形成专长，同时补齐工程化能力，把经验沉淀成工具和规则。

50. 审的一般是什么，java?python?

参考完整回答（Java代码审计）：

51. csrf了解吗，怎么做一个修复

参考完整回答（CSRF）：

CSRF 的关键点是攻击者无法读取目标站响应，但可以诱导用户浏览器带着 Cookie 发起请求。如果用户已经登录，浏览器会自动携带 Cookie，导致转账、改密码、绑定邮箱等操作被伪造。

我会从三层防护回答：第一，关键状态变更请求必须校验 CSRF Token，Token 与会话绑定且不可预测；第二，校验 Origin/Referer，拦截跨站来源；第三，Cookie 设置 SameSite=Lax 或 Strict，HTTPS 下加 Secure。对于高危操作，还可以加二次确认、验证码或重新认证。只靠 GET 改状态是不安全的，状态变更应使用 POST/PUT/DELETE 并做服务端校验。

52. 在拿到java系统的代码时，审计的流程是怎样的

参考完整回答（Java代码审计）：

53. java系统中的sql注入怎么做一个防御和修复

参考完整回答（SQL注入绕过）：

54. 在浏览器中输入一个域名去访问时，浏览器做了什么

参考完整回答（浏览器访问流程）：

浏览器输入域名后，首先解析 URL，检查浏览器缓存、系统缓存和 hosts，然后进行 DNS 解析得到 IP；接着建立 TCP 连接，如果是 HTTPS 还会做 TLS 握手和证书校验；随后发送 HTTP 请求，服务器返回响应；浏览器解析 HTML，构建 DOM，加载 CSS/JS/图片等子资源，构建 CSSOM，执行 JS，最后布局、绘制和合成页面。

从安全角度可以补充：DNS 阶段可能有劫持，TLS 阶段要验证证书，HTTP 阶段要关注 Cookie、CORS、缓存和安全响应头，渲染阶段要防 XSS、混合内容和不安全第三方脚本。

55. 一个系统的登录页，通常可能出现什么漏洞

参考完整回答（登录页漏洞）：

登录页常见漏洞包括弱口令、爆破、撞库、用户名枚举、验证码绕过、SQL 注入、XSS、CSRF、会话固定、短信轰炸和 MFA 缺失。测试时我会看错误提示是否区分用户存在、是否有限速和锁定、验证码是否可复用、登录后 Session 是否重新生成、Cookie 是否安全。

修复包括统一错误提示、限速和风控、强密码和 MFA、验证码防重放、参数化查询、安全 Cookie、登录审计和异常登录告警。

56. 云安全了解吗

参考完整回答（云安全）：

云安全我会重点看身份、网络、数据和审计。身份侧是 AK/SK、RAM/IAM 权限、临时凭证和 MFA；网络侧是安全组、ACL、公网暴露和出入站策略；数据侧是 OSS/S3 桶权限、数据库公网访问、KMS 加密和备份；审计侧是云审计日志、登录异常、API 调用和告警。

常见攻击链是代码泄露 AK/SK、SSRF 访问元数据服务、过宽 IAM 权限横向到云资源、对象存储公开导致数据泄露。修复上要最小权限、密钥轮换、元数据服务加固、存储桶默认私有、安全组收敛和开启云审计。

57. 有做过安全工具的开发吗，比如waf或者扫描器之类的

参考完整回答（WAF/IDS/误报）：

58. 惯例反问

参考完整回答（反问）：

返回安全面经目录