企业内部安全漏洞修复流程的建立与思考（其三）

3.漏洞修复具体方案

3.1补丁修复

笔者这里主要接触到的漏洞修复方案主要是涉及补丁修复、代码修复和提高相关网络措施或其他进行调整。（组件替代和系统关停、下线笔者这里认为偏向于业务侧或监管侧，并非是漏洞修复方面的主要职责），主要注意如下情况：

1.升级包/补丁包等的来源安全性

2.升级/补丁之后的兼容性（包括技术上的兼容和业务上的无感知）

3.是否为正常渠道获取的补丁（涉及到维保、合规等）

4.升级/补丁安装后是否能真正意义上的修复漏洞

针对这几点其实其他修复方案也有或多或少的涉及，后续在注意事项中分析。

3.2 代码修复

代码修复一般主要针对逻辑类漏洞，如暴力破解、越权等，这类主要是由开发部门进行评估修复，这里主要是涉及到一些采购、漏洞修复情况、业务影响等，主要如下：

1.在修复逻辑漏洞时，需要采购额外的组件，如短信验证码、滑块验证码、认证机制等，需要进行采购、适配等，这个时候的修复周期会较长。

2.修复时需要确定是否修复成功（举例：sql注入时，不单单是过滤等，业务允许的情况下还需要进行预编译），这个时候需要开发人员针对漏洞的修复有前瞻性，并且要和安全部门的人员保持好有效的修复沟通机制。

3.逻辑漏洞修复后是否会对业务造成影响，是否对业务无感知。

这里附一下逻辑漏洞的修复方案。

越权漏洞越权漏洞是指应用在检查授权时存在缺陷，使得攻击者可以绕过权限检查，访问或操作原本无权访问的高权限功能。修复这类漏洞的方法是对用户操作进行权限校验，防止通过修改参数进入未授权页面及进行非法操作。服务端应对请求的数据和当前用户身份做校验检查支付逻辑漏洞支付逻辑漏洞包括负值反冲、正负值对冲等。例如，如果程序没有校验订单的取值范围，使用负值则可以进行支付逻辑利用。修复方法包括服务器端在生成交易订单时，从数据库中取出商品的价格，禁止使用客户端发送的商品价格。同时，服务器端在生成支付订单时，对支付订单中影响支付金额的所有因素进行签名，校验客户端提交的支付订单短信炸弹短信炸弹是由于没有进行时间戳等校验，导致短时间内可以重复发送大量的短信校验码。修复方法是短信平台对同一手机号进行识别，一定时间内不允许继续发送验证短信请求未授权访问未授权访问漏洞是在攻击者未授权的情况下，不需要输入密码，即可通过直接输入网站控制台主页面地址访问。修复方法是在系统中加入用户身份认证机制或者token验证，防止可被直接通过连接就可访问到用户的功能进行操作用户名枚举用户名枚举是在登录时，输入不存在的用户名和错误的密码，若提示“该用户并不存在”，则证明该漏洞存在。修复方法是统一所有的提示信息为“用户名或密码错误”验证码问题验证码问题包括图形验证码使用过一次未立即失效、短信验证码可预测、短信验证码绕过等。修复方法是使用过一次验证码后，立即注销，不要将验证码返回，删除特权码，不仅仅对code返回值进行校验登录认证绕过登录认证绕过通常存在于仅适用前端校验，可以通过关闭js特效或者是伪造response的code值进行绕过。修复建议是不使用前端校验，严格校验用户的数据密码重置漏洞密码重置漏洞是在得知他人的手机号码时，通过修改response返回值欺骗服务器进行重置密码。修复建议是正确的校验验证码，不要使用前端校验SSO认证缺陷SSO认证存在缺陷，可越权登录他人账户。修复建议是正确的配置用户的权限信息，不要使用简单的cookie或session空口令漏洞空口令漏洞是在不使用密码直接登录成功的情况下存在的。修复建议是判断输入密码是否为空，禁止空口令登录会话固定会话固定是在用户进入登录页面，但还未登录时，就已经产生了一个session，用户登录后，session的id不会改变。修复方式是在用户提供的认证信息发生变化时，服务器端应重新生成SessionID，并强制失效之前的会话会话重用会话重用是用户退出系统后，服务器端Session未失效，攻击者可利用此Session向服务器继续发送服务请求。修复方式是用户退出系统后，服务器端应清空此用户的Session信息重放攻击重放攻击是关键业务操作未作token或者唯一标识码，导致攻击者可以重复多次进行请求，导致恶意操作。修复方式是服务端应用程序应检查客户端提交的数据的唯一性，如使用流水号、时间戳、token等，并将流水号、时间戳等进行签名

3.3 临时规避措施

在很多时候，比如单位有关于漏洞处置有时间要求的情况下（高危一天、中危五天等），具体操作时可能存在滞后性，这个时候更多的是增加临时规避措施，例如增加WAF规则、配置调整等。

最常见的就是通过WAF、EDR、HIDS这些可以进行拦截的安全设备，进行相关策略的添加，例如关键字、可疑路径、相关特征值等，但是在添加时需要注意。

1.相关网络设备的过略/防护的支持力度是否有那么高

2.是否会对正常的业务造成影响

3.规则是否生效

3.4 注意事项

针对上述三点修复时，具体实施时需要注意如下事项。

1.首先，相关升级/补丁包在进入测试环境、生产环境时要进行严格的管控，说明相关的来源（最好是官方或者维保合同要求）、文件md5值、文件查杀情况，最好可以的话附上相关沙箱报告，确保补丁文件的安全可控。

2.在涉及到具体修复时，无论是逻辑漏洞，还是组件漏洞，在修复之前，一定要评估漏洞影响性，是否会对系统或环境造成巨大影响（例如：jdk版本升级、mysql替代等），在该类漏洞修复时，就需要额外的流程，针对开发部门、安全部门、运维部门等进行交流、沟通，对升级/修复方案进行评审，做预案，同时联系业务侧，在测试环境进行严格的业务测试（注：业务测试相关细节在其五中阐述）。

3.漏洞修复完成后，需要进行复测，根据单位的现有环境，由安全部门牵头，对修复的组件、系统、服务器进行验证，验证是否修复漏洞、组件版本是否升级，做好相关台账和记录，后续在上生产环境时，需要安全部门针对修复的漏洞进行一定程度的背书。

4.在涉及到漏洞修复可能会对业务造成影响时（举例：jdk版本升级、mysql替代等），笔者觉得，应该以技术部门的视角进行看待，技术部门（包括开发、运维和安全）应保持相关的底线，即解决事情的角度进行分析，相关讨论会时，做好预案，最好不要把这个漏洞修不修的权利交由业务部门，这样很多漏洞尤其是重要漏洞的修复无法推进下去，当然，这要看具体部门的领导的态度。

5.临时规避措施这块，需要对设备定期巡检，一些WAF、防火墙的封禁策略有极限（比如上限一万条），这个时候需要定期清理已修复的安全规则等，做好设备规则库可用的冗余。

原文始发于微信公众号（云下信安）：企业内部安全漏洞修复流程的建立与思考（其三）