作者简介：

肖文棣，OWASP中国广东分会负责人、网安加社区特聘专家，现任某外企安全架构师，负责应用安全设计、管理和评审等工作。

数字经济的时代浪潮让企业纷纷踏上了数字化转型的征程，新业态与新产业的涌现，也在催生着新的需求，专业开发人员的缺口显著，数字化转型不断加快，传统的应用开发方式已经无法满足需求，近几年发展起来的“低代码技术”作为解决企业数字化转型以及增强企业复原力的有力手段，得到越来越多的关注，并不断渗透到各行各业。

本文将介绍低代码相关概念、背景知识、以及低代码的安全风险，最后分享OWASP低代码安全风险Top 10以及相关预防措施。

低代码简介

百度百科：“低代码”是一种可视化编程方法，允许企业不必通过编写代码而是通过图形界面快速搭建应用程序。

Gartner定义：低代码平台被称为企业级低代码平台（LCAP），是支持快速应用开发，使用陈述性、高级的编程抽象实现一站式应用部署、执行和管理的应用平台。

我们可以通过下图可以形象地了解低代码：

1.低代码简史

低代码虽然近几年才火起来，但最早却是可以追溯到20世纪90年代至21世纪初的编程语言和工具。至于正式的提出，则是由Forrester Research在2014年第一次正式使用“Low-Code”来描述这个市场的，我们这边也就是这几年才直译为“低代码”，以前都是叫“可视化搭建”。

我们可以了解一下低代码的发展历史：

• 1970年代-1990年代：第四代编程语言（4GL，Fourth-Generation Programming Language）
• 1990年代：快速应用程序开发（RAD，Rapid Application Development）
• 2001：模型驱动架构（MDA，Model-Driven Architecture）
• 2007：移动平台（Mobile Platform）
• 2016：低代码与低代码开发平台

2.低代码为什么流行？

由此可见此领域许多玩家早在几年前就已经存在，那为什么近几年低代码赛道被重点关注，又重新流行起来了呢？归因于两个方面：1）技术成熟度；2）业务收益。

我们都知道，任何的技术都会遵守所谓的“技术成熟曲线”。从现在来看，支撑低代码的“老技术”已经通过几十年的酝酿打磨变得稳固，互补的新技术如云原生、响应式web等技术均慢慢走向成熟，低代码已经快爬到生产力高地；另一方面，由于企业线上数字化需求，由过去简单粗暴的的应用架构逐渐迭代为多样化体验、多粒度服务的应用架构，低代码也就顺水推舟，应运而生。

3.低代码的分类

• 无代码开发平台
• 低代码应用平台（LCAP）
• 多重体验开发平台（MXDP）
• 智能业务流程管理套件（iBPMS）

4.低代码平台的核心价值

隐私价值

低代码应用程序可以由没有深厚技术技能的业务人员开发，因此企业不能将这些开发任务外包给第三方，而是交给内部人员，这增强了保密性。

快速价值

由于代码的主要部分已经开发出来，用户无需手动编写代码，只需直观配置应用程序或进行必要的调整即可开发他们需要的应用程序。一项调查显示，低代码平台将开发速度提高了5~10倍。

降低成本价值

由于开发周期缩短，无论是由公司开发还是由外包人员开发，成本都会降低。

降低复杂性价值

应用程序不是从头开始构建的，其开发已经简化，因此开发人员可以更加注重自定义软件，以满足用户的要求。

易维护价值

软件维护非常重要，需要快速更改软件，以确保应用程序提供的服务与业务需求一致。由于低代码平台提供的代码很少，因此几乎没有需要维护的代码。

贴近业务实际价值

低代码平台提供了一个简单、直观的界面作为应用程序部署的开发环境。在这种情况下，这些应用程序的最终用户不需要技术知识，因为他们了解业务需求。根据调查，44%的低代码平台用户是与技术人员合作的业务用户。

最小化不稳定或不一致的需求价值

在当前的软件开发过程中，需求之间可能存在冲突，并影响需求变化的应用程序。然而，由于业务人员也可以参与开发，使用低代码意味着可以快速建立最小的可行产品来验证想法和客户要求，然后将资源花在客户可能不注意的特点和功能上。

5.低代码平台的能力维度

Gartner共列出了低代码平台的11个关键能力维度：

易用性

