ePartool 4.12 – PHP 7.3 sowie Sicherheits- und Stabilitätsverbesserungen

Update | https://pixabay.com/de/service/license/
Update | https://pixabay.com/de/service/license/

Heute veröffentlichen wir eine neue Version des ePartool. Diese neue Version 4.12 beinhaltet nahezu ausschließlich Fehlerbehebungen, Aktualisierungen der Programmbibliotheken und der technischen Dokumentation. Sie legt zudem den Grundstein für deutliche Überarbeitungen im kommenden Jahr.

Was wurde verändert?

  • Besonders hinweisen möchten wir darauf, dass das ePartool künftig nicht mehr mit PHP-Versionen vor 7.3 getestet wird. Wir haben uns für diesen Schritt entschieden, da PHP 7.3 schon länger bei allen großen Providern verfügbar ist und einige technische Verbesserungen und Geschwindigkeitszuwächse mit sich bringt. Das ePartool kann derzeit (wahrscheinlich) weiterhin auf PHP 7.2 betrieben werden. Allerdings ist zu beachten, dass hier Fehlerbehebungen der PHP-Community nur noch in unregelmäßigen Abständen zu erwarten sind und in einem Jahr komplett eingestellt werden.
  • Der Installationsassistent hatte in der vergangenen Version den notwendigen ersten Medien-Ordner nicht eingerichtet, was man bisher manuell korrigieren musste. Diese Nacharbeit ist nun nicht mehr notwendig.
  • Die Passwort-E-Mail ist auf vielfachen Wunsch künftig länger gültig: 24 Stunden lang kann man sich damit ein neues Passwort vergeben.
  • Wenn die System-E-Mail falsch eingetragen war, reagierte das ePartool bisher mit einem „Error 500“.

Der ePartool-Downloader, der die Installation gerade bei langsamen DSL-Leitungen deutlich beschleunigt, da man direkt auf den Server herunterladen kann, ist ebenfalls aktualisiert worden. Er testet den Server und gibt Tipps, wenn Probleme gefunden werden. Alle neuen Installations- und Update-Dateien finden sich hier.

Wir haben uns dazu entschieden, dass wir sehr alte ePartool-Versionen nicht mehr direkt als Download zur Verfügung stellen. Die älteste Version auf unserem Server ist daher seit heute die 4.5.3 von Mitte 2017. Diese Version war die erste, die von vorherigen Versionen direkt geupdatet werden konnte.

Mitentwickeln

Das ePartool wird öffentlich einsehbar auf Github [github.com/DeutscherBundesjugendring/epartool] entwickelt. Wir haben weiter an einer guten technischen Dokumentation gearbeitet. Neben oben beschriebenen Verbesserungen fanden viele Aktualsierungen von externen Programmbibliotheken statt. Auch wurden die Ruby-Abhängigkeiten für die Jekyll-Dokumentation (Github Pages) ebenfalls aktualisiert. Für die Mitentwicklung ist künftig mindestens NodeJS 10 notwendig.

Wie geht die Weiterentwicklung 2020 weiter?

Nach einem relativ ruhigen Jahr wollen wir das ePartool 2020 wieder deutlich erneuern. Wir haben dazu neben unseren eigenen Ideen zahlreiche Rückmeldungen von Nutzenden gesammelt und freuen uns natürlich weiterhin über Feedback.

Unsere Pläne sehen folgende Schwerpunkte vor:

  • Die Nutzeroberfläche soll entschlackt werden, dass sie nicht mehr so überfachtet ist. Gerade für nur gelegentlich stattfindende Beteiligungsrunden ist das ePartool bisher zu komplex.
  • Über Mittel von „Progressive Web Apps“ soll das ePartool so gestaltet werden, dass es sich für Nutzer*innen wie eine Smartphone-App nutzen lässt.
  • Für einzelne Beteiligungsrunden soll es eine Startseite geben, bzw. die Möglichkeit die jetzige Startseite besser auf genau eine laufende Maßnahme anzupassen.
  • Die Registrierung soll nicht länger nur per E-Mail möglich sein, da Jugendliche heutzutage eher über Messenger erreicht werden können: Hier sind aber noch einige Fragen nach Schnittstellen und Datenschutz zu klären.
  • Beteiligungsrunden sollen auch mit Audio und Bilder-Uploads ermöglicht werden. Videos sollen möglicherweise auch direkt hochgeladen werden können, um nicht wie bisher auf Fremdplattformen angewiesen zu sein.
  • Neue ePartool-Versionen sollen direkt über einen komfortablen Updater einzuspielen sein.

