Top 3 Findings unserer Cyber-Security-Reviews

1. XSS

Was ist das?

Bei Cross-Site-Scripting-Angriffen (XSS) werden bösartige Skripte im Browser ausgeführt. Das gefährliche daran ist, dass der Code im Kontext eines anderen Benutzers ausgeführt wird. Es gibt XSS-Angriffe, welche z.b. durch das Öffnen eines Links ausgeführt werden oder wo das bösartige Script auf dem Server gespeichert wird und dann von diesem an andere Benutzer ausgeliefert wird. Diese Schwachstelle kann bei allen Webapplikationen auftreten, bei welchen die Eingabe eines Benutzers bei anderen Benutzern geladen wird und keine Massnahmen für das Verhindern eines solchen Angriffes getroffen wurden.

Beispiel 1:

Ein Angreifer bucht einen Service-Termin bei einem Handwerker. Im Bemerkungsfeld des Formulars konnte man bösartigen Javascript-Code schreiben, der dann im Adminpanel im Kontext des Adminbenutzers ausgeführt wurde. So konnten alle Cookies und Sitzungs-Token gestohlen werden, die es dem Angreifer erlaubten sich selbst als Admin einzuloggen.

Beispiel 2:

Ein Angreifer reserviert bei einem Kino Tickets. Beim Reservations-Formular fügt er bösartigen Code hinzu. Dieser Code wurde im Kontext eines Admins, bei der Bestätigung der Reservation, ausgeführt. So war es dem Angreifer möglich das Guthaben seines Kontos beim Kino beliebig zu manipulieren.

Wichtigste Gegenmassnahme:

Alle Eingaben des Benutzers müssen korrekt gesäubert und bei der Darstellung escaped werden. Die meisten Web-Framework unterstützen den Programmierer beim Validieren, Escapen und Säubern der Benutzer-Eingaben. Sowohl bei einem Blackbox- wie auch einem Whitebox-Pentest prüfen wir immer ausführlich, ob XSS-Angriffe in einer Form möglich sind.

2. BOLA / IDOR

Was ist das?

BOLA (Broken Object Level Authorization) und IDOR (Insecure direct Object References) sind Angriffe, auf fremde Daten. Dabei wird via ID auf Daten-Objekte zugegriffen, welche nicht dem Benutzer gehören. Dies ist immer ein Fehler bei der Rechte-Überprüfung auf dem Server.

Beispiel 1:

Bei einem Firmen-Portal für Versicherungen, welches einer Firma erlaubte, gewisse Dinge selber zu erledigen, gab es eine Funktion das Logo seiner Firma hochzuladen. Die Bilder waren dann im Admin-Bereich unter /uploads/company_images/[id] erreichbar und nur für eingeloggte Benutzer gedacht. Das Portal diente zur Unterstützung in einem hoch kompetitiven Umfeld. Jedoch konnte jeder Benutzer alle IDs durchiterieren und so Informationen erlangen, welche Mitbewerber im gleichen Markt, ebenfalls auf dieser Plattform unterwegs sind.

Beispiel 2:

Die Applikation hat eine Funktion, wobei Daten der eigenen Mitarbeiter angepasst werden können. Es kann entweder nur ein einzelner Mitarbeiter aktualisiert werden, hier konnten keine fremden Daten angepasst werden. Oder es konnten mehrere Mitarbeiter auf einmal aktualisiert werden. Hierfür wurden von der App eine Liste mit IDs der Mitarbeiter und die Daten erwartet. Beim Bulk-Updaten ging jedoch die Validierung, ob der Mitarbeiter überhaupt einer meiner Mitarbeiter ist, vergessen. Bei dieser BOLA konnten zwar keine fremden Daten gelesen werden, aber überschrieben.

Wichtigste Gegenmassnahme:

BOLA-Fehler sind Fehler in der Programmierung, wenn eine Überprüfung der Zugriffsrechte vergessen ging. Jede Applikation hat ein eigenes Datenmodell und eine eigene Businesslogik, deshalb unterstützen Frameworks in diesem Punkt nur bedingt. Bei jedem Security-Review legen wir ein spezielles Augenmerk auf Endpoints, welche IDs verwenden. Hier sehen wir oft, dass der Grundsatz "Vier Augen sehen mehr als zwei" sich bestätigt und ein Review sinnvoll ist.

3. Veraltete, unsichere Libs

Was ist das?

Jedes Programm verwendet heutzutage Libraries und Frameworks. Diese bieten Funktionalität, die der Entwickler nicht selbst programmieren muss. Diese Libraries können jedoch Sicherheitsmängel haben. Wird eine solche Sicherheits-Lücke bekannt, behebt der Herausgeber der Libray diese so schnell wie möglich und released eine neue Version. Verwendet man nun anstelle der gefixten Lib immer noch die Alte ist man anfällig auf Angriffe.

Beispiel 1:

Beim Anmelden für einen Kurs, wurde eine Kursbestätigung als PDF erstellt. Das Anmeldeformular konnte so manipuliert werden, dass schadhafter Code an den Server gesendet wurde. So konnten, bei der Generierung des PDFs, alle Dateien, die auf dem Server gespeichert waren in das PDF-Dokument eingebunden werden. Dies bedeutete, dass alle Dateien auf dem Server gelesen werden konnten.

Beispiel 2:

Eine der bekanntesten und am weitest verbreiteten Libraries, die es einem Angreifer erlaubte bösartigen Code auszuführen, war Log4J. Log4j wird zum Loggen von Events in Java verwendet. Im November 2021 wurde ein Fehler entdeckt, der bekannt wurde als "Log4Shell". Dem CVE-2021-44228 wurde mit einer 10.0 die höchste Risiko-Stufe des CVSS (Common Vulnerability Scoring System) zugeordnet. Millionen von Business-Applikationen waren aufgrund dieses CVEs nicht mehr sicher.

Wichtigste Gegenmassnahme:

Regelmässiges überprüfen aller eingebetteter Libraries und Frameworks. Gibt es neuere Versionen, sollte man die Alte ersetzen. Ist für die verwendete Lib eine Schwachstelle bekannt, gilt es diese sofort auszutauschen. Für gewisse Systeme/Frameworks gibt es Tools, welche diesen Punkt automatisiert im Continous-Integration-Prozess prüfen.