Moodle App - Sicherheit

Die Moodle App ist eine Hybrid-App (die Web-Technologien nutzt), die auf Basis eines bewährten und weit verbreiteten Frameworks Cordova entwickelt wurde, das einen robusten Container für HTML Apps bereitstellt.

Sicherheit ist uns sehr wichtig. Deshalb halten wir uns an die OWASP-Grundsätze sowie an die Sicherheitsempfehlungen von Cordova und Moodle. Zudem führen wir KI-gestützte Sicherheitsüberprüfungen mit maßgeschneiderten Vorgaben für unseren spezifischen Kontext durch.

• Cordova: https://cordova.apache.org/docs/en/latest/guide/appdev/security/
• Moodle: https://docs.moodle.org/dev/Security (bei der Entwicklung von Web Services)

Unser Sicherheitsansatz

• Anmeldung und Autorisierung
  • Die Autorisierung erfolgt über temporäre Zugriffstoken. Die Gültigkeitsdauer der Zugriffstoken kann über die Moodle-Einstellungen konfiguriert werden.
  • Das Single Sign On (oder die automatische Anmeldung) von der App zur Moodle-Site erfolgt mithilfe eines speziellen privaten Tokens (das beim Anmelden der Nutzer/innen über die App abgerufen und gespeichert wird).
  • Das Single Sign On (oder die automatische Anmeldung) von der App zur Moodle-Site unterliegt einigen zusätzlichen Einschränkungen (z.B. ist es auf wenige Male pro Stunde begrenzt)
  • Die QR-Anmeldung erfolgt über temporäre Token, für die Nutzer/innen sich im selben Netzwerk (mit derselben IP-Adresse) befinden müssen, und ist auf 10 Minuten begrenzt.
  • Zum Abrufen von Dateien vom Server (Bilder oder andere Assets) wird ein anderes Token verwendet, das keine Authentifizierung erfordert.
  • Authentifizierungstoken werden sicher im Keystore/Schlüsselbund des Geräts gespeichert.

• Berechtigungen
  • Die App hat nur Zugriff auf einen Teil der Moodle-Funktionen (verfügbar über den Moodle App Service).
  • Eine Erweiterung der Berechtigungen über die Web-Services-Ebene ist nicht möglich, da alle Vorgänge ohne erweiterte Berechtigungen ausgeführt werden und die Berechtigungen auf der Grundlage der aktuell authentifizierten Person geprüft werden.
  • Selbst wenn ein temporäres Zugriffstoken für die Moodle-Administration (oder privilegierte Nutzer/innen) abgefangen würde, wäre es Angreifer/innen nicht möglich, über den Moodle-App-Service auf die Funktionen der Website-Administration von Moodle zuzugreifen.

Da es sich bei der App um einen Webservice-Client handelt, empfehlen wir, sie nur über HTTPS zu aktivieren und die folgenden Einstellungen zu verwenden, um die Sicherheit zu gewährleisten:

• Legen Sie über Systemfunktionen fest, dass nur bestimmte Rollen über die App zugreifen dürfen (vermeiden Sie Moodle-Administrator/innen)
• Verwenden Sie die Moodle-Sicherheitseinstellungen, um die Gültigkeitsdauer von Webservice-Zugriffstoken zu verkürzen (damit sich Nutzer/innen erneut authentifizieren müssen)
• Darüber hinaus sorgt das Cordova-Framework für Sicherheit, indem es Einschränkungen hinzufügt, wie z.B. das Vermeiden von Verbindungen zu Websites, die nicht vertrauenswürdig sind.

Wie läuft der Prozess bei Sicherheitsproblemen mit der Moodle App ab?

• Wir halten uns an den Standard-Sicherheitsprozess von Moodle: https://docs.moodle.org/dev/Moodle_security_procedures
• Es gibt nur einen wesentlichen Unterschied: Sicherheitspatches werden sofort in der nächsten App-Version oder in einer Notfallversion (je nach den mit dem Problem verbundenen Risiken) implementiert.

Geteilte Verantwortung

• Die Organisation, die die Moodle-Sete hostet, ist auch dafür verantwortlich, einen sicheren Zugriff auf die Moodle-Site zu gewährleisten. Moodle sollte so konfiguriert sein, dass HTTPS (sichere Verbindung) verwendet wird, damit die Verbindung zwischen der App und Moodle verschlüsselt ist.
• Darüber hinaus kann die Moodle-Administration zusätzliche Sicherheitsmaßnahmen aktivieren, wie beispielsweise die Durchsetzung einer Ende-zu-Ende-Verschlüsselung für Push-Benachrichtigungen über die Benachrichtigungseinstellungen der Website-Administration von Moodle.