Was ist eigentlich … ein »Cronjob«?

Wenn man neue Website-Anwendungen oder Online-Portale einrichtet, findet sich in der Installationsanleitung häufig auch der Hinweis, dass ein »Cronjob« einzurichten sei. Aber worum handelt es sich dabei eigentlich?

Cronjobs beinhalten Aufgaben, die regelmäßig oder zu bestimmten Zeitpunkten stattfinden sollen. Ein Beispiel wäre ein automatischer Versand von E-Mails zur Erinnerung an Fristen oder tägliche Zusammenfassungen eines Forums. Diese Mails werden in der Regel nicht jedes Mal von einem Menschen zusammengestellt, sondern von der Server-Software.

Gebraucht werden diese wiederkehrenden Aufgaben vor allem auf Systemen, die rund um die Uhr laufen: Backups werden automatisiert angelegt oder bestimmte Systembereinigungen können so regelmäßig zu weniger frequentierten Zeiten (meist nachts) ablaufen. Das Entkoppeln von Momenten hoher Systemlast und Hintergrundaufgaben, die auch zu anderen Zeitpunkten stattfinden können, stellt den neben termingebundenen Aufgaben einen weiteren großen Vorteil von Cronjobs dar – ein typisches Beispiel wäre die Aktualisierung eines Inhaltsindexes für die Suchfunktion: Diese muss nicht exakt in dem Moment geschehen, wenn ein neuer Artikel in die Datenbank eingetragen wird, sondern darf meist auch einige Minuten später erst erfolgen.

Auf Arbeitsplatzrechnern oder Notebooks hingegen sind Cronjobs seltener anzutreffen. Oft werden wiederkehrende Aufgaben wie die Suche nach neuen Antivirus-Signaturen einfach jedes Mal bei Systemstart durchgeführt.

Für einen Cronjob benötigt man die Aufgaben, die erledigt werden sollen, niedergeschrieben in einem Programmskript. Skripte in einer Programmiersprache wie PHP, die gerade bei Website-Anwendungen sehr beliebt ist, kann aber von einem Server nicht direkt verstanden werden, sondern muss von einem »Interpreter« übersetzt werden. Welcher das ist, muss beim Einrichten eines Cronjobs ebenfalls angegeben werden. Und schließlich sind die Zeitangaben für das Ausführen wichtig – hier gibt es eine Fülle von Möglichkeiten (siehe Grafik).

Dieser Cronjob läuft jeden Morgen um 7:00 Uhr.

Cronjobs werden tabellarisch in einer Crontab-Datei abgespeichert. Bei Webhosting-Providern ist häufig eine grafische Benutzeroberfläche vorhanden, um die Jobs einzutragen und zu verwalten. Leider sind dabei oft Begrenzungen vorgegeben, z.B. dass mindestens zwei Stunden zwischen der Ausführung eines Cronjobs liegen muss. Für Web-Anwendungen, die häufiger solche Hintergrundaufgaben benötigen, kann man den Cronjob dann ggf. mehrfach anlegen: Während der erste z.B. zu allen ungeraden Stunden ausgeführt würde, wäre Cronjob 2 für alle geraden Stunden zuständig.

Gelegentlich sind Cronjobs mit Zugriffstokens abgesichert, d.h. nur wenn man eine Art Passwort mit übermittelt, wird der Cronjob ausgeführt. Dieses Verfahren setzen wir u.a. im ePartool ein, um sicherzustellen, dass ein Cronjob nicht missbräuchlich zum Spam-Mail-Versenden fehlgeleitet werden kann.

Tipp: Nextcloud komfortabler verwalten mit »OCC Web«

