安全测试技能 | web、app、PC应用测试面试题梳理
web和app
| 序号 | 面试题 | 核心考点 | 回答思路（Web端+App端） | 建议答案 |
|---|---|---|---|---|
| 1 | 如何测试Web端和App端的“敏感信息泄露”漏洞？请分别举例说明测试方法。 | 敏感数据存储/传输安全、Web与App的差异点 | 1. 先明确敏感信息范围（账号、密码、手机号等） 2. Web端重点查前端存储（localStorage）、接口响应、日志 3. App端重点查本地文件（SharedPreferences/沙盒）、日志文件、内存缓存 4. 补充传输层（HTTPS）测试 | Web端： 1. 前端检查：F12查看localStorage是否存储token/手机号，页面源码是否硬编码密钥 2. 接口测试：用Burp拦截响应，检查是否返回password_hash等多余字段 3. 日志检查：访问错误页面（如404），确认不暴露数据库路径/IP App端： 1. 本地文件：通过ADB导出沙盒文件（如Android的/data/data/包名），检查SharedPreferences是否明文存储用户信息 2. 日志抓取：用logcat查看App运行日志，确认无打印密码/验证码 3. 内存分析：通过Frida Hook内存数据，验证敏感信息是否加密存储 |
| 2 | 针对“支付金额篡改”这类业务逻辑漏洞，你会设计哪些测试用例覆盖Web和App场景？ | 业务逻辑漏洞测试、全链路数据校验 | 1. 从“输入→传输→处理→输出”全流程拆解 2. Web端重点测表单参数、API请求体篡改 3. App端重点测本地计算逻辑、请求签名绕过 4. 补充异常场景（如负数金额、重复提交） | 1. 正常流程：输入合法金额（如100元），验证支付结果与订单一致 2. 参数篡改： - Web：用Burp修改POST请求body的 amount字段为1元或-100元- App：通过Charles修改请求参数，或反编译后修改本地计算逻辑（如折扣公式） 3. 签名校验：删除/篡改请求中的 sign字段，验证是否拒绝请求4. 重复提交：短时间内多次发送相同支付请求，验证是否只扣一次款 5. 边界值：输入极大值（如9999999元）或极小值（如0.01元），验证业务限制是否生效 |
| 3 | 如何自动化检测Web端的XSS漏洞和App端的本地存储漏洞？请说明技术方案。 | 安全测试自动化、工具开发能力 | 1. 明确自动化范围（XSS关注输入点，本地存储关注敏感字段） 2. Web端：基于Payload字典的接口扫描+页面渲染检测 3. App端：静态分析APK/IPA文件+动态Hook敏感API 4. 补充结果验证机制（避免误报） | Web端XSS自动化： 1. 用Python+Requests编写爬虫，收集所有输入点（URL参数、表单字段） 2. 加载XSS Payload字典（如 <script>alert(1)</script>、img src=x onerror=alert(1)）3. 发送含Payload的请求，用Selenium渲染页面，检测是否执行脚本（如监听alert事件） 4. 集成到CI/CD，每次迭代自动扫描 App本地存储自动化： 1. 静态：用MobSF分析APK，检测SharedPreferences/NSUserDefaults中是否存储敏感字段（如 password、token）2. 动态：用Frida Hook putString（Android）/setObject（iOS）方法，记录存储的键值对3. 规则引擎判断是否包含敏感信息，生成漏洞报告 |
| 4 | 解释CSRF和SSRF的区别，并说明在Web和App中分别如何测试这两种漏洞。 | 漏洞原理区分、测试场景适配 | 1. 先定义两种漏洞的核心差异（攻击对象：用户vs服务器） 2. Web端：CSRF关注表单提交，SSRF关注URL参数 3. App端：CSRF较少见（因无Cookie自动携带），SSRF关注远程资源加载 4. 举例说明测试工具和Payload | 区别： - CSRF：诱导用户在已登录状态下执行非预期操作（攻击对象是用户） - SSRF：诱导服务器向非预期地址发送请求（攻击对象是服务器） Web测试： - CSRF：构造含恶意操作的HTML页面（如转账），诱导用户点击，检查是否执行（验证是否有CSRF Token） - SSRF：在URL参数（如 ?url=http://xxx）中输入内网IP（127.0.0.1:3306），用Burp Collaborator检测外连App测试： - CSRF：较少见（因用token而非Cookie），测试是否在关键操作（如修改密码）中校验请求来源 - SSRF：在“图片上传（从URL拉取）”“第三方API调用”功能中输入内网地址，通过抓包确认服务器是否发起请求 |
| 5 | 如何测试App在“越狱/root环境”下的安全性？需覆盖哪些风险点？ | 移动终端环境安全、权限控制 | 1. 先明确越狱/root环境的风险（权限提升、数据篡改等） 2. 从“本地数据保护”“权限控制”“功能限制”三个维度设计测试 3. 结合工具（如Frida、Xposed）模拟攻击 | 1. 环境检测：验证App是否能识别越狱/root环境（如Android检测/system/xbin/su，iOS检测/Applications/Cydia.app），并触发安全策略（如拒绝启动）2. 本地数据：在越狱环境下，尝试用iFunBox（iOS）/RE管理器（Android）读取App沙盒文件，检查敏感数据是否加密（如数据库文件是否用SQLCipher加密） 3. 权限控制：通过Xposed框架Hook权限校验函数，尝试越权访问（如普通用户调用管理员接口） 4. 功能限制：验证高风险功能（如支付、转账）在越狱环境下是否禁用或增加验证（如二次人脸识别） |
| 6 | 针对“第三方组件漏洞”（如Log4j2、Fastjson），Web和App端分别如何开展测试和防护？ | 供应链安全、漏洞响应能力 | 1. 先说明组件漏洞的危害（无需代码开发即可利用） 2. 测试方法：组件识别→漏洞匹配→验证利用 3. 防护措施：版本管理→自动化检测→应急响应 | 测试方法： - Web端：用OWASP Dependency-Check扫描pom.xml/package.json，识别组件版本；对高危组件（如Log4j2 <2.17.0），用JNDIExploit验证是否可远程代码执行 - App端：用MobSF分析APK的lib目录，检测含漏洞的.so库（如OpenSSL心脏出血漏洞）；对Android，反编译后查看classes.dex中的第三方SDK版本 防护措施： 1. 建立组件白名单，禁止使用无维护的库（如Java的commons-collections旧版本） 2. 在CI/CD中集成Snyk，每次构建自动检测组件漏洞 3. 应急响应：对爆发漏洞（如Log4j2），先临时修复（如设置 log4j2.formatMsgNoLookups=true），再推动版本升级 |
| 7 | 如何设计测试用例验证Web和App的“会话管理安全性”？ | 身份认证安全、会话生命周期管理 | 1. 从“会话创建→传输→使用→销毁”全周期拆解 2. Web端重点测试Cookie属性、会话固定 3. App端重点测试token存储、过期策略 4. 补充异常场景（如会话劫持） | 1. 会话创建： - Web：登录后检查会话ID是否变化（防御会话固定），是否使用强随机值（长度≥128位） - App：验证token是否包含过期时间（如JWT的exp字段），是否每次登录刷新 2. 传输安全： - Web：检查Cookie是否设置 HttpOnly（防XSS劫持）、Secure（仅HTTPS传输）、SameSite=Strict（防CSRF）- App：确认token是否在HTTPS请求的Authorization头中传输，而非URL参数 3. 生命周期： - 闲置15分钟后检查是否自动登出，手动注销后检查token是否失效 4. 会话劫持：用旧token尝试访问接口，验证是否拒绝（如返回401） |
| 8 | 结合等保2.0三级要求，Web和App测试中需重点关注哪些安全控制点？如何验证？ | 安全合规测试、等保核心要求 | 1. 先列举等保2.0三级的核心控制点（如访问控制、数据加密、日志审计） 2. 针对每个控制点说明Web和App的测试方法 3. 结合实际案例说明合规验证过程 | 1. 访问控制： - 测试是否实现“最小权限”（如普通用户无法访问 /admin）、“三权分立”（开发/运维/审计权限分离）- Web：验证URL访问控制；App：验证功能入口权限（如非VIP用户无法进入会员中心） 2. 数据加密： - 传输：用SSL Labs验证Web的TLS版本（≥1.2）；App用Charles抓包确认所有接口均用HTTPS - 存储：检查数据库中敏感字段（如身份证）是否加密，密钥是否符合“定期轮换”要求 3. 日志审计： - 验证登录失败、权限变更等操作是否记录“用户ID、IP、时间、结果” - Web：检查Nginx日志；App：检查本地日志文件是否同步到服务端 4. 应急响应：测试是否有漏洞应急处置流程（如发现SQL注入后2小时内修复） |
| 9 | 如何测试Web端的“文件上传漏洞”和App端的“恶意文件解析漏洞”？ | 文件处理安全、不同端的攻击面差异 | 1. 明确文件上传的攻击路径（后缀绕过、内容伪装、路径遍历） 2. Web端重点测试服务器端校验逻辑 3. App端重点测试本地文件解析器漏洞（如PDF/图片解析） | Web端文件上传： 1. 后缀绕过：上传 test.php被拦截后，尝试test.php5、test.jpg.php、test.php%00.jpg2. 内容伪装：在图片文件头部添加GIF头（ GIF89a），尾部嵌入PHP代码，验证服务器是否仅校验文件头3. 路径遍历：上传时修改文件名含 ../（如../test.php），验证是否写入上级目录4. 执行验证：访问上传文件URL，确认 test.php无法执行PHP代码App恶意文件解析： 1. 构造含漏洞的文件（如利用PDF阅读器漏洞的恶意PDF） 2. 通过App的“文件导入”功能打开，观察是否崩溃或执行非预期操作（如弹出Toast） 3. 测试压缩包解析：上传含软链接的ZIP包，验证是否能访问App沙盒外文件 |
| 10 | 作为测试负责人，如何推动团队在研发流程中落地安全测试（左移）？请说明具体措施。 | 安全测试体系建设、SDL流程落地能力 | 1. 从“需求→开发→测试→上线”全流程设计措施 2. 结合工具、制度、培训三个维度说明 3. 举例说明落地效果（如漏洞数量下降比例） | 1. 需求阶段： - 引入威胁建模（用STRIDE方法），联合产品、研发识别核心风险（如支付场景的“信息泄露”风险） - 输出《安全测试点清单》（如支付接口必须校验签名） 2. 开发阶段： - 推动研发使用SAST工具（如SonarQube），在提交代码时自动扫描“硬编码密钥”等问题 - 组织安全编码培训（如Java避免 String.format拼接SQL）3. 测试阶段： - 将安全用例集成到自动化测试套件（如Pytest用例中加入XSS检测） - 对高风险功能（如登录、支付）执行渗透测试 4. 上线阶段： - 门禁控制：漏洞未修复至低危以下（CVSS＜4.0）禁止上线 - 定期复盘：每月分析漏洞趋势，优化测试策略 效果：某项目落地后，线上高危漏洞数量下降70%，平均修复时间从3天缩短至12小时 |
pc端
| 序号 | 面试题 | 核心考点 | 回答思路（聚焦PC端特性） | 建议答案 |
|---|---|---|---|---|
| 1 | 如何测试PC端应用的“本地文件权限滥用”漏洞？与Web/App相比有何特殊关注点？ | 本地文件系统交互安全、操作系统权限机制（如Windows UAC、Linux文件权限） | 1. 明确PC端直接操作本地文件/目录的风险（区别于Web的沙箱、App的沙盒限制） 2. 从“文件读写范围”“权限级别”“路径遍历”三个维度设计测试 3. 结合操作系统特性（如Windows的System32目录保护） | 测试方法： 1. 权限边界测试： - 验证应用是否以“最小权限”运行（非管理员权限下能否正常工作，避免滥用admin权限） - 尝试写入系统敏感目录（如Windows的 C:\Windows\System32、Linux的/etc），检查是否被拒绝2. 路径遍历测试： - 在文件打开/保存功能中输入 ../构造路径（如../../Windows/system.ini），验证是否能访问非预期文件- 测试文件名含特殊字符（如 *、?、空格）时是否解析异常3. 文件关联测试： - 检查应用注册的文件类型（如 .xxx）是否存在“双击打开即执行恶意代码”风险（如解析逻辑漏洞）特殊关注点：PC端无Web/App的沙箱隔离，需重点验证“是否限制对系统关键文件的读写”，避免因权限过高导致整台设备被控制 |
| 2 | PC端应用常见的“进程权限与通信安全”问题有哪些？如何测试？ | 进程权限管理、IPC（进程间通信）安全、恶意进程注入风险 | 1. 从“进程运行权限”“IPC机制（如管道、共享内存）”“进程注入防护”展开 2. 结合工具分析进程属性及通信链路 3. 模拟恶意进程交互场景 | 常见问题及测试： 1. 进程权限过高： - 用Process Explorer查看应用进程的权限（如是否属于 Administrators组），验证非必要功能是否滥用高权限- 测试低权限用户能否通过应用执行高权限操作（如修改系统时间） 2. IPC通信未加密： - 检查应用是否使用命名管道（Named Pipe）、共享内存等IPC机制，用Wireshark或Process Monitor捕获通信数据，验证是否明文传输敏感信息（如账号密码） - 尝试伪造IPC消息（如向管道发送恶意指令），检查是否校验发送方身份 3. 进程注入防护： - 用Injector工具尝试向应用进程注入DLL，验证是否触发防护机制（如弹出告警、进程崩溃） - 检查应用是否启用ASLR（地址空间布局随机化）、DEP（数据执行保护）等系统级防护 |
| 3 | 如何测试PC端应用的“注册表操作安全”？需关注哪些风险点？ | 注册表篡改风险、持久化攻击防护、系统配置依赖安全 | 1. 明确注册表在PC端的作用（配置存储、自启动项等） 2. 从“读写范围”“权限控制”“恶意篡改影响”设计测试 3. 结合注册表修复机制验证 | 测试方法： 1. 注册表读写边界： - 检查应用是否过度读写敏感注册表项（如 HKLM\Software\Microsoft\Windows\CurrentVersion\Run自启动项、HKCU\Credentials凭证信息）- 尝试修改应用依赖的注册表配置（如修改服务器地址为恶意IP），验证应用是否校验配置合法性 2. 权限控制测试： - 用Regedit查看应用创建的注册表项权限，确认普通用户无法篡改关键配置（如设置 Administrators组独占写入权限）3. 持久化风险： - 测试应用卸载后是否清理所有注册表残留（如自启动项未删除，导致恶意程序仍能启动） - 检查是否存在“通过修改注册表诱导应用加载恶意DLL”的风险（如DLL搜索路径劫持） 风险点：注册表被篡改可能导致应用异常、系统配置被破坏，甚至成为恶意程序持久化入口（如添加自启动项） |
| 4 | PC端应用的“内存安全漏洞”（如缓冲区溢出）如何测试？与Web/App相比有何特殊性？ | 内存操作安全、静态/动态分析能力、编译时防护机制 | 1. 明确PC端原生应用（C/C++）更易出现内存漏洞（区别于Web的脚本语言、App的沙箱限制） 2. 结合静态分析（代码层面）和动态调试（运行时）设计测试 3. 验证编译选项的安全性 | 测试方法： 1. 静态分析： - 用IDA Pro、Binary Ninja反编译应用二进制文件，查找危险函数（如 strcpy、gets未做长度校验）- 检查编译选项是否启用安全机制（如Visual Studio的 /GS缓冲区溢出检测、/DYNAMICBASE ASLR）2. 动态测试： - 用模糊测试工具（如AFL、LibFuzzer）向输入函数（如文件解析、网络接收）传入畸形数据（超长字符串、特殊字符），监控是否崩溃（可能触发缓冲区溢出） - 用OllyDbg、x64dbg调试，观察内存是否被非法覆盖（如返回地址被篡改） 3. 漏洞验证： - 针对疑似溢出点，构造Exploit POC（如覆盖返回地址到shellcode），验证是否能执行恶意代码 特殊性：PC端原生应用直接操作内存，漏洞可能导致远程代码执行（RCE），且影响范围是整台设备（无沙箱隔离），需重点关注编译时防护和运行时监控 |
| 5 | 如何测试PC端应用的“安装包/升级包安全”？需验证哪些环节？ | 安装包完整性、签名验证、升级流程安全、恶意代码捆绑 | 1. 从“包完整性”“签名合法性”“升级链路”“安装目录权限”展开 2. 结合工具验证数字签名和文件哈希 3. 模拟恶意包替换场景 | 测试方法： 1. 安装包验证： - 用Sigcheck（Windows）或 gpg（Linux）检查安装包是否有数字签名，签名是否来自可信发布者（避免篡改）- 计算安装包哈希值，与官方发布的哈希比对，验证完整性 - 解压安装包，检查是否捆绑恶意文件（如隐藏的 .exe、病毒脚本）2. 升级流程测试： - 拦截升级请求（如修改HTTP响应），替换升级包为恶意版本，验证应用是否校验升级包签名 - 测试“强制升级”逻辑是否可被绕过（如修改本地版本号文件） 3. 安装目录权限： - 检查默认安装路径（如 C:\Program Files\XXX）的权限，确认普通用户无法修改应用程序文件（防止被替换）- 验证安装过程是否创建弱权限目录（如Everyone可写） |
| 6 | PC端应用如何防范“DLL劫持”攻击？测试时需关注哪些场景？ | DLL加载机制、路径搜索顺序漏洞、防御措施有效性 | 1. 明确DLL劫持原理（应用加载非预期DLL） 2. 从“DLL搜索路径”“依赖DLL完整性”“防御配置”设计测试 3. 结合系统工具验证防护效果 | 防御措施及测试场景： 1. 防御措施： - 使用绝对路径加载DLL（而非依赖系统搜索顺序） - 对依赖DLL进行数字签名验证 - 启用Windows的“安全加载”机制（ SetDllDirectory("") + LoadLibraryEx带LOAD_LIBRARY_SEARCH_SYSTEM32参数）2. 测试方法： - 查找应用依赖的DLL（用Dependency Walker工具），在系统搜索路径（如当前目录、 C:\Windows\System32）放置同名恶意DLL，验证应用是否误加载- 替换应用目录下的非签名D |