易用性是标识低代码平台生产力的关键指标，是指在不写代码的情况下能够完成的功能的多少。

用户体验

这个指标能够决定最终用户对开发者的评价。一般来说，独立软件开发团队为企业客户开发的项目对用户体验的要求会显著高于企业客户自主开发的项目，开放给企业的客户或供应商的项目对用户体验的要求会高于企业内部用户使用的项目。

数据建模和管理的便利性

这个指标就是通常所讲的“模型驱动”，模型驱动能够提供满足数据库设计范式的数据模型设计和管理能力。开发的应用复杂度越高，系统集成的要求越高，这个能力就越关键。

流程与业务逻辑开发能力和效率

这个能力有两层含义：第一层是指使用该低代码平台是否可以开发出复杂的工作流和业务处理逻辑，第二层是开发这些功能时的便利性和易用性有多高。一般来说，第一层决定了项目是否可以成功交付，而第二层则决定了项目的开发成本。无论如何，使用者都应关注第一层。在此基础上，如果项目以工作流为主，则还应该将第二层作为重要的评估指标。

开发平台的生态系统

低代码平台的本质是开发工具，内置的开箱即用的功能无法覆盖更多的应用场景。此时，就需要基于该平台的完整生态系统来提供更深入、更全面的开发能力。很多开发平台都在建立自己的插件机制，这就是平台生态的一个典型体现。

编程接口与系统集成能力

为了避免“数据孤岛”现象，企业级应用通常需要与其他系统进行集成，协同增效。此时，内置的集成能力和编程接口就变得至关重要。除非确认在可预期的未来项目不涉及系统集成和扩展开发，否则开发者都应该关注这个能力。

支持更先进的架构和技术

系统是否支持更先进的架构、清晰的分层，以对接IoT、RPA、机器学习等新的技术？如果开发者希望自己开发的应用有更长的生命周期，深入了解低代码平台产品的架构就变得尤为重要。

服务质量

与上一点类似，服务质量也是衡量运行于公有云模式下低代码平台的指标。这里的服务质量，除了通常所说的“无故障使用时间”外，还要考虑资源是否支持独占模式，避免某一个应用的高负荷，导致其他应用不可用或出现性能劣化。

用户模型与软件开发周期支持

在软件开发的生命周期中，除了开发和交付，还有设计、反馈、测试、运维等多个环节，如系统开发早期的用户模型建立和验证过程通常需要快速模拟和迭代，投入的开发力量甚至不少于正式开发。如果一套低代码平台具备全生命周期所需的各项功能，将会大大简化开发者的技术栈，进一步提高开发效率。开发者所开发的系统规模越大，这一能力就越重要。

开发管理

企业级软件的项目规模通常比较大，而且业务更关键，这就对开发团队管理提出了更高的要求。现代软件开发中主推的敏捷开发是否能在低代码中落地，是衡量开发管理能力的重要指标。这通常包含代码库权限管理、版本权限管理、发布权限管理等一系列功能，帮助开发团队负责人降低软件开发管理过程中的各种人为风险。开发团队规模越大，开发者越应当关注这一指标。

安全与合规

低代码平台需要在部署方式、系统安全机制、权限管理和控制功能等层面发力，全方位赋能开发者构建安全的、符合企业规则的企业级应用。支持本地部署、全SSL数据传输、密码强度策略、跨域访问控制、细粒度的用户权限控制等都是该能力的具体体现。大型企业、特定行业企业（如军工、金融等）通常对该指标的关注程度会更高一些。

6.国内典型的低代码平台

2021年11月，Forrester推出《The State of Low-Code Platforms in China》（中国低代码平台发展报告），将中国的低代码平台厂商和产品划分为9大类，并列出了对应的代表厂商和产品。

7.低代码的安全风险

低代码/无代码应用程序的可见性低

低代码厂商提供的封装代码模块是无法被开发者检查测试的，开发过程类似于“黑箱状态”，只能通过低代码平台内置的组件和流程来大致检查其内在逻辑是否相容。

不安全的代码

如果低代码平台的组件开发得不够完善，这将会产生潜在的安全问题。有漏洞的代码片段不可避免地会被复制粘贴到其他地方。

