0x51 商汤
来源：https://github.com/vvmdx/Sec-Interview-4-2023
说明：本文件按原面经问题整理答题要点，答案为面试复习口径。
一面
1. 自我介绍
参考完整回答（自我介绍）：
可以按“背景、方向、项目、工具、优势、求职动机”来讲。示例：我主要学习网络安全方向，熟悉 Web 漏洞、渗透测试、Linux 安全、日志分析和代码审计；项目中做过资产收集、漏洞验证、权限控制或应急处置，常用 Burp、Nmap、sqlmap、Wireshark、Linux 等工具。最后强调自己能从漏洞原理、利用条件和修复方案三个层面分析问题。
2. 给一个网段，聊聊攻击思路
参考完整回答（给一个网段聊聊攻击思路）：
这题我会这样完整回答：针对“给一个网段，聊聊攻击思路”，我会先说明它对应的安全场景和要解决的问题，再给出一个具体例子。比如在真实测试或审计中，我会先确认入口在哪里、用户输入是否可控、数据经过哪些处理、最终进入哪个敏感操作；验证时尽量使用低风险方式证明影响，例如观察响应差异、日志、时间延迟、回连记录或权限边界，而不是破坏数据。修复时从代码、配置和权限三方面处理：代码层使用安全 API、参数化、白名单和输出编码；配置层关闭危险功能、升级组件、限制网络和文件权限；权限层坚持最小权限，避免单点漏洞扩大影响。最后我会补充复测方法，用原触发条件验证漏洞不可再利用，并确认正常业务流程仍然可用。
3. xss的修复
参考完整回答（XSS）：
XSS 是用户可控内容被浏览器当成脚本执行。反射型常见于搜索参数或错误提示，存储型常见于评论、昵称、工单内容，DOM 型常见于前端从 location、hash、postMessage 中取值后写入页面。影响包括窃取用户信息、发起越权操作、劫持页面、钓鱼和横向传播。
修复要按输出上下文处理：输出到 HTML 文本要 HTML 编码，输出到属性要属性编码，输出到 JS 字符串要 JS 编码，输出到 URL 要限制协议并 URL 编码。富文本不能自己写黑名单，应该用成熟清洗库。Cookie 设置 HttpOnly、Secure、SameSite，降低被盗风险；CSP 可以限制脚本来源，作为纵深防御。
4. xss所有地方都可以用html编码修复吗
参考完整回答（XSS）：
XSS 是用户可控内容被浏览器当成脚本执行。反射型常见于搜索参数或错误提示，存储型常见于评论、昵称、工单内容，DOM 型常见于前端从 location、hash、postMessage 中取值后写入页面。影响包括窃取用户信息、发起越权操作、劫持页面、钓鱼和横向传播。
修复要按输出上下文处理：输出到 HTML 文本要 HTML 编码，输出到属性要属性编码，输出到 JS 字符串要 JS 编码，输出到 URL 要限制协议并 URL 编码。富文本不能自己写黑名单，应该用成熟清洗库。Cookie 设置 HttpOnly、Secure、SameSite，降低被盗风险；CSP 可以限制脚本来源，作为纵深防御。
5. 在设置了httponly的情况下怎么利用xss
参考完整回答（XSS）：
XSS 是用户可控内容被浏览器当成脚本执行。反射型常见于搜索参数或错误提示，存储型常见于评论、昵称、工单内容，DOM 型常见于前端从 location、hash、postMessage 中取值后写入页面。影响包括窃取用户信息、发起越权操作、劫持页面、钓鱼和横向传播。
修复要按输出上下文处理：输出到 HTML 文本要 HTML 编码，输出到属性要属性编码，输出到 JS 字符串要 JS 编码，输出到 URL 要限制协议并 URL 编码。富文本不能自己写黑名单，应该用成熟清洗库。Cookie 设置 HttpOnly、Secure、SameSite，降低被盗风险；CSP 可以限制脚本来源，作为纵深防御。
6. sql注入绕waf
参考完整回答（SQL注入绕过）：
SQL 注入绕过通常是因为防护用了黑名单，比如只过滤空格、逗号、select、union 这类关键字。攻击者可以用大小写混淆、注释符、URL 编码、宽字节、换行、括号、函数等价替代、布尔盲注、时间盲注、二次注入等方式绕过。例如过滤空格时可能用 /**/、换行或括号替代；过滤逗号时，MySQL 某些场景可以用 join、from for 或子查询改写。
但我在面试中会强调：绕过技巧说明黑名单不可靠，修复不能继续堆规则。正确做法还是参数化查询、白名单映射、最小权限和统一 ORM/DAO 层封装。安全设备如 WAF 可以作为辅助，但不能代替代码层修复。
7. 文件上传绕waf
参考完整回答（文件上传/WebShell）：
文件上传漏洞的风险在于攻击者上传脚本文件或伪装文件，最终让服务器解析执行。绕过方式可能包括双后缀、大小写、MIME 伪造、图片马、解析漏洞、条件竞争和上传路径可控。
完整修复我会这样做：后端使用扩展名白名单，只允许业务需要的类型；校验文件头和真实内容，不信任 Content-Type；上传后随机重命名，文件名不使用用户输入；上传目录放到静态资源域或对象存储，禁止脚本执行；图片类文件做二次处理；限制大小和数量；最后配合杀毒/内容检测和日志审计。Nginx/Apache/PHP-FPM 也要避免把非脚本目录交给解释器解析。
8. 有没有了解过windows&linux的提权
参考完整回答（Linux安全）：
Linux 安全我会从账号、权限、进程、网络、启动项、日志和补丁几个方面回答。账号侧检查 /etc/passwd、sudoers、SSH key、弱口令和异常登录；权限侧关注 SUID/SGID、777 目录、敏感文件权限和 Web 目录可写可执行；进程和网络侧用 ps、top、ss、lsof 看异常进程和外连；持久化侧看 crontab、systemd、rc.local、shell profile 和自启动服务。
加固时禁用 root 远程登录，使用密钥和 MFA，最小化 sudo 权限，关闭不必要服务，配置防火墙，开启日志审计，及时打补丁。发现入侵时先保留证据，再做隔离和清除。
9. mysql提权的条件
参考完整回答（MySQL提权）：
MySQL 提权常见思路包括 UDF 提权、FILE 权限写文件、弱口令登录、利用高权限账号读取敏感数据或写 WebShell。UDF 提权通常需要数据库账号具备写文件能力，并且能把恶意动态库写到 plugin_dir，再创建函数调用系统命令。
防护上要坚持最小权限，业务账号不应有 FILE、SUPER、CREATE FUNCTION 等高危权限；plugin_dir 不允许数据库进程随意写入；MySQL 进程使用低权限系统用户；数据库不要暴露公网；强密码和访问控制必须到位；同时审计 create function、select into outfile、load_file 等高危行为。
10. log4j漏洞原理
参考完整回答（Log4j/JNDI）：
Log4j2 的 Log4Shell 漏洞是因为日志内容中的 ${jndi:...} 会触发 JNDI Lookup。攻击者只要能控制被记录到日志里的内容，比如 User-Agent、用户名、请求参数，就可能让服务器访问恶意 LDAP/RMI 地址，进而触发远程类加载或本地 gadget，造成 RCE。
完整修复是升级 Log4j 到安全版本；临时措施包括删除 JndiLookup 类、关闭 lookup、设置相关安全参数，但最终仍应升级。还要排查传递依赖，因为很多应用不是直接引入 Log4j；网络层限制服务器访问外部 LDAP/RMI；日志侧检索 ${jndi:、lower、upper、::- 等混淆特征，确认是否被探测或利用。
11. jndi原理
参考完整回答（JNDI）：
JNDI 是 Java 命名和目录接口，可以通过 LDAP、RMI、DNS 等方式查找资源。安全问题出现在攻击者能控制 lookup 的名字时，服务端可能访问攻击者控制的 LDAP/RMI，并触发远程类加载、本地 gadget 或反序列化链。
以 Log4j 为例，可控日志内容触发 ${jndi:ldap://...}，服务器发起 JNDI 查询，最终导致 RCE。防护是禁用危险 lookup、升级组件、限制 JNDI 协议和出网访问，并监控异常 LDAP/RMI 请求。
12. log4j除了升级版本外还有什么修复方式
参考完整回答（Log4j/JNDI）：
Log4j2 的 Log4Shell 漏洞是因为日志内容中的 ${jndi:...} 会触发 JNDI Lookup。攻击者只要能控制被记录到日志里的内容，比如 User-Agent、用户名、请求参数，就可能让服务器访问恶意 LDAP/RMI 地址，进而触发远程类加载或本地 gadget，造成 RCE。
完整修复是升级 Log4j 到安全版本；临时措施包括删除 JndiLookup 类、关闭 lookup、设置相关安全参数，但最终仍应升级。还要排查传递依赖，因为很多应用不是直接引入 Log4j；网络层限制服务器访问外部 LDAP/RMI；日志侧检索 ${jndi:、lower、upper、::- 等混淆特征，确认是否被探测或利用。
13. jsp免杀
参考完整回答（免杀）：
免杀的本质是绕过静态特征、行为检测和沙箱检测。常见思路包括编码/加密载荷、分阶段加载、API 动态解析、混淆、反沙箱、内存加载和行为降噪。但在面试中我会注意边界，不展示可直接滥用的细节，而是从防守视角说明检测点。
防护上不能只依赖特征查杀，要结合行为监控、命令行审计、父子进程关系、网络外连、内存执行、脚本执行策略和最小权限。对企业来说，PowerShell 日志、EDR、应用白名单和出网控制很关键。
14. 从甲方视角，如何检测web服务器是否被上传了webshell
参考完整回答（文件上传/WebShell）：
文件上传漏洞的风险在于攻击者上传脚本文件或伪装文件，最终让服务器解析执行。绕过方式可能包括双后缀、大小写、MIME 伪造、图片马、解析漏洞、条件竞争和上传路径可控。
完整修复我会这样做：后端使用扩展名白名单，只允许业务需要的类型；校验文件头和真实内容，不信任 Content-Type；上传后随机重命名，文件名不使用用户输入；上传目录放到静态资源域或对象存储，禁止脚本执行；图片类文件做二次处理；限制大小和数量；最后配合杀毒/内容检测和日志审计。Nginx/Apache/PHP-FPM 也要避免把非脚本目录交给解释器解析。
15. 内网渗透，windows域渗透
参考完整回答（内网渗透/横向）：
内网渗透我会先确认当前落点的权限、网段、路由、DNS、域环境和出网情况。然后做低噪声主机发现和端口识别，重点关注域控、文件共享、数据库、中间件、运维平台和代码仓库。接着收集凭证线索，例如配置文件、历史命令、浏览器缓存、数据库连接串、共享目录和内存凭证；如果授权允许，再验证横向移动和权限提升路径。
防守视角我会补充：内网安全不能只靠边界防火墙，要做分区分域、最小权限、凭证隔离、禁用明文密码和本地管理员复用、开启 EDR、监控东西向流量、审计异常登录和远程执行行为。
16. msf用的多吗
参考完整回答（msf用的多吗）：
这题我会这样完整回答：针对“msf用的多吗”，我会先说明它对应的安全场景和要解决的问题，再给出一个具体例子。比如在真实测试或审计中，我会先确认入口在哪里、用户输入是否可控、数据经过哪些处理、最终进入哪个敏感操作；验证时尽量使用低风险方式证明影响，例如观察响应差异、日志、时间延迟、回连记录或权限边界，而不是破坏数据。修复时从代码、配置和权限三方面处理：代码层使用安全 API、参数化、白名单和输出编码；配置层关闭危险功能、升级组件、限制网络和文件权限；权限层坚持最小权限，避免单点漏洞扩大影响。最后我会补充复测方法，用原触发条件验证漏洞不可再利用，并确认正常业务流程仍然可用。
17. docker和k8s的漏洞了解吗
参考完整回答（容器安全）：
容器安全要从镜像、运行时、编排和宿主机四层看。镜像层要避免使用高危基础镜像、硬编码密钥和 root 用户；运行时要限制特权容器、hostPath、hostNetwork、SYS_ADMIN 等危险能力；Kubernetes 层要控制 RBAC、ServiceAccount token、API Server 暴露、etcd 访问和网络策略；宿主机层要及时更新内核和容器运行时。
容器逃逸通常依赖特权配置、危险挂载、内核漏洞、Docker socket 暴露或 K8s 权限过大。防护是最小权限、只读文件系统、seccomp/AppArmor、禁止特权容器、镜像扫描、网络隔离和审计异常容器行为。
18. docker逃逸
参考完整回答（容器安全）：
容器安全要从镜像、运行时、编排和宿主机四层看。镜像层要避免使用高危基础镜像、硬编码密钥和 root 用户；运行时要限制特权容器、hostPath、hostNetwork、SYS_ADMIN 等危险能力；Kubernetes 层要控制 RBAC、ServiceAccount token、API Server 暴露、etcd 访问和网络策略；宿主机层要及时更新内核和容器运行时。
容器逃逸通常依赖特权配置、危险挂载、内核漏洞、Docker socket 暴露或 K8s 权限过大。防护是最小权限、只读文件系统、seccomp/AppArmor、禁止特权容器、镜像扫描、网络隔离和审计异常容器行为。
19. docker api未授权
参考完整回答（容器安全）：
容器安全要从镜像、运行时、编排和宿主机四层看。镜像层要避免使用高危基础镜像、硬编码密钥和 root 用户；运行时要限制特权容器、hostPath、hostNetwork、SYS_ADMIN 等危险能力；Kubernetes 层要控制 RBAC、ServiceAccount token、API Server 暴露、etcd 访问和网络策略；宿主机层要及时更新内核和容器运行时。
容器逃逸通常依赖特权配置、危险挂载、内核漏洞、Docker socket 暴露或 K8s 权限过大。防护是最小权限、只读文件系统、seccomp/AppArmor、禁止特权容器、镜像扫描、网络隔离和审计异常容器行为。
20. 拿到一个webshell怎么判断他是在docker里还是实机里
参考完整回答（容器安全）：
容器安全要从镜像、运行时、编排和宿主机四层看。镜像层要避免使用高危基础镜像、硬编码密钥和 root 用户；运行时要限制特权容器、hostPath、hostNetwork、SYS_ADMIN 等危险能力；Kubernetes 层要控制 RBAC、ServiceAccount token、API Server 暴露、etcd 访问和网络策略；宿主机层要及时更新内核和容器运行时。
容器逃逸通常依赖特权配置、危险挂载、内核漏洞、Docker socket 暴露或 K8s 权限过大。防护是最小权限、只读文件系统、seccomp/AppArmor、禁止特权容器、镜像扫描、网络隔离和审计异常容器行为。
21. 反问
参考完整回答（反问）：
反问可以围绕岗位职责、团队方向、技术栈、培养机制、实习生预期、日常工作比例和后续流程。不要只问薪资和作息，可以问“这个岗位更偏漏洞研究、工程建设还是应急响应？”来体现目标感。
二面
22. 自我介绍
参考完整回答（自我介绍）：
可以按“背景、方向、项目、工具、优势、求职动机”来讲。示例：我主要学习网络安全方向，熟悉 Web 漏洞、渗透测试、Linux 安全、日志分析和代码审计；项目中做过资产收集、漏洞验证、权限控制或应急处置，常用 Burp、Nmap、sqlmap、Wireshark、Linux 等工具。最后强调自己能从漏洞原理、利用条件和修复方案三个层面分析问题。
23. 聊个印象深刻的经历（细聊细节，聊了很久）
参考完整回答（项目/实习经历）：
项目经历我会用 STAR 讲完整，而不是只列技术名词。先说项目背景：这是一个什么系统、业务价值是什么、我负责哪块安全工作；再说任务：比如接口鉴权、代码审计、漏洞验证、应急处置或安全工具开发；然后讲行动：我如何定位入口、使用了哪些工具、验证了哪些风险、如何推动修复；最后讲结果：修复了什么漏洞、减少了什么暴露面、沉淀了什么规则或文档。
如果面试官深挖，我会准备一个具体案例。例如“我在某系统审计中发现订单详情接口只校验登录态，没有校验订单 owner，导致水平越权。我用两个普通账号互换订单 ID 复现，确认能读取他人数据。修复方案是在服务端统一鉴权中间件里加入用户、租户和资源归属校验，并补充异常访问日志。复测时原越权请求返回 403，正常用户访问不受影响。”
24. 再聊一个印象深刻的经历（也是细聊）
参考完整回答（项目/实习经历）：
项目经历我会用 STAR 讲完整，而不是只列技术名词。先说项目背景：这是一个什么系统、业务价值是什么、我负责哪块安全工作；再说任务：比如接口鉴权、代码审计、漏洞验证、应急处置或安全工具开发；然后讲行动：我如何定位入口、使用了哪些工具、验证了哪些风险、如何推动修复；最后讲结果：修复了什么漏洞、减少了什么暴露面、沉淀了什么规则或文档。
如果面试官深挖，我会准备一个具体案例。例如“我在某系统审计中发现订单详情接口只校验登录态，没有校验订单 owner，导致水平越权。我用两个普通账号互换订单 ID 复现，确认能读取他人数据。修复方案是在服务端统一鉴权中间件里加入用户、租户和资源归属校验，并补充异常访问日志。复测时原越权请求返回 403，正常用户访问不受影响。”
25. python一般是用来干什么的
参考完整回答（Python安全库）：
Python 在安全里常用于自动化验证、扫描、协议交互和应急分析。HTTP 测试常用 requests/httpx，底层网络用 socket，构造和解析数据包用 scapy，SSH 运维用 paramiko，Windows/域协议相关常见 impacket，加密和证书处理用 cryptography、hashlib、hmac、ssl，DNS 分析用 dnspython，HTML 解析用 BeautifulSoup/lxml，恶意样本规则可用 yara-python。
如果被问“有没有用 Python 写过工具”，我会举一个具体例子：比如写过一个批量资产存活探测和标题指纹识别脚本，输入域名/IP 列表，异步请求 HTTP/HTTPS，提取状态码、标题、Server、证书信息和指纹，做去重和导出。重点强调限速、超时、异常处理和授权范围。
26. 漏洞挖掘的思路
参考完整回答（漏洞挖掘的思路）：
这题我会这样完整回答：针对“漏洞挖掘的思路”，我会先说明它对应的安全场景和要解决的问题，再给出一个具体例子。比如在真实测试或审计中，我会先确认入口在哪里、用户输入是否可控、数据经过哪些处理、最终进入哪个敏感操作；验证时尽量使用低风险方式证明影响，例如观察响应差异、日志、时间延迟、回连记录或权限边界，而不是破坏数据。修复时从代码、配置和权限三方面处理：代码层使用安全 API、参数化、白名单和输出编码；配置层关闭危险功能、升级组件、限制网络和文件权限；权限层坚持最小权限，避免单点漏洞扩大影响。最后我会补充复测方法，用原触发条件验证漏洞不可再利用，并确认正常业务流程仍然可用。
27. 水平越权怎么进行代码审计
参考完整回答（越权）：
越权分水平越权和垂直越权。水平越权是同权限用户访问他人资源，例如 A 用户通过修改 orderId 看到 B 用户订单；垂直越权是低权限用户访问高权限功能，例如普通用户调用管理员删除接口。根因通常是服务端只校验“是否登录”，没有校验“是否有权访问这个资源或动作”。
测试时我会准备两个不同角色或不同用户账号，对比请求中的 userId、tenantId、role、resourceId、orderId 等参数，尝试替换后看响应是否越界。修复必须在服务端统一鉴权，基于当前登录用户从服务端上下文取身份，校验角色、租户和资源归属，不能相信前端传来的 role 或 userId。
28. java中的注入怎么防御（sql、xss）
参考完整回答（XSS）：
XSS 是用户可控内容被浏览器当成脚本执行。反射型常见于搜索参数或错误提示，存储型常见于评论、昵称、工单内容，DOM 型常见于前端从 location、hash、postMessage 中取值后写入页面。影响包括窃取用户信息、发起越权操作、劫持页面、钓鱼和横向传播。
修复要按输出上下文处理：输出到 HTML 文本要 HTML 编码，输出到属性要属性编码，输出到 JS 字符串要 JS 编码，输出到 URL 要限制协议并 URL 编码。富文本不能自己写黑名单，应该用成熟清洗库。Cookie 设置 HttpOnly、Secure、SameSite，降低被盗风险；CSP 可以限制脚本来源，作为纵深防御。
29. spring的鉴权
参考完整回答（spring的鉴权）：
这题我会这样完整回答：针对“spring的鉴权”，我会先说明它对应的安全场景和要解决的问题，再给出一个具体例子。比如在真实测试或审计中，我会先确认入口在哪里、用户输入是否可控、数据经过哪些处理、最终进入哪个敏感操作；验证时尽量使用低风险方式证明影响，例如观察响应差异、日志、时间延迟、回连记录或权限边界，而不是破坏数据。修复时从代码、配置和权限三方面处理：代码层使用安全 API、参数化、白名单和输出编码；配置层关闭危险功能、升级组件、限制网络和文件权限；权限层坚持最小权限，避免单点漏洞扩大影响。最后我会补充复测方法，用原触发条件验证漏洞不可再利用，并确认正常业务流程仍然可用。
30. burp使用（场景：token不能重放的情况下怎么设置）
参考完整回答（Token安全）：
Token 设计要看是否可伪造、可泄露、可重放和可撤销。如果是 JWT，Header 和 Payload 只是 Base64URL 编码，不是加密，不能放密码、身份证这类敏感信息；签名算法要固定，禁止 alg=none 和算法混淆；密钥要足够强；exp、iat、aud、iss 等字段要校验。
保护上，浏览器侧 Token 放 HttpOnly Secure SameSite Cookie 更能防 XSS 读取；如果放 localStorage，要重点防 XSS。服务端要支持过期、刷新、吊销和设备维度失效；关键操作可要求短期 Token 或二次认证；传输必须走 HTTPS。
31. 反问
参考完整回答（反问）：
反问可以围绕岗位职责、团队方向、技术栈、培养机制、实习生预期、日常工作比例和后续流程。不要只问薪资和作息，可以问“这个岗位更偏漏洞研究、工程建设还是应急响应？”来体现目标感。
返回安全面经目录