Low code, high stakes: Addressing SQL injection


Like a bad movie that seems to go on forever, SQL injection (SQLi) attacks have lingered since the late 1990s. Due to various factors, they remain the third most common source of web application vulnerabilities. Reasons include human error, new technologies that lack mature code, and a growing use of open-source code that diminishes control for developers.

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 eradicating SQLi vulnerabilities. The agencies recommended a Secure by Design framework that builds protections as a business requirement rather than simply a technical feature.

Unfortunately, a new wave of SQLi attacks is emerging—and it’s taking a different trajectory than in the past. Software developed on low-code and no-code (LCNC) platforms, including robotic process automation (RPA), which are expected to reach 70% of apps by 2025, represents a different type of risk. It’s one thing to alert CISOs and professional developers at software companies. It’s another to address citizen developers.

SQLi vulnerabilities in LCNC platforms

Dismiss this evolution in software development at your own risk. LCNC platforms introduce powerful and highly attractive capabilities. They boost productivity, trim costs, and spur innovation. Yet, it’s crucial to remember that LCNC apps and RPAs are created by citizen developers, not professional coders, who have little or no understanding of the technical factors underpinning risks.

LCNC and RPAs 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 building these apps, no professional developer or security analyst will ever touch, test, or evaluate the final app.

LCNC development creates an often-unrecognized external attack surface that allows hackers to exploit any external data source processed by an LCNC application or RPA. Some examples include processing email messages sent to customer support or even social media posts and responses collected automatically from the company’s feeds.

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

Whether it is a business-critical application for credit card processing or internal automation, SQLi in LCNC apps is a real-world risk to the enterprise.

The growing concern

Unfortunately, existing AppSec stacks aren’t designed to address LCNC security and citizen developers rarely receive training to address the risk of SQLi.

In other words, SQLi attacks won’t subside anytime soon—even with government warnings to commercial software vendors. As citizen developers turn to LCNC platforms, the frequency and severity of attacks will likely spike. The reason? A secure software development life cycle (SSDLC) with citizen developers is typically tossed out the window.

The problem revolves around four critical factors:

  • A lack of traditional security measures in the rapid app development process.
  • An over-reliance on platform security features without layering in additional safeguards.
  • The misconception that LCNC platforms are inherently secure against such attacks.
  • While investing in educating professional software engineers to avoid SQLi errors is practical, applying this methodology to citizen developers is not.

To eradicate risks, CISOs and other security professionals must recognize the problem and take steps to fill the gaps. Applying a secure development approach solely to commercial software isn’t sufficient.

Instituting LCNC app security

Despite all these challenges, it’s possible to ensure the implementation of secure-by-design principles while allowing citizen developers and automation engineers to use LCNC and RPA tools. The right approach can boost business productivity and secure LCNC development environments.

A LCNC security program should focus on three areas:

  • Governance. It’s important to maintain an inventory that identifies redundant or outdated applications and singles out live apps and automation that require stringent controls.
  • Compliance. An organization must look for issues such as PII leakage related to PCI-DSS, GDPR and HIPAA violations, for example. Citizen developers are typically unaware of compliance requirements or how LCNC can introduce risks.
  • Security. Understanding access control, authentication, and authorization is vital since default configurations are commonly used by citizen developers who are not security experts.

Best practices for mitigating LCNC SQLi risks

There’s good news. CISOs can create more secure LCNC development environments. However, it’s necessary to focus on citizen developers. An effective program spans five core areas:

  • Discovery. Achieving broad and deep visibility into all existing LCNC applications is vital.
  • Monitor. An organization must scan applications and automation, analyze third-party components, and identify and classify data usage.
  • Manage. Establish a comprehensive framework for governing development processes. This includes setting up step-by-step guidance for citizen developers.
  • Detect and respond. Monitor citizen developer activity to detect flaws that introduce vulnerabilities into applications and automations so they can be remediated promptly.
  • Scale. Use security tools to streamline and automate tasks, including overseeing and enforcing policies and processes.

In the end, the task at hand for CISOs isn’t to toss a greater number of resources at SQLi, it’s to focus the right resources on the task. As LCNC continues to gain traction in the business world, a more advanced security framework is essential. It’s up to CISOs to ensure that they’ve adopted a best-practice approach.



Source link