Nachlese: Gehärteter Online-Banking-Browser S-Protect, neue Version, neue Erkenntnisse

Der Deutsche Sparkassen- und Giroverband stellt mit dem S-Protect einen "gehärteten" Browser bereit, der Online-Banking-Kunden der Sparkassen vor den Risiken bei Bankgeschäften auf Windows PCs oder Macs besser schützen soll. Bei einem Test stellte sich heraus, dass diese Software in einer Komponente anfällig für DLL-Hijacking war. Inzwischen haben die Entwickler nachgebessert und gegenüber mir auch einige Details zum technischen Konzept des gehärteten Browsers S-Protect offen gelegt. In nachfolgendem Text gehe ich auf die Informationen und Erkenntnisse zur aktualisierten Fassung von S-Protect ein.

Ein kurzer Rückblick

Vom deutschen Sparkassen- und Giroverband wurde das Projekt eines gehärteten Browsers zum Online-Banking auf Desktop-Systemen (Mac, Windows) angestoßen. Und die Sparkasse Niederrhein stellt den Browser als S-Protect im Moment im Rahmen eines Pilot-Projekts auf ihrer Webseite als sichere Lösung zum Online-Banking auf dem PC an.

Bei heise gab es zum 2. Mai 2022 den Artikel Sichereres Online-Banking mit gehärtetem Browser der Sparkassen über dieses Konzept, und ich hatte mir zum Artikel die Notiz verfasst "da solltest Du bei Gelegenheit mal drüber bloggen – denn der Ansatz, einen "gehärteten" Browser für Online-Banking zu verwenden, klang für mich spannend.

Sicherheitsexperte Stefan Kanthak hatte sich die Lösung S-Protect der Sparkasse Niederrhein in Bezug auf Sicherheitsprobleme angesehen und stieß darauf, dass der Download s-protect.exe anfällig für DLL-Hijacking-Schwachstellen sei.

Stefan Kanthak hatte mich bei den Mails zwischen der IT der genannten Sparkasse und sich auf cc gesetzt, so dass ich über die sich abzeichnende Problematik im Bilde war. Im Mail-Austausch zeichnete sich für mich keine irgendwie geartete Lösung ab, so dass ich das Modul ebenfalls einem eigenen Test unterzog und die DLL-Hijacking-Schwachstelle im Download s-protect.exe verifizieren konnte. Am 9. Mai 2022 hatte ich die Ergebnisse im Artikel Gehärteter Online-Banking-Browser S-Protect, ein Totalausfall? dokumentiert.

Neue Entwicklungen und Erkenntnisse

Mit obigem Artikel war das Thema aus meiner Sicht abgeschlossen, die Entwickler konnten nachbessern oder auf den Sachverhalt reagieren. Durch Leserkommentare konnte ich aber Kontakt mit den Entwicklern aufnehmen. Zum 17. Mai 2022 gab es dann ein Telefonat, in dessen Nachgang mir diverse Informationen bereitgestellt wurden. Das ist der Anlass für diesen Nachfolgeartikel.

Anfälligkeit des Starters behoben, Browsersicherheit nicht getestet

Die Entwickler haben mir gegenüber bestätigt, dass das seinerzeit von mir getestete Modul s-protect.exe anfällig für DLL-SearchPathHijacking war. Das Konzept der Entwickler besteht aber aus zwei Komponenten:

• Dem sogenannten Starter s-protect.exe, der vom Benutzer von der jeweiligen Sparkassenseite als portable Anwendung heruntergeladen wird.
• Dem eigentlichen gehärteten Browser, der von s-protect.exe auf der Maschine eingerichtet wird.

Im Sinne der Transparenz: Diese Information wurde von keiner der Sparkassen, wo der Download erhältlich ist, auch nur angedeutet – das habe ich durch die Diskussion mit den Entwicklern erfahren.

