OWASP Low Code Top 10 – Was die Sicherheitsempfehlungen für A12-Anwendungen bedeuten

Während sich Low-Code-Ansätze zunehmender Beliebtheit erfreuen, rücken auch Sicherheitsaspekte stärker in den Fokus. Mit den OWASP Low Code/No-Code Top 10 wurde kürzlich eine Liste der häufigsten Sicherheitsrisiken veröffentlicht, die Organisationen bei der Entwicklung und dem Einsatz von Low-Code-Anwendungen beachten sollten. Wir fassen zusammen, inwiefern die Punkte A12-Anwendungen betreffen.

Wenn es um die Sicherheit von Software geht, ist das Open Worldwide Application Security Project (OWASP) eine der wichtigsten Institutionen. Weltweit engagieren sich Security-Expertinnen und Experten ehrenamtlich in einer wachsenden Community. Die Non-Profit-Organisation fördert die Entwicklung von Sicherheitstechnologie und stellt zahlreiche Tools und Ressourcen frei zur Verfügung.

Mit der OWASP Low-Code/No-Code Top 10 steht nun auch ein richtungsweisendes Dokument für Low-Code-Anwendungen in den Startlöchern. Das Dokumentationsprojekt ist aktuell im „Lab“-Status. Es hat damit bereits die „Incubator“-Phase überwunden und einen gewissen Reifegrad erreicht, befindet sich aber immer noch in der Entwicklungsphase und strahlt nicht die Verbindlichkeit der ausgewachsenen Projekte aus.

Die zehn OWASP-Risiken im Detail – und wie A12 sich schlägt

Im Folgenden fassen wir zusammen, was in Bezug auf die aufgeführten Risiken bei Anwendungen auf Basis der Enterprise Low Code Plattform A12 zu beachten ist:

1. Account Impersonation (LCNC-SEC-01)
   Punkt 1 beschreibt Risiken, die sich durch eingebettete Entwickler-Accounts ergeben. In A12 gibt es jedoch keine solchen Accounts. Stattdessenverfügt A12 über ein eigenes Authentifizierungs- und Autorisierungsmodell. Dementsprechend sind A12-Anwendungen von diesem Szenario nicht betroffen.
2. Authorization Misuse (LCNC-SEC-02)
   Siehe Punkt 4.
3. Data Leakage and Unexpected Consequences (LCNC-SEC-03)
   Siehe Punkt 4.
4. Authentication and Secure Communication Failures (LCNC-SEC-04)
   Die Punkte 2 bis 4 hängen eng mit Konnektoren zusammen, die Verbindungen zu weiteren externen Systemen herstellen. Hier kann es bei vielen Low-Code-Plattformen zu einem Missbrauch von Berechtigungen, Datenlecks oder Pannen bei der Authentifizierung und sicheren Kommunikation kommen. In A12 gehören solche Konnektoren nicht zum direkten Modellierungsumfang. Es gibt zwar vorgefertigte Adapter zu gängigen externen Systemen. Sie werden jedoch ausschließlich vom Entwicklungsteam nach individuellem Bedarf eingesetzt und gezielt abgesichert.
5. Security Misconfiguration (LCNC-SEC-05)
   Punkt 5 fasst den anonymen Zugang zu sensiblen Daten, ungeschützten öffentlichen Endpunkten sowie Probleme im Zusammenhang mit mandantenfähigen Anwendungen unter der Gesamtkategorie „Fehlkonfiguration“ zusammen. In A12 verfolgen wir das Konzept “Security by Default”. Das bedeutet, dass alle bereitgestellten Module im Standard sicher konfiguriert sind. In der Dokumentation weisen wir besonders auf Konfigurationen hin, die einen Einfluss auf die Sicherheit der Anwendung haben und die bei individuellen Lösungen berücksichtigt werden müssen.
6. Injection Handling Failures (LCNC-SEC-06)
   Punkt 6 adressiert Risiken durch das Einschleusen von Schadcode über von Nutzern bereitgestellte Daten – eine Gefahr, die potenziell alle Webanwendungen betrifft. Für das Überprüfen von Benutzereingaben verwendet A12 eine strenge Validierung sowohl auf der Client- als auch auf der Serverseite. Wenn die Anwendung auch Eingaben aus anderen Quellen erlaubt, sind projektspezifisch Sicherheitsvorkehrungen zu treffen.
7. Vulnerable and Untrusted Components (LCNC-SEC-07)
   Punkt 7 umfasst alle Risiken, die durch die Verwendung von verwundbaren und nicht vertrauenswürdigen Komponenten verursacht werden. In der A12-Entwicklung haben wir Prozesse implementiert, um alle unsere Abhängigkeiten regelmäßig auf bekannte Schwachstellen zu überprüfen. Als Teil der Build-Pipeline führt unser selbst entwickeltes Tool ATLAS verschiedene Sicherheitsscans durch. Potenzielle Schwachstellen der A12-Plattform und von auf Standard-A12-Komponenten basierenden Anwendungen werden so sehr früh erkannt.
8. Data and Secret Handling Failures (LCNC-SEC-08)
   Punkt 8 beinhaltet Probleme beim Speichern von vertraulichen Daten, wenn diese auf den geteilten Datenbanken und Systemen von Low-Code Anbietern abgelegt werden. A12 Anwendungen werden in der Regel so eingerichtet, dass sie komplett eigene Resourcen für Datenbanken, Secrets und Logs haben. Es bleiben daher alle sensitiven Daten in der Hand des Anwendungsbetreibers.
9. Asset Management Failures (LCNC-SEC-09)
   Punkt 9 beschreibt das Risiko, das durch nicht mehr genutzte Anwendungen entsteht, die von einzelnen Benutzern erstellt wurden. Da A12 ausschließlich für die Entwicklung von Geschäftsanwendungen im Rahmen von professionellen Software-Projekten mit größeren Teams zum Einsatz kommt, tritt dieser Fall in der A12-Praxis jedoch nicht auf.
10. Security Logging and Monitoring Failures (LCNC-SEC-10)
    Punkt 10 beschreibt Unzulänglichkeiten beim Logging und Monitoring. Hier sind zwei verschiedene Arten des Monitorings relevant: Einerseits ist die Überwachung des Datenverkehrs grundsätzlich für alle Webanwendungen – und damit auch für A12-basierte Anwendungen – unerlässlich. Hierfür werden typischerweise Standard-Logging-Tools eingesetzt, je nach Projektvorliebe. Andererseits müssen auch Änderungen in der Geschäftslogik überwacht werden. Da A12-basierte Anwendungen stets in professionelle Projektumgebungen eingebunden sind, werden alle Änderungen durch Versionsverwaltungsysteme dokumentiert.

Fazit

Die OWASP Low-Code/No-Code-Top-10 sind ein weiteres Zeichen für die zunehmende Verbreitung und die Maturität des Low-Code-Paradigmas. Awareness für die damit verbundenen Risiken zu schaffen, ist ein wichtiger Schritt, um die Anwendungsentwicklung mit Unterstützung von Business Analyst:innen und Citizen Developern sicherer zu machen.

Aufgrund seiner besonderen Ausrichtung als Enterprise Low Code Plattform, fallen für A12 einige der identifizierten Risiken weniger ins Gewicht. A12 ist schließlich nicht für schnell zusammenklickbare Apps ausgelegt, sondern für ausgewachsene Geschäftsanwendungen. Jede A12-Anwendung entsteht im Rahmen eines professionellen Softwareprojekts, das ohnehin alle gängigen Sicherheitsanforderungen an Webanwendungen erfüllen muss und von Sicherheitsexpert:innen begleitet wird.