Für (noch) mehr Sicherheit

Pentests und Qualitätssicherung

Das verinice-Team setzt auf testgetriebene Software-Entwicklung, um höchste Qualitätsstandards zu gewährleisten. Unsere Entwicklungsprozesse umfassen Tests sowohl für das Front- als auch für das Backend.

Wesentlicher Bestandteil unserer Sicherheitsstrategie sind regelmäßige Penetrationstests (Pentests), die auch die Hosting-Plattform umfassen. Diese Tests sollen potenzielle Schwachstellen identifizieren und so behoben werden, bevor sie ausgenutzt werden können. Die Ergebnisse der Pentests fließen in unsere kontinuierlichen Verbesserungsprozesse ein und erhöhen stetig die Sicherheit unserer Plattform.

Großen Wert legen wir auch auf Usability und Barrierefreiheit. Zukünftig werden wir Tests in diesen Bereichen durchführen. verinice soll benutzerfreundlich und für alle zugänglich sein.

Sprechen Sie uns an! Nutzen Sie das verinice-Forum oder schreiben Sie uns an verinice@remove-this.sernet.de. Wir beantworten gerne Fragen zu unseren Sicherheitsmaßnahmen.

2023

Beauftragt

RedTeam Pentesting GmbH

Zeitraum

Februar 2023

Gesamtbewertung des RedTeams

"Der Penetrationstest von verinice.veo kommt zu einem positiven Ergebnis. Es konnten nur sehr wenige Schwachstellen und Auffälligkeiten aufgedeckt werden. Im Kernsystem ist sogar nur eine einzige Stelle auffällig: Im Bereich des Reportings ist es möglich, einen Endpunkt ohne jegliche Authentifizierung aufzurufen. Die zurückgelieferten Daten sind aber so allgemein und nicht kundenspezifisch, dass das Verhalten kein Risiko darstellt und lediglich inkonsistent und unerwartet ist. Alle anderen Schwachstellen und Auffälligkeiten wurden außerhalb des Kernsystems in externen, verbundenen Systemen aufgedeckt. […] Insgesamt ist das getestete System damit auf einem sicheren Stand, der dem Einsatzzweck und den später hiermit verwalteten Daten entspricht. Die aufgedeckten Schwachstellen und Auffälligkeiten sollten sich vermutlich außerdem sehr kurzfristig adressieren lassen, um das bereits hohe Niveau noch weiter zu steigern.”

Findings und Reaktionen der SerNet

Fehlende Autorisierung beim Zugriff auf Hauptbenutzerkonten
Risiko: gering
Status: Das Aufrufen der URL erfordert jetzt einen angemeldeten Shop-Account, dem die Subskription zugeordnet ist, somit behoben.
Information-Disclosure E-Mail-Adressen von Benutzerkonten
Risiko: gering
Status: Fehlermeldungen bei bereits vorhandenen E-Mail-Adressen wurden entsprechend der Hinweise der Pentester geändert.
Clientseitiger Schutz vor Änderung der Benutzendennamen
Risiko: nur Info
Status: Änderung der Keycloak-Konfiguration, um die Änderung der Benutzendennamen zu unterbinden.
Fehlende Authentifizierung für Reports
Risiko: nur Info
Status: Kein Handlungsbedarf. Abfragbarkeit der verfügbaren Report-Vorlagen ist kein Risiko. Diese sind über das öffentliche Quellcode-Repository gleichermaßen abrufbar und nicht vertraulich.

2021

Beauftragte

Cure53, Dr.-Ing. M. Heiderich

Zeitraum

Dezember 2021

Findings von Cure53

“Das Cure53-Team hat eine hervorragende Abdeckung der WP1- bis WP3-Bereichsgegenstände erreicht und insgesamt acht Schwachstellen identifiziert. Davon wurden zwei als Sicherheitslücken und sechs als allgemeine Schwächen mit geringerem Ausnutzungspotenzial eingestuft. Keines der entdeckten Probleme ist kritisch oder von hoher Schwere, wobei der höchste Schweregrad ‘Medium’ zugewiesen wurde. Dies zeigt, dass das SerNet-Team Sorgfalt in seinen Web- und Anwendungssicherheitsprozessen walten lässt. Die meisten Probleme betreffen HTTP-Header und könnten es einem Angreifer ermöglichen, einen Exploit vorzubereiten oder auszuführen, obwohl die Anwendung selbst sehr robust ist.”

Reaktion der SerNet

Dieser erste Penetrationstest wurde gegen eine frühe Entwicklungsversion durchgeführt, um frühzeitig Probleme in der Sicherheitsarchitektur aufzudecken. Alle identifizierten Schwachstellen wurden behoben, zum großen Teil durch Konfigurationsänderungen: Änderung der CSP, Anpassen der HTTP-Header etc. Das Entfernen der "unsafe-inline"-Direktive gestaltete sich aufwändiger aufgrund der verwendeten Open-Source-Komponenten im Web-UI, welche Inline-Javascript enthielten. Durch eigene Anpassungen konnten diese aber letztlich auch beseitigt werden.