Nextcloud ist ein datenschutzbewusster Gegenentwurf zu den großen Cloudanbietern und bietet vielfältige Möglichkeiten für Dateiaustausch und Onlinezusammenarbeit. Diese selbst betriebene Cloud ist dabei ausgesprochen genügsam: Sogar auf einfachen, gemieteten Webhosting-Paketen kann Nextcloud eingerichtet und mit Freund*innen und Kolleg*innen genutzt werden – sogar noch parallel zu einer bestehenden Website. Zusätzlich Kosten für den Betrieb können so vermieden werden.

Wer so eine kleine Nextcloud-Instanz betreibt, kann damit ohne Weiteres mit 20-50 gleichzeitig aktiven Nutzer*innen zurechtkommen: Die meisten Funktionen und Erweiterungs-Apps funktionieren ganz wunderbar. Einschränkungen treten im Betrieb am ehesten in Erscheinung, wenn mehrere Personen zeitgleich mit derselben Datei arbeiten oder auf aufwändige Funktionen zugreifen. In solchen Fällen geht nichts kaputt, aber es kann passieren, dass Nextcloud Dateien zu konservativ vor einem Löschversuch schützt.

Während die Nutzung von Nextcloud auf einfachen Webhosting-Paketen gut möglich ist, sind hier vor allem die administrativen Funktionen eingeschränkt: Auf einem „richtigen“ Server kann das Nextcloud-eigene Konfigurationswerkzeug OCC benutzt werden; kostengünstige Shared-Hostings erlauben jedoch meist keinen SSH- und damit keinen Befehlszeilen-Zugriff. Das erschwert Wartungsarbeiten, insbesondere wenn nach einer Versionsaktualisierung bestimmte Datenbank-Aktionen oder Neuindizierungen empfohlen werden oder zentrale Aufgaben für mehrere Nutzer*innen anstehen. Diese Aufgaben per Hand direkt in der Datenbank oder in diversen Installationsverzeichnissen zu erledigen ist unkomfortabel, technisch anspruchsvoll und fehleranfällig. Bisher gab es dazu aber keinen anderen Weg.

Das Wehklagen der Admins wurde von den Nextcloud-Entwickler*innen jedoch ernst genommen: Seit wenigen Tagen existiert ein Plug-in (in Nextcloud-Sprache: „App“), das die Befehlszeileneingabe direkt im Backend nachrüstet: Ein Admin kann sich also ins Backend einloggen und die notwendigen OCC-Befehle hierüber eingeben. Auch ist diese „OCC Web“ genannte Erweiterung recht hilfsbereit und zeigt nach Drücken der ENTER-Taste alle verfügbaren Befehle und deren Bedeutung an. Auch Wartungsfunktionen für andere installierte NC-Apps stehen bereit.

Befehlsübersicht von OCC_Web

Als Admin sollte man sich bei allen Vorteilen von »OCC Web« dennoch überlegen, ob man diese Erweiterung nur anlassbezogen oder dauerhaft einrichtet. Möglicherweise tun sich über die administrativen Funktionen Angriffsvektoren für Bots oder Schädlinge auf, die die Nextcloud-Instanz übers Web erreichen können. Generelle gilt, dass jede installierte App stellt ein mögliches Einfalltor darstellt, vor allem wenn sie sich noch recht jung in Entwicklung befindet. Daher könnte es sinnvoll sein, OCC Web nur im konkreten Bedarfsfall zu installieren und danach wieder herauszunehmen – in Nextcloud eine Sache von wenigen Sekunden.

Und wofür steht nun eigentlich das Kürzel »OCC«? „OCC“ wurde bereits eingeführt, als sich das Nextcloud-Projekt noch nicht von OwnCloud abgetrennt hatte. Daher bedeutet die Abkürzung OCC vermutlich „OwnCloud Configuration“ und wurde in Nextcloud so beibehalten.

Nextcloud: Was passiert mit Dateien, wenn ein Nutzeraccount gelöscht wird?

