LCNC-SEC-03: Data Leakage and Unexpected Consequences
Risk Rating *
| Prevalence | Detectability | Exploitability | Technical Impact |
|---|---|---|---|
| 3 | 2 | 3 | 3 |
The Gist
Low-code/no-code development legitimately accesses data from underlying services but can also serve as a conduit to those backend systems for actions that were not anticipated or approved of. This includes unintended negative side effects such as data leakage beyond the application/security boundary, triggering create/read/update/delete operations on the data, and accidental/malicious data exfiltration.
Business User Description
Data leakage occurs when data moves outside of the organization’s control, and ends up in locations not intended or appropriate, which can lead to unexpected consequences.
Description
Low-code/no-code development often accesses data or performs operations on underlying services. As data operators, low-code/no-code applications can easily cause data leakage by moving data outside its designated storage or even the organizational boundary.
In some cases, low-code/no-code development can be used to sync data between multiple systems or trigger operations on one system due to a change in another. As operation triggers, these resources can result in unexpected consequences by implicitly coupling an operation within one system with a change in another. Furthermore, multiple applications can be connected to and triggered by a single data source, resulting in chained data movement or operation triggers, which are difficult to predict or fully map.
Example Attack Scenarios
Scenario #1
A developer grants an application that was built using low-code/no-code access to a corporate database. The application is shared with other users, granting them implicit access to the database without going through an approval or access request process.
Scenario #2
A developer configures an automation that triggers each time they receive an email in their corporate mailbox. The automation sends a new email to the developer’s personal email account, copying the recipients, subject, and body from the original email received in the corporate mailbox. Since data is copied to a separate mailbox rather than emails being forwarded from the corporate mailbox, the automation bypasses DLP controls.
Scenario #3
A developer builds an automation that syncs changes between two SharePoint sites, so every new file on site A is copied to site B. A business user accidentally writes a sensitive document to site A, not knowing that it is replicated to site B. Even if the business user deletes the document from site A, the document is still available on site B.
Example Attack & Misuse Scenarios - Business Users
Scenario #1
A developer builds a process to copy emails with specific words to their personal email account. The content and its attachments, are all now outside of corporate control creating a risk of that data being compromised or being used inappropriately.
Scenario #2
A user writes a process to automatically store data from a SharePoint site to a network drive. After loading a file to SharePoint, a user realizes the content is sensitive and deletes it from the SharePoint. They don’t realize the file has been copied to the network drive, and as a result, that sensitive data remains available.
How to Prevent
- Limit connectors to an approved services list
- Limit creation of custom connectors to dedicated personnel
- Monitor platforms for data flow outside the organizational boundary, including multi-hop paths