Penetrationstests an Web-Apps, Portalen und Firmennetzen. Kein automatischer Scan mit einem Siegel am Ende: jemand, der wirklich hineinzukommen versucht, mit denselben Techniken wie jemand, der es zum Stehlen täte — und der Ihnen danach aufschreibt, was er gefunden hat, in einer Sprache, die Sie an Ihren Dienstleister weitergeben können.
pentest --scope "app + api" --mode grey-box
Oberfläche kartiert .... 148 Endpunkte
Anmeldeversuche ........ keine Begrenzung gefunden
Berechtigungsprüfung ... 1 kritische Lücke
[ok] Bericht in 5 Werktagen übergeben
pentest --retest
zweiter Durchgang nach Ihrer Behebung: inbegriffen
wartet
$ ./pentest --target "Ihr System"
Ein Penetrationstest ist kein automatischer Scan mit einem Siegel am Ende. Es ist jemand, der wirklich hineinzukommen versucht, mit denselben Techniken wie jemand, der es zum Stehlen täte — und der Ihnen anschließend aufschreibt, was er gefunden hat, in einer Sprache, die Sie an Ihren Dienstleister weitergeben können.
Eine Ziffer in der Adresse geändert, und die Dokumente eines anderen Unternehmens gingen auf. Es ist die häufigste Lücke, die wir finden, und fast nie hat jemand danach gesucht.
API-Schlüssel und Passwörter im Repository oder im JavaScript, das an den Browser ausgeliefert wird. Wer weiß, wo er hinsehen muss, findet sie.
Das Anmeldeformular ließ unbegrenzt viele Versuche zu: ein schwaches Passwort fällt in wenigen Minuten.
Ein gestohlener Zugang bleibt für immer gültig. Wer das Unternehmen verlassen hat, kommt weiterhin hinein.
Komponenten mit bekannten, bereits veröffentlichten Schwachstellen. Es braucht keinen Angriff: es genügt, die Meldung zu lesen.
Keine davon ist theoretisch: es sind die fünf, die uns am häufigsten begegnen. Der Bericht, den wir übergeben, sagt, wo es ist, wie wir hingekommen sind und was zu tun ist — mit kostenloser Nachprüfung nach der Behebung.
// wann es nötig ist
Nicht alle brauchen es gleichermaßen. Aber wenn Sie drei davon wiedererkennen, sind die Kosten des Nicht-Hinsehens bereits höher als die einer Prüfung.
// was wir wirklich tun
Eine ernsthafte Prüfung unterscheidet sich von einer vorgetäuschten in genau einem Punkt: die vorgetäuschte liefert eine Liste automatischer Warnungen, diese liefert einen tatsächlich gegangenen Weg.
Wir kartieren die exponierte Oberfläche: Domains, Subdomains, Endpunkte, vergessene Dienste, die seit Jahren laufen. Die Hälfte aller Einbrüche beginnt bei etwas, von dem niemand mehr wusste, dass es online ist.
Wir probieren die Wege wirklich: umgehbare Berechtigungen, wiederverwendbare Sitzungen, fremde Daten, erreichbar durch das Ändern einer Zahl. Grenzen und Zeitfenster vereinbaren wir vorher, und echte Daten fassen wir nie an.
Ein Teil für die Entscheiderinnen — wo das Risiko liegt, wie schwer es wiegt, was zuerst zu tun ist. Ein Teil für die, die beheben, mit Anfragen, Antworten und Schritten zum Nachvollziehen. Ohne den zweiten lässt sich der erste nicht umsetzen.
Nachdem Sie behoben haben, kehren wir zu denselben Punkten zurück und prüfen. Das ist der Teil, den fast niemand einschließt, und der einzige, der belegt, dass das Problem wirklich geschlossen ist.
// wie wir dahin kommen
Ein Penetrationstest ohne unterschriebenes Mandat ist kein Test: er ist eine Straftat. Das ist das Erste, was wir auf den Tisch legen, und ohne das fangen wir nicht an.
Es wird schriftlich festgehalten, was dazugehört und was nicht, zu welchen Zeiten, mit welchen Grenzen. Unterschrieben von der Person, die das genehmigen darf — nicht von der, die das System betreut, sondern von der, der es gehört.
Wir erstellen das Verzeichnis dessen, was erreichbar ist. Oft taucht hier die erste Überraschung auf: eine offene Testumgebung, eine alte Subdomain, die noch lebt.
Kritische Lücken melden wir sofort, nicht bei der Übergabe: finden wir eine offene Tür zu den Daten Ihrer Kunden, wissen Sie es noch am selben Tag.
Übergabe des Berichts mit Prioritäten und Behebungsschritten, und nach Ihren Eingriffen prüfen wir dieselben Punkte erneut.
// ein Ausschnitt aus dem Bericht
So kommen die Dinge im Bericht an: was wir geschickt haben, was geantwortet hat und wo der Punkt liegt. Es ist zugleich die Lücke, die wir am häufigsten finden.
Bericht 04 · fehlende Berechtigungsprüfung · hoher Schweregrad
# Die Sitzung gehört zu einem echten Benutzer: Er hat sich\n# normal angemeldet. Nur die Nummer in der Adresse ändert sich.\n\nGET /api/documenti/4187 HTTP/2\nHost: portale.esempio.it\nCookie: sessione=8f2a91c4d7e0\n\nHTTP/2 200 OK\nContent-Type: application/json\n\n{\n "id": 4187,\n "cliente": "ein anderes Unternehmen",\n "file": "contratto-firmato.pdf",\n "url": "https://portale.esempio.it/media/9f1c2b.pdf"\n}// Der Code, der mit 200 geantwortet hat.\n\nfunction documento(int $id): ?array\n{\n // Eine Prüfung gibt es, und auf den ersten Blick ist es die richtige:\n // ohne gültige Sitzung kommt hier niemand vorbei.\n if (!utente_autenticato()) {\n return null;\n }\n\n // Aber die Frage, die diese Zeile beantwortet, lautet\n // "Existiert Dokument 4187?" — und nicht\n // "Gehört Dokument 4187 dem, der danach fragt?".\n return db()->riga(\n 'SELECT * FROM documenti WHERE id = ?',\n [$id]\n );\n}// Dieselbe Funktion, mit dem Eigentümer in der Frage.\n\nfunction documento(int $id): ?array\n{\n $utente = utente_autenticato();\n if (!$utente) {\n return null;\n }\n\n // Jetzt fragt die Zeile beides zugleich, und\n // das Dokument eines anderen ist nicht "verboten": es existiert nicht.\n // Keine zweite Prüfung, die man sich anderswo merken müsste, denn\n // es gibt kein Anderswo mehr, wo man sie vergessen könnte.\n return db()->riga(\n 'SELECT * FROM documenti WHERE id = ? AND cliente_id = ?',\n [$id, $utente->cliente_id]\n );\n}Die Korrektur fügt keine Prüfung hinzu: Sie nimmt die Möglichkeit, eine zu vergessen. Solange die Berechtigung ein if neben der Abfrage ist, wird früher oder später jemand eine neue Abfrage ohne dieses if daneben schreiben. In die Abfrage hineingelegt, lässt sich die falsche Frage gar nicht mehr stellen — und wer eine Nummer aufs Geratewohl probiert, bekommt einen 404 und erfährt nicht einmal, dass die Nummer zu irgendetwas gehört.
$ cat stack.json
$ ./domande --frequenti
Nur mit einem schriftlichen Mandat derjenigen, denen das System gehört, das Umfang, Zeiten und Grenzen festlegt. Das ist das Erste, was wir vorbereiten, und ohne das beginnen wir nicht: ein nicht genehmigter Penetrationstest ist eine Straftat, für uns und für die Auftraggeberin.
Zerstörende Tests — solche, die einen Dienst lahmlegen können — führen wir nur auf Wunsch und in vereinbarten Umgebungen durch, in einem angekündigten Zeitfenster. In produktiven Systemen arbeiten wir zerstörungsfrei und fassen keine echten Daten an.
Eine Prüfung einer mittelgroßen Web-App dauert fünf bis zehn Werktage einschließlich Bericht. Die Aufklärung dauert länger, als man denkt: sie entscheidet über die Qualität von allem Weiteren.
Einen Bericht in zwei Teilen: einen für Entscheiderinnen, mit Risiko und Prioritäten, und einen technischen mit Schritten zum Nachvollziehen jeder Lücke. Dazu ein Gespräch, um ihn gemeinsam zu lesen — ein bloß übergebenes PDF landet in einem Ordner.
Wenn sie Daten von Menschen erhebt, ja — und nicht wegen der Größe: die automatischen Scanner, die nach Lücken suchen, prüfen nicht erst Ihren Umsatz. Bei einer reinen Visitenkarten-Website ohne Daten und ohne Login lautet die ehrliche Antwort meist, dass Updates und Sicherungen genügen.
Sicherheit ist kein Zustand, sondern Wartung: Updates, Überprüfung der Zugänge und eine neue Prüfung, wenn sich etwas Wesentliches ändert. Im Bericht schreiben wir, in welchem Abstand das in Ihrem Fall sinnvoll ist.
fymera init --projekt "Ihres"
Dreißig Minuten per Video, um den Umfang zu klären. Wenn die richtige Antwort lautet „aktualisieren Sie alles und begrenzen Sie die Anmeldeversuche“, sagen wir das, statt Ihnen einen Test zu verkaufen.
