从三类常见高危漏洞 洞见那些“风平浪静”的代码

这里的问题是：程序没有对读取自用户的 backuptype 参数做任何验证。通常情况下 Runtime.exec() 函数不会执行多条命令，但在这种情况下，程序会首先运行 cmd.exe shell，从而可以通过调用一次 Runtime.exec() 来执行多条命令。一旦调用了该 shell，它即会允许执行用两个与号分隔的多条命令。如果攻击者传递了一个形式为 "&& del c:dbms*.*" 的字符串，那么应用程序将随程序指定的其他命令一起执行此命令。由于该应用程序的特性，运行该应用程序需要具备与数据库进行交互所需的权限，这就意味着攻击者注入的任何命令都将通过这些权限得以运行。

为防止任意命令执行漏洞，应当禁止用户直接控制由程序执行的命令。在用户的输入会影响命令执行的情况下，应将用户输入限制为从预定的安全命令集合中进行选择。如果输入中出现了恶意的内容，传递到命令执行函数的值将默认从安全命令集合中选择，或者程序将拒绝执行任何命令。

有时还可以执行其他检验，以检查这些来源是否已被恶意篡改。例如，如果一个配置文件为可写，程序可能会拒绝运行。如果能够预先得知有关要执行的二进制代码的信息，程序就会进行检测，以检验这个二进制代码的合法性。如果一个二进制代码始终属于某个特定的用户，或者被指定了一组特定的访问权限，这些属性就会在执行二进制代码前通过程序进行检验。

四、总结&解决方案

上述三类安全漏洞，无一例外是在代码功能正常的前提下进行的，可见功能可用不代表安全可靠。而为解决这些问题，更多的是需要在研发过程中各环节介入安全能力，实现对上述各类漏洞的上线前检出以及修复，降低项目上线安全隐患。

企业应该将赋能服务贯穿需求分析、架构设计、研发、测试回归以及发布迭代全流程，通过赋能将专业安全能力赋予研发各环节人员，并在各环节提供不同工具(STAC、SAST、IAST、常态化安全运营)使赋能知识真实应用落地，最终以统一平台展示、分析、回归、闭环安全问题，并向安全部提供 SIEM，根据各流程频现的漏洞类型、研发人员知识盲区等再次提供针对性培训，最终针对性制定规章制度，实现制度精准逆推落地。

• 需求和架构阶段：基于业务场景的威胁建模 (STAC)，以威胁建模赋能方式教会需求分析和架构审计人员对项目内场景潜在场景风险进行识别和剥离，通过威胁建模针对性提出安全方案，用于后续研发等环节的解决或规避。
• 软件编码阶段：静态应用安全测试 (SAST)，通过与 git、svn 等代码仓库联动，自动化拉取全量或增量代码进行代码安全检查，以波谷时间检测方式在上班时间前根据提交历史以邮件形式同时相关责任人，降低对相关人员工作方式更改。
• 软件测试阶段：交互式安全测试 (IAST)，IAST 通过代理、VPN 或者服务端 Agent 方式无感知获取功能测试人员测试交互流量，基于模糊测试 (fuzz) 思想对流量进行攻击代码随机插入和攻击流量构建，并自动化对被测程序进行安全测试，同时可准确确定漏洞所在的代码文件、行数、函数及参数。
• 上线迭代阶段：常态化安全运营，对项目上线后所在的服务器资产、中间件以及项目本身进行 7*24 小时周期性安全检查，相当于有一个安全团队或渗透测试工程师全天候管理线上资产、站点以及中间依赖的安全问题，有效确保安全健壮性。

【本文是51CTO专栏作者“李少鹏”的原创文章，转载请通过安全牛（微信公众号id:gooann-sectv）获取授权】

戳这里，看该作者更多好文

（编辑：辽源站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!