Alle Ausführungen in meinem Artikel bezogen sich ausschließlich auf den sogenannten Starter s-protect.exe, der für DLL-SearchPathHijacking anfällig war. Ob dies ggf. auch für den eigentlichen gehärteten Browser zutrifft, wurde von mir nicht mehr getestet. Dafür gab es zwei Gründe:

• Im Artikel stand die DLL-Hijacking-Schwachstelle des vom Nutzer herunterladbar und ausführbaren Moduls s-protect.exe in der Betrachtung des Sicherheitskonzepts im Vordergrund.
• Weiterhin verweigerte der Starter in meiner Windows 7-Umgebung anschließend jegliche Funktion, so dass zusätzliche Komponenten des Browsers erst gar nicht heruntergeladen und eingerichtet wurden.

Es lässt sich also festhalten, dass der gehärtete Browser von mir nicht separat (und nach meinem aktuellen Kenntnisstand auch nicht von Stefan Kanthak) getestet wurde.

Stefan Kanthak wies in seiner Antwort auf den Punkt "der Browser wurde nicht getestet" darauf hin, dass es dazu auch keine Veranlassung gab: "Es genügt, eine Schwachstelle aufzuzeigen, um Konzept zu zerlegen. Wieso sollte ich weitere unbezahlte Arbeit machen."

Die nachfolgenden Informationen, die mir nun vorliegen, blieben daher unberücksichtigt. Nach einer telefonischen Diskussion schrieben mir die Entwickler am 17. Mai 2022 zum Sachverhalt folgendes:

• Der Starter war anfällig für DLL-SearchPathHijacking. Herr Kanthak hat leider nur den Starter auf Sicherheit überprüft. [Dazu verweise ich auf die obige Stellungnahmen von Herrn Kanthak.] Seine Testergebnisse lassen daher keine Rückschlüsse auf die Sicherheit des Browsers zu.
• Wir haben Teile der Sicherheitsfunktionen des Browsers auf den Starter ausgedehnt, so dass der Starter jetzt nur System-DLLs aus dem Windows-Verzeichnis nutzt.
• Der Browser ist geschützt durch ein Zwiebelschalenmodell unterschiedlicher Sicherheitsfunktionen. Auch wenn man einen Mechanismus angreift, sind andere Mechanismen in der Lage gegenzuhalten.
• Ein großer Teil der Sicherheit wird durch das Whitelist-Konzept erzeugt. Dies unterscheidet den Bank-Browser strukturell von allen anderen Browserkonzepten.

Zur Aussage, dass die Testergebnisse von Herrn Kanthak keine Rückschlüsse auf die Sicherheit des Browsers zulassen, antwortete dieser:

Jede vom Starter geladenen DLL kann bzw. konnte jede Komponente des anschließend gestarteten Browsers kompromittieren, beispielsweise die Signaturen immer als gültig ausweisen und den Browser mit ausgetauschten Dateien starten!

Ich habe diese Hinweise zum Anlass genommen, den sogenannten Starter (s-protect.exe) erneut von der Webseite der Sparkasse am Niederrhein herunterzuladen und in einem Sicherheitstestbett auf die DLL-Hijacking-Schwachstelle zu testen. Zudem ermöglichen mir die jetzt vorliegenden Informationen eine etwas erweiterte Betrachtung.

Kurzfassung des aktuellen Stands: Die Ausführung der Entwickler lässt sich bestätigen, in meiner Testumgebung konnte ich in diesem Modul keinerlei DLL-Hijacking-Anfälligkeiten mehr feststellen. Dieser Punkt ist inzwischen durch die Nachbesserung abgeräumt.

Hinweis auf nicht unterstützte Windows-Versionen

In meiner Testumgebung verwende ich bevorzugt Windows 7 SP1 mit Extended Security Update-Support (ESU). Das Betriebssystem wird ja von Microsoft noch bis Januar 2023 mit Sicherheitsupdates versorgt. In der Anfang Mai 2022 getesteten Form verweigerte S-Protect aber die Funktion und meldete sich mit diesem Dialogfeld.

