Kleine Angriffsfläche, veröffentlichte Prüfung

Die Anwendungszugriffsrichtlinie von Exchange begrenzt den Schadensradius. Jeder Befund unten wird von ihr eingefasst — selbst vollständig kompromittierte Zugangsdaten können als ein freigegebenes Postfach senden und sonst nichts. Deshalb behandelt die Installationsanleitung die Richtlinie als Pflichtschritt mit Prüfbefehl, nicht als optionale Härtung.

Der Stand v0.1.1 wurde nach der ersten Installation im Wirkbetrieb geprüft — der Graph-Transport, das Einstellungsmodell, die API-Methode für die Test-E-Mail und die Vue-Komponente, untersucht auf durchsickernde Geheimnisse über Protokolle, API-Antworten, HTML-Quelltext und Browserkonsole; Authentifizierung und CSRF auf der API-Oberfläche; Eingabevalidierung bei jeder Einstellung; und die Frage, ob Graph-Fehlermeldungen jemanden außer einem Superuser erreichen können. Aussagen über das Verhalten von Matomo wurden am Quellcode von Matomo überprüft, nicht aus dem Gedächtnis übernommen.

Vor der Veröffentlichung behoben

• Eine überschreibbare Basis-URL hätte das Client-Secret auf den Host eines Angreifers richten können — URLs werden nun als reine https-Ursprünge validiert, bevor eine Anfrage gebaut wird.
• Ein Netzwerkfehler mitten im Upload konnte eine vorab authentifizierte Upload-URL ins Protokoll durchsickern lassen — sie wird nun wie jeder andere Fehler umgewandelt und geschwärzt.
• Die Einstellungen akzeptierten jede Zeichenkette — jedes Feld validiert nun seine Form, sodass eine eingefügte Secret ID beim Speichern scheitert und nicht später als undurchsichtiger Microsoft-Fehler.
• Die API-Methode für die Test-E-Mail akzeptierte jeden Empfänger und antwortete auf GET — nun nur noch POST mit validierter Adresse, außerhalb der Zugriffsprotokolle des Servers gehalten.

Als sauber bestätigt

• Geheimnisse erreichen weder den HTML-Quelltext noch die API-Antwort noch die Browserkonsole — Passwortfelder werden von Matomo selbst maskiert, und das Plugin legt zwei eigene Schutzmechanismen darüber.
• Der Testaufruf ist durch das Token-Modell von Matomo CSRF-geschützt, ergänzt um eine reine POST-Regel als zusätzliche Verteidigungsebene.
• Alles, was protokolliert oder geworfen wird, läuft durch einen Redaktor, der bekannte Geheimnisse nach Wert und Zugangsdaten nach Form unkenntlich macht — Token, Assertions, Bearer-Header, Upload-URLs — und im Zweifel blockiert.

Abgewogene Kompromisse, dokumentiert

• Das kurzlebige Zugriffstoken liegt im dateibasierten Cache von Matomo — wer ihn lesen kann, kann bereits die Konfiguration von Matomo lesen, in der womöglich das Secret selbst steht. Abgemildert durch die Lebensdauer von 55 Minuten und die Zugriffsrichtlinie.
• Ein Superuser kann unbegrenzt Test-E-Mails senden — ein Ärgernis, kein Rechteproblem; ein Superuser könnte den Mailversand ohnehin vollständig umkonfigurieren.
• Ein in der Einstellungsoberfläche eingetragenes Secret liegt unverschlüsselt in der Datenbank von Matomo — die Ebenen Konfigurationsdatei und Umgebungsvariable existieren genau deshalb, damit es das nicht muss, und sie haben Vorrang.

Die vollständige Prüfung mit allen elf Befunden auf GitHub lesen

Schreiben Sie mit den Details an die unten stehende Adresse. Bitte geben Sie uns die Gelegenheit, ein Problem zu beheben, bevor es öffentlich wird — und fügen Sie einem Bericht niemals ein Client-Secret, ein Zertifikat oder eine PEM-Datei bei.

Sicherheitskontakt: …