Security Interview

0x27 奇安信 安全研究员 实习

来源:vvmdx/Sec-Interview-4-2023,已转换为博客静态页面。

0x27 奇安信 安全研究员 实习

来源:https://github.com/vvmdx/Sec-Interview-4-2023
说明:本文件按原面经问题整理答题要点,答案为面试复习口径。

一面 5.17

1. 自我介绍,内容包括:第一部分,做过的安全相关的有难度的项目,难点在哪。第二部分,安全技能树,哪些是比较擅长的,能做什么。

参考完整回答(自我介绍):

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

2. 讲讲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 权限,关闭不必要服务,配置防火墙,开启日志审计,及时打补丁。发现入侵时先保留证据,再做隔离和清除。

3. 讲讲linux平台的ELF文件结构,或者windows平台的PE文件结

参考完整回答(Linux安全):

Linux 安全我会从账号、权限、进程、网络、启动项、日志和补丁几个方面回答。账号侧检查 /etc/passwd、sudoers、SSH key、弱口令和异常登录;权限侧关注 SUID/SGID、777 目录、敏感文件权限和 Web 目录可写可执行;进程和网络侧用 ps、top、ss、lsof 看异常进程和外连;持久化侧看 crontab、systemd、rc.local、shell profile 和自启动服务。

加固时禁用 root 远程登录,使用密钥和 MFA,最小化 sudo 权限,关闭不必要服务,配置防火墙,开启日志审计,及时打补丁。发现入侵时先保留证据,再做隔离和清除。

4. NX是怎么绕过的

参考完整回答(SQL注入绕过):

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

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

5. 讲讲ASLR怎么绕过

参考完整回答(SQL注入绕过):

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

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

6. 用过kali的msf吗?都用来干嘛了,哪些工具用的比较多?

参考完整回答(用过kali的msf吗都用来干嘛了哪些工具用的比较多):

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

7. 函数的调用约定有哪些?区别是什么?32与64位有什么不同

参考完整回答(函数的调用约定有哪些区别是什么与位有什么不同):

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

8. 用fuzzing主要是用来干嘛?主流的产品(chrome那些)有挖过漏洞吗?

参考完整回答(用fuzzing主要是用来干嘛主流的产品chrome那些有挖过漏洞吗):

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

9. 对windows平台的漏洞和保护机制了解多少?

参考完整回答(对windows平台的漏洞和保护机制了解多少):

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

10. 分析过linux的公开漏洞吗?写过exp吗?

参考完整回答(Linux安全):

Linux 安全我会从账号、权限、进程、网络、启动项、日志和补丁几个方面回答。账号侧检查 /etc/passwd、sudoers、SSH key、弱口令和异常登录;权限侧关注 SUID/SGID、777 目录、敏感文件权限和 Web 目录可写可执行;进程和网络侧用 ps、top、ss、lsof 看异常进程和外连;持久化侧看 crontab、systemd、rc.local、shell profile 和自启动服务。

加固时禁用 root 远程登录,使用密钥和 MFA,最小化 sudo 权限,关闭不必要服务,配置防火墙,开启日志审计,及时打补丁。发现入侵时先保留证据,再做隔离和清除。

11. 有没有逆向分析过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 权限,关闭不必要服务,配置防火墙,开启日志审计,及时打补丁。发现入侵时先保留证据,再做隔离和清除。

12. 英文水平怎么样

参考完整回答(越权):

越权分水平越权和垂直越权。水平越权是同权限用户访问他人资源,例如 A 用户通过修改 orderId 看到 B 用户订单;垂直越权是低权限用户访问高权限功能,例如普通用户调用管理员删除接口。根因通常是服务端只校验“是否登录”,没有校验“是否有权访问这个资源或动作”。

测试时我会准备两个不同角色或不同用户账号,对比请求中的 userId、tenantId、role、resourceId、orderId 等参数,尝试替换后看响应是否越界。修复必须在服务端统一鉴权,基于当前登录用户从服务端上下文取身份,校验角色、租户和资源归属,不能相信前端传来的 role 或 userId。

返回安全面经目录