Cyber-Safe: Web & Mobile Pentesting für Profis

Willkommen in der Welt des Penetration Testings (kurz: Pentesting). Im Kern geht es darum, kontrolliert und sicher in eigene Systeme einzubrechen. Das Ziel: Sicherheitslücken finden, bevor es die Kriminellen tun.

Während bösartige Hacker („Black Hats“) Schwachstellen für Profit oder Chaos ausnutzen, agieren Pentester als „White Hats“. Du nutzt dieselben Techniken und Tools, aber mit einem anderen Ziel: die Anwendung zu härten.

Der Pentesting-Prozess ist strukturiert: Er beginnt mit der Reconnaissance (Informationsbeschaffung), geht über zum Scanning (Einstiegspunkte finden), zur Exploitation (Lücken ausnutzen) und endet im Reporting.

Um ein Profi zu werden, brauchst du das Hacker-Mindset. Wenn du ein Login-Feld siehst, fragst du nicht: „Wie benutze ich das?“, sondern: „Wie bringe ich das System dazu, etwas völlig Unerwartetes zu tun?“

Bevor die erste Zeile Code getestet wird, müssen die Rules of Engagement (RoE) stehen. Dies ist ein rechtlich bindendes Dokument, das festlegt, was du hacken darfst, wann und mit welchen Methoden.

Hacken ohne explizite, schriftliche Erlaubnis ist eine Straftat – selbst bei edlen Absichten. Die RoE definieren den Scope: Du darfst vielleicht `api.example.com` testen, aber niemals den Abrechnungsserver anrühren.

Tests werden nach dem Informationsstand kategorisiert. Beim Black-box-Test startest du blind, wie ein externer Angreifer. Beim White-box-Test hast du vollen Zugriff auf den Quellcode und die Architektur.

Dazwischen liegt der Grey-box-Test. Hier hast du die Rechte eines normalen Nutzers. Das ist im Web- und Mobile-Bereich extrem üblich, um zu prüfen, was ein regulärer Kunde böswillig ausnutzen könnte.

Um eine Web-App zu hacken, musst du ihre Architektur verstehen. Moderne Apps bestehen aus zwei Welten: dem Client (dein Browser) und dem Server (der Computer, der Daten verarbeitet).

Die Kommunikation erfolgt über HTTP-Requests und Responses. Klickst du einen Link, sendet der Browser einen Request. Der Server verarbeitet diesen und schickt eine Response mit der Webseite zurück.

Als Pentester suchst du die Attack Surface (Angriffsfläche). Das sind alle Punkte, an denen Daten eingegeben oder Interaktionen stattfinden können. Nicht nur Textfelder, sondern auch versteckte URL-Parameter und HTTP-Header gehören dazu.

Indem du diese Interaktionen abfängst und analysierst, siehst du die App nicht mehr als bunte Oberfläche, sondern als komplexes Getriebe aus Datenströmen, die manipuliert werden können.

Eine der fatalsten Lücken ist die SQL-Injection (SQLi). Datenbanken sprechen SQL. Web-Apps senden ständig SQL-Befehle an ihre Datenbanken, um etwa Profile abzurufen oder Passwörter zu prüfen.

Eine Schwachstelle entsteht, wenn eine App User-Input blind vertraut und ihn direkt in einen Befehl einbaut. Ein Login-Query könnte so aussehen: `SELECT * FROM users WHERE username = 'DEIN_INPUT'`.

Gibst du als User `admin' --` ein, könnte die Datenbank das Anführungszeichen als Ende des Inputs und `--` als Kommentar lesen – der Passwort-Check wird ignoriert! Du hast die Datenbank gezwungen, deinen Input als Code auszuführen.

SQLis ermöglichen es, Daten zu stehlen, Kontostände zu ändern oder Datenbanken zu löschen. Pentester suchen danach, indem sie Sonderzeichen nutzen und auf Fehlermeldungen achten.

Während SQLi den Server angreift, zielt Cross-Site Scripting (XSS) auf die Browser anderer Nutzer ab. Es passiert, wenn eine App ungeprüfte Daten in einer Webseite anzeigt.

Stell dir ein Forum vor. Wenn die Seite Inputs nicht filtert, könnte ein Hacker einen Kommentar mit JavaScript posten, zum Beispiel: ``. Das ist fatal.

Besuchst du diese Seite, lädt dein Browser den Kommentar, hält das Skript für legitim und führt es aus. Man nennt das Stored XSS, da der schädliche Code dauerhaft auf dem Server gespeichert ist.