另一个要考虑的方面是，许多低代码和无代码平台都是以SaaS方式交付的。SaaS应用程序本身存在许多安全风险，需要适当的治理和严格的安全性。如果没有对企业正在使用的SaaS应用程序和平台进行适当的审查，可能会让其业务面临不必要的风险。

失控的影子IT

由于低代码和无代码平台允许快速创建应用程序，即使是那些没有开发背景的人员，也可能导致影子IT的泛滥。影子IT发生在业务部门和员工创建应用程序并将它们用在企业内部或外部时。这些应用程序可能包含企业和客户敏感的或受监管的数据，如果这些应用程序在数据泄露中受到损害，可能会对企业产生一系列影响。

业务中断

从业务连续性的角度来看，如果平台出现中断，作为服务交付的低代码和无代码平台可能会中断业务。对于企业而言，为关键业务应用程序(包括低代码和无代码平台)建立服务水平协议(SLA)非常重要。

8.如何减少低代码安全风险

• 从具有受人尊敬的行业声誉的可信赖供应商处购买软件和平台。
• 确保这些供应商拥有第三方认证证书，以代表其内部安全实践和流程。
• 在您的应用程序和软件清单中考虑低代码和无代码平台，以及通过使用它们创建的应用程序。
• 保持良好的访问控制；知道谁在访问平台以及他们被允许执行哪些活动。
• 实施安全数据实践以了解您的关键数据所在的位置，以及使用低代码和无代码平台创建的应用程序是否包含敏感数据。
• 了解低代码/无代码平台的托管位置。这些平台是否托管在 AWS、Google 或 Microsoft Azure 等超大规模全球云服务提供商 (CSP) 中？或者它们是否托管在传统的本地数据中心中，仅限于没有物理和逻辑访问控制？

Owasp低代码安全风险Top10

LCNC-SEC-01：身份冒充

无代码/低代码应用程序可以冒充任何应用程序用户隐式使用的用户身份。这为特权提升创建了一条攻击路径，允许攻击者隐藏在另一个用户的身份背后来绕过传统的安全控制.

攻击场景示例：

场景#1

创客创建一个简单的应用程序来查看数据库中的记录。创客使用自己的身份登录数据库，创建嵌入在应用程序中的连接。用户在应用程序中执行的每个操作最终都会使用创客的身份查询数据库。恶意用户利用这一点并使用该应用程序查看、修改或删除他们不应访问的记录。数据库日志表明所有查询都是由单个用户（应用程序创客）进行的。

场景#2

创客创建了一个业务应用程序，允许公司员工用他们的信息填写表格。为了存储表单响应，创客使用自己的个人电子邮件帐户。用户无法知道该应用程序将他们的数据存储在创客的个人帐户中。

场景#3

创客创建业务应用程序并与管理员共享。创客将应用程序配置为使用其用户的身份。除了声明的目的外，该应用程序还使用其用户的身份来提升创客的权限。一旦管理员使用该应用程序，就会无意中提升了创客的权限。

预防措施：

• 提供与外部服务的连接时，请遵守最低权限原则。
• 确保应用程序使用专用服务帐户而不是用户帐户。
• 确保应用程序在其所有连接中使用单一一致的身份，而不是为每个连接使用不同的身份。
• 确保维护适当的审计跟踪，以识别通过共享连接执行的操作背后的参与者。

LCNC-SEC-02：授权失效

在大多数无代码/低代码的平台中，服务连接都是头等对象。这意味着应用程序、其他用户或整个组织之间的连接。应用程序也可以与不应访问其基础数据的用户共享。

攻击场景示例

场景#1

创客创建一个连接到他们公司的电子邮件账户并且无意中点击了“与所有人共享”选项。组织中的每个用户，包括承包商和供应商，都可以访问创客公司的电子邮件账户。恶意用户触发“忘记密码”流程并使用连接来完成该过程，从而获得对账户的控制权。

场景#2

创客创建一个简单的应用程序来查看数据库中的记录。该应用程序配置成确保每一个用户只能查看相关的记录。但是应用程序的配置方式是底层数据库连接与其用户隐式共享。应用程序用户可以直接使用数据库连接，获得对所有记录的完全访问权限。

场景#3

管理员使用服务账户将应用程序连接到自己的源代码管理系统（即BitBucket）。配置的服务账户可以不受限制地访问所有存储库，以实现无缝集成。任何内部用户都可以滥用此连接来访问自己通常无权访问的受限存储库。

