Drama ePetitionssystem

Dass das ePetitionssystem des Bundestages, sagen wir: nicht so wirklich prima ist, war ja schon hinlänglich bekannt: Unbenutzbar, nicht performant, überhaupt eine ziemlich blöde Lösung, die von den Anforderungen der Ausschreibung nicht all zu viele erfüllt.

Nun ist es außerdem unsicher. Die Mitzeichnung bzw. Entfernung der Mitzeichnung einer Petition geschieht nämlich über einen GET-Request. GET-Requests sind eigentlich nur zum Abruf von Informationen gedacht, sollen aber keine Daten verändern. Wenn sie das doch tun, und die Aufrufe nicht zusätzlich geschützt sind, dann kann jeder mittels sogenanntem Cross-Site Request Forgery (XSRF) Aktionen im Namen anderer auslösen, wenn der Angreifer nur die entsprechende URL als Bild oder unsichtbaren Frame in eine Seite einbindet.

Wie das im konkreten Fall aussieht, hat Bernd Eckenfels anschaulich zusammengefasst: XSRF-Schwachstelle auf dem ePetitions-Server auf itblog.eckenfels.net. Danke für die anschauliche Ausarbeitung an @eckes.

Lieber Bundestag, ich kenne da so ein paar “Internetexperten”, die so ein Petitionssystem ganz gut und ganz gerne mal richtig umsetzen würden. So mit “an die Ausschreibung halten” und so. Ihr dürft uns auch gerne Geld dafür in den Rachen werfen.

Update 2009-05-20: Die Antwort kommt “als Anlage” in einem Word-PDF per Mail. Darin wird gesagt:

Der Datenschutzbeauftragte des Deutschen Bundestages hat unser System geprüft
und für gut befunden.
Zurzeit werden alle Hinweise in einer „Mängel- bzw. Anregungsliste“ aufgenommen,
zu gegebener Zeit ausgewertet und soweit wie möglich in das Verfahren des
Petitionsausschusses mit öffentlichen Petitionen eingebracht.

Das macht mir nicht wirklich Mut.

Update 2009-06-14: Die XSRF-Schwachstelle wurde irgendwann stillschweigend beseitigt. Zum einen wurden zufällige Keys eingeführt, zum anderen erhält man nun Mails, wenn sich der Mitzeichnungsstatus ändert. Nicht perfekt, vor allem nicht transparent kommuniziert, aber immerhin. Es bewegt sich was.

Was fehlt: Chrome Shell

Eine Application Shell ähnlich XULrunner oder AIR, aber auf Chromium basierend: Der Browser kann ja jetzt schon Application Shortcuts. Diese werden allerdings noch in einem Chromium-Fenster dargestellt und teilen sich die Datastores mit anderen Webapps.

Nur ein kleiner Schritt wäre es davon zu einer Flex-ähnlichen Umgebung. Mit Google Gears bzw. den offenen LocalStorage APIs kann man schon sehr viel erreichen, z.B. einen vollwertigen Twitterclient als “Offline”-Gears-App bauen. Erweitert man die APIs um Dateizugriffe u.ä. und baut eine kleine Abstraktionsschicht ein – à la AIR – könnte man bald Anwendungen in HTML + JS schreiben. Die Hürde zur Anwendungsentwicklung würde nochmal ein Stück fallen.

Könnte das mal jemand…?