» Datenschutz

1.1. Sicherheit auf einen Blick

• Passwörter gehasht und gesaltet
• Sicheres Session- und Loginsystem
• Berechtigungssystem nach dem Principle of Least Privilege
• Schutz vor XSS durch Zeichenenkodierung
• Schutz vor SQL-Injections durch MySQLi-Prepared-Statements

1.2. Sicherheitserklärung

Hier kann die komplette Sicherheitserklärung eingesehen werden.

1.2.1. Passwörter

Passwörter von angemeldeten Nutzern werden mithilfe von als sicher erwiesenen kryptographischen Verfahren (PHP PASSWORD_DEFAULT (= bcrypt)) nur in gehashter, gesalteter Form in der MySQL-Datenbank gespeichert.
Folglich können Administratoren oder Angreifer, welche Zugriff zur Datenbank erlangen, keine Passwörter im Klartext auslesen.

1.2.2. Berechtigungen

Innerhalb der Anwendungen wird ein Berechtigungssystem eingesetzt, welches Administratoren erlaubt, Nutzer zu Gruppen hinzuzufügen und die Berechtigungen einer Gruppe verwalten.
Die Berechtigungen werden nach dem Principle of Least Privilege vergeben, d.h. es werden einer Gruppe möglichst wenige Berechtigungen erteilt.
Weiterhin stellt das Login- und Berechtigungssystem sicher, dass Personen ohne Login keinerlei Daten von der Datenbank aufrufen können.
Die einzigen ohne Login verfügbare Funktionen sind die zum Erstellen eines neuen Tickets und zum Erstellen von Kommentaren.
Also sind Tickets, Benutzer und Gruppen vor unberechtigtem Zugriff geschützt.
Auch die einzelnen Benutzer, welche nicht über Administrationsrechte verfügen, können bis auf zwei Ausnahmen keine Namen oder andere Details der anderen Benutzer einsehen.

1. Ausnahme: Ein Benutzer erstellt freiwillig unter seinem Account ein Ticket, dann ist der Benutzername in den Details dieses Tickets einsehbar.
   Falls dies nicht geschehen soll, kann man sich zum Erstellen eines Tickets ausloggen und einen falschen Namen / Nickname beim Feld des Erstellers eingeben.
2. Ausnahme: Ein Benutzer entscheidet sich dafür, seinen Namen in der Autocomplete-Liste für Personen (z.B. zum Zuweisen von Tickets) erscheinen zu lassen.
   Standardmäßig ist diese Einstellung deaktiviert.
   Bei Bedarf können Sie sich umentscheiden, indem Sie im Helpdesk in den Datenschutzeinstellungen unter "Allgemeines" den Haken bei "Ihren Namen in der Auswahlliste für die Zuweisung anzeigen" setzen oder wieder entfernen.

1.2.3. Verhinderung von Vulnerabilities

Vulnerabilities (= Verwundbarkeiten) in einer Webanwendung können dazu führen, dass ein Angreifer nach dem Ausnutzen einer Sicherheitslücke Befehle auf dem Server ausführen kann, über erhöhte Rechte verfügt, Daten von Nutzern abgreift oder versucht, deren Systeme anzugreifen.
Im gesamten Internet weisen sehr viele Seiten sehr einfach auszunutzende Verwundbarkeiten auf.
Einige stechen in ihrer Häufigkeit des Auftretens heraus.
Diese werden in der OWASP Top Ten Web Application Security Risks-Liste nach Häufigkeit und Folgenschwierigkeit sortiert.
Obwohl diese Sicherheitslücken sehr leicht zu beheben sind, sind viele Websites immer noch betroffen.
Um die höchstmögliche Sicherheit der Daten unserer Nutzer zu gewährleisten, wurden bei der Programmierung unserer Anwendungen diese Risiken bedacht und verhindert.
Anbei folgt eine Liste mit den Verwundbarkeiten, die auf unsere Anwendung zutreffen könnten, und wie sie behoben werden.

1.2.3.1. Injection

