OWASP Mobile Top 10 Risks 2014

Die Stiftung Open Web Application Security Project (OWASP) ist eine gemeinnützige Non-Profit-Organisation in den Vereinigten Staaten, welche sich mit der Sicherheit für Web-Apps beschäftigt und regelmäßig eine Liste mit den zehn häufigsten Sicherheitslücken veröffentlicht. Mittlerweile gibt es neben dieser Liste auch eine weitere Liste für die zehn häufigsten Sicherheitslücken in mobilen Apps und ist ein aus der Community heraus entstandenes, freies Projekt, welches Entwicklern und Sicherheits-Teams als zentrale Ressource dienen soll. Ziel ist es Sicherheitsrisiken zu klassifizieren und Kontrollen für die Entwicklung anzubieten, die die Auswirkungen oder die Wahrscheinlichkeit der Ausbeutungen reduzieren. Folgende zehn numerisch sortierte Sicherheitslücken wurden für das Jahr 2014 veröffentlicht:

M1: Weak Server Side Controls
Auf Platz 1 und damit die kritischste Risikokategorie stehen die unzureichend abgesicherten serverseitigen Komponenten. Dieses Risiko umfasst alle Sicherheitslücken, die in einem Web Service, einem Webserver oder einem Application Programming Interface (API)-Aufruf auf dem Server auftreten können. Durch unsichere Codierungstechniken ist es möglich, über die mobile Schnittstelle bösartige Eingaben, wie bspw. Cross-Site-Scripting oder SQL-Injection-Angriffe, durchzuführen sowie unerwartete Folgen von Ergebnissen zu erhalten. Dies kann auch den Client betreffen, der die Anfragen versendet, da auch er solche Ergebnisse geliefert bekommen kann und somit verwundbar ist.

M2: Insecure Data Storage
Dies betrifft die unsichere Speicherung von Daten auf einem mobilen Gerät. Dabei sollte immer davon ausgegangen werden, dass Benutzer oder Malware Zugang auf das Dateisystem oder den Speicher eines mobilen Gerätes und somit auf vertrauliche Informationen erlangen könnten. Die Arten von Daten und vor allem wie die Speicherung dieser auf dem Gerät erfolgt unterliegen einer Prüfung. Zugangsinformationen können z.B. im Schlüsselbund hinterlegt werden und Daten per Dateiverschlüsselung.

M3: Insufficient Transport Layer Protection
Um den Netzwerkverkehr zwischen Server und Client zu schützen, sollte das Secure Socket Layer (SSL) bzw. Transport Layer Security (TLS)-Verschlüsselungsprotokoll zum Einsatz kommen. Doch es reicht nicht aus, nur den Anmeldevorgang zu schützen, sondern es sollten auch alle Verbindungen einer Sitzung abgesichert werden, so dass ein Web Service idealerweise nur noch über HTTPS erreichbar ist und somit der Netzwerkverkehr nicht im Klartext übertragen wird. Dennoch gibt es auch hier Unterschiede in der Implementierung, da nicht alle Protokollversionen sowie die eingesetzten Verschlüsselungsmethoden als sicher gelten.

M4: Unintended Data Leakage
Ein unbeabsichtigtes Datenleck tritt auf, wenn versehentlich vertrauliche Informationen oder Daten an einem Speicherort auf dem mobilen Gerät abgelegt werden, die leicht von anderen Anwendungen zugänglich sind oder auf die Angreifer zugreifen können. Dabei können diese Daten bspw. in Caches (Copy/Paste, Tastatureingabe) oder Logfiles liegen und sind meist eine Nebenwirkung vom zugrundeliegenden Betriebssystem.

M5: Poor Authorization and Authentication
Hierbei handelt es sich um Schwachstellen in der Autorisierung und Authentifizierung, die innerhalb der serverseitigen Implementierung oder der mobilen App auftreten können. Das betrifft häufig die lokale Authentifizierung innerhalb einer mobilen App, die auf vertrauliche Informationen zugreift oder im Offline Modus agiert. Wo geeignete Sicherheitskontrollen fehlen besteht die Möglichkeit, die Authentifizierung zu umgehen. Dieses Risiko bezieht sich auch auf Schwachstellen in der Autorisierung, so dass ein Benutzer auf Funktionen zugreifen oder ausführen kann, die außerhalb seiner Berechtigungen liegen.

M6: Broken Cryptography
Nicht jeder kryptografische Algorithmus ist auch sicher. Mittels schwacher Verschlüsselung ist es einem Angreifer möglich, sensible Informationen zu entschlüsseln, d.h. wieder lesbar zu machen. Einer dieser schwachen Algorithmen ist die kryptografische Hashfunktion MD5. Dabei liegt es nicht immer am Algorithmus selbst, sondern auch an der Implementierung.

M7: Client Side Injection
Über eine mobile App kann Schadcode in Form von SQL-Injection oder Cross-Site-Scripting eingeschleust und ausgeführt werden, umso an die clientseitige Datenbank oder serverseitig an Informationen zu kommen. Dazu zählen auch Angriffe, die auf Pufferüberlaufschwachstellen abzielen, da auch hier unerwünschte Eingaben eingeschleust und den Speicherbereich zum Überlauf bringen oder aber auch Brute-Force Angriffe, dem widerholten Ausprobieren von möglichem Schadcode.

M8: Security Decisions Via Untrusted Inputs
Die Verwendung von ausgeblendeten Feldern und Werten oder versteckten Funktionen, um zwischen Benutzerebenen zu unterscheiden, welche sich meistes auf Interprocess Communication (IPC) Mechanismen beziehen, können von Angreifern abgefangen und mit sensiblen Parametern ergänzt werden, umso erhöhte Rechte zu erlangen oder an die Sitzungs-ID zu gelangen.

M9: Improper Session Handling
Zu Beginn einer Sitzung wird nach der Authentifizierung eines Benutzers eine Session-ID an diesen übergeben, um ihn so bei jeder Transaktion zu identifizieren. Fehler in der Handhabung mit solchen Session-IDs können dazu führen, dass die ID in fremde Hände gelangt, umso unberechtigte Transaktionen durchzuführen.

M10: Lack of Binary Protections
In der letzten Risikokategorie geht es um den defensiven Schutz, den Entwickler in mobile Apps einbauen können. Somit werden keine Angriffsflächen geboten, was bedeutet, dass Angreifer keine Chance zum analysieren, Reverse-Engineering oder modifizieren haben. Sensible Daten sind grundsätzlich besser auf einem Server aufgehoben und sollten nur im nötigen Umfang und ausreichend geschützt auf dem Client vorliegen.

Kommentar verfassen

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.