网络安全面试八股文（第5期）

原创于 2025-12-05 14:55:35 发布 · 329 阅读

4 ·

CC 4.0 BY-SA版权

文章标签：

#web安全 #面试 #安全 #网络安全 #职场和发展 #系统安全 #计算机网络

网安面经专栏收录该内容

6 篇文章

订阅专栏

GitHub等三方泄漏敏感信息如何防御

问题分析：

严格访问控制与权限管理：使用私有仓库限制非授权访问，通过角色分配和访问控制列表（ACL）细化权限，仅授予必要用户对特定分支或文件的操作权限，避免敏感信息被意外或恶意提交。
启用自动化检测与防护机制：部署推送保护（Push Protection）功能，自动扫描并阻止包含API密钥、密码等敏感信息的提交；集成静态代码分析工具（如SecretFinder、GitHub Advanced Security）实时识别代码中的敏感内容。
规范敏感数据存储方式：禁止在代码中硬编码密钥或凭证，改用专用密钥管理服务（如Vault、AWS Secrets Manager）进行加密存储，运行时从安全后端动态获取密钥，通过.gitignore文件排除敏感配置文件的提交。

相关知识：

专用密钥管理服务（动态获取密钥）

把密钥或密码直接写在代码里很危险，就像把家门钥匙贴在门上，一旦代码泄露，别人就能直接拿到。所以应该把这些敏感信息单独存起来，用专门的密钥管理服务（比如Vault、AWS Secrets Manager），这些服务就像更高级的保险柜，不仅能加密保存密钥，还能控制谁可以访问、记录使用痕迹，程序运行时再从这个“保险柜”里安全地取出来用，这样即使代码被看到，也不会暴露真正的密钥。

面试回答：

仓库要私有，推送先扫描，密钥不落地

仓库要私有：用私有仓库+权限控制，防止未授权访问。
推送先扫描：提交时自动检测，拦截密钥等敏感信息。
密钥不落地：密钥存专用服务，运行时动态获取，不进代码库。

业务逻辑漏洞如何通过技术手段避免写出来？

问题分析：

强化业务流程设计与威胁建模：在系统设计阶段明确核心业务规则，通过文档化流程和威胁建模识别潜在逻辑风险，例如支付流程中强制校验订单状态、库存扣减顺序，避免因设计疏漏导致越权操作或重复支付漏洞。
实施严格的输入验证与状态控制：对所有用户输入（如价格、数量、用户ID）进行后端校验，结合白名单过滤和污点分析技术，确保参数符合业务规则；通过服务端Session或数据库记录操作状态，防止跳过关键步骤（如未付款直接提交订单）。
规范权限校验与最小权限原则：强制在服务端实现基于角色的访问控制（RBAC），避免依赖前端参数（如用户角色字段）判断权限；对敏感操作（如删除账户）增加二次验证（如短信验证码或双因素认证）。

业务逻辑漏洞的核心在于设计和控制缺失，因此设计防漏洞是源头防控，能提前发现规则缺陷；输入严把关确保关键操作不被绕过，防止攻击者篡改流程；权限服务端则杜绝因权限判断不当导致的越权行为。这三条覆盖了设计、执行和访问控制三大关键环节，构成了防范业务逻辑漏洞的基础防线。

相关知识：

白名单过滤和污点分析技术

白名单过滤就像只允许名单上的人进门，系统只接受预先定义好的合法输入，其他一概拒绝；污点分析则是给用户输入的数据打上“可疑”标签，追踪它会不会跑到执行命令或查询数据库的地方去，防止恶意数据引发安全问题。

在服务端做权限控制

强制在服务端做权限控制，意思是不能相信前端传来的“我是管理员”这类信息，必须由服务器自己查数据库或会话来确认用户真实身份和角色，因为前端数据容易被黑客篡改，只有服务端的判断才是可信的。

面试回答：

口诀：设计防漏洞，输入严把关，权限服务端

设计防漏洞：提前做威胁建模，规范业务流程，堵住逻辑缺陷。
输入严把关：后端校验所有参数，用白名单和状态记录防篡改。
权限服务端：权限判断放在服务端，不信任客户端传来的角色信息，关键操作加二次验证。

软件供应链后门和漏洞如何系统规避

问题分析：

