Nein. Dass eine interne Webanwendung seit Jahren ohne Vorfall läuft, sagt nichts über ihre Sicherheit aus – nur, dass bisher niemand gezielt danach gesucht hat. Code, der nie mehr angefasst wird, verändert sich zwar nicht selbst, aber sein Umfeld schon: Was beim Bau eine übliche Vorgehensweise war, gilt heute oft als eine der am häufigsten ausgenutzten Schwachstellen im Web.
Warum «es lief ja immer» nichts über Sicherheit aussagt
Eine ruhige Anwendung ist nicht dasselbe wie eine geprüfte Anwendung. Die meisten Angriffe auf kleine, unauffällige interne Tools sind keine gezielten Attacken durch jemanden, der die Firma kennt, sondern automatisierte Scans, die routinemässig nach bekannten Mustern suchen – einem Login-Formular, einer veralteten PHP-Version, einer offen erreichbaren Konfigurationsdatei. Ob so ein Scan je stattgefunden hat, lässt sich von aussen kaum beurteilen, und wenn niemand die Logs auswertet, hinterlässt selbst ein erfolgreicher Zugriff oft keine Spur, die auffällt.
Hinzu kommt: Viele dieser Anwendungen sind über die Jahre gewachsen, ohne dass es einen Zeitpunkt gab, an dem «die Sicherheit» bewusst geprüft wurde. Ein Formular kam dazu, eine Schnittstelle zu einem Lieferanten, ein Upload-Feld für Belege – jede Erweiterung ein sinnvoller Schritt für sich, aber niemand hat die Summe je aus der Perspektive eines Angreifers betrachtet.
Was bei zwei ungewarteten KMU-Anwendungen tatsächlich gefunden wurde
Bei zwei unabhängigen internen Anwendungen von Schweizer Betrieben – beide seit über zehn Jahren im Einsatz, beide ohne laufende Wartung – zeigte eine Sicherheitsüberprüfung ein sehr ähnliches Bild. Keine der beiden Firmen hatte einen Vorfall gemeldet oder auch nur vermutet; in beiden Fällen bestätigte die Analyse dieselbe Grundaussage aus dem vorigen Abschnitt.
| Befund | Was das konkret bedeutete |
|---|---|
| Login-Formular anfällig für SQL-Injection | Ein Angreifer hätte sich ohne Kenntnis eines Passworts als beliebiger Benutzer anmelden können – mit einem gewöhnlichen Browser, ohne Spezialwerkzeug |
| Zugangsdaten im Programmcode | Datenbank-, E-Mail- und Schnittstellen-Passwörter standen als lesbarer Text im Code – sichtbar für jeden mit Code-Zugriff |
| Fehlender Formularschutz (CSRF) | Eine präparierte fremde Webseite hätte im Namen eines angemeldeten Mitarbeiters Aktionen auslösen können, etwa Einträge löschen |
| Ungeprüfte Ausgaben (XSS) | Werte aus der Datenbank wurden ungefiltert angezeigt – ein Einstiegspunkt, um Schadcode im Browser anderer Nutzer auszuführen |
| Veraltete Serverkomponenten | Die Anwendungen liefen auf PHP-Versionen und Funktionen, die seit Jahren keine Sicherheitsupdates mehr erhalten |
Nach der Behebung war der praktische Unterschied für die tägliche Arbeit gleich null – die Anwendungen sehen aus und verhalten sich wie vorher. Der Unterschied liegt ausschliesslich darin, was ein Angreifer damit anfangen könnte.
Eine Webanwendung wird nicht sicherer, weil sie ruhig ist – nur unauffälliger.
Warum genau diese Lücken entstehen, wenn niemand mehr hinschaut
Keiner dieser Befunde entsteht durch Nachlässigkeit einer einzelnen Person. Sie entstehen, weil sich der Massstab dafür, was «normal programmiert» bedeutet, seit dem Bau der Anwendung verschoben hat. Vor zehn, fünfzehn Jahren war es üblich, Benutzereingaben direkt in eine Datenbankabfrage einzusetzen oder ein Passwort als Konstante im Code zu hinterlegen – Konzepte wie CSRF-Schutz oder systematisches Output-Encoding waren in vielen Entwicklungsumgebungen schlicht noch kein Standard. Der Code hat sich seither nicht verändert; die Bedrohungslage und der Stand der Technik aber schon.
Ohne laufende Pflege gibt es auch keinen Moment, an dem diese Verschiebung nachgeholt wird. Jede neue Funktion wird nach dem Muster der bestehenden gebaut, und das Muster stammt aus einer Zeit, in der es noch als unbedenklich galt.
Wie Sie einschätzen, ob ein eigenes Tool betroffen sein könnte
Ein belastbares Urteil braucht eine Analyse, aber ein paar Fragen zeigen bereits eine Tendenz:
- Ist die Anwendung ohne VPN oder IP-Einschränkung aus dem offenen Internet erreichbar?
- Verarbeitet sie Kunden- oder Personendaten, Rechnungen oder Zugangsdaten zu weiteren Systemen?
- Weiss noch jemand im Betrieb, wann der Code zuletzt inhaltlich – nicht nur im Server-Update – angefasst wurde?
- Gab es je eine gezielte Sicherheitsprüfung, oder lief die Anwendung einfach, weil sie funktionierte?
Zwei oder mehr «Ja» bei den ersten drei Fragen sind kein Beweis für eine Schwachstelle, aber ein guter Grund, das genauer anzuschauen, statt sich auf die störungsfreie Historie zu verlassen.
Häufige Fragen
Reicht ein Server-Update, oder muss der Programmcode selbst geprüft werden?
Ein Server-Update schliesst nur Lücken in der zugrunde liegenden Software (PHP, Webserver, Bibliotheken). Fehler im eigenen Programmcode – etwa eine unsichere Datenbankabfrage oder ein fehlender Formularschutz – bleiben davon unberührt und brauchen eine eigene Prüfung des Codes.
Ist eine Anwendung ohne Internetzugang automatisch sicher?
Nein, aber das Risiko sinkt deutlich. Ein System, das nur im internen Netz oder per VPN erreichbar ist, kann kaum von aussen automatisiert abgesucht werden. Bleibt es dennoch offen im Internet erreichbar, zählt es zum gleichen Risiko wie jede öffentliche Website – unabhängig davon, wie wenige Personen die Adresse kennen.
Muss man ein altes internes Tool gleich neu programmieren?
In der Regel nicht. Die in diesem Beitrag beschriebenen Lücken lassen sich meist gezielt im bestehenden Code schliessen, ohne die Anwendung neu zu bauen. Eine Neuentwicklung lohnt sich erst, wenn der technische Unterhalt insgesamt teurer wird als eine Ablösung.
Woran erkennt man solche Lücken, ohne selbst Programmierkenntnisse zu haben?
Als Entscheider muss man den Code nicht lesen können – die Checkliste im vorherigen Abschnitt reicht, um einzuschätzen, ob eine nähere Prüfung sinnvoll ist. Die eigentliche Analyse gehört dann in fachkundige Hände.