问题分析：

1. 部署环境的安全加固：部署三方软件前，需先对承载软件的基础环境（如操作系统、数据库、服务器）进行安全加固，为软件提供安全的运行基础。操作包括为操作系统、数据库安装最新安全补丁，关闭无需使用的端口和服务（如 unused 的 FTP 服务、Telnet 服务），并通过防火墙划分隔离区域，将三方软件所在环境与核心业务系统（如用户数据库、交易系统）隔离开。
2. 部署过程的安全配置：部署三方软件时，需按“最小权限、最小暴露”原则配置软件参数，避免因配置不当产生安全漏洞。具体需为软件分配最小必要权限（如仅授予访问特定数据的权限，不赋予服务器管理员权限），关闭软件默认开启的非必要功能（如默认的调试模式、匿名访问功能），对软件的敏感配置信息（如数据库连接密码、API 密钥）进行加密存储，不使用明文形式写入配置文件，同时禁用软件默认账号或修改默认密码（如默认的 admin 账号需立即更换为强密码）。

面试回答：

1. 部署环境的安全加固：给系统、数据库打最新补丁，关无用端口服务；用防火墙隔离三方软件与核心业务系统。
2. 部署过程的安全配置：给软件最小权限，关默认非必要功能（如调试、匿名访问）；加密存敏感信息（密码、密钥），改默认账号密码。

Maven源的安全性需要考虑哪些点？

问题分析：

1. 源的官方性与可信度：选择 Maven源时，应优先使用Maven中央仓库等官方源，或行业内知名、长期稳定运行的第三方源，非官方或小众源可能被恶意注入有害代码、替换正常依赖包，导致项目引入病毒、木马等安全隐患，比如运行时出现数据泄露或功能异常。
2. 依赖包的完整性校验：需确认 Maven源支持依赖包的完整性校验机制，比如通过校验和或数字签名验证，下载依赖包后会自动比对校验信息，确保下载的包与源上存储的一致，未被中途篡改，防止黑客修改包内容后植入恶意程序。

相关知识：

1. “Maven”：Java项目的“工具管家”

比如你要做一个Java项目（像一个APP、一个网站后台），不可能所有代码都自己写——比如需要“处理支付”“连接数据库”“发验证码”的功能，这些都有现成的“代码模块”（行业里叫“依赖”，就像手机APP需要的“插件”）。

而Maven（mvn）的核心作用就是：帮你自动从网上下载这些“依赖”，并把它们整理好，让你的项目能直接用，不用自己手动找、手动装。

2. “Maven源”：Maven的“依赖商店”

既然Maven要下载“依赖”，那这些“依赖”存在哪里呢？答案就是“mvn源”——你可以把它类比成手机的“应用商店”（比如华为应用市场、苹果App Store）。

• 官方默认的“mvn源”在国外（比如Apache官方源），下载速度慢；
• 国内程序员常用“国内mvn源”（比如阿里云、华为云、网易的mvn源），速度快；
• 有些公司还会建“私有mvn源”（相当于公司内部的“专属应用商店”），只供公司内部项目用，里面是经过筛选的依赖。

3. 问题的本质：“依赖商店”会不会有坑？

“mvn源的安全性”，本质就是问：你从这个“依赖商店”里下载的“代码模块（依赖）”，会不会有问题？会不会给你的项目埋雷？

比如：

• 商店里的“依赖”被人动过手脚（加了病毒、后门），你下载后，项目就被黑客控制了；
• 你想下A依赖，结果商店给你发了个假的A依赖（里面有恶意代码）；
• 甚至你连“商店”本身都是假的（不是官方/可信的源），里面全是有问题的依赖。

面试回答：

1. 选靠谱的源：优先用 Maven 中央仓库这类官方源，或者知名、稳定的第三方源，小众非官方源可能被加恶意代码、换正常包，让项目出安全问题。
2. 校验包完整：确认源能校验依赖包，防止黑客植恶意程序。

如何识别依赖的三方组件（jar/pip/npm包） 的后门 、投毒？

问题分析：

