Cloud, QA & Sicherheit

Penetrationstests für Webanwendungen

Gjethe testet Webanwendungen so, wie Angreifer sie angehen: Logins und Sitzungen, Zugriff zwischen Nutzern und Rollen, Eingabeverarbeitung, Zahlungen und Geschäftslogik. Die Tests folgen den OWASP-Richtlinien, jeder Befund kommt mit Belegen und einer Lösung, und ein Nachtest bestätigt, dass die Probleme behoben sind.

  • Kostenlose Erstberatung
  • Schriftliches Angebot für Ihr Projekt
  • Flexible Zahlungsmeilensteine
✓ build passed

Auf einen Blick

Standards
OWASP Top 10, OWASP ASVS, WSTG
Schwerpunkt
Zugriffskontrolle, Logik, Datenpreisgabe
Vorgehen
Meist Grey Box mit Testkonten
Ausgabe
Bericht, Korrekturen und Nachtest

Definition

Was ist Web-App-Penetrationstest?

Ein Web-Application-Penetrationstest ist eine manuelle Sicherheitsbewertung einer Website oder Web-App, die versucht, Kontrollen zu umgehen, an Daten zu gelangen, die nicht preisgegeben werden sollten, und Funktionen zu missbrauchen, um ausnutzbare Schwachstellen zu finden und zu beheben.

Die meisten ernsten Probleme in Webanwendungen sind nicht exotisch. Ein Nutzer, der die Rechnung eines anderen Kunden sieht, indem er eine Zahl in der Adresszeile ändert. Eine Admin-Aktion, die das Menü prüft, aber nicht die Anfrage dahinter. Ein Passwort-Reset, der wiederverwendet werden kann. An der Oberfläche verhalten sie sich normal; die Anwendung vertraut nur dem Falschen. Sie zu finden braucht einen Tester, der versteht, wie die Anwendung funktionieren soll, und gezielt prüft, ob die Regeln auf dem Server durchgesetzt werden und nicht nur in der Oberfläche versteckt sind.

Für wen ist es geeignet?

  • SaaS-Produkte

    Mehrere Kunden teilen sich ein System, daher muss die Trennung zwischen Konten lückenlos sein.

  • Onlineshops und Buchungssysteme

    Checkout, Rabatte, Lagerbestand und Zahlungen sind häufige Ziele von Missbrauch.

  • Portale mit personenbezogenen Daten

    Kunden-, Patienten- oder Mitgliederportale müssen jeder Person nur ihre eigenen Informationen zeigen.

  • Teams vor einem großen Release

    Ein Test vor dem Launch ist der günstigste Zeitpunkt, strukturelle Probleme zu finden.

Was enthalten ist und was Sie behalten

Was enthalten ist

  • Kartierung von Seiten, Funktionen und Nutzerrollen
  • Tests von Authentifizierung und Passwort-Reset
  • Prüfung von Sitzungsverwaltung und Tokens
  • Zugriffskontrolltests über Nutzer und Rollen hinweg
  • Tests der Eingabeverarbeitung und von Injection
  • Prüfung der Ausgabe- und clientseitigen Verarbeitung
  • Prüfung der Behandlung von Datei-Uploads und -Downloads
  • Tests auf Missbrauch von Geschäftslogik und Workflows
  • Prüfung auf Preisgabe sensibler Daten
  • Prüfung von Sicherheits-Headern, Cookies und TLS
  • Prüfung von Drittanbieter-Skripten und Abhängigkeiten
  • Bericht mit Nachweisen, Korrekturen und Nachtest

Was Sie erhalten

Wird am Ende übergeben. Gehört Ihnen.

  • Testbericht zur Webanwendung
  • Befunde den OWASP-Kategorien zugeordnet
  • Klare Beschreibung jedes bestätigten Problems
  • Priorisierter Behebungsplan
  • Nachtestbericht

Was wir in einer Webanwendung immer prüfen

  • Kann ein Nutzer die Daten eines anderen lesen oder ändern?
  • Kann ein normaler Nutzer Admin-Funktionen direkt erreichen?
  • Lassen sich Logins umgehen oder wiederverwenden?
  • Laufen Passwort-Resets und Einladungen korrekt ab?
  • Wird Nutzereingabe je als Code oder Abfrage behandelt?
  • Können hochgeladene Dateien dem Server oder anderen Nutzern schaden?
  • Lassen sich Preise, Mengen oder Workflow-Schritte manipulieren?
  • Enthalten Antworten Daten, die die Seite nie anzeigt?

