Sicherheitsrisiko bei Salesforce Industry Cloud – Source: www.csoonline.com

Sundry Photography – shutterstock.com

Die vertikal ausgerichtete Lösungssuite Salesforce Industry Cloud umfasst eine Low-Code-Plattform, die vorgefertigte Tools für die digitale Transformation für bestimmte Branchen wie Finanzdienstleistungen und Fertigung bereitstellt. Forscher von AppOmni haben nun herausgefunden, dass Kunden ihre Komponenten leicht falsch konfigurieren können. Dadurch besteht die Gefahr, dass Angreifer Zugriff auf verschlüsselte Kundendaten, Sitzungsdaten, Anmeldedaten und Geschäftsinformationen erhalten.

Low-Code-Tools richten sich an Citizen Developer und ermöglichen es „nicht-technischen Anwendern, kritische Systeme und sensible Daten zu verwalten“, erklärt Aaron Costello, Leiter der SaaS-Sicherheitsforschung bei AppOmni. „Diese Erweiterung kann jedoch zu Lasten der Sicherheit gehen und das Risiko von Fehlkonfigurationen durch Kunden drastisch erhöhen.“

Der Experte warnt: „Diese Kombination aus Flexibilität und impliziertem Vertrauen bedeutet, dass die Fehlkonfiguration einer Komponente oder das Übersehen einer Einstellung durch einen Kunden zu einer systemweiten Offenlegung von Daten führen kann.“

Zu den identifizierten Risiken zählen:

• Low-Code-Komponenten, die standardmäßig keine Zugriffskontrollen durchführen oder verschlüsselte Datenfelder nicht berücksichtigen;
• Workflow-Code, der von externen oder nicht authentifizierten Benutzern ausgeführt werden kann;
• Caching-Mechanismen, die zur Umgehung von Zugriffskontrollen führen können;
• Schlecht entwickelte Off-Platform-Anwendungen, die zum Diebstahl von API-Tokens führen können;
• Sensible API-Schlüssel und andere Daten, die direkt in Komponenten eingebettet sind und ohne Berechtigung gelesen werden können;
• Unsichere Berechtigungen für gespeicherte Workflows.

Salesforce gibt fünf CVEs heraus

AppOmni hat insgesamt 20 Risiken durch Fehlkonfigurationen identifiziert. Daraufhin hat Salesforce CVEs und Leitlinien herausgegeben, um fünf davon zu verhindern. Die übrigen müssen von den Kunden selbst vermieden werden.

Die fünf herausgegebenen CVEs betreffen Probleme, die in den Komponenten FlexCards und Data Mappers von OmniStudio entdeckt wurden.

FlexCards, die Daten aus Salesforce und Drittanbieterquellen für die Verwendung in Workflows oder zur Anzeige in kundenorientierten Webansichten abrufen, sind für vier der CVEs verantwortlich:

• CVE-2025-43698: Die SOQL-Datenquelle ignoriert die Sicherheit auf Feldebene (FLS) und legt alle Felddaten für Datensätze offen.
• CVE-2025-43699: Das Feld „Erforderliche Berechtigungen“ kann umgangen werden, da die Überprüfung auf der Client-Seite durchgeführt wird.
• CVE-2025-43700: Die Berechtigung „Verschlüsselte Daten anzeigen“ wird nicht durchgesetzt, sodass Daten, die auf klassische Weise verschlüsselt sind, für nicht autorisierte Benutzer im Klartext angezeigt werden.
• CVE-2025-43701: Gastbenutzer haben Zugriff auf Werte für benutzerdefinierte Einstellungen.

Data Mappers ist eine Funktion, die als Option für FlexCards-Datenquellen oder als Aktion im Rahmen von Backend-Integrationsprozeduren (IProcs) für die serverseitige Datenverarbeitung verfügbar ist. Data Mappers lesen Daten und wandeln sie in Formate um, die für die Verwendung in APIs oder Salesforce-Objekten geeignet sind.

Die AppOmni-Forscher entdeckten, dass zwei der vier Data Mapper-Typen – „Extract“ und „Turbo Extract“ – standardmäßig keine FLS erzwingen und verschlüsselte Werte als Klartext an Benutzer zurückgeben. Auch, wenn diese keine Berechtigung zum Anzeigen dieser Werte haben. Salesforce hat diesem Problem die CVE-2025-43697 zugewiesen.