Nextcloud ist eine freie Software zum Teilen und gemeinsamen Bearbeiten von Dateien, Terminen, Aufgaben, zum Chatten, Videokonferieren, Zusammenarbeiten und Vielem mehr. Nextcloud skaliert dabei von kleinen Teams bis vielen tausenden Nutzer*innen – und bereits auf recht einfachen Webhosting-Paketen können kleine Organisationen und Teams schon sehr gut zusammenarbeiten. Der eigene Nextcloud-Server kann dabei hervorragend mit weiteren Nextclouds, Ownclouds und anderen interagieren: Die Vernetzung über den eigenen „Serverrand“ ist also schon mitgedacht.

Meine Daten gehören mir! Der empowernde Ansatz von Nextcloud

Nextcloud und ihr Quasi-Vorfahre ownCloud sind aus dem Gedanken entstanden, dass Nutzer*innen die Herrschaft über ihre Daten behalten sollten. Bei großen kommerziellen Anbietern werden Daten in irgendeinem Datenzentrum gespeichert (und man hat keinen Einfluss darauf wo genau das ist). Bei Nextcloud ist das anders: Man entscheidet selbst, ob man »die Cloud« bei sich zu Hause installiert oder irgendwo anders.

Dateien in Nextcloud können auf vielfältige Art freigegeben und geteilt werden: persönlich, öffentlich, Cloud-übergreifend; mit und ohne Schreibberechtigung, Ablaufdatum, Schlagwörtern und Erklärnotizen. Im Bildschirmausschnitt ein paar der Möglichkeiten.

Teams arbeiten zusammen, aber nicht für immer

Teams sind nicht beständig – mal kommen neue Personen hinzu, mal steigen Akteure wieder aus. Was bedeutet das für die Zusammenarbeit auf Basis der Nextcloud? Wenn neue Personen hinzukommen, dann ist die Sache meist recht einfach: Man holt sie neu in Gruppen (systemzentral eingerichtete Gruppen) oder Kreise (von Personen gestartete Gruppen) hinzu oder teilt ganz individuell die relevanten Dateien. Problematisch ist jedoch, wenn Personen aus einem Team aussteigen. Hier herrscht unserer Erfahrung nach viel Unsicherheit über die Daten, die in der gemeinsamen Zeit entstanden sind.

Was passiert mit Dateien, wenn ein Nutzeraccount entfernt wird?

Bildschirmdialog Nutzer entfernen

Nutzeraccounts in Nextcloud können entweder deaktiviert oder ganz gelöscht werden.

Wir haben nachgeforscht und stellen euch hier die verschiedenen Varianten vor. Grundsätzlich ist es so, dass Nutzeraccounts deaktiviert oder ganz gelöscht werden können. „Deaktiviert“ bedeutet, dass sich diese Person nicht mehr einloggen kann, die erstellten Dateien aber noch vorhanden sind – also auch für alle, mit denen etwas geteilt oder gemeinsam erstellt wurde.

Ob Daten für Teampartner*innen noch vorhanden sind, wenn ein Account komplett gelöscht wird, ist abhängig vom Speicherort.

1. Persönlich erstellte Dateien der Person: werden mit Nutzeraccount gelöscht.

2. Persönlich erstellte Dateien, die mit anderen Personen geteilt wurden: sind mit Löschung des Nutzeraccounts ebenfalls für die anderen Personen nicht mehr vorhanden.

3. Persönlich erstellte Dateien, mit anderen geteilt und von diesen bereits bearbeitet: Hier überwiegt ebenfalls, wer die Datei angelegt hat – und somit werden diese Dateien inkl. aller Bearbeitungen beim Löschen des Ursprungs-Nutzeraccounts ebenfalls gelöscht.

4. Persönlich erstellte Dateien, in einem Ordner gespeichert, der von jemandem Anderen erstellt und mit mir geteilt wurde: Hier überwiegt der Ursprung des Ordners – wenn von jemandem Anderen erstellt (und mit dem zu löschenden Account geteilt), dann bleiben die Dateien bestehen.

5. Persönlich erstellte Dateien, in einem Gruppenordner gespeichert: Auch ein Gruppenordner wurde von jemand Anderes erstellt (nämlich dem System) und daher bleiben hier erstellte Dateien unabhängig von den Personen, die die Dateien erstellt oder bearbeitet haben, bestehen.

Was also tun, wenn euch ein*e Kolleg*in verlässt?

