作者：Csaba Kabai；前成员；Aline SENART；Uwe Sodan

我们在SAP使用静态应用程序安全测试（SAST）作为安全软件开发生命周期（secure SDL）的一部分。SAP已实施此流程框架，淘客平台，以解决其产品开发生命周期所有阶段的安全问题。自动静态源代码扫描有助于我们在开发过程中和开发后检测软件漏洞。

SAP Fiori是所有SAP应用程序的领先设计，提供跨内部部署、移动和云解决方案的统一用户体验。Fiori的主要构建块是基于SAPUI5的接口。SAPUI5库基于jQuery，SAP发布了一个名为OpenUI5的开源版本，允许每个人构建或扩展openui5ui。然而，以一种安全的方式构建它们是非常具有挑战性的，因为编程语言是JavaScript。

因此，我们必须创建自己的SAST检查并增强现有的SAST检查，以便在标准代码分析工具（在我们的例子中是Checkmarx）上运行。

Checkmarx使用户能够轻松直观地自定义SAST检查或定义他们自己的附加检查。这对于支持SAPUI5之类的专有框架是非常必要的，电商平台数据分析，这些框架不是Checkmarx提供的标准检查的一部分。这可确保识别所有真正的漏洞，物联网展，并有助于消除误报。提供了一种简单的编程语言和一个支持工具，使用户能够创建新的检查、试验对现有检查的更改，并将这些更改保存到服务器。

以下代码片段演示了由于违反SAPUI5安全准则而导致的跨站点脚本（XSS）漏洞：

A）示例.js–控制定义（属性+行为）

b）ExampleRenderer.js示例–控制实现（实际的HTML输出）

仔细阅读SAPUI5 API文档的读者可能已经认识到了第15行中的罪魁祸首ExampleRenderer.js示例. 开发人员希望在一个write（）调用中将标记的三个组件（opening、text content、closing）放在一起，从而生成带有自由文本的HTML，而不需要输出编码。这是XSS的一种典型模式，特别是当我们考虑到UI控件通常包含在可重用库中时，如果数据类型是string，那么这些库就不知道它们的输入有效性。这允许其中存在任意文本，包括恶意脚本。

可靠性可以这样理解：代码扫描结果应完整可靠。换言之，始终检测问题，并且不要用错误的警报对开发人员进行bug。在我们的例子中，它的意思是：

这是一个非常复杂的挑战，因为：

上面的一些要点包含了SAST工具的"有根据的猜测"。应充分理解SAPUI5 API背后的语义和契约（如命名约定），云服务器主机，仅在运行时生成的工件关系需要建模。"在SAPUI5中大量使用Duck typing！有多种数据类型未经框架验证有多种方法提供直接的HTML输出而不需要编码自定义控件实现有多种方法（"记事本"控件与库、当前与传统编码等）SAPUI5本身提供了各种可用的清理（如验证、编码）所有这些都应得到妥善处理，以实现我们获得可靠代码扫描结果的目标。

我们共同开发了一个定制检查，用于检测SAPUI5控件中的潜在XS，该检查正与Checkmarx执行上述步骤。

我们在SAP Fiori编码上运行了许多其他检查–请随时联系作者了解更多细节。我们还看到更多使用HANA XS或HANA XSA的服务器端JavaScript应用程序(节点.js)为此，我们还使用了一些检查——但这可能是下一篇博客的主题。

，个人用云服务器