Leistungen
Partner
Anwendungsfälle
Kunden
Unternehmen
Kontakt
FRENDE
Applikation & Web

Eine Webanwendung vor dem Produktivgang testen

Eine Anwendung geht mit geprüften Funktionen und vermuteter Sicherheit live. Der applikative Penetrationstest macht aus dieser Vermutung einen Befund — bevor jemand anderes das übernimmt.

Die Herausforderung

Was ein Scanner nie finden wird

Die automatisierte Analyse deckt den Grossteil der bekannten technischen Mängel ab: veraltete Bibliotheken, fehlende Header, klassische Injections. Das ist nützlich, das ist schnell, und es gehört gemacht. Nur kennt ein Scanner Ihr Geschäft nicht.

Die teuersten Mängel liegen aber genau in Ihrer Logik: eine Bestellnummer, die sich hochzählen lässt, um das Dossier des nächsten Kunden zu lesen; eine Rolle, deren Berechtigung nur bei der Anzeige und nicht bei der Aktion geprüft wird; ein im Browser neu berechneter Preis; ein Freigabeschritt, den man überspringen kann. Keine dieser Lücken hat eine Signatur — man findet sie, indem man versteht, was die Anwendung tun soll.

Dazu kommt die Oberfläche, die der Browser nicht zeigt: die APIs. Sie tragen oft lockerere Kontrollen als die Oberfläche, die sie aufruft, weil niemand damit rechnet, dass sie direkt angesprochen werden. Diese Annahme hält der Prüfung selten stand.

Was auf dem Spiel steht
  • Zugriff auf Daten eines anderen Kunden durch blosses Ändern einer Kennung
  • Berechtigungsprüfung bei der Anzeige vorhanden, bei der Aktion nicht
  • API schwächer geschützt als die Oberfläche, die sie nutzt
  • Geschäftsregel umgehbar, indem ein Schritt übersprungen wird
  • Korrekturen ausgeliefert, ohne zu prüfen, ob sie halten
Schema

Fünf Schritte, einer davon oft vergessen

Ablauf eines applikativen Penetrationstests 1Scoping& Konten2FunktionaleKartierung3ManuelleAusnutzung4PriorisierteRückgabe5Nachtestder Korrekturen
Der Nachtest ist keine Formsache: Er unterscheidet einen gelesenen Bericht von einem tatsächlich geschlossenen Risiko.
Unser Vorgehen

Wie wir vorgehen

Der Test läuft vorzugsweise auf einer Abnahmeumgebung, die der Produktion entspricht — mit repräsentativen, aber keinen echten Kundendaten.

01

Scoping und Zugänge

Umfang, Umgebung, zu prüfende Rollen und Rules of Engagement. Wir bitten um Konten jeder Berechtigungsstufe: Nur so lässt sich prüfen, dass ein einfacher Benutzer nicht kann, was eine Administration kann.

02

Funktionale Kartierung

Die Anwendung wie ein Benutzer durchlaufen, dann Einstiegspunkte, darunterliegende APIs und die sie steuernden Geschäftsregeln erfassen. Dieser Schritt bestimmt alles Weitere: Gut prüfen lässt sich nur, was man verstanden hat.

03

Manuelle Ausnutzung

Suche nach Mängeln in Berechtigung und Geschäftslogik, in Authentisierung und Sitzungsführung, nach Injections und verwundbaren Abhängigkeiten. Jeder Fund wird bis zum Nachweis seiner realen Wirkung ausgenutzt, nie als Verdacht belassen.

04

Priorisierte Rückgabe

Ein Bericht mit zwei Lesarten: was ein Angreifer erreichen konnte und was zu entscheiden ist, dann der technische Teil mit reproduzierbarem Nachweis und Korrekturvorschlag. Sortiert wird nach dem Risiko in Ihrem Kontext, nicht nach einem rohen Punktwert.

05

Nachtest

Nach der Behebung spielen wir die vereinbarten Szenarien erneut durch und prüfen, ob die Korrekturen halten und das Problem nicht bloss verschoben haben.

Eingesetzte Leistungen

Mehrere Disziplinen, eine Ansprechperson

Der Test deckt auf, das Code-Review geht an die Wurzel, die Schulung verhindert die Wiederholung.

Ergebnisse
  • Nach tatsächlichem Risiko priorisierter Bericht
  • Von Ihren Teams reproduzierbarer Exploit-Nachweis
  • Korrekturvorschlag zu jedem Befund
  • Technische und Management-Präsentation
  • Nachtest zur Bestätigung der Behebung
Häufige Fragen

Häufige Fragen

Auf der Abnahmeumgebung, sofern sie der Produktion entspricht und die Daten repräsentativ sind. Das ist der bequemere Rahmen: Man kann ohne Rücksicht suchen. Ein Test in der Produktion bleibt möglich, mit strengeren Rules of Engagement — zerstörende Handlungen ausgeschlossen, vereinbartes Zeitfenster, erreichbare Ansprechperson auf beiden Seiten.

Konten ja, und zwar jeder Berechtigungsstufe: Ohne sie lassen sich die Berechtigungsregeln nicht prüfen, und genau dort liegen die schwerwiegendsten Mängel. Quellcode ist nicht erforderlich, beschleunigt und vertieft aber erheblich — das ist Gegenstand eines Code-Reviews, ergänzend.

Ein Jahrestest fotografiert eine Anwendung, die sich seither fünfzigmal verändert hat. Bei rascher Auslieferung hält die automatisierte Analyse die laufende Abdeckung, und der manuelle Test konzentriert sich auf strukturelle Änderungen: neuer Ablauf, neue Rolle, neue Exposition.

Nein, beide ergänzen sich. Der Scanner deckt bekannte Mängel breit und laufend ab; der manuelle Test findet, was in Ihrer Geschäftslogik wurzelt und keine Signatur beschreibt. Auf den ersten zu verzichten kostet Abdeckung, auf den zweiten kostet Tiefe.

Ihre Anwendung geht nächste Woche live?

Beschreiben Sie uns ihren Umfang — wir sagen Ihnen, was ein Test bis dahin abdecken kann.