Bei einer Injection-Vulnerability werden die Daten einer Nutzereingabe fälschlicherweise vertraut und ohne Sicherheitsmaßnahmen verarbeitet, was dazu führen kann, dass mit einer Nutzereingabe Befehle ausgeführt oder Daten abgerufen / verändert werden können.
Beispiele für Injections sind SQL-, NoSQL-, OS- und LDAP-Injections.
Aufgrund des Aufbaus unserer Anwendungen wären diese nur für SQL-Injections verwundbar.

1.2.3.1.1. SQL-Injections

Bei einer SQL-Injection wird eine Anfrage, die eine Nutzereingabe enthält, direkt zur Verarbeitung an die Datenbank weitergegeben.
Dabei kann es passieren, dass die Nutzereingabe nicht nur Daten, sondern auch SQL-Anweisungen enthält, welche bei einer Nichtbeachtung von Schutzmaßnahmen vor SQL-Injections vom Datenbanksystem ausgeführt werden.

Betrachten wir z.B. folgenden Code (PHP, MySQL):

...
$query = "SELECT user_id FROM users WHERE user_name = " . $_POST["user_name"] . ";";
mysqli_query($database);
...

Dabei wird eine Query vorberetet und an die Datenbank gesendet.
Es wird der Inhalt der POST-Variable $_POST["user_name"] vom Nutzer gesteuert.
Ein Angreifer gibt folgende Daten ein:

test OR 1 = 1

Dann wird folgender Befehl erstellt und von der Datenbank ausgeführt:

SELECT user_id FROM users WHERE user_name = test OR 1 = 1;

Dies führt dazu, dass der Nutzer anstatt nur seiner Nutzer-ID auch alle anderen Nutzer-IDs auslesen kann.
Weitere Variationen erlauben es dem Angreifer, Tabellen in der Datenkbank zu löschen, andere Daten auszulesen oder Login-Systeme zu übergehen, ohne dass ein valides Passwort benötigt wird.

Unsere Programme verhindern solche SQL-Injections, indem Nutzereingaben nie vertraut werden.
Es werden MySQLi-Prepared-Statements eingesetzt, welche die Daten seperat vom Befehl an die Datenbank senden, sodass vom Angreifer keine Befehle ausgeführt werden können.

1.2.3.1.2. NoSQL-Injections (nicht zutreffend)

Es wird keine Datenbank, die die NoSQL-Technik verwendet, eingesetzt.

1.2.3.1.3. OS-Injections (nicht zutreffend)

Es werden innerhalb des PHP-Codes keine Shell-Befehle ausgeführt.

1.2.3.1.4. LDAP-Injections (nicht zutreffend)

Es werden keine Queries an LDAP-Server gesendet.

1.2.3.2. Kaputte Authentifizierungsmechanismen

Unsere Authentifizierungsmechanismen wurden mit den aktuellsten Funktionen von PHP, welche eine falsche Verwendung unwahrscheinlicher machen, programmiert.
Eine Authentifikation gilt als gültig, wenn die Sessionvariablen gesetzt werden.
In unseren Programmen werden Sitzungsvariablen nur an zwei Stellen gesetzt: beim durch ein Passwort authifizierten Login und beim durch ein Token authentifizierten Login.
An beiden dieser Stellen wird die Ausführung des Programmes vor dem Setzen der Sessionvariablen abgebrochen, falls Token oder Passwort falsch sind.
Token und Passwort werden mit aktuellen Funktionen von PHP verglichen.
Da der Umfang des Codes, der diese Vergleiche übernimmt, sehr überschaubar ist, ist die Wahrscheinlichkeit eines Fehlers sehr gering.
Weiterhin werden bei einem falschen Passwort oder Token nicht nur Header geschickt, die den Browser auf eine Fehlerseite weiterleiten, sondern das Programm beendet sich auch, falls ein Angreifer Header ignoriert.

1.2.3.3. Preisgabe von sensitiven Daten

Wie bereits oben genannt werden vor der Authentifizierung keine Daten aus der Datenbank abgerufen.
Alle Seiten, die Informationen aus der Datenbank abrufen, überprüfen vor der Herstellung der Datenbankverbindung, ob die Sitzung valide ist.
Das Berechtigungssystem verhindert, dass selbst eingeloggte Nutzer Zugriff auf sensible Informationen haben.

1.2.3.4. XML External Entities