Falls sich bei euch Fall 2 oder 3 als Problem andeutet, könnt ihr dem Verlust von Daten vorbeugen: Jemand, mit dem/der die Dateien geteilt wurden, kann sie herunterladen und dann neu (als eigene Dateien oder in einem Gruppenordner) wieder hochladen. Dieser Weg erscheint möglicherweise nicht als bequem, aber ist als kleiner Handel für den höheren Schutz der eigenen Daten durchaus zu verschmerzen.

– – –

Wir haben diese Zusammenstellung mit der aktuellsten Nextcloud-Version 14.0.3 getestet. Wen ihr andere Erfahrungen in Nextcloud-Erweiterungen (die „Apps“) gemacht habt, kommentiert und ergänzt gerne!

ePartool: Mindestvoraussetzungen aktualisiert (PHP 7.1, MySQL 5.7, Verschlüsselung)

In wenigen Tagen erscheint das ePartool mit Unterstützung von regionalen Beteiligungsrunden (Landkarten-Funktionen) sowie Neuerungen bei den Abstimmungsmöglichkeiten (verschiedene Designs und Ja/Nein-Abstimmungen). Diese weitreichenden Änderungen haben wir zum Anlass genommen, die Mindestvoraussetzungen an das ePartool zu aktualisieren.

Wir empfehlen serverseitig den Umstieg auf PHP 7.1, das im Dezember 2016 erschienen ist. PHP 7.0 wird offiziell vom Hersteller noch bis Dezember 2018 gepflegt, jedoch werden wir das ePartool nur noch auf mindestens PHP 7.1 testen. Auch hinsichtlich der Datenbank empfehlen wir euch eine Aktualisierung. Der MySQL-Server 5.7 erschien bereits im Oktober 2015 – auch hier werden wir ältere Versionen nicht mehr in Tests berücksichtigen.

Zu guter Letzt gibt es nun eine verpflichtende Mindestanforderung an das ePartool: Die Übertragungsverschlüsselung (https) ist Voraussetzung für das Funktionieren der Landkarten-Funktionen. Hierfür wird ein sogenanntes SSL-Zertifikat benötigt, was allerdings bei Installationen der letzten Jahre auch schon längst üblich gewesen sein sollte: Ihr schützt doch sicherlich die Daten und Passwörter eurer Nutzer_innen, nicht?

Bei Fragen zu den Umstellungen helfen wir euch gerne weiter.

Heute ist „Safer Internet Day“

Am zweiten Tag der zweiten Woche des zweiten Monats findet jährlich der „Safer Internet Day“ statt. Die Zielsetzung an diesem „Tag für mehr Internetsicherheit“ ist über Aktionen und Informationen eine langfristige Sensibilisierung und Stärkung der Medienkompetenz für die Gefahren im Internet zu fördern. Mit jährlich wechselnden Schwerpunkten wird eine Bandbreite von Themen abgedeckt: „Safer“ kann das Internet ja in vielerlei Hinsicht sein.

Im Jahr 2018 steht der Aktionstag in Deutschland unter dem Motto »Alles Unter Kontrolle?!«. Es soll darum gehen, wie souverän und selbstbestimmt wir alle eigentlich online unterwegs sind.

Logo des Safer Internet Day 2018 [Quelle: saferinterneday.org]

Logo des Safer Internet Day 2018 [Quelle: saferinterneday.org]

Damit der Safer Internet Day nicht nur ein Tag von Pressemitteilungen bleibt, fördern die Europäische Union und verschiedene Ministerien eine Vielzahl von Online-Angeboten, die von Telefonberatung und Jugendschutzmaßnahmen über eine Internet-Beschwerdestelle bis hin zu Fortbildungsangeboten für Kinder, Jugendliche und Erwachsene reichen. Einen guten Einstieg bzw. Übersicht über die verschiedenen Angebote gibt es unter der Adresse www.saferinternet.de. Einen großen Pool an Angeboten, sortierbar nach Sprachen und Altersspanne der jeweiligen Zielgruppe, gibt es unter www.saferinternetday.org/web/sid/resources/gallery.

