®Offensive Security / Software- & SaaS-Pentesting
Schnelle Releases brauchen eine Sicherheitsprüfung, die Ihre Anwendung versteht. OTOKO® analysiert SaaS-Produkte, APIs, auf PaaS betriebene Anwendungen und gewachsene Legacy-Software. Im Mittelpunkt stehen erreichbare Auswirkungen: fremde Mandantendaten, unzulässige Aktionen, missbrauchte Geschäftslogik und die Grenzen zwischen Benutzerrollen. Reproduzierbare Befunde geben Ihrem Entwicklungsteam eine Grundlage für die Behebung.
Leistungen im Detail
Analyse, Integration und nachvollziehbare Übergabe
Ihr Auftrag an OTOKO®
Die Arbeitspakete werden aus Ihrer Ausgangslage abgeleitet. Ihr Team kennt den vereinbarten Umfang, die benötigte Mitwirkung und die Ergebnisse, die bei der Übergabe vorliegen sollen.
Gemeinsam legen wir fachlich wichtige Abläufe und Testrollen fest. Anschließend untersuchen wir, ob eine Funktion über ihre vorgesehenen Grenzen hinaus genutzt werden kann. Automatisierte Prüfungen werden durch manuelle Analyse der Anwendung ergänzt.
Bewertete Befunde mit fachlicher Auswirkung und nachvollziehbarem Nachweis.
Mandantenzuordnung, Objektzugriffe und privilegierte Funktionen werden im freigegebenen Umfang geprüft. Ein eigener Testbestand macht die Auswirkungen bewertbar, ohne fremde Kundendaten für einen Nachweis verwenden zu müssen.
Dokumentierte Prüfung der vereinbarten Rollen- und Mandantengrenzen.
Bei PaaS-Anwendungen betrachten wir die von Ihnen verantworteten Einstellungen und Schnittstellen. Bei Legacy-Systemen werden bekannte Betriebsgrenzen und Abhängigkeiten in die Testplanung aufgenommen. Fremde Plattformen bleiben außerhalb einer nicht erteilten Freigabe.
Abgegrenzter Testumfang mit technisch und betrieblich passenden Verfahren.
Befunde werden priorisiert und mit Ihrem Entwicklungsteam besprochen. Der vereinbarte Retest prüft, ob die konkrete Ursache im neuen Stand behoben ist. Ergebnisse werden auf den tatsächlich geprüften Umfang und Zeitpunkt bezogen.
Technischer Bericht, Management-Einordnung und dokumentierte Retest-Ergebnisse.
Planung & Umsetzung
Ein SaaS-Produkt besteht nicht nur aus öffentlich erreichbaren Endpunkten. Unterschiedliche Rollen, Einladungen, Exporte, Hintergrundaufgaben und Administrationsfunktionen bilden zusammen die Geschäftslogik. Vor dem Test klären wir deshalb, welche Abläufe besonders schutzbedürftig sind und welche Grenzen die Anwendung durchsetzen soll. Diese Sicht ergänzt klassische technische Prüfungen. Eine Funktion kann formal korrekt antworten und dennoch eine Handlung erlauben, die für die angemeldete Person oder ihren Mandanten nicht vorgesehen ist.
Auf dieser Grundlage entsteht ein abgestimmter Testumfang. Black-, Grey- oder White-Box-Anteile werden nach Ziel und verfügbaren Informationen ausgewählt. Wenn Quellcode oder Architekturunterlagen bereitgestellt werden, lassen sich Beobachtungen gezielter einordnen. Die Prüfung konzentriert sich auf die autorisierte Anwendung und verwendet die vereinbarten Konten und Daten. Ein Werkzeugbefund wird nicht ohne Bewertung als bestätigte Schwachstelle übernommen; Auswirkung und Voraussetzungen müssen für Ihr Team nachvollziehbar sein.
Bei SaaS und PaaS ist die Verantwortungsgrenze entscheidend. Die Prüfung Ihrer Anwendung oder Konfiguration ist nicht automatisch eine Erlaubnis, die Infrastruktur eines Plattformbetreibers anzugreifen. Gemeinsam werden Ziele, erlaubte Verfahren und erforderliche Freigaben festgehalten. APIs und Integrationen werden auf den vorgesehenen Daten- und Berechtigungsumfang geprüft. Besonderes Augenmerk liegt darauf, ob unterschiedliche Rollen und Mandanten in den tatsächlichen Anwendungswegen zuverlässig getrennt bleiben.
Legacy-Software verlangt häufig ein anderes Vorgehen. Dokumentation kann lückenhaft sein, Testumgebungen bilden den Produktivbestand nur teilweise ab und einzelne Komponenten reagieren empfindlich auf Last. Diese Bedingungen gehören vor dem Start in die Planung. Wir stimmen Testfenster, erreichbare Ansprechpartner und Abbruchkriterien ab. Wo eine Prüfung nicht vertretbar durchgeführt werden kann, wird diese Grenze im Ergebnis sichtbar gemacht. So bleibt klar, welche Aussage der Test ermöglicht und wo zusätzliche Untersuchung erforderlich wäre.
Ein Bericht soll eine Entscheidung ermöglichen und der Entwicklung bei der Korrektur helfen. Ein bestätigter Befund beschreibt daher den betroffenen Stand, die benötigten Voraussetzungen, den vereinbarten Nachweis und die mögliche Auswirkung. Management und Technik benötigen dabei unterschiedliche Detailtiefe. Die Priorisierung berücksichtigt den Anwendungskontext, statt nur eine lange Liste gleichgewichteter Meldungen zu erzeugen. Nachweise werden auf das notwendige Maß begrenzt und über abgestimmte Wege mit den berechtigten Ansprechpartnern geteilt.
Die Behebung wird mit Ihrem Team besprochen; ein vereinbarter Retest bewertet die konkrete Änderung. Ein behobener Befund bedeutet jedoch nicht automatisch, dass die gesamte Anwendung frei von Schwachstellen ist. Neue Releases und Konfigurationsänderungen können die Ausgangslage verändern. Auf Wunsch lässt sich daraus eine regelmäßige Prüfung wichtiger Änderungen entwickeln. Für geeignete, klar abgegrenzte Ziele kann außerdem Result as a Service vereinbart werden: Die Vergütung hängt dann vom vorher definierten und nachgewiesenen Ergebnis ab.
Illustratives Projektszenario
Zwei getrennte Testmandanten bilden reguläre Benutzer und Administration ab. Vor dem Release werden die vereinbarten Geschäftsabläufe und Berechtigungsgrenzen untersucht. Das Team erhält priorisierte Nachweise und prüft die Korrekturen im Retest – ohne dass fremde Kundendaten für die Demonstration benötigt werden.
Vor dem Start
Ja. Legacy-Anwendungen werden mit ihren Betriebsgrenzen, verfügbaren Testumgebungen und Abhängigkeiten eingeplant. Nicht durchführbare Prüfungen werden im Bericht als Einschränkung benannt.
Scanner unterstützen die Arbeit. Geschäftslogik, Rollen und der tatsächliche Anwendungskontext benötigen jedoch eine fachliche Bewertung und gezielte manuelle Prüfung.
Für geeignete Vorhaben kann ein schriftlich definierter Ergebnisnachweis mit einem festen Betrag vereinbart werden. Ohne diesen Nachweis fällt die vereinbarte erfolgsabhängige Pentest-Vergütung nicht an. Details stehen auf der Seite Result as a Service.
Nein. Die Aussage bezieht sich auf den vereinbarten Umfang, den geprüften Stand und das Zeitfenster. Ein fehlender Nachweis ist keine allgemeine Sicherheitsgarantie.
Zusammenhängende Leistungen
Software- & SaaS-Pentesting mit OTOKO®
Nennen Sie die betroffenen Systeme und das Ziel Ihrer Anfrage. Im ersten Gespräch grenzen wir Umfang, Voraussetzungen und die nächsten Schritte gemeinsam ab.
Software- & SaaS-Pentesting besprechen