Es wird kein XML-Verarbeitungssystem eingesetzt, daher trifft diese Verwundbarkeit nicht auf unsere Programme zu.

1.2.3.5. Kaputte Zugriffsrechte

Unser Berechtigungssystem ist so modular aufgebaut, dass jede einzelne Funktion überschaubar ist und sich leicht überprüfen lässt.
Weiterhin wird in jeder Datei die Ausführung des Programmes unterbrochen, falls der Nutzer nicht über ausreichende Berechtigungen verfügt.

1.2.3.6. Fehlkonfiguration von Sicherheitseinstellungen

Fehlermeldungen von PHP werden komplett unterdrückt.
Die Fehlermeldungen, die der Nutzer zu sehen bekommt, wurden auf das Nötigste reduziert, was sowohl dazu führt, dass weniger Informationen durch diese preisgegeben werden, als auch dazu, dass Nutzer diese und deren Ursachen besser verstehen können, ohne über ausreichendes technisches Wissen zu verfügen.
Es liegt nicht in unserer Kontrolle, die Software, die unsere Anwendungen bereitstellt (Linux, Apache, MySQL, PHP), auf dem aktuellen Stand zu halten.

1.2.3.7. Cross-Site Scripting (XSS)

Ähnlich wie bei einer Injection-Vulnerability ist eine Website gefährdet, von XSS betroffen zu sein, falls Nutzereingaben vertraut wird.
Dabei nutzt ein Angreifer die Funktion der Website, benutzerdefinierten Text auf ihr einzufügen (z.B. Nutzername, Beschreibungen etc.), um anstatt Text JavaScript-Malware einzufügen.
Diese Malware wird dann Browser des Nutzers ausgeführt, der diese Website aufruft.
Dabei kann der Inhalt der Website manipuliert werden, Cookies, welche den Nutzer authentifizieren, gestohlen werden, der Nutzer auf andere, vom Angreifer gesteuerte Websiten weitergeleitet werden oder sogar Verwundbarkeiten im Browser des Nutzers verwendet werden, um das System des Nutzers anzugreifen.

Unsere Anwendungen vertrauen keinen Nutzereingaben.
Jeder Text, der einmal von einem Nutzer eingegeben oder gesendet wurde, wird zuvor mit htmlspecialchars enkodiert, was dazu führt, dass keine Skripte mehr ausgeführt werden, da dann der Code des Skriptes wie normaler Text auf der Website steht, anstatt vom Browser verarbeitet zu werden.

1.2.3.8. Unsichere Deserialisierung

Es wird in unseren Anwendungen keine Serialisierung oder Deserialisierung eingesetzt.

1.2.3.9. Verwendung von Komponenten mit bekannten Verwundbarkeiten

Wie bereits oben genannt haben wir keinerlei Einfluss auf die Aktualität der Software, die unsere Anwendungen bereitstellt.
Wir können z.B. nicht Linux, Apache, MySQL oder PHP aktualisieren, da wir keinen regelmäßigen Zugriff auf eine Serverkonsole haben.
Dadurch kann es sein, dass Komponenten mit bekannten Verwundbarkeiten verwendet werden.

1.2.3.10. Unausreichendes Logging und Monitoring

Wie aus der unten stehenden Datenschutzerklärung herauszulesen, wird von uns direkt noch kein Logging oder Monitoring betrieben.
Dies ist zwar gut für den Datenschutz, aber schlechter für die Sicherheit.
Uns ist nicht klar, ob auf dem Server bereits ein Logging- oder Monitoringsystem vorhanden ist und wie wir daran anbinden / darauf zugreifen könnten.
Wir sehen von manuellem Logging in die Datenbank vorerst aufgrund der Nachteile für den Datenschutz ab.

2.1. Datenschutz auf einem Blick

• Keine Tracking-Skripte
• Verwendung der Grundfunktionen unserer Anwendungen auch mit deaktiviertem JavaScript möglich
• Einsatz von Open-Source-Serversoftware
• Optionale Speicherung von IP-Adressen, HTTP-User-Agents und Loginzeiten für mehr Sicherheit

2.2. Datenschutzerklärung

