Datenschutz bei Websites

Hallihallo,
worauf sollte man besonders achten, wenn man eine datenschutzkonforme Website erstellen (lassen) möchte?

Das man sich mit dem Thema Cookies und Cookie-Banner auseinander setzt und nur das nötigste im Einsatz hat. Wenn man z.B. Google Web Fonts für die Schriftart benutzen will, kann man dies selber hosten und muss sich die Schriftart nicht von Google Servern aus den USA einbinden lassen mit dem Nebeneffekt, dass man die IP-Adressen der User übermittelt.

→ eine “cleane” Webseite ist Trumpf

1 Like

Für deine Frage muss man enorm ausholen…

Cookies

  • am besten keine Cookies, wenn Cookies unbedingt nötig dann sollte man diese ‘wenigstens’ absichern und sie sollten ablaufen
  • wenn notwendig muss man diesen Cookies dann zustimmen (nur wenn wirklich nötig, muss man z. B. bei Matomo nicht)

Zertifikate

  • Welches Zertifikat wird benutzt? Kann man dem Hersteller trauen? (gerne Let’s Encrypt)
  • Wie sicher ist das Zertifikat? (ist es vlt. noch SSLv3 - was nicht mehr sicher ist)
  • Läuft es regelmäßig ab und hat man eine Zertifikatsüberwachung, damit die Website dann nicht unverschlüsselt ist?
  • Wie leitet man auf die verschlüsselte Seite um (Einstellung im Webserverpart)?

Skripte

  • am besten so wenig oder kein Javascript (wenn möglich)
  • keine externen Scripte (z. B. Google & Co.)
  • wenn ihr z. B. euren EIGENEN CDN nutzt und dort Grafiken auslagert, dann vlt. ok aber dann kümmert euch um SRI um euch vor Manipulationen zu schützen