Keine Chance für Hetze dank der »Internet-Beschwerdestelle«

Als Lesezeichen setzen kann man sich dabei auch die „Internet-Beschwerdestelle“, die sich um Inhalte in Deutschland und weltweit kümmert. Dabei klärt die Website auch über die Art der Inhalte und über die Verfahrenswege auf, die nach eine Beschwerde getätigt werden. Los geht’s auf: internet-beschwerdestelle.de

Empfohlenes Sicherheitsupdate: Antragsgrün 3.7.5

Kurzfristig ist ein Sicherheitsupdate für Antragsgrün verfügbar, das mehrere Angriffspunkte für XSS-Attacken schließt. „XSS“ ist ein Kürzel für „Cross-Site Scripting“, also website-übergreifendes Skripting. Das bedeutet, dass Angreifer eine Sicherheitslücke in Antragsgrün ausnutzen könnteb, um JavaScript-Code in Anträgen einzuschleusen, der dann bei anderen Nutzer_innen ausgeführt würde.

Darüber hinaus wurden kleinere Fehler behoben. Neue Funktionen sind nicht vorhanden.

Das komplette Changelog befindet sich wie immer unter https://github.com/CatoTH/antragsgruen/blob/v3/History.md. Das fertige Installationspaket in Version 3.7.5 für Webhostings kann heruntergeladen werden unter https://www.hoessl.eu/antragsgruen/antragsgruen-3.7.5.tar.bz2.

Fremde Inhalte einbinden und trotzdem „sicher“ bleiben?

Das Besondere am World Wide Web ist, dass alle Inhalte miteinander vernetzt sein können. Mit nur einem Klick gelangt man zu weiterführenden Informationen oder neuen Inhalten. Zugleich wurde auch das traditionelle Konzept von „Seiten“ durch das WWW dank seiner Vernetzungs- und Interaktionsmöglichkeiten deutlich erweitert. Neben Fließtext und Bildern kann eine Seite aus weiteren Elementen bestehen, die aus ganz unterschiedlichen Quellen interaktiv eingebunden sind: Youtube-Videos, aktuelle Podcasts, Instagram-Fotos, Tweets (Twitter) oder Präsentationen mit Prezi sind nur ein paar der bekannteren Beispiele.

Diese Einbinde-Möglichkeit hat aber auch ihre Kehrseite, da man selbst als Seitenbetreiber_in kaum mehr überblicken kann, was am Ende auf einer Seite zu sehen sein wird. Thematisch unpassende, aufdringliche Werbeanzeigen nerven; Tracking-Cookies von Werbetreibenden oder von Social Media Funktionen durchleuchten die Besucher_innen meist ohne Vorwarnung und ohne Opt-out-Möglichkeit.

Über solche unerwünschte Aspekte hinaus bedeutet die vernetzte Herangehensweise des World Wide Web auch, dass sogar gefährliche Inhalte in eigentlich harmlose Seiten hineingeraten können.

Typische Einfallstore

Die Einfallstore sind zum Einen die eigentlich willentlich eingebundenen externen Quellen und zum Anderen (unbewusst) bestehende Sicherheitslücken: Wenn die eigene Website durch ein Content Management System befüllt wird, finden sich trotz aller Sorgfalt immer wieder Schwachstellen in der Programmierung dieses Redaktionssystems. Gerade interaktive Funktionalitäten sind besonders gefährdet. Typische Beispiele sind hierfür

  • Formulare (Anmeldemasken, Registrierungsformulare, Fragebögen, Suchfelder), die die eingegebenen Daten nicht auf den eigentlich beabsichtigten Inhalt prüfen oder beschränken, sondern z.B. statt der Eingabe einer eMail-Adresse dann möglicherweise die Übertragung von Programmiercode erlauben;
  • Funktionen zum Hochladen von Dateien (im Kern ebenfalls Formulare), die es versäumen zu überprüfen, ob z.B. wirklich nur eine Grafik oder doch stattdessen Programmcode übertragen wurde;
  • Suchfilter oder andere Parameter, die von einer Seite an die nächste übergeben wurden und bei denen aufgrund mangelnder Überprüfung Code-Einschleusung nicht verhindert wurde.