Die vollständige Datenschutzerklärung, deren Bedingungen Sie bei der Verwendung unseres Ticketsystems oder anderer Dienste zustimmen, kann hier eingesehen werden.

2.2.1. Kontaktdaten des Datenschutzverantwortlichen

Der Verantwortliche im Sinne der Datenschutz-Grundverordnung (DSGVO) und anderer nationaler Datenschutzgesetze ist:

S-Crew GmbH
Regiomontanus-Gymnasium
Tricastiner Platz 1
97437 Haßfurt
Deutschland

E-Mail: datenschutz@s-crew-helpdesk.de

2.2.2. Rechtsgrundlage für die Datenverarbeitung

Insofern wir für die Verarbeitung der personenbezogenen Daten eine Einwilligung der betroffenen Person eingeholt haben, gilt Artikel 6 Absatz 1 Unterabsatz 1a der DSGVO als rechtliche Grundlage.

2.2.3. Angabe des Datenverarbeitungszwecks

Um Ihren Besuch so benutzerfreundlich wie möglich zu gestalten und sämtliche verfügbaren Funktionen anbieten zu können, erheben wir eine Reihe von Daten und Informationen des Geräts, mit dem Sie unsere Website aufgerufen haben. Dabei handelt es sich um folgende Daten:

• IP-Adresse
• Betriebssystem
• Browsertyp und -version
• Datum und Uhrzeit des Zugriffs

Diese Daten werden nach Ende der Verbindung gelöscht.

In den Datenschutzeinstellungen des Helpdesks kann - falls Sie angemeldet sind - optional eine dauerhafte Speicherung dieser Daten aktiviert werden.
Diese Option ist standardmäßig deaktiviert, sodass diese Daten nicht in der Datenbank gespeichert werden.
Bei Bedarf jedoch können die drei Optionen zur Speicherung der IP-Adresse, des HTTP-User-Agents (enthält Betriebssystem, Browsertyp und -version) und des Datums und der Uhrzeit des Zugriffs jeweils einzeln aktiviert werden, um die Sicherheit zu erhöhen, da durch mehr Daten in der Sitzungsverwaltung Angriffe besser von Ihnen erkannt werden können.
Schließlich können diese Daten jederzeit gelöscht werden, indem Sie das betroffene Gerät durch die Sitzungsverwaltung ausloggen.

Eine Auswertung dieser Daten zu Marketingzwecken findet in diesem Zusammenhang nicht statt.

2.2.4. Empfänger oder Kategorien von Empfängern personenbezogener Daten

Unsere Dienste geben keinerlei Daten an Drittanbieter weiter.
Es werden keine Trackingskripte oder Anzeigendienste verwendet.

2.2.5. Angabe der Datenspeicherungsdauer

Alle personenbezogenen Daten, die wir während Ihres Besuchs durch den Einsatz von Sitzungs-Cookies gesammelt haben, werden automatisch gelöscht, sobald der Zweck für ihre Erhebung erfüllt ist. Die Sitzungsdaten werden demnach so lange gespeichert, bis Sie Ihre Sitzung beenden (durch das Verlassen bzw. Schließen der Website).
Alle personenbezogenen Daten, die nach der Sitzung in der Datenbank gespeichert werden, können entfernt werden, indem Sie ihren Account durch einen Administrator löschen lassen.

2.2.6. Hinweis auf Betroffenenrechte

Im Sinne der DSGVO zählen Sie als Betroffener, wenn personenbezogene Daten, die Sie betreffen, von uns verarbeitet werden. Aus diesem Grund können Sie von verschiedenen Betroffenenrechten Gebrauch machen, die in der Datenschutz-Grundverordnung verankert sind. Hierbei handelt es sich um das Auskunftsrecht (Artikel 15 DSGVO), das Recht auf Berichtigung (Artikel 16 DSGVO), das Recht auf Löschung (Artikel 17 DSGVO), das Recht auf Einschränkung der Verarbeitung (Artikel 18 DSGVO), das Widerspruchsrecht (Artikel 21 DSGVO), das Recht auf Beschwerde bei einer Aufsichtsbehörde (Artikel 77 DSGVO) sowie das Recht auf Datenübertragbarkeit (Artikel 20 DSGVO).