Drupal-Penetrationstest
Wir prüfen Drupal-Installationen auf Schwachstellen, die sich ausnutzen lassen. Geprüft werden Modulbestand, Berechtigungen, Textformate, eigener Modulcode, Konfiguration und Auslieferung.
Was eine Drupal-Prüfung von einer Webprüfung unterscheidet
Drupal-Core wird vom Security-Team gepflegt und schnell gepatcht. Die Befunde aus unseren Prüfungen liegen fast immer woanders. In zu weit vergebenen Rechten, in Textformaten, die der falschen Rolle offenstehen, in Modulen ohne Sicherheitsunterstützung und in eigenem Code, der an der Zugriffsprüfung vorbeiarbeitet.
Diese Stellen sieht nur an, wer das Rechtemodell von Drupal kennt. Eine Prüfung, die ausschließlich das Frontend gegen die üblichen Angriffsklassen testet, läuft an ihnen vorbei.
Was wir prüfen
Der konkrete Umfang wird vor Beginn festgelegt. Die Gliederung folgt dem Aufbau von Drupal selbst, von Core und Contrib über Rollen, Textformate und Entity Access bis zum eigenen Code. Die Auslieferung prüfen wir entlang des OWASP Web Security Testing Guide.
Modulbestand und Sicherheitsunterstützung
Core- und Modulstand gegen die veröffentlichten Advisories. Dazu die Module, für die es gar keine Advisories gibt. Dazu die externen Bibliotheken, die Module voraussetzen.
Rollen und Berechtigungen
Die vollständige Berechtigungsmatrix, mit Schwerpunkt auf den Rechten, die Drupal selbst als zugriffsbeschränkt kennzeichnet. Dazu die Frage, welche Rolle welchen Weg zur Rechteausweitung hat.
Textformate und Filter
Welches Format welcher Rolle offensteht und was sich damit erreichen lässt.
Zugriff auf Inhalte und Felder
Entity Access, Zugriffsrechte auf Feldebene, Views und deren Filter, Zugriffsmodule und ihr Zusammenspiel.
Eigener Modulcode
Hook-Implementierungen, Render Arrays und Ausgabepfade, Datenbankzugriffe, eigene Routen und Callbacks, Formularverarbeitung.
Dateisystem und Uploads
Trennung von öffentlichen und privaten Dateien, Validierung hochgeladener Dateien, Auslieferungspfad.
Konfiguration und Betrieb
Einstellungen in der Konfigurationsverwaltung, Debug- und Entwicklungsmodule im Produktivsystem, erreichbare Staging- und Entwicklungsumgebungen, Deployment-Weg.
Authentifizierung und Sitzungen
Anmeldeverfahren, Zwei-Faktor, Passwortrichtlinie, Alt- und Dienstkonten.
Auslieferung
Sicherheitsrelevante Header, TLS-Konfiguration, Fehlerseiten.
Je nach Installation
Bei Multisite die Trennung der Mandanten. Bei Drupal Commerce die Preis- und Bestelllogik. Bei angebundenen Systemen die Schnittstellen.
Warum der Modulbestand gesondert geprüft wird
Die Sicherheitsunterstützung für Drupal-Module ist kein Automatismus. Der Maintainer muss sie selbst aktivieren. Sie gilt nur für stabile Releases, also nicht für Dev-, Alpha-, Beta- und RC-Versionen.
Bibliotheken, die ein Modul voraussetzt, sind nie abgedeckt, auch wenn das Modul selbst es ist. Abgedeckt sind nur die Bibliotheken, die Drupal-Core mitliefert.
Die Verbreitung eines Moduls spielt dabei keine Rolle. Ein Modul mit fünfstelliger Installationszahl kann ohne Sicherheitsunterstützung laufen. Im Update-Report fällt das nicht auf.
Wir gleichen den vollständigen Modulbestand dagegen ab und benennen, welche Module aus dieser Unterstützung herausfallen.
Mit oder ohne Quellcode
Ohne Quellcode prüfen wir aus der Position eines externen Angreifers. Das zeigt, was von außen erreichbar ist. Fehler in eigenem Modulcode bleiben dabei teilweise unsichtbar.
Mit Quellcode und Konfigurationsexport prüfen wir zusätzlich die Rechtevergabe, die Textformate und den eigenen Code direkt. Bei Drupal-Installationen mit eigenen Modulen findet dieser Weg deutlich mehr.
Welcher Weg passt, klären wir im Erstgespräch.
Wie eine Drupal-Prüfung abläuft
Fünf Schritte vom ersten Gespräch bis zur Besprechung der Befunde.
Erstgespräch
Wir klären Umfang, Zugänge, Prüfumgebung und die Fragen, die der Test beantworten soll.
Angebot und Beauftragung
Umfang, Vorgehen und Rahmenbedingungen schriftlich.
Vorbereitung
Zugänge, Testdaten, Abstimmung mit dem Betrieb. Dazu die Eskalationswege für den Fall, dass wir auf etwas Kritisches stoßen.
Prüfung
Technische Durchführung im abgestimmten Rahmen.
Bericht und Besprechung
Übergabe der Befunde und Durchsprache mit den Verantwortlichen.
Was Sie bekommen
Den Bericht
Jeder Befund mit Reproduktionsschritten, Risikobewertung nach dem vereinbarten Schema und einer eindeutigen Kennung für die Nachverfolgung.
Befund und Empfehlung stehen getrennt, damit Ihre Entwickler die Bewertung nachvollziehen und die Umsetzung selbst entscheiden können.
Die Zusammenfassung
Eine Fassung der Ergebnisse für Leser ohne technischen Hintergrund, für Geschäftsführung, Datenschutz und Audit.
Was nicht Bestandteil ist
Wir prüfen und berichten. Die Behebung der Befunde liegt bei Ihnen oder Ihrer Agentur. Wir übernehmen keine Entwicklungsarbeit, keine Modulpflege und keine laufende Überwachung, soweit das nicht gesondert beauftragt wird.
Ein technisches Audit prüft Code-Qualität, Updatestand, Architektur und Performance. Es wird meist von einer Drupal-Agentur durchgeführt und beantwortet die Frage, ob die Installation sauber gebaut ist. Ein Penetrationstest beantwortet die Frage, ob ein Angreifer durchkommt. Beides hat seinen Platz. Keines ersetzt das andere.
Ein Penetrationstest beschreibt den Stand zum Zeitpunkt der Prüfung. Nach größeren Releases prüfen wir dieselben Befunde auf Wunsch erneut. Eine wiederkehrende Prüfung macht aus der Momentaufnahme einen Verlauf.
Wovon der Aufwand abhängt
Wir veröffentlichen keine Pauschalen, weil der Aufwand bei Drupal stark auseinandergeht. Diese Größen bestimmen ihn.
- Anzahl und Umfang der eigenen Module
- Anzahl der Rollen und die Komplexität der Rechtevergabe
- Anzahl der Textformate und deren Zuordnung
- Multisite ja oder nein, dazu die Zahl der Mandanten
- Drupal Commerce oder andere Zusatzsysteme
- angebundene Schnittstellen und Fremdsysteme
- Prüfung mit oder ohne Quellcode
- Prüfung gegen eine Kopie oder gegen das Produktivsystem
Was in Ihrem Fall ins Gewicht fällt, klären wir im Erstgespräch.
Drupal 10 läuft im Dezember aus
Drupal 10 erreicht am 9. Dezember 2026 sein End of Life. In der Woche vom 7. Dezember 2026 erscheint Drupal 12. In derselben Woche endet die Sicherheitsunterstützung für 11.3.x und 10.6.x. Drupal 7 ist seit dem 5. Januar 2025 ohne Unterstützung.
Eine Migration ist der Zeitpunkt, an dem sich Rechtevergabe, Modulbestand und eigener Code ohnehin bewegen. Eine Prüfung vor oder nach dem Umstieg trifft deshalb auf einen Stand, der für die nächsten Jahre trägt.
Regulatorischer Rahmen
Einrichtungen unter NIS-2, Betreiber kritischer Anlagen und Stellen, die nach IT-Grundschutz arbeiten, müssen die Wirksamkeit ihrer Maßnahmen nachweisen. Ein Penetrationstest durch eine unabhängige Stelle ist dafür ein anerkanntes Mittel. Ob er im konkreten Fall gefordert ist, klären wir mit Ihren Verantwortlichen.
Für Behörden und Hochschulen kommt hinzu, dass die prüfende Stelle unabhängig von der Stelle sein soll, die das System gebaut hat.
Häufige Fragen zum Drupal-Penetrationstest
Eine Sicherheitsprüfung, bei der eine Drupal-Installation gezielt angegriffen wird, um ausnutzbare Schwachstellen zu finden. Geprüft werden Modulbestand, Berechtigungen, Textformate, eigener Code, Konfiguration und Auslieferung.
Der Aufwand hängt an der Anzahl der eigenen Module, der Komplexität der Rechtevergabe und dem Einsatz von Multisite oder Commerce. Dazu daran, ob mit oder ohne Quellcode geprüft wird. Was in Ihrem Fall ins Gewicht fällt, klären wir im Erstgespräch.
Ein Agentur-Audit prüft Code-Qualität, Updatestand und Architektur. Ein Penetrationstest prüft, ob sich Schwachstellen ausnutzen lassen.
Nein, eine Prüfung ohne Quellcode ist möglich. Mit Quellcode und Konfigurationsexport findet die Prüfung bei Installationen mit eigenen Modulen deutlich mehr.
Beides ist möglich. Was geprüft wird, legen wir vor Beginn gemeinsam fest.
Drupal 10 und 11, dazu Drupal 12 nach dessen Erscheinen in der Woche vom 7. Dezember 2026.
Ja. Dazu gehört der Abgleich gegen die veröffentlichten Advisories und die Feststellung, welche Module aus der Sicherheitsunterstützung herausfallen. Diese Unterstützung ist für Module freiwillig und gilt nur für stabile Releases.
Sie erhalten einen Bericht mit Reproduktionsschritten und Risikobewertung. Die Behebung liegt bei Ihnen oder Ihrer Agentur.
Regulierte Einrichtungen müssen die Wirksamkeit ihrer Maßnahmen nachweisen. Ein Penetrationstest ist dafür ein anerkanntes Mittel. Ob er im konkreten Fall gefordert ist, hängt von der Einrichtung ab.
Nachbarleistungen
Diese Prüfungen laufen häufig im selben Auftrag.
Zertifizierungen und Mitgliedschaften.
OSWE deckt die Ausnutzung von Webanwendungen ab und ist für diese Prüfung die einschlägige Qualifikation. Wir betreiben unsere eigene Seite auf Drupal. Die Fragen, die bei einer Prüfung auftauchen, stellen sich uns im eigenen Betrieb ebenfalls.
Drupal-Installation prüfen lassen.
Im Erstgespräch klären wir Umfang und Ausgangslage.