Bernd Wurst schrieb:
Am 24.08.2013 08:41, schrieb Matthias Kirschner:
Grund dafür ist, dass hier geeignete serverseitige Plausibilitätsprüfungen zur Verfügung stehen. Die von ELSTER selbst zur Verfügung gestellten Bibliotheken werden nicht als OpenSource bereitgestellt.
Das sagt deutlich, dass nur COALA-Eingaben mit echt freier Software möglich sind. Und dass es bei ERiC eben *keine* funktionierende, serverseitige Plausibilitätsprüfung gibt. Die Finanzvarwaltung ist daher darauf angewiesen, dass die wesentlich komplexeren Daten der ERiC-Schnittstelle stets von der proprietären Client-Bibliothek erstellt werden, die eine Plausibilitätsprüfung der Eingabedaten durchführt.
Um eine (brauchbare) Offenlegung von ElsterFormular zu erreichen, müsste zunächst ERiC offen gelegt werden. Da dessen Server-Schnittstelle laut obigem Zitat aber zu einer ungesunden Portion auf security by obscurity basiert, ist das wohl eher unwahrscheinlich.
Genau das ist der Knackpunkt: ERiC basiert auf "security by obscurity" und ist damit nach Stand der Technik _nicht sicher_ und manipulierbar!
Und zwar nicht nur "manipulierbar" im Sinne von "ich kann für jemand anderen eine falsche Steuererklärung abgeben", sondern wahrscheinlich eher im Sinne von "ich kann korrekte Zahlen in meine Steuererklärung schreiben, und erhalte dennoch einen Steuerbescheid über 0 EUR."
Wobei ich stark hoffe, dass zumindest _diese_ Art des Angriffs irgendwie serverseitig abgefedert wird, wenn sie auch sonst nichts abfedern.
Wenn das Ding irgendein Cracker aufmacht, indem der den proprietären Client bzw. das Netzwerkprotokoll reverse- engineered, dann werden viele Leute in Erklärungsnot kommen.
(Es sei denn, die Presse lässt sich damit einlullen, dass dies eine normale "Sicherheitslücke" sei, obwohl das eher als "Fehlen eines brauchbaren Sicherheitskonzeptes" bezeichnet werden sollte ...)
Vertrauenswürdiger Client ... dafür wurde man bereits in den 80ern geteert und gefedert (genauer: von Scriptkiddiez geownzt), und heute haben wir es 2013!
Gruß Volker