Eine so präparierte Website kann dadurch ganz andere Inhalte anzeigen als ursprünglich beabsichtigt. Wenn Nutzer_innen dann per eMail oder über Social-Media eine Einladung erhalten die Seiten zu besuchen, können sie nur sehr schwer erkennen, dass die Inhalte manipuliert wurden. Die Web-Adresse sieht ja weiterhin vertrauenswürdig aus und selbst die möglicherweise vorhandene https-Verschlüsselung funktioniert wie eh und je.

Die Lösung naht: Fremde Quellen explizit durch CSP freigeben

Um diesem Dilemma etwas entgegenzusetzen, wurde das Konzept der »Content Security Policy« (CSP) ersonnen. Im Kern funktioniert es so, dass die Betreiber einer Website im Rahmen einer Liste (Whitelist) einzeln aufführt, von welchen fremden Quellen Inhalte überhaupt auf der Website erscheinen dürfen. Die Liste ist dabei in einzelne Sektionen unterteilt. So kann beispielsweise festgelegt werden, dass für Audio und Video bestimmte Quellen zugelassen sind, Schriftarten oder eingebundene Fragebogen aber wiederum nur von anderen Quellen. Dadurch soll verhindert werden, dass eingebunde Quellen Inhalte mit ausliefern, die man als Betreiber_in einer Website nicht vorher eingeplant hat.
Dieses „Whitelisting“ hat allerdings eine Kehrseite: Nicht explizit freigegebene Quellen werden auch ohne weitere Erklärung unterdrückt. Wenn man beim Befüllen der Inhalte die Liste der Freigaben nicht im Kopf hat, wird man bei nicht-angezeigten Inhalten kaum die Ursache des Problems erkennen. Eine Einführung von CSP-Mechanismen sollte daher immer in enger Abstimmung zwischen den technisch und den redaktionell verantwortlichen Teams erfolgen.

Umsetzung von Content Security Policy im ePartool

Das ePartool unterstützt seit dem Frühjahr 2017, ab den Versionen 4.3.x, das Konzept der Content-Security-Policy.

Seither haben wir die Konfiguration noch etwas vereinheitlicht und verbessert. Die Quellen können in der Datei config.ini des ePartool eingetragen werden. Aus Sicherheitserwägungen heraus kann die Liste leider nicht bequem über die Redaktionsoberfläche verändert werden (da sie sonst angreifbar wäre und der Sicherheitsaspekt konterkariert würde). Wir liefern das ePartool bereits mit häufig benutzen Quellen aus, allerdings lohnt es sich auf jeden Fall, die Liste selbst noch zu überprüfen.

Der Aufbau und eine Übersicht der vorhandenen Einstellungsmöglichkeiten finden sich in der config.ini-Beispieldatei, die im selben Ordner zu finden ist wie die config.ini selbst: tool/application/configs/config.local-example.ini

; CORS settings - contains list of allowed addresses from where can be loaded external resources
; allow address for specific type of resource
; for details see https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy

; Serves as a fallback for the other fetch directives
; cors.default-src[] = "*.example.com"

; Specifies valid sources of application manifest files - <link rel=manifest>
; cors.manifest-src[] = "*.example.com"

; Specifies valid sources for loading media using the <audio> and <video> elements - <video> <audio> <source> <track>
; cors.media-src[] = "*.example.com"

; Specifies valid sources for the <object>, <embed>, and <applet> elements
; cors.object-src[] = "*.example.com"

; Restricts the URLs which can be used as the target of a form submissions from a given context
; cors.form-action[] = "*.example.com"

; Specifies valid sources of images and favicons
; cors.img-src[] = "data: *.example.com"

; Specifies valid sources for fonts loaded using @font-face
; cors.font-src[] = "*.example.com"

; Specifies valid sources for JavaScript
; cors.script-src[] = "*.example.com"

; Specifies valid sources for stylesheets - <link rel=stylesheet>
; cors.style-src[] = "*.example.com"

; Restricts the URLs which can be loaded using script interfaces - XmlHttpRequest() WebSocket() EventSource() sendBeacon() fetch()
; cors.connect-src[] = "example.com"