预防措施

• 禁用或监控隐式共享连接的使用。
• 在提供对包含共享连接的环境的访问时，遵循最小特权原则。
• 监控无代码/低代码平台的过度共享连接。
• 教导业务用户了解连接共享的风险及其与凭证共享的关系。

LCNC-SEC-03：数据泄漏和意外后果

无代码/低代码应用程序通常会跨多个系统同步数据或触发操作，这为数据跨越组织边界创造了一条路径，这就意味这在一个系统内的操作可能会在其他系统中造成意想不到的后果。

攻击场景示例

场景#1

创客配置了在其公司邮箱中收到的每一封新电子邮件时触发的自动化操作，该操作会自动向创客的个人电子邮件账户发送一封新的电子邮件，并从公司邮箱中收到的原始电子邮件中复制收件人、主题和正文。由于数据是复制到单独的邮箱而不是从公司邮箱转发的电子邮件，因此可以自动绕过数据防泄漏（DLP）的控制。

场景#2

场景1的创客配置了在两个Sharepoint网站之间同步更改的自动化操作，因此站点A的每一个新文件都复制到站点B。用户2不小心将敏感文件写入到了站点A，但不知道敏感文件会同步复制给站点B。用户2删除了战斗A的敏感文件，然而该敏感的文件仍会存在站点B上。

预防措施

• 将平台连接限制在批准的服务列表中。
• 将自定义连接器的创建限制为专职人员。
• 监控平台以了解组织边界外的数据流，包括多跳路径。

LCNC-SEC-04：身份验证和安全通信失效

无代码/低代码应用程序一般通过业务用户设置的连接来连接到关键业务数据，这通常会导致不安全的通信。

攻击场景示例

场景#1

创客创建了一个使用FTP连接的应用程序，并且没有勾选打开加密的复选框。由于应用程序与其用户之间的通信是加密的，因此应用程序的用户无法获悉自己的数据正在未加密的情况下进行传输。

场景#2

创客使用管理员凭据来创建数据库连接并构建了一个应用程序，且该应用程序使用该连接向用户显示数据。在这种情况下，尽管创客的计划是只允许用户通过应用程序进行只读操作，但用户也可以使用特权连接从数据库中写入或删除记录。

预防措施

• 在生产环境中，将连接的创建限制为专职人员。
• 监控平台是否存在不符合最佳做法的连接。
• 教育业务用户了解不安全通信的风险并且在做相关设置时需要让安全团队参与进来。

LCNC-SEC-05：安全配置错误

错误配置往往会导致匿名访问敏感数据或操作、不受保护的公共端点、密钥泄漏和过度共享。

攻击场景示例

场景#1

创客创建了一个的应用程序，该应用程序公开了一个API端点，但该端点没有配置为拒绝匿名访问。攻击者扫描低代码/无代码平台的子域，找到该应用并窃取其底层数据。

场景#2

创客创建了由webhook触发的自动化，但未能用密钥保护该webhook。攻击者识别了webhook，现在可以随意触发自动化。该自动化可能是修改或删除数据。

预防措施

• 阅读供应商的文档并遵循最佳实践指南。
• 确保配置符合行业最佳实践。
• 监测配置的漂移。
• 为租户级的配置实施一个变更管理系统。

LCNC-SEC-06：注入处理失效

无代码/低代码应用程序以多种方式接收用户提供的数据，包括直接输入或从各种服务中检索用户提供的内容。此类数据可能会包含给应用程序带来风险的恶意有效载荷。

攻击场景示例

场景#1

创客设置自动化，在新RSS订阅发布时触发，并将该RSS订阅存储到 SQL 数据库中。控制 该RSS订阅的攻击者使用该流程向数据库中注入删除重要记录的命令。

场景#2

创客创建了一个允许用户填写表单的应用程序。该应用程序将表单数据编码为 CSV文件并将CSV文件存储在共享驱动器上。即使平台为SQL注入攻击清理了表单输入，但并没有针对Office宏攻击进行清理。攻击者利用这一点并在CSV文件中写入一个宏。用户打开CSV文件以分析用户表单，然后就执行了宏。

预防措施

• 清理用户输入，同时考虑应用程序将对该输入执行的操作。
• 告知业务用户并使其了解到未经处理的用户输入的会带来的风险，这是平台无法自行解决的问题。