An dieser Stelle rätselte ich, was da an nicht erfüllten Systemvoraussetzungen gegeben sei. Der Hinweis, das Log-Protokoll in die Zwischenablage zu kopieren, brachte mich nicht weiter, da diese Informationen verschlüsselt waren. Bei meinem Telefonat mit den Entwicklern stellte sich heraus, dass S-Protect (auf Anforderung von Kunden) die Funktion auf Betriebssystemen sofort einstellt, wenn diese nicht mehr im Support für die Allgemeinheit sind. Beim Test der aktuellen Fassung von S-Protect erhalte ich nun diese wesentlich aufschlussreichere Meldung.

Also auch hier wurde nachgebessert, mit der Anforderung kann der Benutzer etwas anfangen. Das Log-Protokoll ist zwar weiterhin verschlüsselt, aber normale Benutzer können damit eher nichts anfangen – das ist aus meiner Sicht für die Zielgruppe in Ordnung. An diesem Punkt kann ich also feststellen, dass die zwei Kritikpunkte aus meinem ursprünglichen Artikel im Rahmen der Nachbesserung durch die Entwickler von Coronic beseitigt wurden und somit gegenstandlos sind.

Erläuterungen der Entwickler zum S-Protect-Konzept

Inzwischen liegt mir eine schriftliche Stellungnahme der Entwickler zum Konzept von S-Protect und den von mir im ersten Artikel aufgeworfenen Sicherheitsfragen vor. Hier ein Abriss dessen, was mir jetzt an Informationen vorliegt.

Der Starter war anfällig für DLL-SearchPathHijacking, der Browser ist es nicht

Getestet wurde von mir ursprünglich der Starterprozess s-protect.exe, nicht jedoch den Browser selbst. Der Starter s-protect.exe ein gesondertes Programm, das den Browser auf Aktualität prüft, bevor der eigentliche Browser startet. Der Starter (als reiner Update-Prüfer) stand, so die Entwickler in der Stellungnahme, daher sicherheitstechnisch nicht so stark im Fokus wie der Browserprozess. Dafür gibt es zwei Gründe:

• Es wurde lediglich gezeigt, dass man den Starter dazu bringen kann eine DLL zu laden und dann eine Falschmeldung anzuzeigen. Das kann man aber auch, indem man die Starter-Exe löscht und eine beliebige Datei gleichen Namens auf den Desktop legt. Das ist für alle Computer gleich: lösche die Anwendung, ersetze sie durch die Falschmeldung, das funktioniert immer. Ein gegen DLL-SearchPathHijacking abgesicherter Starter kann weiter durch Austauschen der Exe manipuliert werden.
• Der Browser ist mit mehreren Sicherheitsmethoden (dazu unten etwas mehr) geschützt. Eine geladene DLL im Starter stellt keinen erfolgreichen Angriff auf den Browser da.

Anmerkungen: Das Problem, dass die Dateien wie s-protect.exe, die beim Download durch den Nutzer mit dessen Berechtigungen abgelegt werden, durch jeden Prozess, der über diese Benutzerrechte verfügt, ersetzt wird, hatte ich im ursprüngliche Artikel ja bereits angedeutet. Das ist das prinzipielle Problem bei portablen Apps.

Der Browser liegt im Benutzerprofil

Ich habe dann nachgesehen, beim Starten von s-protect.exe wird von diesem der eigentliche Browser protect.exe samt den benötigten Dateien im Benutzerprofil:

C:\Users\<username>\AppData\Local\CORONIC\

abgelegt. Beim Aufruf lässt sich über ein Dialogfeld eine Desktop-Verknüpfung auf den Starter anlegen. Der Profilordner mit den Dateien des gehärteten Browsers ist mit den jeweiligen Benutzerrechten beschreibbar – die Dateien im Benutzerprofil ließen sich also durchaus austauschen. Umgehen ließe sich dies lediglich durch eine installierbare (msi-Installer-) Version des s-protect-Pakets, die dann administrative Berechtigungen erfordert.

