大家好，我是Dest1ny。
今天是面试题目的最后一期。
其实就是好多小伙伴都问我咋面试，其实背题是一方面；
其他的就是人脉和情商。
这个我会专开一个这种方面的，代码真的不是目的。
大家多多点赞关注！！！！！！
之前的章节：
https://blog.csdn.net/m0_70065235/article/details/142595836?spm=1001.2014.3001.5501
https://blog.csdn.net/m0_70065235/article/details/142569485?spm=1001.2014.3001.5501
https://blog.csdn.net/m0_70065235/article/details/142567208?spm=1001.2014.3001.5501
漏洞处置
★☆☆☆☆ 漏洞修复一般分为哪几个步骤？
- 漏洞发现：通过内部检测或外部报告发现漏洞。
- 漏洞分析：分析漏洞的影响范围、风险等级。
- 修复方案制定：设计修复方法，决定是否打补丁、代码修改或配置调整。
- 漏洞修复：实施修复，更新系统、打补丁或修改代码。
- 验证修复：测试漏洞是否彻底修复，确保不会引入新的问题。
- 复盘总结：分析修复过程的优缺点，制定未来的防范策略。
★★☆☆☆ 如何制定漏洞的修复时间？需要考虑哪些因素？
- 漏洞风险等级：高危漏洞需要优先修复，低危漏洞可以推迟修复。
- 业务影响：评估漏洞对业务的影响，决定修复的优先级。
- 外部要求：如果是外部披露的漏洞，可能有合规性或法律上的时间限制。
- 修复难度：复杂漏洞可能需要更多时间，简单配置调整可立即修复。
- 可用资源：考虑团队的人力、物力和技术资源，合理安排时间。
★★★☆☆ 如何有效提升漏洞修复效率？
- 自动化工具：使用自动化扫描和修复工具提升效率。
- 漏洞管理流程标准化：制定统一的漏洞修复流程，减少沟通和决策时间。
- 预案与应急响应：预先制定修复预案，出现漏洞时快速响应。
- 团队协作与分工明确：各团队（开发、安全、运维）分工明确，提高协作效率。
- 安全培训：提升开发团队的安全意识和漏洞修复能力，减少修复时间。
★★☆☆☆ 漏洞复盘的关键是什么？
- 漏洞根本原因分析：找出漏洞产生的根本原因，是技术问题、流程问题还是认知问题。
- 修复效果评估：评估修复是否彻底解决了问题，有无潜在风险。
- 安全流程优化：根据复盘结果，改进现有的漏洞管理流程。
- 预防措施：针对类似漏洞制定预防策略，防止同类问题再次发生。
- 知识分享与总结：将漏洞修复过程中的经验教训共享给相关团队，提升整体能力。
★★★☆☆ 如何快速有效推进修复外部厂商的漏洞？
- 建立沟通渠道：快速与厂商建立直接沟通渠道，确保信息传递顺畅。
- 提供详细漏洞报告：为厂商提供详细的漏洞信息，包括复现步骤、风险评估等。
- 督促修复进度：定期跟踪厂商修复进度，必要时通过法律或合规手段推进。
- 提出临时缓解方案：在修复未完成前，提出临时性缓解方案，减少漏洞风险。
- 合作与支持：必要时提供技术支持，帮助厂商加快修复进度。
★★★★☆ 外部白帽子发现某个高危漏洞，但完整修复需要多天，安全产品的止血手段不彻底，你该如何处置？
- 立即部署临时防护措施：通过 WAF、IDS、IPS 等工具，立即拦截相关攻击，降低漏洞的利用可能性。
- 风险评估：评估漏洞对系统和业务的实际威胁，确定受影响的范围。
- 制定缓解方案：根据漏洞特点，制定临时的缓解措施，减少漏洞的暴露面，如禁用受影响的功能或更改配置。
- 持续监控：实时监控系统日志和流量，观察是否有攻击尝试，及时响应。
- 沟通外部白帽子：保持与白帽子良好的沟通，告知修复进度，争取更多时间。
- 加快修复进度：通过增加人力、资源等方式，尽量缩短修复时间，尽早完成彻底修复。
漏洞自动化发现
白盒 SAST
★★★☆☆ 当前阶段，人工和自动化的代码审计差异点在哪里？
- 自动化工具：可以快速扫描大量代码，适合检测常见的漏洞模式，但对业务逻辑复杂性理解不足。
- 人工审计：人类审计师可以理解业务逻辑、推测潜在的安全风险，但速度较慢，容易受个人经验限制。
★★★☆☆ 什么类型漏洞是代码审计无法准确判断存在与否的？
- 逻辑漏洞：涉及复杂的业务逻辑或权限控制，自动化工具难以判断其安全性。
- 时间性漏洞：如竞争条件（Race Condition）漏洞，工具无法有效模拟多线程环境下的竞争情况。
- 输入过滤/校验漏洞：某些需要上下文判断的输入校验问题工具难以捕捉。
★★★☆☆ 密钥识别的正则如何写？
[A-Za-z0-9]{32,64}
这个正则匹配常见的 API 密钥或令牌，字符长度为 32 到 64。
★★★☆☆ 正则(a+)+会存在什么风险？
正则 a+)+ 存在 回溯爆炸 问题，匹配长字符串时效率极低，可能导致正则处理时间过长甚至拒绝服务。
★★★☆☆ 程序对读取的文件名的正则为 /\.markdown/，如何绕过？
使用类似 .markdown. 或 .markdown/../filename 绕过正则匹配。
★★★☆☆ 程序对请求的 URL 的正则为 ^http\:\/\/.*\.feei.cn($|(\/[^<>\'\"*]))，如何绕过？
可以通过 http://feei.cn@attacker.com 这种方式绕过，利用 URL 中的用户信息部分进行混淆。
★★★☆☆ 解释型语言和编译型语言在语法树分析上有什么差异？
- 解释型语言：代码在运行时生成并执行，语法树可以动态生成，分析过程中需要考虑动态特性（如动态变量、函数调用）。
- 编译型语言：编译时生成语法树，分析较为静态，流程明确，变量和函数解析固定。
★★★☆☆ Java Web 应用中的反序列化漏洞的 Source 和 Sink 是什么？
- Source：从不受信任的来源（如用户输入或文件）反序列化对象。
- Sink：将序列化的对象传递给执行代码的地方，如
readObject()、readResolve()等。
黑盒 DAST
★★★☆☆ 黑盒如何检测 XSS 漏洞？
- 输入字段探测：发送带有恶意 JavaScript 的输入，观察输出是否被反射回页面。
- 响应分析：检查响应中是否存在未过滤的输入内容。
- DOM 分析：检查页面是否有不安全的 DOM 操作。
★★☆☆☆ 甲方黑盒是否应该有爬取流量功能？
是的，黑盒测试中的爬取功能有助于全面了解应用的页面结构、动态加载内容，从而发现潜在的安全漏洞。
★★★☆☆ 黑盒如何扫描无法出网的 SSRF？
可以使用内部服务模拟外部请求，或者通过 DNS 外带（DNS Rebinding）等方式检测 SSRF。
★★★☆☆ 黑盒如何扫描越权漏洞？
- 角色切换测试：通过低权限账户访问高权限资源，观察是否有权限控制问题。
- 强制浏览测试：手动构造 URL 尝试访问未授权页面。
★★★★☆ 黑盒带登录态扫描如何规避业务影响？
- 测试环境：尽量在测试环境或沙箱中进行扫描，减少对实际业务的影响。
- 流量控制：限制扫描速度和频率，避免对服务产生负载压力。
- 选择性扫描：只对敏感页面和功能进行深度扫描，避免对核心业务页面的大范围扫描。
★★★★☆ 黑盒扫描时如何避免被反制？
- 流量伪装：通过不同的 IP 地址和 User-Agent 模拟正常用户行为。
- 检测防护机制：识别目标的 WAF、IPS 规则，避免触发拦截。
- 扫描间隔调整：控制
★★★☆☆ 灰盒相较于黑白盒的优势是什么？
- 综合视角：灰盒测试结合了黑盒和白盒的优点，能够从业务逻辑和代码层面全面评估安全性。
- 提高效率：测试人员能够访问部分代码和系统结构信息，减少测试时间，提升漏洞发现效率。
- 准确性：能够更精准地判断应用逻辑漏洞和安全缺陷，尤其是在复杂的系统中。
安全评估与解决方案
★★★☆☆ 抽象来看，安全评估到底要评什么东西？
- 资产识别：识别系统、网络、应用程序等资产的清单。
- 威胁建模：评估可能的安全威胁和攻击面。
- 安全控制：检查现有的安全控制措施是否有效。
- 合规性要求：确保遵守相关的法规和标准。
- 漏洞识别：通过各种工具和方法识别潜在的安全漏洞。
★★★☆☆ 一个应用开放出去 API，可能存在哪些风险以及如何应对？
- 传输窃取：使用 HTTPS 加密传输。
- 未授权访问：使用 API 调用密钥进行访问控制。
- 请求篡改：为请求签名，确保数据完整性。
- 请求重放：在请求中添加随机数和时间戳，以防重放攻击。
★★★★☆ 设计 API 签名时，随机数使用秒时间戳（timestamp/s）会存在什么风险？
秒时间戳在防重放攻击时存在一秒内可重发多次的问题。解决方案可以是增加一个随机数，或使用毫秒级时间戳，减少重放的风险。
★★★★☆ 设计 API 签名时，HMAC SHA256 和 SHA256 区别是什么？
- SHA256：仅对数据进行哈希，存在彩虹表碰撞的问题。
- HMAC SHA256：通过使用密钥加盐来生成哈希，增加了安全性，抵抗伪造和重放攻击。
★★★☆☆ 密码如何加密保存？
使用高强度的不可逆哈希算法，加上动态盐。可以使用 pbkdf2、bcrypt 或 scrypt 等算法确保密码安全。
★★★☆☆ 某些场景（登录、注册、修改密码、支付）会存在哪些风险以及如何防范？
- 登录：暴力破解、会话劫持，使用验证码和限流。
- 注册：垃圾账号注册，限制注册频率和使用邮箱验证。
- 修改密码：CSRF 攻击，使用 CSRF Token。
- 支付：请求篡改和重放，使用 HTTPS 加密传输和请求签名。
★★★☆☆ 新应用如何评估安全风险？
- 设计评审：在设计阶段进行安全评审，识别潜在风险。
- 源代码审计：对关键代码进行安全审计，发现漏洞。
- 渗透测试：进行黑盒或灰盒渗透测试，模拟攻击场景。
- 合规性检查：确保符合行业标准和法规要求。
★★★☆☆ 需求阶段、系分阶段安全评估的侧重点是什么？
- 需求阶段：重点在于识别潜在安全需求，明确安全目标和合规性要求。
- 系统分阶段：根据系统架构进行细化评估，识别不同模块的安全风险，制定相应的控制措施。
★★★☆☆ 接口 B 的参数是从接口 A 的响应中获取的，会存在什么风险？
可能存在 未授权访问 和 请求篡改 的风险。攻击者可能利用接口 A 的返回数据构造恶意请求。
★★★☆☆ 新的 API 接口上线时，如何设计使其避免出现请求篡改和请求重放？
- 请求签名：为每个请求生成唯一签名，确保数据未被篡改。
- 随机数和时间戳：在请求中加入随机数和时间戳，防止重放攻击。
- OAuth 认证：使用 OAuth 等标准进行访问控制，增强安全性。
★★★☆☆ Docker 容器以及 K8s 有哪些风险？
- 容器逃逸：恶意用户可能通过漏洞逃逸到宿主机。
- 默认配置风险：不安全的默认设置和弱密码。
- 镜像安全：使用不可信的镜像，可能含有恶意代码。
- 网络隔离不足：容器间网络隔离不够，可能导致数据泄露。
★★★☆☆ IPv6 和 IPv4 安全差异？
- 地址空间：IPv6 的地址空间大大增加，减少了 IP 扫描的可能性。
- 内建安全性：IPv6 内建了 IPsec 支持，提高了数据传输的安全性。
- 配置复杂性：IPv6 配置更复杂，可能导致安全配置不当。
★★★☆☆ 三方引入的应用和自研应用评估差异有哪些？
- 自研应用：可掌控源代码，风险评估更为全面。
- 三方应用：对外部应用的理解和控制有限，主要依赖于第三方的安全性和合规性。
- 风险识别：三方应用需重点识别集成点、接口风险及依赖库的安全性。
★★★☆☆ 金融业务有何特色？
- 合规性要求高：必须遵循严格的金融法规和标准。
- 风险容忍度低：金融业务对安全风险的容忍度极低，任何漏洞可能导致重大损失。
- 数据敏感性：处理大量的敏感数据，包括个人信息和交易数据，需加强保护。
★★★☆☆ mvn 源的安全性需要考虑哪些点？
- 依赖安全性：确认依赖库的安全性，避免使用有漏洞的库。
- 私有仓库：使用私有仓库存放敏感项目，减少外部依赖。
- 版本控制：确保使用的库版本是安全的，定期检查并更新。
★★★☆☆ 如何让业务方主动找你评估？
- 定期安全培训：开展安全意识培训，提高业务方的安全意识。
- 成功案例分享：分享之前评估后的成功案例，展示评估的价值。
- 建立沟通渠道：与业务方保持良好沟通，主动关注他们的需求和风险。
★★★☆☆ 如何判断评估覆盖范围的优先级？
- 资产重要性：优先评估对业务至关重要的系统和资产。
- 漏洞历史：根据历史漏洞数据，优先评估易受攻击的组件。
- 业务影响评估：根据业务影响程度划分优先级，优先处理对业务影响大的风险。
★★★☆☆ 如何降低各人检验导致评估不一致？
- 标准化流程：制定统一的评估标准和流程，确保每个评估人员遵循相同的规则。
- 定期审查：定期审查评估结果，比较不同评估人员的结果，发现偏差并进行调整。
- 团队协作：强调团队协作与分享，确保信息的共享与透明。
★★★☆☆ 如何系统提高安全评估效率？
- 自动化工具：利用自动化工具进行初步扫描和评估，减少人工工作量。
- 模板与文档：建立标准化的评估模板和文档，提高评估一致性和效率。
- 培训与知识分享：定期进行团队培训，分享最新的安全知识和评估经验。
★★★☆☆ 安全评估和人工测试以及自动化测试三者差异是什么？
- 安全评估：总体评估安全态势，识别风险，制定策略。
- 人工测试：基于专业知识和经验进行深度测试，发现复杂漏洞。
- 自动化测试：使用工具快速扫描，检测常见漏洞，效率高但可能漏掉复杂问题。
★★★☆☆ 算法模型的安全风险如何评估？
- 数据隐私：确保训练数据不泄露用户隐私。
- 模型攻击：评估模型是否容易受到对抗性攻击。
- 可解释性：确保模型的决策过程可解释，避免黑箱风险。
扫一扫
872
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