; Defines the valid sources for web workers and nested browsing contexts loaded using elements such as <frame> and <iframe>
; cors.child-src[] = "*.example.com"

 

Browserunterstützung: Fast alle sind dabei

CSP wurde bereits weiter entwickelt und ist derzeit in der zweiten Ausbaustufe technisch definiert. Während die Grundfunktionen mittlerweile in den meisten Browsern Einzug gefunden haben, wird der aktuelle Level 2 des Content Security Policy Konzepts vom Opera Mini und dem Internet Explorer 11 nicht unterstützt (aber vom Microsoft-Edge-Browser). Detaillierte Informationen hierzu finden sich bei »Can I Use …« unter https://caniuse.com/#search=csp

Tipp: Antragsgrün-Installation aktualisieren

Antragsgrün wird laufend weiterentwickelt. Fehlerbehebungen und neue Versionen erscheinen manchmal im Abstand von wenigen Tagen. Damit Installationen mit nicht allzu großem Aufwand auf dem aktuellen Stand gehalten werden können, gibt es einen Assistenten für das Installationspaket von Antragsgrün. Er kümmert sich um eventuell notwendige Datenbankanpassungen selbst:

  1. Die neueste Version von Antragsgrün herunterladen.
  2. Alle Dateien extrahieren und damit die bestehende Installation überschreiben. Die bisherige Konfiguration bleibt dabei unangetastet (zu finden in /config/config.json).
  3. Die Datei /config/INSTALLING entfernen
  4. Auf der Kommandozeile ./yii migrate ausführen, um die ggf. notwendigen Datenbankänderungen der neuen Version automatisch zu erledigen. Falls man lediglich ein Webhostingpaket benutzt, gibt es den Ausweg eine exakte Kopie auf dem lokalen Rechner zu aktualisieren und dann erst auf den Server hochzuladen.

Trotz dieses Assistenten sollte man nie vergessen, vorher ein Backup der Installation sicherzustellen: Nur dann kann man ohne Weiteres auf die alte Version zurückkehren, falls die Aktualisierung schiefgelaufen ist.

 

Was ist eigentlich… ein »Staatstrojaner«?

Frage: In den Medien wird immer wieder von „Staatstrojanern“ und „Quellen-TKÜ“ berichtet. Worum geht’s da?

Antwort: Vom trojanischen Pferd, das einen Angriff auf die Stadt Troja von innen heraus ermöglichte, hat die Software-Gattung der »Trojaner« ihren Namen. Es handelt sich um vom Nutzer unerwünschte Anwendungen, die ihn ausspionieren, Daten manipulieren oder Geräte fernsteuern. Diese Trojaner existieren für Computer und Smartphones/Tablets gleichermaßen.
»Quellen-TKÜ« steht für Telekommunikationsüberwachung (TKÜ) an der „Quelle“, also dort wo die konkreten Vorgänge passieren. Es geht also darum die Trojaner direkt auf die Geräte der zu überwachenden Personen zu bekommen und dort die Daten live zu durchsuchen oder Eingaben oder Kommunikation mitzuprotokollieren. »Quellen-TKÜ« und »Online-Durchsuchung« sind daher auch die offiziellen Bezeichnungen für den Staatstrojaner. Unbemerkt vom Nutzer/von der Nutzerin soll das Mikrofon eingeschaltet werden, Bildschirmfotos gemacht und von der Ferne auf das Gerät zugegriffen werden.

Das Bundesverfassungsgericht beschloss 2008, den Einsatz von Staatstrojanern nur unter großen Auflagen für die Bekämpfung von Terrorismus zuzulassen. Der Bundestag möchte die Rahmenbedingungen und Einsatzmöglichkeiten allerdings derzeit deutlich erweitern.

Neben rechtsstaatlichen Fragen zieht Trojaner-Software aber auch konkrete Sicherheitsprobleme nach sich: Durch das Ausnutzen vorhandener oder neu geschaffener Einfallstore sind die Geräte auch noch anfälliger für Kriminelle. Man darf nicht vergessen: Die Überwachung soll der Aufklärung von Straftaten dienen und sollte daher nicht noch weitere Straftaten befördern.