Warum Zugriffskontrollprobleme der häufigste Befund sind

Fehlerhafte Zugriffskontrolle steht aus gutem Grund an der Spitze der OWASP Top 10. Frameworks erledigen viele Sicherheitsaufgaben automatisch, aber sie können nicht wissen, welche Datensätze zu welchem Kunden gehören oder welche Schaltflächen ein Manager drücken darf. Diese Regeln stehen in Ihrem Code, Funktion für Funktion geschrieben, und eine fehlende Prüfung genügt.

Wir testen das systematisch: Wichtige Anfragen werden als andere Nutzer und andere Rollen wiederholt, mit geänderten Kennungen, um zu sehen, ob der Server die Regel durchsetzt oder nur die Oberfläche die Option verbirgt. Es ist sorgfältige, repetitive Arbeit, und daher stammen viele der ernsten Befunde in modernen Anwendungen.

OWASP-Top-10-Bereiche, die wir abdecken

BereichBeispiel für das, was wir prüfen
Fehlerhafte ZugriffskontrolleDatensätze anderer Nutzer ansehen oder bearbeiten
Kryptografische FehlerSensible Daten ohne angemessenen Schutz gesendet oder gespeichert
InjectionAbfragen oder Befehle, die aus Nutzereingaben gebaut werden
Unsicheres DesignAbläufe, die konzeptionell missbraucht werden können
SicherheitsfehlkonfigurationDebug-Seiten, Standardeinstellungen, ausführliche Fehlermeldungen
Anfällige KomponentenVeraltete Bibliotheken mit bekannten Schwächen
AuthentifizierungsfehlerSchwache Behandlung von Login, Sitzung oder Reset
Software- und DatenintegritätUnsichere Updates oder nicht vertrauenswürdiger Drittanbieter-Code
Logging und MonitoringAngriffe, die unbemerkt blieben
Server-Side Request ForgeryDer Server ruft Adressen ab, die ein Angreifer kontrolliert

Die Teile einer App testen, die Scanner überspringen

Automatische Scanner erkennen gut reflektierte Eingaben und bekannte Muster, aber sie verstehen nicht, wofür Ihre Anwendung da ist. Sie können nicht wissen, dass ein Rabattcode nur einmal gelten soll, dass eine Rechnung im Entwurf nicht zahlbar sein sollte oder dass ein Support-Mitarbeiter Tickets sehen, aber die Abrechnung nicht ändern darf. Diese Regeln sind spezifisch für Ihr Geschäft, und ihr Bruch ist genau, wie echter Missbrauch geschieht.

Den größten Teil eines Web-App-Tests verbringen wir mit dieser menschlichen Seite: nachlesen, wie jede Funktion funktionieren soll, und dann prüfen, ob der Server es tatsächlich durchsetzt, wenn eine Anfrage in falscher Reihenfolge, mit geändertem Wert oder vom falschen Konto eintrifft. Das ist langsamer als ein Scan und weit nützlicher, weil es die Probleme erreicht, die Geld und Vertrauen kosten, und nicht die, die ein Tool ohnehin gemeldet hätte.

So funktioniert Penetrationstesting für Webanwendungen, Schritt für Schritt

Jeder Schritt hat ein klares Ergebnis, das Sie prüfen können. Der Zeitrahmen wird in Ihrem Angebot vereinbart.

  1. 1

    Umfang

    Anwendung, Umgebungen, Rollen und Testaccounts schriftlich abgestimmt.

  2. 2

    Karte

    Jede Seite, jede Anfrage und jede Rolle erfasst, bevor das Testen beginnt.

  3. 3

    Testen

    Manuelles Testen über die OWASP-Bereiche und Ihre Geschäftslogik.

  4. 4

    Verifizieren

    Jeder Befund sorgfältig bestätigt, mit ungefährlichem Nachweis der Auswirkung.

  5. 5

    Bericht

    Befunde, Risikobewertungen und Lösungen, denen Ihre Entwickler folgen können.

  6. 6

    Nachtest

    Korrekturen verifiziert und Bericht aktualisiert.