Die Dateien in diesem Profilordner sind allerdings digital durch Coronic signiert und können beim Start des Moduls starter.exe per Internet aktualisiert werden. Auf meinem Windows 10-Testsystem benötigt der Browser dann auch einige Zeit, bis er arbeitsfähig ist. Wenn ich es richtig gesehen habe, wird die QT5 Web-Engine zur Implementierung des Browsers verwendet.

Wie es letztendlich um die Sicherheit dieses Pakets bestellt ist, vermag ich nicht abschließend zu beurteilen – und sehe dies auch nicht als meine Aufgabe (bin ja kein bezahlter Pentester). Ein Anfälligkeit gegen DLL-SearchPathHijacking konnte ich bei einem schnellen Test nicht feststellen. Die notwendigen DLLs im Profilverzeichnis trugen ein aktuelles Datum. Hier kommt es in meinen Augen darauf an, wie zuverlässig und zeitnah der Entwickler ggf. in den Helper-Bibliotheken aufgedeckte Sicherheitslücken durch aktualisierte Module schließen kann. Jedenfalls wird der gehärtete Browser beim Start auf Aktualisierungen geprüft. Und zur Frage: Müssen Schwachstellen sofort gefixt werden, da sehr kritisch, gibt es im folgenden Text auch noch eine Abschätzung.

Modifikationen am Starter

Auf Grund meines Artikels haben die Entwickler reagiert und schreiben, dass sie Teile der Sicherheitsfunktionen des Browsers auf den Starter ausgedehnt haben. Hier die Kernpunkte der schriftlichen Aussagen:

Trotz unserer Anmerkungen im vorangegangenen Abschnitt, haben wir uns entschieden den Starter mit Sicherheitsmechanismen des Browsers weiter abzusichern.

Die Entwickler möchten damit der Diskussion vorgreifen, wann genau welche Sicherheitsmechanismen am besten ergriffen werden sollten. Sie merken auch an, dass es nicht schade, den Starter stärker abzusichern. Aber das ist nicht wirklich hilfreich, das der betreffend abgesicherte Starter weiterhin durch einfachen Austausch der exe-Datei manipuliert werden könnte.

Das gilt aber auch für die Dateien des eigentlichen Browsers und der Bibliotheken, die von einem Angreifer mit lokalen Benutzerrechten ausgetauscht werden könnten. Damit könnte das nachfolgend skizzierte Sicherheitskonzept des Browsers durch Ersetzen der prüfenden Module außer Kraft gesetzt werden. Aus praktischen Erwägungen stellt sich aber die Frage, ob Angreifer diesen Aufwand treiben.

Wie wird der Browser geschützt?

Kern- und Angelpunkt des ganzen Ansatzes ist die Frage, ob es Angreifern gelingt, die Komponenten des gehärteten Browsers zu kompromittieren – oder ob Schwachstellen, die vielleicht durch fehlende Updates der Komponenten entstehen, ausgenutzt werden könnten. Hier hatte ich eine kurze Diskussion mit den Entwicklern und diese haben mir auch schriftlich einige zusätzliche Informationen zukommen lassen. Der verfolgte Ansatz: Der Browser ist geschützt durch ein Zwiebelschalenmodell unterschiedlicher Sicherheitsfunktionen – und Geschäftsprozesse im Internet sind nur so sicher wie der Browser mit dem sie durchlaufen werden. Dazu schreiben die Entwickler:

• Die Aufgabe eines Browsers ist es, jede Internetseite anzuzeigen und jedes Video abzuspielen. Damit ist der Browser das genaue Gegenteil einer sicheren Software, denn er erlaubt erst einmal alles. So zielen auch die Angriffsmethoden von Banking-Trojanern stets auf die Manipulation von Browserfunktionen. Sie verändern die Seitendarstellung der Bank im Browser und täuschen die Nutzer mit gefälschten Einblendungen.
• Um dem zu begegnen, wurden die technischen Schutzverfahren von Banken in den vergangenen Jahren immer komplexer. Auch Zweikreisverfahren nützen wenig, solange der Nutzer sich, basierend auf den gefälschten Meldungen im Browser, nicht korrekt verhält und sich gewissermaßen selber ausraubt. Gerade bei diesen fehlgeleiteten und technisch nicht aufgeklärten Kunden muss man heute attestieren, dass jeder Online-Geschäftsprozess nur so sicher ist, wie der Browser mit dem er durchlaufen wird.
• Könnte man den Zugriff der Trojaner auf den Internetbrowser des Bankkunden verhindern, so wäre der im Browser ablaufende Geschäftsprozess sofort wieder sicher – weil gegen Fehlbedienung gefeit.
• Gleichzeitig muss der Browser so einfach zu benutzen sein, dass ihn auch nicht technisch-affine Kunden (denn die werden üblicherweise beklaut) problemlos und fehlerfrei benutzen können. Wegen dieser einfachen Nutzbarkeit ist der Browser als portable Anwendung designed, man kann ihn herunterladen, ihn ohne Adminrechte nutzen, alles ist auf Endkunden ohne technische Vorbildung ausgelegt.

Hier verwenden die Entwickler den Ansatz: Der Browser kontrolliert sich selbst und die genutzten Bibliotheken anhand von Zertifikaten.

• Im Update-Prozess des Starters werden sämtliche für den Browser benötigten Dateien heruntergeladen. Diese werden anhand ihrer Zertifikate und Prüfsummen kontrolliert. Auch der Update-Server selbst wird überprüft und auch der Update-Server überprüft den Client anhand seiner Zertifikate.
• Alle im Programmverzeichnis des Browsers befindlichen DLLs sind signiert.
• Der Browser selbst ist mit einem Code-Zertifikat signiert, sodass der Nutzer jederzeit überprüfen kann, dass es sich tatsächlich um die Browser-Datei der Firma CORONIC handelt.
• Beim Programmstart des Browsers wird erneut die Identität der Softwaresignaturen überprüft. Die Prüfung wird für alle Artefakte der Software durchgeführt.
• Der gesamte Prozessspeicher wird zur Laufzeit stetig auf Manipulation überwacht.

Hinweis der Entwickler: Auch das bisher mögliche Nachladen einer DLL im Starterprozess (wie von Herrn Kanthak gezeigt) hätte keine Auswirkung auf den Browserprozess. Selbst wenn er weitere manipulierende DLLs nachgeladen hätte, könnten diese im Browser-Prozessraum nicht agieren und die Sicherheit des Browsers nicht beeinträchtigen.

Anmerkung: Diese Annahme der Entwickler im letzten Absatz kann ich nicht abschließend werten und bestätigen oder widerlegen, da mir da die zeitlichen Ressourcen und auch die Kenntnisse fehlen, dies bis zum letzten Winkel zu durchdenken und zu überprüfen. Ich gestehe aber, dass mir genau an dieser Stelle die meisten Bauchschmerzen kommen. Denn gelingt es, nur ins unreine gedacht, einem Angreifer den Starter und dann die initale Updater-Komponente samt den Prüfroutinen des gehärteten Browsers auszutauschen, wäre eine Manipulation in meinen Augen denkbar.