Mit XSS können Hacker Sessions stehlen, User auf Phishing-Seiten umleiten oder Website-Inhalte verändern. Pentester testen dies oft mit harmlosen Alert-Boxen, um die Ausführung von Fremdcode zu beweisen.

Ein häufiger Fehler ist Broken Access Control. Hierbei müssen wir Authentifizierung (Wer bist du?) von Autorisierung (Was darfst du?) unterscheiden. Letzteres ist oft die Schwachstelle.

Stell dir vor, du bist in deinem Online-Banking eingeloggt. Die URL endet auf `?account_id=1005`. Was passiert, wenn du die Zahl einfach auf `1006` änderst und Enter drückst?

Prüft der Server nicht, ob *du* berechtigt bist, das Konto 1006 zu sehen, werden dir fremde Daten angezeigt. Diese Lücke nennt man Insecure Direct Object Reference (IDOR).

Pentester verbringen viel Zeit damit, Berechtigungen zu testen. Sie nutzen zwei Test-Accounts und versuchen, mit Account A die privaten Daten oder Funktionen von Account B zu manipulieren oder einzusehen.

Mobile Pentesting erfordert ein Umdenken. Eine App ist kein Browserfenster; sie ist Software (APK oder IPA), die physisch auf dem Gerät des Nutzers installiert ist.

Da die App lokal läuft, ändert sich die Attack Surface massiv. Beim Web-Testing siehst du den Servercode fast nie. Beim Mobile-Testing hält der Angreifer den binären Code quasi in den Händen.

Pentester nutzen Reverse Engineering, um Apps zu analysieren. Mit Spezialtools dekompilieren sie die App zurück in lesbaren Code, um nach hardcodierten Passwörtern oder geheimen API-Keys zu suchen.

Zudem interagieren Apps tief mit dem Betriebssystem. Pentester analysieren den lokalen Speicher, die Kamera-Nutzung und die Kommunikation zwischen verschiedenen Apps auf demselben Smartphone.

Mobile Apps nutzen oft lokalen Speicher, um schnell und offline zu funktionieren. Die Gefahr: Entwickler wiegen sich in falscher Sicherheit und halten das Smartphone für einen Tresor.

Oft werden sensible Daten wie Passwörter oder Auth-Token im Klartext in lokalen SQLite-Datenbanken oder XML-Dateien gespeichert. Das ist riskant, wenn das Handy verloren geht oder mit Malware infiziert wird.

Angreifer können per Root (Android) oder Jailbreak (iOS) die Sandbox-Sicherheit des Systems umgehen und auf diese unverschlüsselten Dateien zugreifen. Die Daten liegen dann offen.

Als Pentester installierst du die App auf einem gerooteten Testgerät, nutzt sie ganz normal und durchsuchst danach das Dateisystem. Du suchst nach Informationen, die „unter der Matte“ liegen gelassen wurden.

Mobile Apps kommunizieren ständig mit APIs im Internet. Diese Übertragung muss gesichert sein. Ohne korrekte HTTPS-Verschlüsselung sind die Daten im WLAN (z. B. im Café) leichte Beute.

Ein Hacker kann einen Man-in-the-Middle (MitM) Angriff durchführen, um Daten abzufangen oder zu manipulieren. Um das zu verhindern, nutzen Profis Certificate Pinning.

Beim Pinning vertraut die App nur einem ganz bestimmten Server-Zertifikat. Gefälschte Zertifikate eines Angreifers werden sofort abgelehnt. Das macht das Mitlesen für Fremde fast unmöglich.

Ironischerweise müssen Pentester für API-Tests MitM-Angriffe auf sich selbst ausführen. Sie nutzen Frameworks wie Frida, um Pinning zu umgehen, damit sie den Traffic in ihren eigenen Analyse-Tools sehen können.

Für professionelles Pentesting reicht ein Browser nicht aus. Die wichtigste Waffe ist der Intercepting Proxy. Die bekanntesten Tools sind Burp Suite und OWASP ZAP.

Diese Tools sitzen zwischen deiner App und dem Internet. Sie fangen jeden HTTP-Request ab, bevor er deinen Rechner verlässt. Du kannst den Request stoppen, inspizieren und manipulieren.

Du könntest zum Beispiel einen Preis im Request von `100€` auf `1€` ändern, bevor er den Server erreicht! Aber das Finden von Lücken ist nur der erste Teil der Arbeit.

Der wichtigste Schritt ist der Report. Ein guter Pentester übersetzt technische Exploits in Geschäftsrisiken. Der Bericht erklärt, wie die Lücke gefunden wurde, welcher Schaden droht und wie die Entwickler sie fixen können.