Zusätzliche Konfigurationsrisiken

Fünfzehn weitere Konfigurationsmuster können ebenfalls schwerwiegende Sicherheitsrisiken für Kunden von Salesforce Industry Cloud mit sich bringen.

Beispielsweise werden Datenmappers und IProc-Metadaten mithilfe eines Mechanismus namens „Scale Cache“ zwischengespeichert, um die Ausführung in Zukunft zu beschleunigen. Benutzer müssen Sharing Rules konfigurieren , um Datenmappers oder IProcs auszuführen. Dabei stellte das Forscherteam fest, dass diese Komponenten nach dem Zwischenspeichern für alleAnwender unabhängig von ihren Berechtigungen ausführbar sind.

„Leider gibt es keine Konfigurationseinstellung, die die Verwendung von Scale Cache unter Berücksichtigung der Sicherheitskontrollen für Datenmapper ermöglicht“, kritisiert Costello. „Nach gründlichen Tests, einschließlich der Aktivierung der OmniStudio-Einstellung „CheckCachedMetadataRecordSecurity“, hat sich herausgestellt, dass die einzige Möglichkeit, Autorisierungsprüfungen für Datenmapper durchzusetzen, darin besteht, Scale Cache vollständig zu deaktivieren.“

Integrationsverfahren berücksichtigen demnach weder die Einstellung „Erforderliche Berechtigung“ noch die Freigaberegeln von Data Mappern oder anderen IProcs, die sie im Rahmen ihrer Aktionen aufrufen. Dieses Verhalten wird von Salesforce dokumentiert, ist jedoch äußerst riskant. So müssen  Benutzer nur die Zugriffskontrolle des ursprünglichen IProc erfüllen, um einen Data Mapper oder IProc aufzurufen, der an seinem Prozessablauf beteiligt ist.

„Es ist möglich, dass Unternehmen über allgemein zugängliche IProcs verfügen, die mächtige Aktionen aufrufen“, warnt Costello. Der Grund dafür sei, dass sie fälschlicherweise davon ausgehen, dass die Berechtigungsanforderungen aller Aktionen eines IProc für den aufrufenden Benutzer überprüft werden.

Ein weiteres häufiges Konfigurationsrisiko besteht bei HTTP-Aktionen, die häufig als Teil von IProcs zur Kommunikation mit externen APIs verwendet werden. Wenn diese APIs eine Authentifizierung erfordern, könnten Unternehmen Benutzernamen und Passwörter oder API-Zugriffstoken direkt in den Hauptteil des IProc codieren.

Jeder, der einen IProc ausführen kann, kann auch die darin gespeicherten fest codierten Werte sehen. In vielen Fällen gehören dazu auch externe Benutzer oder sogar Gastbenutzer, die IProcs im Debug-Modus ausführen können.

FlexCards und IProcs unterstützen einen Datenquelltyp namens „Remote Actions“, der die Ausführung von Apex-Klassen ermöglicht. Apex ist die Java-ähnliche objektorientierte Sprache von Salesforce zum Erstellen von Anwendungen auf seiner Plattform.

Wenn eine OmniStudio-Komponente versucht, eine Apex-Klasse über Remote Actions auszuführen, wird die Anforderung über die Apex-Klasse „BusinessProcessDisplayController“ weitergeleitet. Diese enthält eine Methode namens „GenericInvoke2NoCont“, die nicht überprüft, ob der aufrufende Benutzer über die Berechtigung zum Zugriff auf die Remote-Aktion verfügt.

„Dies führt zu einer Umgehung der Autorisierung, wodurch sowohl interne als auch externe Benutzer leistungsstarken Apex-Code ausführen können, der ohne Freigabe oder ohne Implementierung von Sicherheitsmaßnahmen wie FLS ausgeführt wird“, führt Costello aus. Er fügt hinzu, dass dies das Standardverhalten sei.

Eine weitere Funktion, die zur Offenlegung sensibler Informationen führen kann, sind Datenpakete, mit denen Komponenten in andere Salesforce-Instanzen exportiert, beziehungsweise von dort importiert werden können. Diese Funktion hinterlässt Artefakte in Form von JSON-Definitionsdateien, die abhängige Objekte wie IProcs enthalten können, die wiederum Data Mapper enthalten.

