Low Code, High Stakes: Addressing SQL Injection

Like a bad movie that seems to go on forever, SQL injection (SQLi) attacks have been around since the late 1990s. For various reasons, they remain the third most common source of vulnerabilities in web applications. Reasons include human error, new technologies lacking mature code, and the increasing use of open source code that limits developer control.

The problem is so serious that in March 2024, CISA and the FBI issued a joint warning to manufacturers and others: it’s time to get serious about addressing SQLi vulnerabilities. The agencies recommended the Secure by Design framework, which creates security as a business requirement, not just a technical feature.

Unfortunately, there is a new wave of SQLi attacks that are taking a different trajectory than in the past. Software developed on low-code and no-code (LCNC) platforms, including robotic process automation (RPA), which is expected to account for 70% of applications by 2025, poses a different type of risk. It’s one thing to warn CISOs and professional developers at software companies. This is another issue addressed to citizen creators.

SQLi vulnerabilities on LCNC platforms

You reject this evolution in software development at your own risk. LCNC platforms introduce powerful and very attractive possibilities. They increase productivity, reduce costs and stimulate innovation. However, it is important to remember that LCNC and RPA applications are created by citizen developers, not professional developers who have little or no knowledge of the technical factors underlying the risks.

LCNC and RPA are fertile ground for SQLi attacks. Meanwhile, a growing ecosystem of business software and development tools supports LCNC. These include Microsoft Power Apps, Mendix, Salesforce, UiPath, ServiceNow, AppEngine, and Automation Anywhere. Increasingly, when such applications are created, no professional developer or security analyst touches, tests, or evaluates the final application.

The development of LCNC creates an often unrecognized external attack surface that allows attackers to exploit any external source of data processed by an LCNC or RPA application. Some examples include processing emails sent to customer service, or even social media posts and replies automatically collected from company channels.

An SQLi attack can be hidden in these external inputs to fool the server and run the string as a command. These hidden instructions can be used to modify, manipulate and steal data; and in some extreme cases, even create fake accounts and take control of the database server.

Whether it’s a business-critical application for credit card processing or internal automation, SQLi in LCNC applications poses a real risk to the enterprise.

Growing concern

Unfortunately, existing AppSec stacks are not designed with LCNC security in mind, and citizen developers are rarely trained on SQLi threats.

In other words, SQLi attacks aren’t going to stop any time soon – even after government warnings to commercial software vendors. As citizen developers turn to LCNC platforms, attacks are likely to increase in frequency and severity. Reason? Secure Software Development Lifecycle (SSDLC) with citizen developers is typically thrown out the window.

The problem centers around four key factors:

• No traditional security measures in the rapid application development process.
• Over-reliance on platform security features without additional safeguards in place.
• There is a misconception that LCNC platforms are inherently secure against such attacks.
• Investing in educating professional software engineers to avoid SQLi bugs is practical, but applying this methodology to citizen developers is not.

To eliminate risk, CISOs and other security professionals must recognize the problem and take steps to fill the gaps. Applying a secure development approach to commercial software alone is not enough.

Implementing security for LCNC applications

Despite all these challenges, it is possible to ensure the implementation of safe design principles while enabling citizen developers and automation engineers to use LCNC and RPA tools. The right approach can increase business productivity and secure LCNC development environments.

The LCNC safety program should focus on three areas:

• Management. It is important to maintain an inventory that identifies redundant or outdated applications and highlights running applications and automation that require rigorous control.
• Compatibility. The organization must look for issues such as personal data leakage related to PCI-DSS, GDPR, and HIPAA breaches, for example. Citizen developers are typically unaware of compliance requirements or how LCNC can introduce risk.
• Security. Understanding access control, authentication, and authorization is essential because default configurations are commonly used by citizen developers who are not security experts.

LCNC SQLi risk mitigation best practices

There is good news. CISOs can create more secure LCNC development environments. However, the focus should be on citizen developers. An effective program covers five main areas:

• Discovery. It is essential to achieve broad and deep visibility across all existing LCNC applications.
• Monitor. The organization must scan applications and automation, analyze third-party components, and identify and classify data usage.
• Manage. Establishing a comprehensive framework for managing development processes. This includes preparing detailed guidance for citizen developers.
• Detect and respond. Monitor citizen developer activity to detect flaws that introduce vulnerabilities in applications and automations so they can be quickly fixed.
• Scale. Use security tools to streamline and automate tasks, including overseeing and enforcing policies and processes.

Ultimately, the CISO’s job is not to push more resources into SQLi, but to focus the right resources on the task. As LCNC continues to gain popularity in the business world, a more advanced security framework is necessary. It’s up to CISOs to ensure they adopt a best-practice approach.