光一样的少年|使用OWASP的AppSec入门( 二 )


因此 , 如果渗透测试发现漏洞 , 我们需要问自己为什么 , 并尝试解决导致该问题的根本原因 。 这是当我们从“测试安全性”转变为“设计安全性”的时候 。 为此 , 您将找到支持OWASP的静态应用程序安全测试(SAST)工具 , 例如静态代码分析 。
不只是DAST和SAST值得注意的一点是 , OWASPTop10中的A9项目与其余项目完全不同 , 并且不适合SAST或DAST , 因为它是在寻找开源中的已知漏洞 , 而不是寻找新漏洞 。
幸运的是 , OWASP为此提供了一个免费的工具OWASPDependencyCheck 。 该工具可识别项目依赖项并检查是否存在任何已知的、公开披露的漏洞 , 并可用于扫描应用程序及其依赖库以识别已知的易受攻击的组件 。
(如果您使用的是Parasoft , 我们实际上将OWASPDependencyCheck集成到了我们的报告系统中 , 并使其成为OWASPTop10仪表板的一部分 。 这使得通过扫描作为CI的常规部分来轻松处理开源组件中的问题 。 与SAST一起使用 , 并将结果与其他OWASP信息一起放入一个统一的仪表板中 。 通过这种方法 , A9可以与前十名集成 , 而不必是一个单独的正交过程 。
静态代码分析工具和技巧静态分析的好处在于您不需要完成整个应用程序或系统 , 因此可以在周期的更早阶段开始检查安全问题(向左移动安全测试) 。 如果您要在开发的后期或即将结束(DevOpsSec)进行安全性保护 , 则可以在实际编写代码(DevSecOps)之前 , 甚至在测试开始之前 , 使用静态分析来推动安全性 。
静态分析的丑陋一面是 , 它以非常嘈杂而著称 , 例如 , 当您以为可以发布时 , 就会产生数百甚至数千个违规 。 幸运的是 , 有一些非常好的策略可以解决这个问题 。 请记住以下几点:
直到最后才保存安全测试 。 开始编码后 , 立即开始运行静态分析 。 如果您等待并且仅将其作为CI/CD管道的一部分来运行 , 那么结果将堆积起来并使您的开发团队不知所措 。 在桌面上运行以查找问题 , 然后在CI/CD中运行以简单地验证代码是否正确构建微调您的配置 。 在代码的上下文中 , 可能不需要某些静态分析检查器 。 检查您的应用程序 , 确定哪些安全风险对您很重要 , 然后再进行处理 。 永远不要寻找您不打算解决的问题 。 代码的年龄很重要 。 “如果没有损坏 , 请不要修复”应适用于旧版代码 。 仅对最旧的代码运行最关键的安全扫描程序 。 小问题会浪费您的时间 , 而这些更改会带来新的风险 。 切勿检查您不打算修复的代码 。 一切都与风险有关 。 SAST工具既可以发现实际漏洞 , 也可以发现潜在漏洞 。 并非所有发现都具有相同的潜在风险 。 OWASP通过根据漏洞利用的难易程度 , 发现漏洞的难易程度以及漏洞的实际影响来定义前十名中每个项目的风险 , 为您提供了帮助 。 使用以下有用信息来对SAST结果进行优先级排序和分类:
光一样的少年|使用OWASP的AppSec入门
文章图片
使用OWASP的AppSec入门
预防的力量如果您想真正强化您的应用程序 , 我想强调一些重要的内容 。 进行安全性测试非常容易 , 但是要进行安全性测试则更加困难 。 幸运的是 , 静态分析检查器具有不同的风格 。 一些检查器会查找诸如污染数据之类的典型问题 , 并尝试找出应用程序中是否存在可能发生数据流的地方 。 这些是许多SAST工具中最常见的检查器 。
但是在静态代码分析中 , 更大的价值在于执行两个特殊操作的检查器:
过去经常与问题相关的模式 。 尽管这看起来不像是针对漏洞利用的特定堆栈跟踪那样有趣 , 但仅修复比其本应弱的所有东西比仅修复具有可靠攻击向量的问题要彻底得多 。 特定类型编码的要求 , 以确保正常运行 。 MISRA和JSF等汽车和飞机标准都依靠此技术来确保功能安全 。 除了标记错误代码之外 , 还需要良好代码的相同技术将帮助您构建更安全的应用程序 。具有讽刺意味的是 , 这是安全关键型行业数十年来一直在使用硬件和软件的方法 , 但是在网络安全方面 , 我们认为可以将安全性测试到应用程序中 , 而不必专注于构建安全代码 。 除早期检测检查程序外 , 还利用主动静态分析的全部功能来获得最大价值 。