Führen Sie Sicherheits-, Penetrations- oder Pentest-Tests sowie statische Codeanalysen durch?

Wir führen regelmäßig KI-gestützte Sicherheitsüberprüfungen mit verschiedenen Modellen und Prompts durch.

Außerdem erhalten wir automatisierte Schwachstellenberichte dieser Art. Das Problem bei automatisierten Tools ist, dass sie in der Regel allgemeine Ergebnisse liefern, die darauf hinweisen, wo ein Exploit möglich sein könnte, was bedeutet, dass die Ergebnisse oft viele Fehlalarme enthalten.

Wie oben erwähnt, basiert unsere App auf Cordova; daher sind wir darauf angewiesen, dass die Entwickler/innen des Cordova-Frameworks etwaige Probleme mit nativem Code erkennen.

Wenn Sie im Cordova-Projekt-Tracker suchen, werden Sie feststellen, dass mehrere Durchläufe mit dem Veracode-Tool zur statischen Codeanalyse Probleme aufgedeckt haben, die bereits behoben wurden, siehe: https://issues.apache.org/jira/issues/?jql=project%20%3D%20CB%20AND%20text%20~%20%22veracode%22%20ORDER%20BY%20priority%20DESC%2C%20updated%20DESC

Leider sind diese Veracode-Läufe nicht öffentlich zugänglich, da sie in den meisten Fällen von externen Parteien unter Verwendung des Frameworks durchgeführt werden.

Bitte beachten Sie außerdem, dass es CVE-Codes für Sicherheitsprobleme bei Cordova gibt: https://www.cvedetails.com/product/27153/Apache-Cordova.html?vendor_id=4

Um eine sichere Entwicklungsumgebung zu gewährleisten, nutzen wir npm audit, um regelmäßig Sicherheitslücken in unseren Paketabhängigkeiten zu erkennen und zu beheben. Wir überwachen proaktiv alle von GitHub bereitgestellten Sicherheitswarnungen und Dependabot-Benachrichtigungen, um CVEs in den Abhängigkeiten unserer Repositorys zu identifizieren und zu beheben.

Warnungen, die typischerweise von statischen Code- oder KI-Analyse-Tools ausgelöst werden