1. 组件来源可信度验证:优先从官方仓库（如Maven Central、PyPI、npm registry）下载组件，并检查发布者认证状态（如npm的2FA标识），避免使用来源不明的镜像站或未经验证的第三方源。同时扫描组件依赖树，递归检测所有间接依赖项是否包含已知恶意包（如通过OWASP Dependency-Check工具）。
2. 静态代码特征分析:使用静态扫描工具（如Snyk、CodeQL）检查组件代码中的危险模式。重点检测高风险行为：包含加密矿机代码（如coinminer相关字符串）、硬编码密钥或密码、敏感系统调用（如Runtime.exec()）、隐蔽网络通信（如连接非常规域名）。
3. 动态行为监控与沙箱测试:在隔离沙箱（如Docker容器）中运行组件，监控其运行时行为。捕获异常活动：未声明的网络请求（特别是到恶意IP的链接）、文件系统篡改（如修改/etc/passwd）、进程注入尝试或异常权限申请（如安卓组件的REQUEST_INSTALL_PACKAGES权限）。工具如Wireshark抓包分析或strace跟踪系统调用。

相关知识：

1. 检测加密矿机代码：

你下载了一个“前端图表组件”，用 Snyk 工具扫描后，发现代码里有“coinminer”（矿机相关）的字符串，还有循环计算哈希值的代码——这说明组件里藏了矿机程序，一旦用在项目里，用户打开网页时，电脑CPU会被占满，用来给黑客挖矿，用户体验会极差，还可能引发投诉。

2. 检测硬编码密钥或密码：

你用了一个“数据库连接组件”，用 CodeQL 扫描后，发现代码里写着“db_password=123456”（直接把数据库密码写死）——如果这个组件被公开，任何开发者都能看到这个密码，轻松登录你的数据库，偷走所有数据。

3. 检测敏感系统调用：

一个“文件处理组件”里有Runtime.exec(cmd)的代码，且cmd参数能被外部控制——黑客可以构造一个“删除服务器所有文件”的命令，通过这个组件执行，直接把你的服务器数据删光。静态扫描工具会识别出这种敏感调用，提醒你“这个组件有风险，可能被黑客利用”。

4. 检测隐蔽网络通信：

你用了一个“日志收集组件”，扫描后发现它会在后台连接“xx.hacker.com”这个非常规域名，还会发送服务器的IP、用户名等信息——这说明组件在偷偷给黑客传数据，会导致你的服务器信息泄露，甚至被黑客定位攻击。

5. 对混淆/加壳代码反编译复审：

一个组件的代码全是“a、b、c”这种无意义的变量名，逻辑绕来绕去（混淆代码），或者需要密码才能解压（加壳）——这时候静态工具可能没法直接分析，需要先“反编译”（拆开黑布），把代码还原成能看懂的样子，再人工逐行检查，看里面是不是藏了恶意功能（比如矿机、窃密代码）。

面试回答：

1. 查组件来源：优先从官方仓库下，看发布者认证；不用不明来源的镜像站或源；用工具扫依赖树。
2. 分析代码特征：用Snyk等工具扫代码，查危险内容（加密矿机代码、硬编码密钥或密码、敏感系统调用、隐蔽网络通信）。
3. 监控运行行为：在沙箱（如Docker）里运行组件，看异常活动；用Wireshark抓包、strace跟踪系统调用。

OWASP Top 10问题：失效的访问控制，什么是失效的访问控制？其常见的表现形式有哪些？在渗透测试中如何检测此类问题，又该从哪些方面进行防范？

问题分析：

1. 什么是失效的访问控制

失效的访问控制是指应用程序在用户访问资源或使用功能时，未严格按照预设的权限规则进行校验，使得用户能够突破权限限制，访问到本不属于自己的信息、执行未被授权的操作。简单来说，就是用户本应只能看自己的内容、做自己权限内的事，却因访问控制机制失效，能查看他人数据、操作更高权限功能。

2. 常见的表现形式