生成并维护软件物料清单（SBOM）：通过SBOM记录软件的组件构成及依赖关系，确保对供应链的深度可见性。例如，使用工具如Snyk或Black Duck自动生成SBOM，并定期更新以追踪新引入的组件和漏洞。
安全左移：在开发早期阶段（需求分析、设计）介入安全管控，例如要求开发人员仅从可信源获取组件（如官方仓库），并通过CI/CD流水线集成漏洞扫描工具（如OWASP ZAP），阻止存在已知漏洞的代码进入构建流程。
持续监控与快速修复：通过自动化工具（如GitHub Dependabot）实时监测依赖库的漏洞公告，结合补丁管理策略（如自动下载安全更新），确保漏洞修复在攻击发生前完成。对于零日漏洞，则依赖威胁情报平台（如MITRE ATT&CK）进行预警。

生成并维护软件物料清单（SBOM）是基础，只有清楚掌握软件由哪些组件构成，才能有效管理依赖风险；左移安全实践将安全控制前置到开发早期，从源头阻止漏洞进入代码，是成本最低、效果最好的防护；持续监控与快速修复则确保在漏洞暴露后能第一时间发现并响应，尤其对零日漏洞至关重要。这三条覆盖了可见性、预防和响应三大核心能力，构成了软件供应链安全的支柱。

面试回答：

口诀：SBOM，安全左移，持续监控

SBOM：生成SBOM记录软件的组件构成及依赖关系，做到供应链透明。
安全左移：在开发早期引入安全管控。
持续监控：持续跟踪依赖漏洞，自动预警和修复，响应快于攻击。

为什么Session ID要和设备关联绑定？

问题分析：

防止跨设备滥用Session ID：若Session ID未与设备绑定，攻击者可通过窃取Session ID（例如通过XSS攻击或中间人攻击）直接在其他设备或平台上冒用用户身份。例如，用户在APP端登录后，攻击者在PC端使用同一Session ID发起请求，若系统未校验设备信息，攻击者可绕过身份验证直接操作账户。
异常可追踪：设备绑定信息可作为会话状态的一部分存储在服务器端（如Redis或数据库），便于在检测到异常行为时快速终止会话。例如，若系统发现同一Session ID同时在多个设备上活跃，可判定为风险行为并强制用户重新认证，进一步保障账户安全。

第1条是核心目标，通过限制Session ID只能在特定设备使用，从根本上防范会话劫持；第2条则增强了系统的主动防御能力，使服务器能基于设备信息进行实时风险识别与响应，如发现异常登录时及时终止会话，进一步保障账户安全。

相关知识：

Session ID

Session ID 是服务器为了识别用户身份而生成的一段唯一字符串。当用户登录系统后，服务器会创建一个 Session ID 并发送给客户端，客户端在后续请求中携带这个 ID，服务器通过它来确认用户已经登录，并维持用户的会话状态。

XSS攻击

XSS攻击是指攻击者将恶意的 JavaScript 代码注入到网页中，当其他用户浏览该页面时，浏览器会执行这段代码。这种攻击可以窃取用户的 Cookie、Session ID 或者在用户不知情的情况下执行操作，比如发送请求或跳转到恶意网站。

中间人攻击

中间人攻击是指攻击者在网络通信过程中插入自己，使得客户端和服务器之间的数据流经过攻击者控制的设备。攻击者可以借此监听、篡改或截取传输中的信息，例如获取登录凭证或注入恶意内容，从而实现身份冒用或数据窃取。

面试回答：

口诀：一码一设备，异常可追踪

一码一设备：Session ID与设备绑定，防止被盗后在其他设备滥用。
异常可追踪：服务器记录设备信息，发现多端登录等异常可及时拦截处置。

为什么要求小程序的Session ID不能在其他平台上使用？

问题分析：

防止会话劫持：防止被拿到其他平台冒用，避免身份劫持。 举例：用户在小程序登录后，攻击者若获取其Session ID，可能在PC端或APP端使用该ID发起请求，绕过原平台的额外验证（如验证码），导致敏感操作（如支付）被非法执行。
避免业务漏洞：防止利用规则差异绕过验证。举例：PC端支付需输入验证码，而移动端无需验证码。若Session ID跨平台可用，攻击者可将PC端的Session ID用于移动端，绕过验证码校验直接完成支付操作。这种漏洞可能导致业务逻辑被滥用，造成经济损失或数据泄露。

这两条虽然都涉及Session ID被滥用的问题，但本质不同。前者是身份验证机制的失效，后者是业务逻辑设计的不一致，两者关注的层面和风险类型不同。第一条的核心是身份冒用，强调攻击者获取Session ID后，在不同平台直接伪装成用户进行操作，重点在于跨平台的身份认证被绕过，导致会话劫持。第二条的核心是业务规则差异，强调不同平台的安全策略不一致，攻击者利用Session ID的通用性，选择安全较弱的平台执行操作，从而绕过较强的业务控制，如验证码。

面试回答：

口诀：防止会话劫持，避免业务漏洞