LCNC-SEC-07：易受攻击和不可信的组件

无代码/低代码应用程序在很大程度上依赖于市场上的现成组件、网络或由开发人员构建的自定义连接器。这些组件通常不受管理，缺乏可见性，并使应用程序暴露在基于供应链的风险中。

攻击场景示例

场景#1

整个组织的创客都使用来自公开的易受攻击的组件。每个使用该组件的应用程序都暴露在攻击下。管理员可能会发现很难找到受漏洞组件影响的应用程序。

场景#2

开发人员创建一个自定义连接器，允许创客连接到内部业务API。自定义连接器在URL上传递身份验证令牌并向应用程序用户暴露身份验证密钥。

预防措施

• 删除不使用的依赖项、不必要的特性、组件、文件和文档。
• 持续关注这些应用程序使用的应用程序和组件版本，并扫描该清单以查找已废弃或易受攻击的组件。
• 限制使用预先批准的公开组件。
• 监控未维护的组件或未为旧版本创建安全补丁的组件。

LCNC-SEC-08：数据和机密处理失效

无代码/低代码应用程序通常将数据或密钥作为其“代码”的一部分进行存储，或者存储在平台提供的托管数据库中，而这些数据必须按照法规和安全要求进行适当的存储。

攻击场景示例

场景#1

创客创建了一个业务应用程序，要求用户填写包含敏感数据的表单。应用程序使用平台提供的托管数据库来存储结果，然而由于所有其他创客默认使用托管数据库进行存储，因此其他创客都可以访问到这些敏感数据。

场景#2

创客在创建的应用程序中使用了自定义的 API，并在代码中硬编码了访问该 API 的密钥。于是，其他创客也就可以直接访问到这些 API 密钥。此外，这些API密钥可能会泄漏到应用程序的客户端代码中，从而使用户也可以直接访问到这些密钥。

预防措施

• 就与数据存储相关的合规性、隐私和安全风险对业务用户进行教育。
• 加强对于无代码/低代码供应商提供的托管数据库、环境变量和配置的监控，及时发现不恰当存储的敏感数据。
• 对于涉及敏感数据处理的应用程序，确保安全团队参与其中。

LCNC-SEC-09：资产管理失效

无代码/低代码应用程序易于创建开发，并且维护成本相对较低，这个特点使这些应用程序在保持活动状态的同时，组织也很容易弃用这些应用程序。此外，内部应用程序可以在不解决业务连续性问题的情况下迅速普及。

攻击场景示例

场景#1

创客创建的应用程序成为流行的内部工具。制作商离开组织或换了另一个角色。由于API更改，应用程序中断，业务中断。IT部门根本不了解这个应用程序，也无法帮助修复这个应用程序。

场景#2

创客浏览平台市场并探索应用模板。每次单击都会创建一个带有面向外部URL的应用程序。用户很可能会忘记这些应用程序，造成业务数据暴露。这种情况再乘以创客的数量，导致废弃应用程序资产数量不断增加。

预防措施

• 维护一个包含有应用程序、组件和用户的全面资产清单。
• 删除或禁用不使用的依赖项、不必要的特性、组件、文件以及文档。

LCNC-SEC-10：安全记录和监控失效

无代码/低代码应用程序通常缺乏全面的审计跟踪，不生成日志或存在日志不足，或者对敏感日志的访问没有严格管控。

攻击场景示例

场景#1

应用日志已关闭。当发生违规尝试行为时，安全团队无法确定谁访问了该应用程序以及访问者尝试执行的操作。

场景#2

业务关键型应用程序在发生变更后停止运行。由于发生了多个变更，每个变更都会导致应用程序更新，因此很难找到哪个创客引入了导致问题的特定变更。创客必须手动检查每个应用程序版本才能找到有问题的版本。由于每个应用程序“保存”都会转换为更新，因此更新的数量将使手动过程的成本过高。在某些平台上，创客只能查看应用程序的当前版本，因此创客将无法找到或恢复到稳定版本。

预防措施

• 利用平台内置功能收集用户访问和平台审核日志。
• 在适用的情况下，使用日志记录机制检测应用程序，以提供额外的可见性。
• 通过配置平台以避免记录原始应用程序的数据，确保日志不包含敏感数据。

– End –