1. 越权访问数据： 用户通过修改请求中的关键参数（如用户ID、订单ID），或直接访问未授权的URL，查看不属于自己的数据，例如普通用户查看其他用户的个人信息、订单详情，或未登录用户访问需要登录才能查看的页面。
2. 越权操作资源： 用户执行超出自身权限的操作，例如普通用户修改其他用户的账号信息、删除他人发布的内容，或低权限管理员执行高权限管理员才能进行的系统配置修改、数据删除操作。
3. 绕过访问控制检查： 用户通过删除请求中的权限验证相关参数、使用特定工具跳过前端权限校验，或利用应用程序漏洞（如未校验Referer头），绕过后端的访问控制逻辑，访问受限资源或功能。

3. 渗透测试中的检测方法

1. 功能点越权测试： 测试人员分别使用不同权限的账号（如普通用户、低权限管理员、高权限管理员）登录应用，尝试访问或操作其他权限账号的功能，例如用普通用户账号尝试访问管理员后台，或用A用户账号尝试修改B用户的个人信息，观察是否能成功执行。
2. 参数篡改测试： 测试人员通过抓包工具（如Burp Suite）捕获应用程序的请求包，修改其中的关键参数（如用户ID、角色ID、资源ID），将参数值改为其他用户或更高权限的标识，重新发送请求，观察服务器是否返回未授权的数据或执行未授权的操作。
3. 路径遍历测试： 测试人员尝试直接在浏览器地址栏输入可能的敏感路径（如后台管理地址、数据库备份文件路径、配置文件路径），或通过修改URL中的路径参数，访问应用程序未公开的、需要授权的页面或资源，检查是否能绕过权限校验直接访问。

4. 防范措施

1. 服务器端严格验证访问权限： 所有访问控制逻辑必须在服务器端实现并进行校验，不能仅依赖前端（如页面隐藏、JavaScript校验）进行权限控制，因为前端校验可被轻易绕过；每次用户请求资源或执行操作时，服务器都需重新校验用户身份、角色及权限，确认是否允许该操作。
2. 使用统一的访问控制机制： 应用程序应采用统一的访问控制框架或组件（如基于角色的访问控制RBAC框架），避免每个功能模块单独实现访问控制逻辑，减少因逻辑不一致或遗漏导致的漏洞；同时，确保访问控制规则的配置集中管理，便于维护和更新。
3. 严格校验请求参数： 对用户请求中的所有关键参数（如用户ID、资源ID、角色标识）进行严格校验，确认参数值与当前登录用户的权限匹配，例如用户请求查看订单时，服务器需校验请求中的订单ID是否属于该用户，避免仅依赖参数值返回数据。

相关知识：

未校验Referer头

定义：服务器没有检查请求的“来源页面”是否合法，导致攻击者能伪造请求绕开权限限制。

1. Referer头是什么？

Referer是HTTP请求中的一个核心字段，作用是告诉服务器“当前这个请求，是从哪个URL页面触发的”。

举例：

• 你在淘宝“商品详情页”（URL：https://detail.tmall.com/xxx）点击“加入购物车”，此时发送给服务器的“加购请求”里，Referer字段就会填“https://detail.tmall.com/xxx”。
• 服务器通过Referer能确认：这个加购请求是从合法的商品页来的，不是凭空伪造的。

2. 未校验的风险：攻击者能“伪造来源”

如果服务器不校验Referer头，就相当于失去了“确认请求来源合法性”的一道关卡，攻击者可以直接构造请求，跳过前端的权限入口。

比如一个典型场景：某网站“修改个人信息”的接口，正常需要从“我的账户页”（仅登录用户可见）进入并触发请求，Referer应为“https://xxx.com/my-account”。

若服务器不校验Referer：

1. 攻击者通过抓包找到“修改信息”的后端接口（比如https://xxx.com/api/update-user）。
2. 直接构造一个请求，目标是修改他人的信息，且不填Referer，或随便填一个无关URL。
3. 服务器因为没校验Referer，误以为这个请求是从合法的“我的账户页”来的，直接执行修改操作，最终导致越权。

3. 关键影响：绕开“前端权限入口”

未校验Referer头的漏洞，本质是让攻击者绕过了“前端必须从特定有权限页面进入”的限制。

