Musterbericht: Technischer Software-Check

Auf einen Blick

Die Muster Service GmbH, 80 Mitarbeitende, betreibt seit 2016 ein Kundenportal, über das Geschäftskunden Serviceaufträge anlegen, Termine sehen und Rechnungen abrufen. Das Portal wurde von einer Agentur gebaut und wird seit 2021 von einem angestellten Entwickler allein weiterentwickelt. Anlass der Prüfung: Geplant ist eine App für Techniker im Außendienst.

Unsere Einschätzung: Das Portal trägt das Tagesgeschäft zuverlässig. Für die geplante App ist es in seinem jetzigen Zustand aber nicht bereit. Zwei Punkte sollten vor jeder Erweiterung erledigt sein, weil sie heute schon ein Risiko sind und mit der App größer würden.

Was zuerst dran ist

1. Kundentrennung in den Datenabfragen absichern. Aufwand 3 bis 5 Personentage. Vor der App, weil sie dieselben Abfragen nutzen würde.
2. Framework-Update planen und umsetzen. Aufwand 10 bis 15 Personentage. Vor der App, weil jede neue Funktion auf veralteter Grundlage später doppelt angefasst werden muss.
3. Persönliche Admin-Zugänge und Sperre nach Fehlversuchen. Aufwand 1 bis 2 Personentage. Kann sofort passieren, unabhängig von allem anderen.

Alles Weitere lässt sich parallel zur App erledigen.

Befunde im Einzelnen

1

Kunden sind nur in der Oberfläche getrennt

Daten und Zugänge · handeln · Aufwand 3 bis 5 Personentage

Beobachtung. Das Portal zeigt jedem Kunden nur seine eigenen Aufträge. Die Trennung geschieht aber in der Oberfläche: Die Schnittstelle dahinter liefert einen Auftrag an jeden angemeldeten Nutzer aus, der dessen Nummer kennt. Die Nummern sind fortlaufend.

Auswirkung. Ein angemeldeter Kunde kann durch Hochzählen die Aufträge anderer Kunden abrufen, mit Adressen und Ansprechpartnern. Das wäre eine meldepflichtige Datenpanne nach DSGVO.

Empfehlung. In jeder Abfrage prüfen, ob der Auftrag zum angemeldeten Kunden gehört, und diese Prüfung an einer Stelle bündeln statt in jedem Endpunkt einzeln. Dazu ein automatischer Test, der es für alle Endpunkte absichert.

2

Das Framework bekommt keine Sicherheitsupdates mehr

Aktualität · handeln · Aufwand 10 bis 15 Personentage

Beobachtung. Das Portal läuft auf einer Hauptversion seines Frameworks, deren Unterstützung 2024 ausgelaufen ist. 14 von 61 eingebundenen Bibliotheken haben bekannte Sicherheitslücken, drei davon mit hoher Einstufung.

Auswirkung. Neue Lücken werden nicht mehr geschlossen. Jede Woche, in der sich nichts ändert, macht das spätere Update größer, und jede neue Funktion auf dieser Grundlage muss danach noch einmal angefasst werden.

Empfehlung. Update in zwei Stufen über die nächste unterstützte Version, vorher die Testabdeckung der Kernabläufe (Auftrag anlegen, Rechnung abrufen) erhöhen. Vor dem Start der App abschließen.

3

Ein gemeinsamer Admin-Zugang, keine Sperre nach Fehlversuchen

Von außen sichtbar · beobachten · Aufwand 1 bis 2 Personentage

Beobachtung. Vier Personen teilen sich einen Administrator-Zugang. Die Anmeldung lässt beliebig viele Fehlversuche zu. Die Sicherheits-Header X-Content-Type-Options und Content-Security-Policy fehlen.

Auswirkung. Wer sich als Administrator angemeldet hat, lässt sich nicht nachvollziehen. Ein Passwort kann ohne Hindernis durchprobiert werden.

Empfehlung. Persönliche Zugänge mit zweitem Faktor, Sperre nach fünf Fehlversuchen, die beiden Header ergänzen.

4

Keine Schnittstelle für eine zweite Anwendung

Aufbau und Erweiterbarkeit · beobachten · Aufwand 8 bis 12 Personentage

Beobachtung. Oberfläche und Geschäftslogik sind eng verwoben. Eine eigenständige Schnittstelle, die eine App nutzen könnte, gibt es nicht.

Auswirkung. Die App müsste entweder Teile der Logik doppelt enthalten oder würde das Portal an Stellen berühren, die dafür nicht gedacht sind. Beides macht spätere Änderungen teuer.

Empfehlung. Die Abläufe, die die App braucht (Aufträge des Tages, Status melden, Foto anhängen), als eigene, dokumentierte Schnittstelle herauslösen. Das Portal nutzt sie danach ebenfalls.

5

Ausrollen steht nur im Kopf eines Entwicklers

Wissen und Übergabe · beobachten · Aufwand 2 bis 3 Personentage

Beobachtung. Eine neue Version wird von Hand auf den Server kopiert. Die Schritte sind nirgends aufgeschrieben. Automatische Tests decken etwa ein Achtel des Codes ab.

Auswirkung. Fällt der Entwickler aus, kann niemand sicher eine Korrektur ausrollen. Das ist kein technisches, sondern ein Geschäftsrisiko.

Empfehlung. Ausrollen automatisieren, sodass es ein Knopfdruck ist, und die Schritte dabei zwangsläufig dokumentieren.

6

Sicherungen funktionieren und sind erprobt

Betrieb und Sicherungen · in Ordnung · Aufwand keiner

Beobachtung. Datenbank und hochgeladene Dateien werden täglich gesichert, getrennt vom Server. Eine Rücksicherung wurde im Juni vollständig durchgespielt und hat funktioniert.

Einordnung. Das ist besser als in den meisten Häusern dieser Größe. Einzige Empfehlung: die Rücksicherung einmal im Jahr wiederholen und das Ergebnis festhalten.

Was gut ist

Nicht alles an einem gewachsenen System ist ein Problem. Die Muster Service GmbH hat einiges richtig gemacht, das bei einem Umbau erhalten bleiben sollte: Die Sicherungen sind erprobt, die Datenbank ist sauber gegliedert, und die Anwendung ist mit durchschnittlich 180 Millisekunden je Anfrage schnell.

Methode und Grenzen

Grundlage sind die Antworten des Entwicklers auf unseren Fragenkatalog, erzeugt mit seinem eigenen KI-Assistenten, dazu zwei Rückfragerunden und eine passive Betrachtung dessen, was das Portal öffentlich ausliefert. Wir hatten keinen Zugriff auf Code oder Server und haben nichts gegen das System getestet.

Eine solche Prüfung findet die Schwachstellen, die aus dem Aufbau folgen. Sie ersetzt keinen Penetrationstest, der gezielt nach ausnutzbaren Lücken sucht. Ob einer sinnvoll ist, lässt sich nach diesem Bericht besser entscheiden als vorher.