• Fehlende Jailbreak-Erkennung: Die Moodle App verfügt über keine Jailbreak- oder Root-Erkennung. Dies liegt am Fehlen offizieller APIs von Google oder Apple, und unsere Tests mit bestehenden inoffiziellen Plugins zur Unterstützung dieser Funktion ergaben eine hohe Rate an Fehlalarmen, insbesondere auf Android-Geräten der unteren Preisklasse oder bei aktuellen iOS-Updates. Insbesondere speichert die App Authentifizierungstoken sicher im Keystore/Keychain und nicht in der Sitzung. Das Sitzungstoken wird nur für den vorübergehenden Abruf von Inhalten verwendet und hat eine begrenzte Gültigkeitsdauer, wodurch sichergestellt wird, dass Angreifer/innen selbst auf kompromittierten Geräten keine sensiblen Daten extrahieren können, um sich als andere auszugeben.
• Kein Zertifikat-Pinning: Die Moodle App unterstützt kein Zertifikat-Pinning, da sie dafür ausgelegt ist, eine Verbindung zu jeder beliebigen Moodle-Site weltweit herzustellen (es gibt Hunderttausende von Seiten, die Moodle nutzen und jeweils eine eigene URL haben), unabhängig davon, ob diese über HTTPS, HTTP oder in lokalen Netzwerken gehostet werden. Zudem unterstützt das von uns verwendete Cordova-Framework Zertifikat-Pinning nicht nativ.
• Fehlende Verschlüsselung für Manifest-Dateien: Die App enthält keine sensiblen Schlüssel oder Zertifikate in öffentlich zugänglichen Dateien, wodurch die Verschlüsselung von Manifest-Dateien entfällt. Die im GitHub-Repository der App verfügbaren Firebase-Zertifikate sind an den Fingerabdruck der App gebunden, wodurch sichergestellt ist, dass sie nicht missbraucht werden können.
• Statische Web Service Authentifizierungstoken (Session Fixation): Web Service Token werden bewusst nicht bei jeder Anmeldung neu generiert. Dies entspricht der Funktionsweise der Moodle Web Services API und ermöglicht es Nutzer/innen, sich über mehrere Geräte (z.B. Smartphone und Tablet) anzumelden, ohne dass die Token ungültig werden. Eine Neugenerierung der Token würde den Zugriff über mehrere Geräte einschränken.
• Fehlende Code-Verschleierung: Der Code der App ist Open Source. Da bei der Kompilierung keine Schlüssel oder privaten Daten generiert werden, ist eine Code-Verschleierung nicht erforderlich.
• cleartextTrafficPermitted auf true gesetzt: Die Moodle App ermöglicht die Verbindung zu jeder Moodle-Site, unabhängig davon, ob diese SSL verwendet oder nicht. Diese Einstellung ist erforderlich, um die Verbindung zu HTTP-Seiten zu ermöglichen (beispielsweise in lokalen Netzwerken).
• Die Content-Security-Policy ist sehr freizügig: Die Moodle App ermöglicht die Verbindung zu jeder Moodle-Site, daher kann die CSP nicht auf eine Liste von URLs beschränkt werden. unsafe-eval ist erforderlich, um die Ausführung des JavaScript-Codes von an die App angepassten Moodle-Plugins zu ermöglichen. unsafe-inline wird benötigt, da nutzergenerierte Inhalte Inline-Elemente enthalten können.
• Verwendung von eval: Die App nutzt eval, um JavaScript-Code aus Plugins, die an die App angepasst wurden, dynamisch auszuführen. In Zukunft wird dies wahrscheinlich durch new Function() ersetzt, um die Isolierung des Gültigkeitsbereichs zu verbessern, aber es handelt sich weiterhin um eine dynamische Codeausführung. eval wird ausschließlich zur Ausführung von vertrauenswürdigem Code verwendet (Plugins, die von der Moodle-Administration auf der Moodle-Site installiert wurden).
• <allow-intent href="*" />: Die App benötigt dies, um externe Apps über nutzerdefinierte URL-Schemata (Deep Links) zu starten, die nicht im Voraus bekannt sind.
• <access origin="*"/>: Die App benötigt diese Berechtigung, da sie Dateien aus verschiedenen Quellen herunterladen muss, sowohl Dateien, die auf der Moodle-Site gehostet werden, als auch Dateien aus nutzergenerierten Inhalten.
• <allow-navigation href="*" />: Die iOS-App benötigt dies, um iframes darzustellen, die auf eine URL verweisen, die nicht im Voraus bekannt ist, beispielsweise bei nutzergenerierten Inhalten oder nutzerdefinierten Menüelementen.
• Verwendung von Math.random oder MD5 für SSO-Passports: Die App nutzt diese Funktionen zur Generierung einmalig verwendbarer temporärer IDs, um lediglich das Gerät zu identifizieren, von dem aus ein SSO gestartet wurde; dies hat jedoch keinerlei Auswirkungen auf die Sicherheit – das Manipulieren oder Erfassen dieser temporären IDs hat keinerlei Auswirkungen auf die Sicherheit.
• Fehlerhafte Sitzungszeitüberschreitung und Abmeldefunktion: Die Moodle App folgt einem gängigen Ansatz, der von den meisten mobilen Apps unter Android und iOS verwendet wird: Nutzer/innen werden nach kurzen Inaktivitätsphasen nicht dazu aufgefordert, sich erneut anzumelden. Mobile Geräte bieten durch Funktionen wie die automatische Sperrung bei Inaktivität einen ausreichenden Schutz. Die Moodle-Administration hat jedoch die volle Kontrolle darüber, wie die App mit Sitzungszeitüberschreitungen und dem Abmeldeverhalten umgeht. Sie kann:
  • festlegen, wie die Abmeldefunktion funktioniert (weiche Abmeldung oder vollständige Beendigung der Sitzung);
  • eine nutzerdefinierte Zeitüberschreitung für die Sitzung festlegen;
  • die Gültigkeitsdauer des Authentifizierungstokens für den Web Service konfigurieren.

Diese Einstellungen können auf folgenden Seiten vorgenommen werden:

• • Website-Administration > Allgemein > Mobile App > Mobile Authentifizierung
  • Website-Administration > Allgemein > Sicherheit > Sicherheitseinstellungen