很多网站会在前端做权限控制（比如没登录就不显示“修改信息”按钮），但后端如果不通过Referer二次校验，攻击者只要知道接口地址，就能直接跳过前端限制，发起非法请求。

4. 简单防范方向

• 服务器明确校验：要求请求的Referer必须是自己网站内的、合法的权限页面URL（比如只能是“我的账户页”“订单详情页”等）。
• 拒绝异常Referer：对Referer为空、或来自其他外部网站的请求，直接拒绝处理。

RBAC（基于角色的访问控制）框架

1. 每个功能模块单独实现是什么样？

比如一个电商系统有3个核心功能，开发时如果“单独实现访问控制”，会是这样：

• 订单查询模块：开发A自己写代码，判断“当前用户ID是否等于订单的创建者ID”，否则不让看。
• 用户信息修改模块：开发B自己写代码，判断“当前用户是否是管理员（角色ID=1）”，否则不让改。
• 商品删除模块：开发C自己写代码，判断“当前用户是否有‘商品管理’权限标签（tag=goods_admin）”，否则不让删。

3个模块各有各的权限判断逻辑、代码位置和校验规则，彼此独立。

2. 为什么这种方式会导致“逻辑不一致”和“漏洞”？

（1）逻辑不一致：规则混乱，攻击者可钻空子

不同模块的权限规则不统一，会出现“有的严、有的松”的情况，攻击者能利用规则差异绕过限制。

• 例子1：订单模块认“用户ID匹配”，但商品模块认“权限标签”。如果一个普通用户没有“商品管理”标签，但通过抓包修改请求，用“订单模块的判断逻辑”去访问商品删除接口，就可能绕过校验。
• 例子2：A模块判断“管理员”是“角色ID=1”，B模块判断“管理员”是“角色ID=1且部门ID=0”。此时一个角色ID=1但部门ID=1的用户，能绕过B模块的校验（通过A模块），执行本不该有的操作。

（2）容易遗漏：新增/修改功能时，忘了加权限校验

每个功能都要手动写校验代码，只要开发时稍有疏忽，就会出现“没设防”的漏洞。

• 例子1：新增“优惠券批量发放”功能时，开发专注于实现发放逻辑，忘了加“只有运营角色能操作”的校验，导致普通用户也能调用接口发优惠券。
• 例子2：修改“订单退款”功能时，不小心把原来的“仅商家/管理员可操作”的校验代码删掉了，变成所有用户都能给任意订单退款。

3. 统一访问控制机制如何解决这些问题？

用RBAC（基于角色的访问控制）框架，所有模块都用同一套规则和代码：

• 第一步：提前在框架里定义好统一规则，比如“管理员角色（ID=1）可执行所有操作”“普通用户只能操作自己的资源”。
• 第二步：所有模块（订单、用户、商品）不再自己写校验代码，而是统一调用框架的接口，比如checkPermission(当前用户ID, 要执行的操作)。
• 结果：不管是新增功能，还是修改旧功能，只要调用这个接口就行。规则只在框架里定义一次，所有模块都遵守同一套逻辑，既不会乱，也不会漏。

面试回答：

失效的访问控制： 没按权限规则校验用户访问，让用户突破限制，比如普通用户看别人信息、操作高权限功能，本只能干自己权限内的事，结果越界了。

1. 常见表现：
   1. 越权访问数据
   2. 越权操作资源
   3. 绕过访问控制检查
2. 渗透测试检测：
   1. 功能点越权测试：用不同权限账号登录，试访问其他权限功能，比如普通用户进管理员后台。
   2. 参数篡改测试：用Burp Suite抓包，改用户ID、角色ID等关键参数，重发请求，看是否返回未授权数据。
   3. 路径遍历测试：输敏感路径（后台地址、备份文件路径），看能否绕权限访问未公开页面。
3. 防范措施：
   1. 服务器端严验权限：服务器端实现，每次请求都校验用户身份、角色和权限，别只靠前端校验。
   2. 用统一访问控制机制：用RBAC等统一框架，集中管理控制规则，避免各模块单独实现，减少漏洞。
   3. 严校请求参数：校验用户ID、资源ID等参数，比如查订单时，确认订单ID属于当前用户，不盲目按参数返回数据。