Tools und was Ihr Angebot beeinflusst

Die Preisgestaltung richtet sich nach Ihrem Projekt und wird in Ihrem Angebot vereinbart. Diese Faktoren bestimmen es.

Web-App-Penetrationstests: Preisfaktoren
FaktorWarum er wichtig ist
Größe der AnwendungMehr Seiten, Formulare und Endpunkte bedeuten mehr zu kartieren und zu testen.
Rollen und MandantenJede Rolle und jede Kundengrenze vervielfacht die Zugriffskontrolltests.
WorkflowsZahlungen, Freigaben und mehrstufige Prozesse brauchen sorgfältige Logiktests.
UmgebungEine stabile Staging-Kopie beschleunigt das Testen; empfindliche Produktion braucht mehr Sorgfalt.
Zugriff auf QuellcodeEin White-Box-Review zusätzlich zum Test bringt Tiefe und Aufwand.

Häufige Fehler, die Sie vermeiden sollten

Was bei uns am häufigsten schiefgeht und wie ein gutes Projekt es vermeidet.

  • Schaltflächen verstecken statt Berechtigungen prüfen

    Wenn der Server nicht jede Anfrage prüft, kann jeder, der die Adresse findet, die Funktion nutzen.

  • Werten aus dem Browser vertrauen

    Vom Browser gesendete Preise, Nutzer-IDs und Rollen lassen sich ändern; der Server muss sie bestimmen.

  • Ausführliche Fehlermeldungen

    Stack-Traces und Datenbankfehler geben Angreifern eine Karte Ihres Systems.

  • Nur mit einem Account testen

    Ohne Accounts für mehrere Nutzer und Rollen bleiben Zugriffskontrollprobleme verborgen.

Häufig gestellte Fragen

Brauchen Sie unseren Quellcode?

Nein, die meisten Web-App-Tests sind Grey Box mit Testkonten. Zugriff auf den Quellcode hilft uns, tiefer zu gehen, und ist bei kritischen Anwendungen nützlich.

Können Sie eine mit React oder Vue gebaute Single-Page-App testen?

Ja. Die Oberfläche läuft im Browser, daher konzentrieren wir uns auf die APIs dahinter, wo die echten Sicherheitsentscheidungen fallen müssen.

Testen Sie auf Produktion oder Staging?

Beides. Staging ist sicherer, wenn es der Produktion eng entspricht. Testen wir die Produktion, vereinbaren wir Zeitfenster und vermeiden Aktionen, die echte Kunden betreffen könnten.

Legen Sie echte Bestellungen oder E-Mails an?

Nur wo vereinbart. Wir nutzen Testkonten und Test-Zahlungsmodi und räumen Testdaten, die wir erzeugen, auf.

Wie bewerten Sie Risiken?

Jeder Befund erhält eine Bewertung danach, wie leicht er ausnutzbar ist und was ein Angreifer gewinnen könnte, mit CVSS, wo es passt, neben der Geschäftsauswirkung in verständlicher Sprache.

Genügt die Abdeckung der OWASP Top 10?

Sie ist eine starke Basis. Wir testen zusätzlich Ihre spezifische Geschäftslogik, die keine generische Liste vollständig abdeckt.

Können Sie nach unseren Korrekturen nachtesten?

Ja, ein Nachtest der Befunde ist enthalten und der Bericht wird mit den Ergebnissen aktualisiert.

Können Sie die Probleme auch beheben?

Ja. Als Entwicklungsteam können wir die Korrekturen umsetzen oder die Korrekturen Ihres Teams vor dem Nachtest prüfen.

Finden Sie heraus, was Ihre Webanwendung wirklich preisgibt.

Sagen Sie uns, was Sie brauchen. Sie erhalten eine ehrliche Einschätzung, einen klaren Plan und ein schriftliches Angebot. Die erste Beratung ist immer kostenlos.

  1. Wie es weitergeht
  2. 1Sie sagen uns, was Sie brauchen
  3. 2Wir melden uns möglichst innerhalb von 24 Stunden mit Rückfragen
  4. 3Sie erhalten ein schriftliches Angebot für Ihr Projekt