Umfang und Testart
Black Box ohne Vorwissen, Grey Box mit Testkonten je Rolle oder White Box mit Einblick in den Code. Für die meisten Anwendungen empfehlen wir Grey Box, weil sie mit demselben Budget am meisten findet.
Was geprüft wird, legen wir gemeinsam fest. Typische Schwerpunkte für Webanwendungen und ihre Umgebung sind die folgenden.
Black Box ohne Vorwissen, Grey Box mit Testkonten je Rolle oder White Box mit Einblick in den Code. Für die meisten Anwendungen empfehlen wir Grey Box, weil sie mit demselben Budget am meisten findet.
Horizontale und vertikale Rechteausweitung: Sieht ein Kunde fremde Daten, erreicht ein einfacher Benutzer Verwaltungsfunktionen, funktionieren gesperrte Konten weiter?
Passwortregeln, zweiter Faktor, Passwort-Zurücksetzen, Sitzungsdauer und Single Sign-on über Entra ID oder ID Austria, sofern eingesetzt.
Injection in Datenbank und Betriebssystem, Cross-Site-Scripting, manipulierte Dateien und Parameter, die Preise, Mengen oder Kundennummern verändern.
Ob die API selbst prüft, wer was darf, ob sie Anfragen begrenzt und ob die App vertrauliche Schlüssel im Gerät ablegt.
Erreichbare Verwaltungsoberflächen, veraltete Komponenten, fehlende Sicherheitsheader, offene Speicher in der Cloud und vergessene Testsysteme.
Jeder Befund mit CVSS-Bewertung, Nachweis und Behebungsvorschlag, eine Zusammenfassung für die Geschäftsführung und nach der Behebung eine Bestätigung.
Ohne unterschriebene Freigabe beginnen wir nicht. Unsere IP-Adressen erhalten Sie vorab, damit Ihr Team uns in den Protokollen erkennt.
Umfang, Testart, Zeitfenster, Notfallkontakte und die Freigabe des Inhabers, bei gehosteten Systemen auch des Hosters.
Aufklärung der Angriffsfläche und manuelle Prüfung mit Werkzeugen wie Burp Suite, ohne Denial-of-Service und ohne Veränderung echter Daten.
Übergabe verschlüsselt an benannte Personen und Besprechung per Videotermin mit Entwicklung und Geschäftsführung.
Prüfung der Korrekturen und eine abschließende Bestätigung für Ihre Unterlagen.
Ein Schwachstellenscan ist kein Penetrationstest. Scanner finden bekannte Lücken in veralteter Software und fehlende Einstellungen, und das ist wertvoll. Sie verstehen aber nicht, dass Kunde A keine Daten von Kunde B sehen darf. Genau diese Logikfehler machen den Unterschied, und sie findet nur, wer die Anwendung wie ein Angreifer von Hand untersucht.
Weil ein Angriff auf fremde Systeme ohne Zustimmung strafbar ist, auch wenn er gut gemeint ist. Die Freigabe muss vom tatsächlichen Inhaber kommen. Läuft das System bei einem Hoster oder Dienstleister, holen wir auch dessen Zustimmung ein.
Wir verzichten auf zerstörerische Methoden, ein Restrisiko bleibt aber bei jedem Test. Deshalb bevorzugen wir eine Testumgebung. Im Livebetrieb testen wir nur im vereinbarten Fenster und mit aktueller Sicherung.
Nein. Sie erhalten einen Bericht mit Umfang, Methodik und Befunden sowie nach dem Nachtest eine Bestätigung. Das genügt in der Regel für Kunden, Versicherungen und Audits nach ISO 27001.
Mindestens jährlich und nach größeren Änderungen, etwa einer neuen Schnittstelle, einem neuen Anmeldeverfahren oder einem Umzug in die Cloud. Für wesentliche und wichtige Einrichtungen nach NIS2 kann das ein Baustein des geforderten Risikomanagements sein.
Wie mit einem Generalschlüssel. Er beschreibt, wie man eindringt. Beschränken Sie den Empfängerkreis und legen Sie ihn nicht in allgemein zugängliche Ordner, bis alle Befunde behoben sind.
Beschreiben Sie die Anwendung, ihre Benutzerrollen und wer der Inhaber ist. Wir schlagen Umfang, Testart und Zeitplan vor.
Ihre Anfrage ist eingegangen
Sie hören spätestens am nächsten Werktag von uns. Haben Sie einen Ausfall gemeldet, der Ihr Team gerade blockiert, kümmern wir uns zuerst darum.
Diese Stadt ist nicht in der Liste. Prüfen Sie die Schreibweise oder wählen Sie die nächstgelegene Landeshauptstadt: Da wir alles per Fernwartung erledigen, ist die Betreuung in jedem Bundesland gleich.