Unpacking the security complexity of no-code development platforms

In this Help Net Security interview, Amichai Shulman, CTO at Nokod Security, discusses how the abstraction layer in no-code environments complicates security by obscuring data flow, identity propagation, and control logic.

Shulman also addresses why vulnerabilities in no-code applications go far beyond simple misconfigurations or insecure defaults.

How does the abstraction layer in no-code environments complicate visibility into data flow, identity propagation, or control logic?

The use of no-code tools to generate custom applications in enterprises creates a bigger distance between the representation of software as reflected to the developer and the actual machine code implementing the application. This distance creates a number of challenges for visibility:

• Data flows, identities and control logic, all need to be extracted and analyzed over the proprietary representation of the application used by the low-code application platform (LCAP). This is different from inspecting standard programming languages that have public documented syntax and structure. Moreover, the information must be collected from multiple API endpoints exposed by the LCAP and is not centralized in a GIT repository as is the case with standard software.
• Dynamic analysis is extremely difficult in such environments since no built-in mechanisms are provided by the platform vendors for simple hooking. As a result, enriching static analysis with dynamic information about run-time value of parameters, actual identities and so on is a challenge.
• Correlating dynamic analysis information (such as actual data access and identity) back to the representation available to the developer is becoming more difficult as there are multiple layers of interpretation and compilation between the original representation of the application and the actual execution environment.

What types of misconfigurations or insecure defaults in no-code environments do you see as most exploitable?

The phrasing of the question is an excellent example of the biggest issue with no-code application security – reducing the discussion to “insecure default settings and misconfigurations”. Applications generated by no-code platforms are first and foremost applications. Therefore, their exploitability is first and foremost attributed to vulnerabilities introduced by their developers. To make things worse for no-code applications, they are also jeopardized by misconfigurations of the development and deployment environments. The vulnerabilities we find to be most common in no-code applications are:

• Hard-coded secrets: developers include credentials, API keys, secret tokens and more in their applications. These are mostly used as part of integration with enterprise systems and external APIs. The secrets embedded in such applications are exposed to the people who use the applications and its also very difficult to rotate them either on an ongoing basis (as recommended) or upon exposure (as required)
• HTML injection vulnerabilities: One of the most common usages of no-code applications is for automatic messaging in various situations, with emails and Microsoft Teams being the most prominent channels. When generating messages with unsanitized user input (as is frequently the case), the threat of HTML injection becomes imminent, allowing attackers to potentially subvert the contents of messages to the point that they become part of a phishing campaign or even carriers of malicious code.
• Data access related injection vulnerabilities: SQL injection, OData injection, DAX injection and SOQL injection are all vulnerabilities that abuse common data access methods used in enterprises. They are the result of inexperienced developers that create data access actions which rely on unsanitized user input. Exploiting these vulnerabilities may provide attackers with unauthorized access to sensitive data as well as the ability to tamper with the data

When the above vulnerabilities are combined with direct exposure to unauthenticated user input (either intentionally or unintentionally) they become an enterprise’s data security worst nightmare.

What guardrails can be embedded at the platform level to prevent high-risk automation patterns, like unvetted data egress or integration with shadow APIs?

Most platforms provide controls at various levels that allow white-listing / blacklisting of connectors. This makes it possible to put guardrails around the use of “standard integrations”. Keeping tabs of these lists in a dynamic environment with a large number of developers is a big challenge.

Shadow APIs are even more difficult to track and manage, particularly when some of the endpoints are determined only in runtime. Most platforms do not provide granular control over the use of shadow APIs but do provide a kill switch for their use entirely.

Mechanisms exist in all the platforms that allow for secure development of applications and automations if used correctly. These mechanisms that can help prevent injection vulnerabilities, traversal vulnerabilities and other types of mistakes have different levels of complexity in terms of their use by developers.

Unvetted data egress is also a big problem in these environments just as it is in general enterprise environments. There are no generic remediations and protection mechanisms are mostly channel specific.

Do you see a future where no-code environments offer native support for attestation, auditing, or formal verification?

There’s generally no technical barrier to prevent this from happening. However, history shows that there are very few secure development controls embedded in development environments by the IDE vendors. Even with standard software engineering, most of the secure development heavy lifting is carried out by third party, specialized, security vendors.

My guess is that platform vendors will keep introducing mechanisms that support secure development, but the evaluation of their use by developers, or enforcement of their use will still remain with third party security vendors.