Authentifizierung & Sessions
Login, Passwort-Reset, Multi-Faktor, Single Sign-on, Tokens und Session-Handling.
Web- & API-Pentest
Scanner finden fehlende Header. Wir finden den Request, der die Daten eines anderen Kunden zurückgibt. Manuelle Tests für Webanwendungen und APIs, mit Beweis für jedes Finding und einem Fix, den deine Entwickler direkt umsetzen können.
Kurz gesagt
Ein Penetrationstest für Webanwendungen ist eine manuelle Sicherheitsprüfung einer Webanwendung und ihrer APIs. Die Tester suchen nach Schwachstellen in Authentifizierung, Session-Handling, Zugriffskontrolle (IDOR, BOLA, BFLA), Eingabeverarbeitung und Business-Logik und orientieren sich an den OWASP Top 10 und den OWASP API Security Top 10. Zyberum liefert CVSS-bewertete Findings mit Proof-of-Concept, Fixes und einem Nachtest zum Festpreis.
Was wir testen
Login, Passwort-Reset, Multi-Faktor, Single Sign-on, Tokens und Session-Handling.
Kann Nutzer A die Daten von Nutzer B lesen oder ändern? IDOR, BOLA und BFLA sind die Findings mit der größten Auswirkung.
Schritte übersprungen, Preise geändert, Limits umgangen: die Lücken, die kein Scanner versteht.
SQL- und Command-Injection, Cross-Site-Scripting, Server-Side Request Forgery, unsichere Deserialisierung.
REST und GraphQL: zu viele Daten in der Antwort, Mass Assignment, fehlende Rate Limits, undokumentierte Endpunkte.
Offene Admin-Oberflächen, geschwätzige Fehlermeldungen, veraltete Komponenten und schwache Transportverschlüsselung.
Warum manuell
Bei den IoT-Produkten, die wir zuletzt getestet haben, waren die schlimmsten Findings keine exotischen Exploits. Es waren API-Aufrufe, die einfach die Geräte anderer Kunden zurückgaben oder änderten, weil der Server einer ID im Request vertraute.
So eine Lücke fällt nur auf, wenn jemand versteht, was die Anwendung tun soll, und dann ausprobiert, was sie nicht erlauben dürfte. Genau damit verbringen wir unsere Zeit. Unsere selbst gehosteten KI-Modelle helfen uns, in derselben Zeit mehr Endpunkte abzudecken, und jedes Finding wird von einem Tester geprüft.
Case Studies
Voller Root-Zugriff auf dem Gerät und Zugriff auf die Live-WebRTC-Kamera fremder Nutzer über die Cloud-API.
Wir haben einen Saugroboter mit Kamera getestet: Root-Zugriff auf dem Gerät und Lücken in der Cloud-API, die die Live-Kamera fremder Nutzer öffneten. Was schieflief.
Case Study lesenÜber MQTT konnten wir die Geräte anderer Kunden sehen und aktivieren und orten, wo sie installiert sind.
Wir haben ein smartes Bewässerungssystem getestet: Durch ein fehlerhaftes MQTT-Setup konnten wir Geräte anderer Kunden sehen, schalten und ihren Standort ermitteln.
Case Study lesenFAQ
Am besten ist ein Staging-System mit produktionsnahen Daten, weil wir dort ohne Risiko für deine Nutzer testen können. Tests auf Produktion sind mit abgestimmten Grenzen möglich.
Die URL, Test-Accounts für jede Rolle und die API-Dokumentation, falls es eine gibt. Für einen White-Box-Test zusätzlich Zugriff auf den Quellcode.
In der Regel 5 bis 10 Testtage pro Anwendung, je nach Anzahl der Rollen und Funktionen.
Jetzt starten
Erzähl uns von der Anwendung, ihren Rollen und ihren APIs. Nach dem Gespräch bekommst du ein Festpreisangebot.

Dein Gespräch führst du mitTom ZaubermannGründer & CEO, Zyberum
Wir antworten innerhalb eines Werktags.
Deine Privatsphäre
Wir nutzen Cookies und ähnliche Technologien, um unsere Website und den Erfolg unserer Anzeigen zu messen. Du entscheidest, welche wir einsetzen dürfen. Deine Auswahl kannst du jederzeit über „Cookie-Einstellungen“ im Footer ändern. Datenschutzerklärung