CMS

  • nutzt man ein CMS im Background?
  • braucht eure Seite überhaupt ein CMS vom Input her oder ging es statisch (Einfallstüren)
  • Welche Daten werden im CMS gespeichert (ggf. Mitglieder, Mitarbeiterinformationen → CMS extremes Einfallstor)
  • Wie viel Zeit habt ihr das CMS zu updaten / euch regelmäßig Backups zu ziehen / es zu härten (Aufwand)
  • Bei Wordpress gibt es hier die Serie von Kuketz https://www.kuketz-blog.de/?s=wordpress, ist aber auch an einigen Stellen unwirksam / veraltet:
  • Gerade Dinge wie Fail2ban, Zugriffsschutz, auf keinen Fall viele Plugins (dann kann euch beim nächsten Update die ganze Seite zusammen brechen und gefährdet immer
    wieder → SQL Injections die Sicherheit eurer Website).
  • Gerade bei Wordpress Backups (wo auch eure gesamte DB gebackupt wird) wenn ihr die im öffentlichen www Ordner ausversehen backupt (was durch eine Einstellung wirklich schnell passieren kann, da alles in einem Ordner gebackupt wrid, dann ist eure SQL Datenbank mit allen Nutzerinfos öffentlich zugänglich im Netz !

HTTP Header

  • keine Sorge hat sogar das BfDI vergessen :smiley: (aber sie haben ganz schnell auf meinen Hinweis reagiert und ausgebessert)
  • HSTS sollte eingerichtet sein
  • sämtliche Header gegen XSS Attacken einrichten

CSP / Content Security Police

  • anständig einrichten und nicht dort Drittressourcen a.k.a Google & Co. einbinden (das ist total sinnlos)

Datenschutz

  • ggf. Robots ausschließen
  • das würde ich gerade machen, wenn es Teamseiten, Kontakinfos oder ähnliches mit personenbezug gibt (Recht auf Löschung)
  • abgesehen davon würde ich solche Dienste sowieso ausschließen und keine Teamseiten anlegen, weil unnötig und nicht jeder wissen muss wo man arbeitet
  • keine Mitarbeiterfotos ungefragt veröffentlichen, keine Mitarbeiternamen ungefragt veröffentlichen bzw. das generell nicht tun

Serverinfos

  • zum Schutz vor dem ausspionieren ausblenden inkl. Version etc.

Kontakt

  • Kontaktformulare z. B. wie speichert man die IP, was wird erfasst? Was ist notwendig? Werden die Mails wohin es geleitet wrid automatisch gelöscht oder landet es in einem Archiv?
  • E-Mail - gebt ihr generelle Mails an und keine personenbezogenen? Wie werden diese vor Spam geschützt?
  • kein Google Recaptcha einsetzen
  • E-Mail ggf. mit GPG Schlüssel anbieten

Maps

  • keine weiterleitungen an Drittserver einfach so aufbauen

Tracking

  • Website allgemeiin testen, ob etwas trackt oder funkt.

Sonstiges

  • Foren etc. wäre nochmal ein eigenes Thema
  • auch wenn es das BSI anders sagt: weit mehr als 8 Zeichen Passwort für ALLES. Am besten ab 24 Zeichen ohne wenn und aber.
  • keine Passwörter im Klartext speichern
  • MySQL auch entsprechend absichern
  • kein MD5 mehr. Niemals.
  • IP Adressen regelmäßig löschen (serverseitig)

Und Datenschutzerklärung erstellen natürlich, die sauber ist und alles enthält was du tust :slight_smile:

Spontan fällt mir nicht mehr ein, aber das fällt einem dann meist auch auf :wink:

So @BfDI-Kelber jetzt kann ja mal ein Jobangebot an mich rausgehen :smiley:

5 Likes

Noch als Ergänzung:
Beim Einsatz von Dritten die auf pbD Zugriff haben (Google Analytics, CRM Dienstleister, Web Hoster etc) ist auch auf die Vorgaben zur Auftragsverarbeitung zu achten.

2 Likes

Google Analytics kann man aber momentan nicht DSGVO konform einsetzen, deswegen wenden sich ja alle davon ab.
Auch nicht mit “anonymize IP” das kann ja niemand überprüfen.

Zu den Dienstleistern (Hetzner etc.) stimme ich dir zu mache eine AVV.
Außerhalb Europas wird dir auf Grund von Wegfall des Privacy Shields auch ein AVV nichts bringen, da unsicheres Drittland (meist).

Daher europäische Hoster.

1 Like

Absolut - War auch nur ein Beispiel, man kann auch sagen Video tools, APIs etc.

2 Likes

Als Ergänzung hierzu: Bei der Einbindung von Drittanbieter Ressourcen Zurückhaltung üben. Aktuell grassiert die Unart fremde Subdomänen über einen Eintrag im CNAME Ressource Record einzubinden. Damit “umgeht” man Blockierlisten von Anti-Tracking-Addons und Browsertrackingprotection.

Hier geht man als Webseitenbetreiber ein gehöriges Risiko ein, wenn hier etwas schief läuft: i) Dangleing DNS / Subdomain Takeover und ii) Cookie-Leaking. Die Folge ist u.U. ein Verstoß gegen Art. 32 DSGVO “Sicherheit der Verarbeitung”.

2 Likes

Das ist schon eine schöne Liste, ich habe da noch ein paar Ergänzungen.

Ich find das ein bisschen verwirrend formuliert; technisch zwingend notwendige Cookies benötigen kein Einverständnis, da reicht ein Hinweis in der Datenschutzerklärung. Alle optionalen (Tracking, Werbung, Analytics) Cookies benötigen eine freiwillige Einwilligung.

