Die binsec GmbH sucht aktuell Verstärkung im Bereich Penetration Testing (als Teilzeit) – und geht dabei einen Weg, der in der Branche eher selten ist:

Ein echtes 3-Wochen-on und 1-Woche-off-Arbeitsmodell.

Das bedeutet:

Du arbeitest drei Wochen ganz normal an Kundenprojekten – und bekommst anschließend eine komplette Woche frei, zusätzlich zu deinem regulären Urlaub. Keine Bereitschaft, keine Meetings, kein „nur mal kurz“: eine echte Off-Week.

Warum machen wir das?

Pentesting ist kognitiv fordernd. Gute Arbeit entsteht nur, wenn man regelmäßig Raum bekommt, runterzufahren. Wir wollen ein Umfeld, in dem man langfristig leistungsfähig bleibt und gleichzeitig ein Leben außerhalb der Arbeit führen kann. Für uns gehört das zu professioneller Arbeitskultur.

Wir suchen erfahrene Penetration Tester (m/w/d) die Lust haben auf:

• echte technische Arbeit (ohne Scanner-Getue)
• kurze Entscheidungswege
• direktem, ehrlichem Austausch
• Projekte mit Abwechslung
• ein Arbeitsmodell, das Erholung ernst nimmt

Die vollständige Stellenanzeige findest du hier:

https://binsec.com/de/jobs/senior-penetration-tester/

Alle paar Monate werde ich dieselbe Frage gestellt: „Was findet ihr eigentlich typischerweise in einem Web-Pentest?“

Statt anekdotisch zu antworten, habe ich die aggregierten Daten der letzten 12 Monate aus unseren Webanwendungstests (inklusive angebundener APIs) bei der binsec GmbH ausgewertet. Das Ergebnis ist die untenstehende Grafik – und sie bestätigt die Muster, die sich seit Jahren wiederholen.

Konfigurationsfehler: Das ewige Low-Hanging-Fruit

Ein großer Teil der Findings entsteht durch einfache Konfigurationsfehler: unsichere Webserver-Defaults, fehlende Security-Header, veraltete TLS-Versionen oder schwache Cipher-Suites. Diese Schwachstellen sind leicht auffindbar und meist nicht kritisch, zeigen aber ein wiederkehrendes Problem: vielen Deployments fehlt eine grundlegende Sicherheitsbaseline. Eine einfache Checkliste würde die meisten dieser Probleme direkt vermeiden.

Session-Management: Alte Probleme in modernen Anwendungen

Fehler im Session-Handling treten überraschend häufig auf. Ein typisches Beispiel ist, dass beim Logout nur die Session im Browser entfernt wird, die serverseitige Session jedoch aktiv bleibt. Wird ein Session-Token kompromittiert, kann ein Angreifer die Session weiter nutzen – auch wenn der Nutzer sich bereits abgemeldet hat.

Wo die kritischen Schwachstellen liegen: Autorisierung

Die meisten kritischen Findings entstehen im Bereich der Autorisierung, insbesondere bei:

• fehlender Objekt- und Ressourcenfreigabe,
• unzureichender Rollenprüfung,
• Privilege Escalation,
• mangelnder Tenant-Isolation in SaaS-Systemen.

Moderne, frontend-lastige Anwendungen verstärken dieses Problem. Der Browser ruft im Hintergrund zahlreiche API-Endpunkte auf, und jeder einzelne Endpunkt benötigt eine explizite Zugriffskontrolle. Frameworks übernehmen diese Aufgabe selten automatisch. Die Implementierung erfolgt manuell. Manuelle Prozesse führen dabei zwangsläufig zu Inkonsistenzen.

Die Klassiker, die nicht aussterben

SQL Injection und Cross-Site Scripting (XSS) treten heute seltener auf, sind aber keineswegs verschwunden. ORMs, Prepared Statements und automatisches Escaping entschärfen viele Risiken, doch sobald jemand sie in der Entwicklung „nur kurz umgeht“, tauchen diese Klassiker wieder auf.

Business Logic: Selten, aber mit hoher Wirkung