OWASP Top 10问题：常见的导致加密机制失效的情况（如算法过时、密钥管理不当等）有哪些？如何检测系统是否存在加密机制失效问题，以及如何修复和防范？

问题分析：

常见的导致加密机制失效的情况

1. 传输层加密配置缺陷： 数据传输过程中加密配置不当，例如网站同时支持HTTP和HTTPS但未强制跳转至HTTPS，HTTPS使用过时的TLS 1.0/1.1协议或不安全的加密套件，或客户端调用HTTPS接口时跳过证书合法性校验（易遭受中间人攻击）。
2. 密钥管理不当： 密钥的生成、存储、分发和轮换过程存在漏洞，例如生成的密钥过于简单（如“123456”）、将密钥硬编码在代码或配置文件中（易被反编译获取）、密钥长期不轮换、密钥泄露后未及时撤销，或多个系统共用同一密钥导致一损俱损。
3. 加密实现逻辑错误： 加密相关的代码或配置存在缺陷，例如随机数生成器不安全导致密钥可预测、加密时初始化向量（IV）固定或重复、解密后未校验数据完整性（导致篡改后的数据被正常解析），或调用加密库时错误配置参数导致加密失效。

检测系统是否存在加密机制失效问题

1. 传输层加密检测： 测试人员使用抓包工具（如Burp Suite）捕获应用程序的网络请求，检查数据传输是否使用HTTPS协议，同时通过工具（如Nessus）扫描HTTPS配置，查看是否使用过时协议、弱加密套件或存在证书过期、自签名等问题。
2. 存储数据加密检测： 测试人员通过数据库查询、配置文件读取等方式，检查存储的敏感数据是否加密，例如查看用户密码字段是否为哈希值（而非明文），信用卡号等数据是否经过加密处理；同时验证哈希算法强度，判断是否为bcrypt、Argon2等强哈希算法。
3. 算法与密钥安全性检测： 借助自动化工具（如CryptoAudit）扫描应用程序使用的加密算法，识别是否存在过时或弱算法；通过代码审计（如使用Fortify SCA）检查代码中是否硬编码密钥，或通过渗透测试尝试暴力破解弱密钥，验证密钥安全性。

修复和防范加密机制失效问题

1. 强制敏感数据加密： 明确界定敏感数据范围（如身份信息、支付数据、登录凭据等），确保所有敏感数据在存储和传输前必须加密，禁止任何场景下的明文存储和传输，即使是内部系统间的数据交互也需加密。
2. 选用强加密算法与协议： 采用经过安全验证的现代加密算法，例如用AES-256-GCM模式加密传输和存储数据，用bcrypt、Argon2或PBKDF2（带足够迭代次数）哈希算法存储密码；传输层强制使用TLS 1.2及以上协议，配置安全的加密套件。
3. 规范密钥全生命周期管理： 使用专门的密钥管理系统（KMS）生成、存储和分发密钥，避免硬编码或明文存储；密钥需设置足够长度并定期轮换（如每90天一次），建立密钥泄露后的紧急撤销机制，不同系统或场景使用独立密钥。

相关知识：

一、加密时初始化向量（IV）固定或重复

初始化向量（IV）是对称加密算法（比如AES）里的关键参数，它和密钥配合使用，作用是：让“相同的明文”每次加密后生成“不同的密文”。

• IV必须是随机的、不重复的（每次加密都用新的IV），且不需要保密（可以和密文一起传输）。
• 如果IV固定或重复，会导致“相同明文加密出相同密文”，攻击者能通过对比密文规律，反推出明文或密钥，让加密失去意义。

最典型的是早期WiFi加密（WPA协议）的漏洞：

• 很多路由器默认配置里，AES加密的IV是固定的，或者生成IV时不够随机，导致重复。
• 攻击者只要收集足够多的WiFi数据包（里面有重复IV对应的密文），就能通过工具（比如Aircrack-ng）分析密文规律，最终破解WiFi的密码（密钥），免费蹭网甚至窃取网络里的信息。