„Ein Benutzer mit Lesezugriff auf dieses Objekt und übermäßig weit gefassten Freigaberegeln kann die JSON-Dateien der Datenpaketkomponente herunterladen, die im sObject „Attachment“ gespeichert sind“, so der Forschungsleiter.

„Da diese Anhänge ausschließlich auf Zugriffsprüfungen im Feld „Id“ des OmniDataPack basieren, benötigen Benutzer keine Berechtigungen auf Feldebene für das sObject ‚OmniDataPack‘, um auf diese Dateien zuzugreifen, sondern nur Berechtigungen auf Objekt- und Freigaberegelebene.“

Datenpakete können auch verwaist werden, beispielsweise wenn der Benutzer, der sie erstellt, während des Vorgangs auf die Schaltfläche „Abbrechen“ klickt. In diesem Fall werden die Anhänge erstellt, aber nie entfernt. Schlimmer noch, sie werden nicht auf der Datenpaket-Inventarseite in OmniStudio aufgeführt, was es für Administratoren schwieriger macht, sie zu erkennen.

Wenn sie in eine externe Website eingebettet sind, benötigen FlexCard- oder OmniScript-Komponenten einen Zugriffstoken, um auf Salesforce zugreifen zu können. Diese Token müssen mit einer OmniOut-App erstellt werden. Der Endbenutzer einer Website kann jedoch die API-Anfragen lokal in seinem Browser überprüfen und diesen Token extrahieren, der dann missbraucht werden kann. Costello empfiehlt Unternehmen, für die Kommunikation zwischen externen OmniStudio-Komponenten und Salesforce einen Proxy zu verwenden.

Ein Proxy hilft allerdings nicht, wenn der Token selbst in einen OmniOut-Code eingebettet ist, der kompromittiert oder in öffentlichen Versionskontrollsystemen wie GitHub gespeichert wurde. Darüber hinaus könnte ein Proxy Risiken mit sich bringen, wenn er schlecht konfiguriert ist und Anfragen ohne Validierung weiterleitet. Benutzer  könnten versuchen, Parameter und Werte zu manipulieren.

„Da OmniOut in der Regel auf authentifizierte Salesforce-APIs zurückgreift, wird diese Kontoanforderung erfüllt, indem der OmniOut-Komponente ein Zugriffstoken für verbundene Apps bereitgestellt wird, das für Anfragen im Namen aller externen Benutzer verwendet wird“, so Costello. „Obwohl dies in der Salesforce-Dokumentation, in der der Erstellungsprozess für verbundene Apps beschrieben wird, nicht ausdrücklich erwähnt wird, ist es unerlässlich, dass Unternehmen keinen Zugriffstoken für OmniOut generieren, der mit einem privilegierten Konto wie dem des Systemadministrators verknüpft ist.“

Schließlich verfügen OmniScripts, die mehrere Backend-Operationen über IProcs, Data Mappers und FlexCards miteinander verknüpfen, über eine Funktion namens „Saved Session“. Mit dieser können Benutzer ihren Fortschritt speichern und später zum Skript zurückkehren. Werden solche Sitzungen generiert, wird im OmniScript Saved Session sObject ein Datensatz zusammen mit allen Daten erstellt, die vom Skript bis zum Speichern eingegeben oder zurückgegeben wurden. Standardmäßig gibt es keine Ablaufzeit für diese gespeicherten Sitzungen.

„Obwohl Gast- und/oder Community-Site-Benutzer ihre eigenen Sitzungen nicht speichern können, werden sie nicht daran gehindert, die Daten anderer Benutzersitzungen zu lesen, wenn sie über die entsprechenden Berechtigungen verfügen, betont der AppOmni-Experte. Dieser Angriffsvektor stellt ein Risiko dar, das sowohl von internen als auch von externen Identitäten ausgenutzt werden könnte.“

Abhilfemaßnahmen

Für die unsicheren Konfigurationen, die Salesforce noch nicht behoben hat, gibt AppOmni in seinem Dokument Empfehlungen zur Risikominderung. Dazu zählt eine Liste von Objekten, deren Objekt-, Feld- und Freigaberegelkonfigurationen regelmäßig überprüft werden sollten. Die Reduzierung der Zugriffsebene für OmniStudio sObjects und deren Datensätze auf das Notwendigste sei die erste Verteidigungslinie, so das Unternehmen. (jm)

Lesetipp: Hacker erbeuten Salesforce-Daten mit Vishing