Stefan Kanthak antwortete zu meinem im vorherigen Absatz aufgeworfenen Punkt: Ich wage sehr zu bezweifeln, dass a) alle Dateien digital signiert sind, und b) die Signaturen bei jedem Laden geprüft werden (das Zeitfenster zwischen der Prüfung durch den Starter und dem Laden im Browser ist sicher gross genug, um die signierten Dateien auszutauschen), und c) dass alle der vielen verwendeten Drittanbieter-Komponenten wie Qt5 keine Schwachstellen haben (Qt5 beispielsweise hat bis vor kurzem Dateien aus einem gaenzlich anderen Pfad C:\… geladen), und d) keine der DLLs/EXE-Dateien des Browsers anfaellig fuer DLL-Hijacking ist.

Das Whitelist-Konzept des Browsers

Bei der Diskussion mit den Entwicklern kam natürlich auch ein Punkt auf, der nicht von der Hand zu weisen ist: 90 % aller mit Schadsoftware hinterlegten Internetseiten werden von den gängigen Standardbrowsern nicht (schnell genug) erkannt. Der Nutzer infiziert sich beim Besuchen der manipulierten Internetseite oder seine Zugangsdaten (PIN) werden abgefischt. Dies passiert mit dem S-Protect Bank-Browser nicht, so die Entwickler, da dieser nur die freigegebenen Seiten der jeweiligen Bank aufrufen kann.

Um das sicherzustellen überprüft der S-Protect-Browser nicht nur die Gültigkeit der Bank-Zertifikate, sondern kontrolliert die Zertifikate anhand ihres Hashwertes auf Echtheit. Das Whitelist-Konzept hat nach Ansicht der Entwickler drei positive Folgen für den Nutzer:

• Wenn der Nutzer immer daran denkt, seine Bankgeschäfte nur mit dem Bank-Browser zu machen, kommt er auf keine Phishing-Seiten.
• Die Anforderungen an eine dauerhafte Aktualität der Rendering-Engine entfällt, denn der Nutzer bewegt sich nur auf den "guten Seiten" seiner Bank.
• Da die meisten Social-Engineering-Angriffe per Telefon darauf basieren im Vorfeld Kontonummer und die PIN zu entwenden, scheitern auch viele betrügerische Telefonanrufe, denn aus dem Bank-Browser lassen sich die Anmeldedaten nicht herauskopieren.

Am Kern dieser Argumentation ist natürlich etwas dran. Verwendet der Bankkunde immer den von seinem Institut bereitgestellten, gehärteten S-Protect-Browser, kommt er auf keine fremde Seiten. Selbst wenn eine Schwachstelle im Browser existiert, wäre dies weniger kritisch, da die Webseiten der Banken für Online-Banking i.d.R. keine Schadsoftware beherbergen – Angriffe aus dieser Ecke durch eine kompromittierte Online-Banking-Seite sind eher nicht zu erwarten.

Mein abschließendes Fazit

Das Konzept des gehärteten Browsers, der sich selbst und die Online-Bankseite zur Sicherheit überprüft, ist nachvollziehbar. Der einzige Punkt, der mich am gesamten Konzept fragend zurücklässt: Gibt es ein Szenario, bei dem ein Angreifer die auf dem Rechner liegenden Komponenten des gehärteten Browsers so austauschen und manipulieren kann, dass der S-Protect-Browser zwar startet, die vermeintlichen Prüfungen nicht mehr ausführen kann und dann Daten vom Nutzer, die dieser ggf. eingibt, abgreift.

Ist der gestartete Browser integer, verhindert er zumindest das Anfertigen von Screenshots oder das Markieren und Kopieren von Inhalten in die Windows-Zwischenablage (das ist mir aufgefallen, als ich die Lizenzbedingungen für diesen Beitrag herauskopieren wollte). Zudem stellt er sicher, dass der Benutzer auf der Online-Banking-Seite seines Instituts unterwegs ist.

Aber an dieser Stelle kommen wir mit der Annahme "der gestartete Browser ist integer" etwas zum Kernproblem des gesamten Ansatzes, welches Stefan Kanthak in folgender Aussage aufgreift:

Sobald der Austausch einer Datei zwischen Prüfung und Laden möglich ist oder im Browser eine Datei aus einem anderen Pfad geladen wird, ist die Aussage "der Browser ist ohne Installation sicher verwendbar" nicht mehr haltbar.

Da der Installationspfad überall gleich %LOCALAPPDATA%\CORONIC\ ist, kann ein Angreifer dies für Manipulationen nutzen.

Hier kommt es in meinen Augen auf die Betrachtungsweise an. Stelle ich die Frage, ist es aus Sicherheitsgründen besser, beim Online-Banking den S-Protect-Browser anstelle eines Standard-Browsers zu verwenden, lautet die Antwort Ja. Denn der Browser kann sich nur mit der Bankingseite der jeweiligen Sparkasse verbinden. Der Preis besteht darin, dass der Nutzer penibel darauf achten muss, den S-Protect-Browser für sein Online-Banking zu verwenden. Auf meiner langsamen Testmaschine dauert es schon mal eine Minute, bis der S-Protect-Browser arbeitsbereit ist. Das läuft dann doch auf eine Geduldsprobe hin. Steht der Bankkunde dies durch, oder greift er doch zu seinem Standard-Browser?

Gehärteter Online-Banking-Browser S-Protect, Sparkasse am Niederrhein

Ich möchte hier eine Analogie anführen: Ein Sicherheitsgurt beim Auto schützt vor den Folgen eines (leichteren) Unfalls oder milder diese, kann aber keinen Unfall als solches verhindern.

Als problematisch empfinde ich in diesem Kontext, wie der S-Protect-Browser für die Zielgruppe beworben wird. Die Sparkasse am Niederrhein preist diesen ja mit "Rundumschutz für Ihr Banking" an. Das verleitet Nutzer u.U. zum Gefühl der totalen Sicherheit (mir kann jetzt nichts mehr passieren), die aus den oben skizzierten Gründe so nicht gegeben ist. Wird das System kompromittiert, hilft der S-Protect-Browser u.U. auch nicht mehr. Hier sehe ich die größte Gefahr: Es wird eine Sicherheit vorgespiegelt (der Sicherheitsgurt verhindert den Unfall), die so nicht gewährleistet werden kann.

Was bleibt noch anzumerken? Die Entwickler haben nach meinem ersten Artikel schnell reagiert und den Browser bzw. dessen Startmodul überarbeitet. Die initialen Kritikpunkte aus meinem ersten Artikel sind damit ausgeräumt – die aktualisierte Fassung des Browser liegt bereits auf der Seite der betreffenden Bank. Das ist top. Auch zeigten sich die Entwickler im Austausch offen und haben mir die obigen Informationen bereitgestellt – ein positiver Zug, den ich so nicht (immer) von anderen Firmen in ähnlichen Situationen kenne.

Was im Rückblick nicht ganz optimal gelaufen ist: Ich hätte ggf. versuchen können, die Entwickler vorab zu recherchieren und zu kontaktieren. Da ich aber über den Mail-Austausch zwischen Stefan Kanthak und der betreffenden Sparkasse im Bilde war, deutete sich für mein Gefühl ein "kein Weiterkommen" an. Ich habe daher gehandelt, den Artikel verfasst und Stefan Kanthak vorab drüber schauen lassen.

Andererseits wurde im Beitrag ja keine Sicherheitslücke im eigentlichen Sinne offen gelegt, die sofort einen unberechtigten Abfluss von Daten ermöglicht hätte. Vielmehr drehte sich alles um die Frage: Wie sicher müssen/sollen bestimmte Module sein und was ist an Design-Kriterien zu beachten. Daher waren die Kriterien für ein resposible disclosure auch nicht gegeben. Mit dem hier vorliegenden Nachtragsartikel, den sowohl die Entwickler als auch Stefan Kanthak vorab lesen konnten, steht jetzt eine weitergehende Betrachtung zur Verfügung, so dass sich Jeder über die Pros und Cons informieren und dann seine Einschätzung treffen kann.