二、解密后未校验数据完整性（导致篡改后的数据被正常解析）

参考知识点第12题：密码如何加密保存？

数据完整性校验是加密流程的“最后一道防线”，作用是：确认解密后的数据，和加密前的“原始明文”完全一致，没有被人篡改过。

• 常用的校验方式是哈希值（如SHA-256） 或消息认证码（MAC） ——加密时，会把明文的“校验值”一起加密；解密时，先验证解密后数据的校验值，和原始校验值是否一致。
• 如果不校验，攻击者可以篡改加密后的密文（比如改转账金额、改订单信息），解密后系统会直接解析篡改后的数据，造成损失。

三、调用加密库时错误配置参数导致加密失效

开发时不会自己写加密算法，而是用成熟的“加密库”（比如OpenSSL、BouncyCastle），但需要正确配置参数才能生效。常见的错误配置包括：

• 选了不安全的加密算法（比如DES，密钥太短易破解）；
• 选了错误的加密模式（比如AES用ECB模式，相同明文会出相同密文，和IV固定同理）；
• 密钥长度不够（比如AES要求密钥128/256位，却配成64位）；
• 没启用“加盐”（盐值是和IV类似的随机值，用于密码哈希，没加盐会让彩虹表破解更简单）。

这些错误会让加密变成“假加密”，看似有密文，实则攻击者能轻松破解。

某社交APP的用户密码加密漏洞：

• 开发时用OpenSSL库给用户密码加密，本该配置“SHA-256哈希算法+随机盐值”（安全的配置）；
• 实际配置时，误把算法改成了“MD5哈希算法”（不安全，易被彩虹表破解），还忘了加“盐值”；
• 黑客拿到数据库后，用现成的MD5彩虹表（提前算好“明文→MD5密文”的对应表），几分钟就破解了大量用户的密码，导致账号被盗。

面试回答：

1. 常见失效情况：
   1. 传输层加密缺陷：没强制跳HTTPS、用过时TLS 1.0/1.1、不安全加密套件，或客户端跳过HTTPS证书校验（易遭中间人攻击）。
   2. 密钥管理不当：密钥太简单（如123456）、硬编码在代码里（易被获取）、长期不换、泄露不撤销，或多系统共用同一密钥。
   3. 加密逻辑错误：随机数生成器不安全（密钥可预测）、加密初始化向量（IV）固定、解密后不验数据完整性，或加密库参数配错。
2. 检测方法：
   1. 传输层检测：用Burp Suite抓包查是否用HTTPS，Nessus扫HTTPS配置（看协议、加密套件、证书是否有问题）。
   2. 存储数据检测：查数据库、配置文件，看敏感数据是否加密（如密码是否为哈希值），验证哈希算法是否是bcrypt等强算法。
   3. 算法与密钥检测：扫描弱加密算法，审计代码查硬编码密钥，或暴力破解弱密钥。
3. 修复防范：
   1. 强制敏感数据加密：明确敏感数据范围，存储和传输前必加密，禁止明文交互。
   2. 用强加密算法与协议：AES-256-GCM加密数据，bcrypt/Argon2哈希存密码；传输强制TLS 1.2+和安全加密套件。
   3. 规范密钥管理：用KMS生成存储密钥，避免硬编码；密钥定期轮换（如90天），泄露后紧急撤销，不同系统用独立密钥。

解锁300+面试题如下图所示：

渗透测试（待解锁🔓）

协议漏洞（待解锁🔓）

算法安全（待解锁🔓）

安全扫描器（待解锁🔓）

前端/移动端安全（待解锁🔓）

基础设施安全（待解锁🔓）

威胁感知与响应（待解锁🔓）

安全开发（待解锁🔓）

安全管理（待解锁🔓）

数据安全（待解锁🔓）

安全合规与审计（待解锁🔓）

网络安全面经前线（大厂面试题全解）

安全运营（待解锁🔓）

渗透测试（待解锁🔓）

基础设施安全（待解锁🔓）

代码审计（待解锁🔓）

威胁感知与响应（待解锁🔓）

安全开发（待解锁🔓）