Business-Logic-Schwachstellen sind weniger häufig, haben jedoch meist erhebliche Auswirkungen, wenn sie auftreten. Beispiele sind das Umgehen von Freigabeprozessen, das Manipulieren von Berechnungen oder das Überspringen notwendiger Validierungsschritte. Diese Schwachstellen erscheinen in keinem Scanner und erfordern ein tiefes Verständnis der Geschäftsprozesse.

Fazit

Die Daten bestätigen, was viele Sicherheitsteams längst wissen:

• Die meisten Schwachstellen sind vermeidbar durch klare Konfigurationsrichtlinien und saubere Deployments.
• Kritische Findings konzentrieren sich fast immer auf Autorisierungsfehler, nicht auf exotische Angriffstechniken.
• Klassische Schwachstellen verschwinden nicht, solange schnelle Workarounds und Zeitdruck sichere Standards aushebeln.

Die binsec GmbH setzt für ihre Penetrationstests auf PTDoc®, ein spezialisiertes Tool zur strukturierten Durchführung von Penetrationstests und professionellen Berichtserstellung. Entwickelt wurde PTDoc von der binsec systems GmbH.

Die Idee zu PTDoc entstand während des Wachstums des binsec-Teams: Wie lässt sich die Qualität konstant hochhalten, obwohl einzelne Penetrationstester unterschiedliche persönliche Schwerpunkte setzen? Und wie stellt man sicher, dass das Ergebnis eines Pentests immer identisch bleibt – unabhängig davon, welcher Senior Penetration Tester den Auftrag durchführt?

Vor PTDoc stand binsec vor der typischen Herausforderung: Soll man Berichte in Word schreiben oder mit LaTeX erstellen? Anfangs fiel die Entscheidung auf LaTeX, wodurch zwar technisch saubere, aber optisch eher „typische“ LaTeX-Dokumente entstanden. Mit PTDoc hat sich dies grundlegend geändert – heute werden daraus professionell gestaltete Reports, die im Hintergrund weiterhin auf umfangreichem LaTeX-Code basieren, jedoch über eine komfortable Oberfläche gesteuert werden können.

Kernidee des Tools ist es, für unterschiedliche Zielsysteme – etwa Active Directory, mobile Anwendungen (z. B. Android Apps) oder Netzwerke – eine einheitliche und standardisierte Vorgehensweise bereitzustellen. Das binsec-Team pflegt und erweitert die Methodik kontinuierlich und integriert etablierte Standards wie den OWASP Testing Guide, MASVS oder OSSTMM. Auf diese Weise wird eine gleichbleibend hohe Qualität sowie die exakte Wiederholbarkeit von Penetrationstests sichergestellt.

In den letzten Jahren hat sich gezeigt, dass durch diese strukturierte Vorgehensweise regelmäßig Schwachstellen identifiziert werden, die bei vorherigen Tests übersehen wurden. Ein Kunde formulierte es sogar so, dass er alle früheren Prüfungen anderer Anbieter nicht mehr als „richtige“ Penetrationstests bezeichnet.

PTDoc deckt alle drei Phasen der Pentest-Dokumentation ab:

• Durchführung des Tests – das strukturierte Abarbeiten der definierten Vorgehensweise.
• Erstellung der Findings – inklusive Beschreibung für den Management-Teil, detaillierter technischer Analyse, Risikobewertung (qualitativ per Ampelsystem oder quantitativ per CVSS) sowie Verwaltung von Screenshots und Evidences.
• Berichtsgenerierung – automatische Erstellung eines konsistenten, revisionssicheren Berichts.

Auch das Nachtesten ist integriert: Stellt der Pentester fest, dass ein Kunde eine Schwachstelle behoben hat, dokumentiert er den Proof of Fix direkt im Finding. Beim erneuten Berichtsbau wird das Finding automatisch als behoben markiert und auch die Management-Zusammenfassung entsprechend aktualisiert.

Darüber hinaus unterstützt PTDoc die Erstellung von deutschen und englischen Berichten. Damit ist es für Kunden besonders einfach, Reports auf Wunsch auch in beiden Sprachen zu erhalten.

Fazit: Mit PTDoc können sich Pentester vollständig auf ihre eigentliche Arbeit – die Durchführung des Tests – konzentrieren. Gleichzeitig ist das Erstellen der Berichte einfach und schnell geworden, sodass Kunden ihre Ergebnisse zeitnah nach Abschluss des Pentests erhalten.