Hiervon fällt einiges eher unter die Kategorie “Webserver-Hardening”. Was den Hersteller angeht bin ich mir nicht sicher wie die Vertrauenswürdigkeit des Zertifikatsausstellers zu bewerten ist (unabhängig davon sind nur Zertifikatsaussteller vertrauenswürdig die von den Brwosern akzeptiert werden, aber darüber hinaus?)
Das Zertifikat an sich hat keinen direkten Zusammenhang mit der SSL/TLS-Version die der Server anbietet (Es gibt kein SSLv3-Zertifikat, der Server liefert aber eine SSLv3-Verschlüsselung aus wenn das in der Konfiguration nicht deaktiviert ist.). Allgemein sollte der Webserver so gehärtet sein, dass veraltete oder nicht sichere Verschlüsselungsversionen Serverseitig deaktiviert sind.
Durch HSTS sollte ein unverschlüsselter Besuch der Website gar nicht möglich sein, zusätzlich lässt sich in der Webserverkonfigurations jegliche unverschlüsselte Verbindung deaktivieren. Ein Monitoring welches auch die Gültigkeit des Zertifikats im Blick behält ist sinnvoll.
Zum Thema Webserver und möglichem CMS sollte darauf geachtet werden dass die gesamte Software auf dem aktuellen Stand ist und Aktualisierungen zeitnah (am besten am gleichen Tag) eingespielt werden.

Auch das gehört wieder zum Thema Webserver-Hardening, ich denke nicht dass das Ausblenden von der Versionsnummer einen großen Beitrag zur Sicherheit leistet. In dem Zusammenhang weise ich auch auf mögliche “debug”-Einstellungen hin. Bitte achtet darauf dass jegliche Software im Webserver im Produktivmodus und nicht in einem Entwicklungs- oder Testmodus läuft.

Ich halte, falls du eine robots.txt meinst, das Werkzeug für nicht ausreichend um personenbezogene Daten im Sinne des Rechts auf Löschung zu schützen. Ich glaube nicht dass es einen Weg gibt im Internet veröffentliche Daten dauerhaft verlässlich zu löschen.

Bei diesem ganzen Thema sehe ich eine sehr enge Überschneidung mit dem Thema IT-Sicherheit. Da hat das BSI bestimmt auch ein paar gute Tipps und Hinweise.

Möchtest du nicht lieber zum BSI gehen? :slight_smile:

2 Likes

Also Datenschutz und IT-Sicherheit gehen Hand in Hand. Das Hardening gehört zu einer datenschutzfreundlichen Website hinzu (Sicherheit der Verarbeitung) und zu den Dingen wie
Datenschutz zählt nicht nur auf dem Papier, man muss auch entsprechende Sicherheitsmerkmale kennen und umsetzen (sonst ist das sinnlos).

  • Vertraulichkeit.
  • Authentizität.
  • Integrität.

sowie nach aktuellen Stand der Technik verarbeiten (auch alles aus dem Datenschutz).
Zertifikatsgeschichten und Hardening zählt zu DSGVO: Art 5, 25 und 32 zählen.

Meine Beschwerden bei Behörden diesbezüglich wurden allesamt ernst genommen, also würde ich das auch tunlichst umsetzen.

Ich muss mir gerade das lachen verkneifen :wink:

Meinst du die, die 8 Zeichen Passwörter erzählen, obwohl sie viele E-Mails haben? Und die die Windows 10 nutzen? Und die die eine ganz komische ISO Zertifizierung haben und die bei denen ich bis heute nicht weiß warum das SI in BSI drinsteht? :wink:
Nein, danke.

Ausreichend auf keinen Fall, aber zumindest ein kleiner Schutz oder Seiten allgemein von der Indexierung ausnehmen. Das macht es zumindest etwas schwerer, ich nehme jetzt mal an das wird nicht eine Seite mit sehr sehr vielen Hits werden.

Ja, das musst du erstmal an haben :wink:

Tatsächlich tut es das. Es gibt Scanner, die die Versionsnummern und Webserver erfassen (außer du härtest deine Seite dementsprechend das die Scanner abstürzen) und diese spucken dir dazu (individuell zudem was sonst noch sichtbar ist Sicherheitslecks aus, ein Angreifer hat so ein leichtes Spiel.
Das habe ich eine Zeit beruflich getan (in einer Sicherheitsfirma selbstverständlich).

1 Like

Schade, ich vermute dass es dem BSI gut tun würde wenn du zu denen gehst damit die die unsinnigen Sachen abstellen und du dem BSI beibringen kannst wie das eigentlich sein sollte. :slight_smile:

Grundsätzlich kann ich nachvollziehen was du meinst. Ich habe geschrieben dass ich nicht der Meinung bin dass es einen hohen Sicherheitsgewinn bei dieser Maßnahme gibt. Das fühlt sich für mich nach der typischen Security through Obscurity-Diuskussion an, daher versuche ich das ein wenig deutlicher zu formulieren.
Systeme auf den aktuellen Patchlevel zu bringen, in welchem alle bekannten Sicherheitslücken geschlossen sind, halte ich für wichtiger und wirkungsvoller als die Versionsnummer zu verstecken damit nicht auf den ersten Blick klar ist welche Sicherheitslücken im System offen sind.
Ja, die Versionsnummer ausblenden macht das System ein Stück weit sicherer, aber andere Maßnahmen verbessern die IT-Sicherheit deutlicher und sind hilfreicher.

1 Like

In diesem Kontext eine ergänzende Frage:
Bei kostenlosen/kostenpflichtigen Tools zur automatisierten (Vor-)Prüfung einer Website fallen mir ad hoc:

ein.

Wie steht ihr zu dem Thema und welche Tools (inkl. Kostenplan/Paket) nutzt ihr?
Welche Erfahrungen habt ihr mit automatisierten Websiteprüfungen (teilweise mit angepriesener automatisierter Prüfung der Rechtstexte) gemacht?

1 Like

Hier noch ein paar weitere Anmerkungen

Cookies

Wie sichere ich den einen Keks ab? Vorm Krümelmonster verstecken? Nein ernsthaft, wie sichere ich so einen ab?

Was man ja machen kann, ist ein Cookie nur für einen bestimmten Pfad setzen.

Ein Hauptanwendungsfall von Cookies ist die Speicherung des Sitzungsidentifikators. Kommt man an dieses Cookie ran und die Sitzungseinstellungen der Anwendung sind auf eine Zeitüberschreitung der Sitzung nach 10 Tagen eingestellt, kann dieses Cookie ohne Abmeldung des betroffenen Nutzers so lange verwendet werden. Also wäre hier eine “abgesicherte” Sitzungskonfiguration wohl eher zu empfehlen.

Man könnte das Sitzungscookie auch verschlüsseln, bloß bringt das vermutlich nichts. Ob man das verschlüsselte oder unverschlüsselte Cookie als Angreifer an den Server sendet ist ja egal.

Bei einigen Cookies könnte Verschlüsselung aber schon Sinn machen. Um z. B. Angreifern keine interne Struktur der Anwendung zu verraten, die über die Cookies bekannt werden würde.

Was gemacht werden kann sind folgende Cookie-Eigenschaften zu setzen wenn benötigt:

  • path für den das Cookie gültig ist
  • secure wenn gesetzt, wird das Cookie nur über mit TLS verschlüsselte Verbindungen gesendet (Vertraulichkeit & Authentizität)
  • port Liste von Ports bei welchen das Cookie bei der Anfrage mitgegeben wird
  • domain zum expliziten angeben der Domäne bei welcher das Cookie mitgesendet werden soll
  • discard um Nutzer Agenten explizit mitzuteilen, dass das Cookie nach beenden des Browsers gelöscht werden soll
  • max-age wie lange das Cookie gültig ist
    Siehe auch RFC 2965

Keine Cookies zu verwenden ist zwar schwierig, sollte aber in jedem Fall angestrebt werden.

Zertifikate

Bezüglich der TLS Zertifikate und der Konfiguration der entsprechenden Webserver, Datendanksysteme und eventuell für die Webseite vorhandene Mailserver ist der TLS Konfigurationsgenerator von Mozilla meinerseits zu empfehlen.

Dadurch geht man dem Problem aus dem Weg, welche Cipher Suites noch sicher bzw. zu empfehlen sind. Natürlich alles unter der Voraussetzung, dass der Konfigurator aktuell gehalten wird.

Bezüglich TLS Protokoll Versionen ist mir aus einer Kryptographie Vorlesung bekannt, dass Versionen 1.2 und 1.3 aktuell als sicher gelten und guten Gewissens empfohlen werden können. Das deckt sich auch mit den deaktivierten Versionen (Intermediate Configuration siehe Konfigurator Verweis oben).

HPKP wird anscheinend nicht mehr empfohlen

Skripte und Verweise

Wenn möglich kein Javascript verwenden, ansonsten die CSP Kopfzeile entsprechend der vertrauenswürdigen Quellen richtig konfigurieren.
Zusätzlich kann die Integrität (siehe SRI) der zu ladenden Skripte und Verweise mittels eines Hash-Werts überprüft werden. Dieser kann als integrity Attribut bei Skripten (script) und Links (link) angegeben werden und beschränkt sich dabei nicht auf Skripte und Stilvorlagen.
Eine Beispiel:

<link rel="stylesheet" href="https://use.fontawesome.com/releases/v5.12.0/css/all.css"
      integrity="sha256-ybRkN9dBjhcS2qrW1z+hfCxq+1aBdwyQM5wlQoQVt/0=" crossorigin="anonymous"/>
<script src="http://code.jquery.com/jquery-3.5.1.min.js"
    integrity="sha256-9/aliU8dGd2tb6OSsuzixeV4y/faTqgFtohetphbbj0=" crossorigin="anonymous"></script>

Wichtig zu erwähnen ist hier wohl, dass wenn die Ressource von einer anderen Domäne geladen wird das crossorigin="anonymous" Attribut explizit gesetzt werden muss. Andernfalls prüft der Browser die Prüfsumme nicht und die entsprechende Prüfsumme ist nutzlos.
Hier ein SRI Onlinegenerator und auch der Befehl für openssl.

HTTP Kopfzeilen

  • HSTS (siehe RFC)
  • XSS Schutz (Die üblichen Kopfzeilen sind nur noch für ältere Browser notwendig, sonst seit CSP obsolet… Siehe MDN)
  • CSP Zum Einstellen, von welcher Domäne ein Frame eingebunden werden darf, woher Skripte geladen werden dürfen etc. Siehe W3C Arbeitsentwurf
1 Like

na dann würde ich noch folgende hinzufügen:
https://observatory.mozilla.org/
https://privacyscore.org/ (wobei hier auch Elemente aus Webkoll und Observatory drin sind)
und natürlich hardenize.com

2 Likes

Über das ganze technische sollten natürlich auch die Grundsätze der Datensparsamkeit etc. nicht in Vergessenheit geraten. Das kann man natürlich beliebig weit drehen und nobody is perfect.

Auch dieses Forum z.B. lässt beim Passwort-zurücksetzen einfach zu, herauszufinden, welche Mailadressen registriert sind und welche nicht, weil die Rückmeldung unnötig eindeutig ist (wenn auch komfortabel für den Benutzer oder die Benutzerin bei Typos, das ist ja immer das Dilemma. :wink: Bei uns wäre das so erst einmal nicht zulässig.

Oder gehört das eher in den Thread zum Forum??

https://forum.bfdi.bund.de/t/zum-forum/62?u=stonie

2 Likes

Würde ich da rein packen und einen MA vom BfDI taggen :wink:

Ich sag mal danke für die ganzen Hinweise, was euch nicht hindern soll, hier noch weiter zu schreiben. :+1::star_struck:

1 Like

Das kommt darauf an, welche Daten mit dieser Webseite verarbeitet werden sollen. Für eine normale Webseite, mit der keine personenbezogenen Daten verarbeitet werden, würde sogar HTTP genügen. Für einen Online-Shop liegt die Hürde schon höher. Habt Ihr etwas spezielles geplant? Was soll der Zweck der Webseite sein?

Also HTTP würde eher nicht genügen. Sicherheit der Verarbeitung? Seite kann einfach manipuliert werden?
HTTP wird bei uns nicht mal im internen Firmennetz geduldet. Dazu kommt, dass viele Suchmaschinen die Website bei HTTP systematisch ausschließen und auch viele Browser auch vor der Website warnen oder diese inzwischen gar nicht mehr anzeigen.

Ausnahme ist Microsoft IE, der afaik als einziger Browser “gewarnt” wenn eine Seite sicher war (kein Scherz).
Aber wer Microsoft nutzt und sich für Datenschutz einsetzt, denn kann auch nicht mehr helfen. :upside_down_face:

Das kann ich nicht bestätigen.

Datenschutzkonform bedeutet nach meinem Verständnis die Anwendung der Datenschutzvorschriften (DSGVO, BDSG u.a.). Gem. Art.2 ist die DSGVO grundsätzlich anwendbar, wenn personenbezogene Daten verarbeitet werden. Das heißt im Umkehrschluss: Werden keine personenbezogenen Daten verarbeitet, ist sie nicht anwendbar. Woraus folgt: Für eine normale Webseite, mit der keine personenbezogenen Daten verarbeitet werden, gilt die DSGVO nicht. Warum die Zuordnung der Datenschutzvorschriften zu datenschutzkonform? Diese unterliegen im Gegensatz zu gefühltem Datenschutz dem Rechtsstaatsprinzip.

Unabhängig von einer solchen normalen Webseite sehe ich die Hintergrundprozesse (Webserver etc.), denn diese verarbeiten regelmäßig personenbezogene Daten. Diese Daten existieren unabhängig von HTTP / HTTPS und darauf sind die Vorschriften idR anzuwenden.

Selbstverständlich kann man bei jeder Webseite HTTPS einsetzen, jedoch kann man es nicht in jedem Fall mit datenschutzkonform begründen.

Etwas anderes ist eine für jegliche Daten einsetzbare Informationssicherheit, bei der man sich dieselben Fragen wie beim Datenschutz stellen kann: Wie hoch ist das Risiko, dass eine normale Webseite auf dem Weg zum Anwender manipuliert wird? Wer könnte so etwas unter welchen Voraussetzungen umsetzen? Ein Angreifer benötigte dafür den Zugriff auf eine Komponente in der Auslieferungskette (Webserver, Router etc.).

Besteht die Gefahr der Manipulation (zB Austausch eines Bildes durch ein Bild mit eingebettetem Bundestrojaner), wäre HTTPS eine Möglichkeit dies einzuschränken, sofern das Root-Zertifikat vertrauenswürdig ist. Nach meiner Ansicht ist ein Root-Zertifikat vertrauenswürdig, wenn es aus der eigenen PKI stammt. Was bei Webseiten regelmäßig nicht der Fall ist, da zum überwiegenden Teil die Zertifikate fremder Anbieter genutzt werden. Ich kann mich an an diverse Anbieter erinnern, deren Root-Zertifikate aus den Browsern entfernt wurden. Bei Überlegungen zu MITM sollte man außerdem im Hinterkopf behalten, dass die Voraussetzungen für eine Manipulation von HTTPS dieselben wie bei HTTP sind.

Fragt aber jemand nach einer datenschutzkonformen Webseite, ist die Standardfrage zunächst dieselbe wie bei allen Verarbeitungen: Welche Daten soll die Webseite zu welchem Zweck verarbeiten? An dieser Verarbeitung richten sich Risikoeinschätzung und Einsatz technischer Maßnahmen aus (wie zB der Einsatz einer eigenen PKI).

Mein erster Anlaufpunkt für Informationen zur Sicherheit von Webseiten, die auch beim Datenschutz zum Tragen kommt, wäre wohl OWASP.

Teilweise werden die nicht einmal mehr angezeigt, je nachdem wie beliebt die Website ist.

https://www.marketing-2.de/webseite-unsicher-google-ssl-zertifikat/
https://www.seo-agentur.biz/blog/wie-sich-ein-ssl-zertifikat-auf-ihr-google-ranking-auswirkt/