0x00 字节跳动-渗透测试实习生

0x00 字节跳动-渗透测试实习生

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

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

1. 自我介绍

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

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

2. 渗透的流程

参考完整回答（渗透测试流程）：

我会先说明渗透测试一定要在授权范围内进行，然后按完整链路展开：第一步确认测试范围、目标资产、时间窗口和禁止事项；第二步做信息收集，包括域名、子域名、IP、端口、服务指纹、历史解析、证书、GitHub 泄露和供应链资产；第三步做漏洞发现和验证，比如弱口令、Web 漏洞、中间件漏洞、配置错误和组件 CVE；第四步在不影响业务的前提下验证漏洞影响，必要时获取低风险证明，比如读取无敏感的标识文件或证明权限边界；第五步如果授权包含内网测试，再做权限提升、凭证收集、内网探测和横向移动验证；最后输出报告，写清楚漏洞位置、复现步骤、影响范围、风险等级、修复建议和复测结果。

面试时我会补一句：真正项目里我不会只追求“打进去”，而是会控制测试强度，保留证据链，避免破坏数据，并且把问题闭环到修复和复测。这样回答能体现流程意识、风险意识和落地能力。

3. 信息收集如何处理子域名爆破的泛解析问题

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

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

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

4. 如何绕过CDN查找真实ip

参考完整回答（绕过CDN找真实IP）：

绕过 CDN 找源站 IP 的思路是寻找没有经过 CDN 的旁路信息。常见来源包括历史 DNS 解析记录、证书透明度、子域名、邮件服务器、同备案资产、GitHub/配置文件泄露、国外节点解析差异、老业务入口、错误页面暴露和源站主动外连记录。

找到候选 IP 后不能直接下结论，要用 Host 头访问、证书、页面标题、静态资源路径、响应指纹和业务内容比对确认是否源站。防护上源站安全组只允许 CDN 回源 IP，源站不要暴露公网管理口，历史解析和测试域名也要清理。

5. phpinfo你会关注哪些信息

参考完整回答（phpinfo）：

phpinfo 重点看 PHP 版本、Server API、disable_functions、open_basedir、上传限制、临时目录、扩展组件、环境变量、配置文件路径、文档根目录、SESSION/Cookie 配置和敏感路径。它可能泄露真实路径、内网地址、中间件版本和可利用的危险函数。

6. 有没有了解过权限维持

参考完整回答（权限维持）：

权限维持是攻击者在拿到初始权限后，尝试长期保留访问能力。常见方式有新增账号、写 SSH key、计划任务、启动项、WebShell、反弹服务、数据库 UDF、系统服务、内存马和云平台访问密钥。授权测试中可以验证风险，但不能在生产留下真实后门。

排查时要看账号变化、authorized_keys、crontab、systemd 服务、启动脚本、Web 目录新增文件、异常进程、外连和登录日志。防护是最小权限、文件完整性监控、EDR、账号审计、凭证轮换和及时修入口漏洞。

7. 说一个你感觉不错的漏洞，展开讲讲

参考完整回答（说一个你感觉不错的漏洞展开讲讲）：

我会选一个自己能讲清楚的漏洞，例如 SSRF。完整回答可以这样说：SSRF 是服务端请求伪造，入口通常是图片抓取、URL 预览、Webhook 或文件下载。如果后端直接请求用户传入的 URL，攻击者就可能让服务器访问内网地址或云元数据服务，比如 169.254.169.254，从而获取临时凭证或探测内网。我会先用普通外部 URL 验证服务端确实发起请求，再尝试回环地址、私有网段和跳转绕过，评估是否能访问敏感服务。修复上限制协议和端口，使用白名单，DNS 解析后校验 IP，禁止访问内网和保留地址，重定向后重新校验，并通过网络隔离限制服务端出网。

8. 输出到href的XSS如何防御

参考完整回答（href XSS）：

输出到 href 属性的 XSS 重点不是只转义尖括号，而是防止危险协议。比如用户输入 javascript:alert(1)、data:text/html 等，如果直接放进 <a href="">，点击时可能执行脚本。还要考虑属性逃逸，例如输入引号闭合 href 后追加事件属性。

修复时先做协议白名单，只允许 http、https 或业务明确允许的 scheme；再对属性值做 HTML 属性编码；生成链接时使用框架安全 API；不要把用户输入拼成完整标签。Cookie 的 HttpOnly 和 CSP 可以降低影响，但根因仍是输出上下文处理错误。

9. samesite防御CSRF的原理

参考完整回答（SameSite）：

SameSite 是 Cookie 的跨站携带策略，用来降低 CSRF 风险。Strict 最严格，跨站跳转也不携带 Cookie；Lax 允许部分顶级 GET 导航携带 Cookie，能兼顾安全和体验；None 表示允许跨站携带，但必须同时设置 Secure，只能在 HTTPS 下使用。

它的防护原理是让攻击者页面发起的跨站请求拿不到用户登录态，从而无法完成敏感操作。但 SameSite 不是万能的，兼容性、同站子域、GET 语义和业务场景都要考虑，所以关键操作仍应配合 CSRF Token、Origin/Referer 校验和二次确认。

10. CSRF防御

参考完整回答（CSRF）：

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

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

11. json格式的CSRF如何防御

参考完整回答（JSON CSRF）：

JSON 接口也可能出现 CSRF，尤其是服务端错误接受 text/plain、表单提交伪造 JSON、CORS 配置过宽，或者没有校验 Content-Type 和 Origin。攻击者虽然通常读不到响应，但可以诱导用户发出带 Cookie 的状态变更请求。

修复时接口只接受 application/json，并严格校验 Content-Type；关键请求校验 CSRF Token；检查 Origin/Referer；Cookie 设置 SameSite；CORS 使用明确白名单，不能把 Access-Control-Allow-Origin 配成任意来源并允许 credentials。

12. 浏览器解析顺序和解码顺序

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

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

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

13. 过滤逗号的SQL注入如何绕过

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

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

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

14. 过滤limit后的逗号如何绕过

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

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

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

15. fastjson相关漏洞

参考完整回答（Fastjson）：

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

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

16. 说一个你知道的python相关的漏洞（SSTI原理，利用过程,payload相关的东西）开放性问答

参考完整回答（SSTI）：

SSTI 是服务端模板注入，用户输入被当作模板表达式编译执行。比如 Flask/Jinja2、Twig、Freemarker、Velocity 等模板引擎，如果把用户输入拼进模板源码，而不是作为普通变量渲染，就可能从表达式求值发展到读取配置、访问对象、执行命令。

检测时可以输入类似算术表达式看是否被求值，再根据语法识别模板引擎。修复是不要动态拼接模板源码，用户输入只作为变量传入；开启沙箱和严格过滤；敏感对象不要暴露到模板上下文；模板错误不要详细回显。