diff --git a/docs/architecture.tex b/docs/architecture.tex index 9f72258a..5447389d 100644 --- a/docs/architecture.tex +++ b/docs/architecture.tex @@ -144,8 +144,8 @@ \section{CSRF-Tokens} \section{Play Cookies} \label{play:cookies} -Das Play Framework nutzt zur Persistierung eines Cookies in dem Client-Browser das \enquote{\gls{jwt}}-Format. -Ein \gls{jwt} besteht aus 3 Teilen: einem Header, einer Payload sowie einer Signatur, siehe \ref{jwtformat}. +Das Play Framework nutzt zur Persistierung eines Cookies in dem Client-Browser das \enquote{JSON Web Token}}-Format. +Ein JWT besteht aus 3 Teilen: einem Header, einer Payload sowie einer Signatur, siehe \ref{jwtformat}. Jeder dieser Teile ist ein namenloses JSON-Objekt. \\ Innerhalb des Headers ist gelistet, welcher Algorithmus genutzt wurde, um das JWT zu signieren. Die Payload ist ein einfaches JSON-Objekt, in welchem Daten gespeichert werden können, die zu signieren sind. @@ -217,7 +217,7 @@ \section{Session-Konzept} Die Annotation bewirkt, dass der korrospondierende Request \underline{vor} Erreichen der dazugehörigen Controller-Methode abgefangen wird und einer Prüfung unterzogen wird, ob der Absender authentifiziert ist. Ist dies nicht der Fall, wird die weitere Ausführung abgebrochen und der Nutzer auf die Login-Seite weitergeleitet. Ansonsten wird der Request an den entsprechenden Controller weitergereicht. Zur Umsetzung dieser Funktionalität setzen wir auf dem Session-Konzept von Play auf. -Initialisiert ein Nutzer eine neue Session, so persistieren wir seine IP-Adresse, seine User-ID, das Initialisierungsdatum und eine kryptografisch sicheren \enquote{\gls{uuid}} als Identifikator dieser neuen Session in unserer Datenbank. \linebreak +Initialisiert ein Nutzer eine neue Session, so persistieren wir seine IP-Adresse, seine User-ID, das Initialisierungsdatum und eine kryptografisch sicheren \enquote{Universally unique identifier (UUID)} als Identifikator dieser neuen Session in unserer Datenbank. \linebreak Um diese Session sicher beim Client speichern zu können, verwenden wir das bereits genannte Cookie \textit{PLAY\_SESSION}. Innerhalb des Payloads dieses JWT befindet sich ein JSON-Objekt namens \enquote{data} hinterlegt, zu welchem man weitere Applikationsdaten als Schlüssel-Wert-Paare hinzufügen kann. Das machen wir uns zu eigen und persistieren das Schlüssel-Wert-Paar (\enquote{HsHSession}: \enquote{UUID}), durch welches wir den Nutzer authentisieren können. @@ -249,7 +249,7 @@ \section{Verschlüsselung von Netzwerkdienst-Zugangsdaten} Als Chiffre wird AES-256 im CBC Modus mit PKCS5 Padding verwendet. Dazu gibt es eine native Java Implementierung. -Um aus dem Passwort des Benutzers einen kryptografisch sicheren Schlüssel zum verschlüsseln des CredentialKey zu generieren wird PBKDF2 benutzt. Die Rundenzahl beträgt 65536. Der Salt ist 8 byte Lang und wird mittels SecureRandom generiert. Auch dazu gibt es eine native Implementeriung in Java. +Um aus dem Passwort des Benutzers einen kryptografisch sicheren Schlüssel zum verschlüsseln des CredentialKey zu generieren wird PBKDF2 benutzt. Die Rundenzahl beträgt 65536. Der Salt ist 8 byte Lang und wird mittels SecureRandom generiert. Auch dazu gibt es eine native Implementeriung in Java. \section{Eingabevalidierung} Für einige Parameter gibt es festgelegte Constraints, die in allen entsprechenden Dtos verwendet werden. Das sind: @@ -403,7 +403,7 @@ \section{Passwort-Zurücksetzen durch unmittelbares setzen eines neuen temporär In Hinblick auf die von uns gewählte Verschlüsselungsmethode für Netzdienst-Zugangsdaten haben wir diesen Ansatz verworfen: Das Secret hierfür ist faktisch das Klartext-Passwort des Benutzers. Eine Funktionalität, die jedem offen steht und das Passwort des Benutzerkontos ändert, führt in diesem Kontext zu Problemen: Ein Nutzer kann sich zwar noch einloggen, jedoch nicht mehr seine Zugangsdaten entschlüsseln. Aus diesem Grund haben wir uns dazu entschlossen, die andere Variante der Anforderungsbeschreibung zu implementieren. - + \printbibliography diff --git a/docs/quality-assurance.tex b/docs/quality-assurance.tex index 4497dce7..1ca1b724 100644 --- a/docs/quality-assurance.tex +++ b/docs/quality-assurance.tex @@ -55,8 +55,8 @@ \subsection{Funktionale Tests} Hierbei haben wir darauf geachtet, dass es uns durch \enquote{Dependency Injection} möglich ist, die Abhängigkeiten einer Klasse durch \enquote{Mocks} zu ersetzen. Dadurch wird garantiert, dass lediglich das Verhalten einer Klasse getestet wird, und dass dieses Verhalten nur auf dem durchs Interface vorgeschriebene Verhalten seiner Abhängigkeiten basiert. -\externaldocument[Arch1-]{architecture} -Für die in dem Klassendiagramm (siehe Architekturbeschreibung \ref{Arch1-architecture:class_diagram} \& \ref{Arch1-architecture:class_diagram2}) aufgezeigten \enquote{Pakete} werden folgende Voraussetzungen sowie Nachbedingungen getestet: +\externaldocument{architecture} +Für die in dem Klassendiagramm (siehe Architekturbeschreibung \ref{architecture:class_diagram} \& \ref{architecture:class_diagram2}) aufgezeigten \enquote{Pakete} werden folgende Voraussetzungen sowie Nachbedingungen getestet: \begin{itemize} \item Controller @@ -133,9 +133,9 @@ \subsubsection{Race Condition bei Einzigartigkeit der Dateinamen} Mit diesem Skript wurde es offensichtlich, das unsere Maßnahmen nicht ausreichend waren, um zu garantieren, dass der Dateiname für jeden Nutzer nur einmal vorkommen kann. Es konnte sogar passieren, dass alle 4 parallelen Anfragen erfolgreich waren. -Das Prüfen ob eine Datei für einen Benutzer mit einem bestimmten Namen bereits existiert und das Anlegen der Datei, falls das nicht so ist findet in einer Datenbank-Transaktion statt. Als Isolationslevel wurde \texttt{serializable} gewählt, was genau so einen Fall verhindern sollte. Die Prüfung ob eine Datei bereits existiert ist ein \texttt{SELCET} Query. Existiert eine Datei nicht, liefer es keine Daten zurück. Um sicherzustellen, dass nebenläufig ausgeführte Transaktionen wirklich \texttt{serializable} ablaufen, müsste H2 bereits bei diesem \texttt{SELECT} eine exklusive Sperre auf die Tabelle vergeben oder ähnliche Maßnahmen ergreifen. Offensichtlich ist das nicht der Fall. +Das Prüfen ob eine Datei für einen Benutzer mit einem bestimmten Namen bereits existiert und das Anlegen der Datei, falls das nicht so ist findet in einer Datenbank-Transaktion statt. Als Isolationslevel wurde \texttt{serializable} gewählt, was genau so einen Fall verhindern sollte. Die Prüfung ob eine Datei bereits existiert ist ein \texttt{SELECT} Query. Existiert eine Datei nicht, liefert es keine Daten zurück. Um sicherzustellen, dass nebenläufig ausgeführte Transaktionen wirklich \texttt{serializable} ablaufen, müsste H2 bereits bei diesem \texttt{SELECT} eine exklusive Sperre auf die Tabelle vergeben oder ähnliche Maßnahmen ergreifen. Offensichtlich ist das nicht der Fall. -Es stellte sich heraus, das H2 das Setzen von Isolationsleveln für Transaktionen ignoriert, wenn \texttt{MVCC} aktiviert ist\footnote{Seit H2 Version 1.4.x ist das die Standardeinstellung. Siehe http://www.h2database.com/html/advanced.html\#mvcc}. Im \texttt{MVCC} Modus vergiebt H2 exklusive Sperren nur in Ausnahmefällen\footnote{Einer dieser Fälle ist \texttt{SELECT ... FOR UPDATE}. In diesem Fall hilft \texttt{FOR UPDATE} aber nicht, da das \texttt{SELECT} Query keine Zeile selektiert.}. Durch das Deaktivieren von MVCC verhalten sich die Transaktionen wie erwartet und des Erstellen von Dateien mit dem gleichem Namen ist nicht mehr möglich. +Es stellte sich heraus, das H2 das Setzen von Isolationsleveln für Transaktionen ignoriert, wenn \texttt{MVCC} aktiviert ist\footnote{Seit H2 Version 1.4.x ist das die Standardeinstellung. Siehe http://www.h2database.com/html/advanced.html\#mvcc}. Im \texttt{MVCC} Modus vergibt H2 exklusive Sperren nur in Ausnahmefällen\footnote{Einer dieser Fälle ist \texttt{SELECT ... FOR UPDATE}. In diesem Fall hilft \texttt{FOR UPDATE} aber nicht, da das \texttt{SELECT}-Query keine Zeile selektieren kann, da sie nicht existiert.}. Durch das Deaktivieren von MVCC verhalten sich die Transaktionen wie erwartet und des Erstellen von Dateien mit dem gleichem Namen ist nicht mehr möglich. \subsubsection{HTTP Response Splitting mittels Dateinamen} @@ -149,12 +149,12 @@ \subsubsection{HTTP Response Splitting mittels Dateinamen} \subsubsection{Aufrufen von Seiten ohne nötige Berechtigung} Einige Seiten in HshHelper sind für normale Benutzer nicht zugänglich. Diese sollen nur von Administratoren verwendet werden. Dazu zählen zum Beispiel die Seiten zum Anlegen und Bearbeiten von Benutzern und Netzdiensten. Mit diesem Penetrationstests sollte geprüft werden, ob ein normaler Benutzer ohne Adminstrator-Rechte Zugriff auf diese Seiten erlangen kann. Da die Anzahl der zu prüfenden Seiten nicht sehr groß war wurde diese Prüfung manuell durchgeführt. Dazu wurde jede URL der betroffenen Seiten\footnote{Alle betroffenen \texttt{GET} Routen aus der \texttt{routes} Datei.} in einem Browser aufgerufen, während ein Benutzer ohne Administrator-Rechte angemeldet war. Das erwartete Verhalten war eine Weiterleitung auf eine Seite mit einer entsprechenden Fehlermeldung. -Ein ähnlicher Test wurde für alle URLs in denen URL-Parameter verwendet werden durchgeführt. Hierbei wurden für die Parameter in den URLs Werte gewählt für die der Test-Benutzer keine Berechtigung hat\footnote{Alle Parameter in URLs sind IDs.}. Zum Beispiel eine Gruppen-Id einer Gruppe in der er nicht Mitglied ist oder eine Datei-Id auf die er keine Berechtigung hat. +Ein ähnlicher Test wurde für alle URLs in denen URL-Parameter verwendet werden durchgeführt. Hierbei wurden für die Parameter in den URLs Werte gewählt für die der Test-Benutzer keine Berechtigung hat\footnote{Alle Parameter in URLs sind IDs.}. Zum Beispiel eine Gruppen-Id einer Gruppe in der er nicht Mitglied ist oder eine Datei-Id auf die er keine Berechtigung hat. Ergebnis dieses Penetrationstests ist, dass die Seiten zum Anlegen und Bearbeiten von Netzdiensten für nicht-Administratoren zugänglichen waren. Zwar konnte ein Benutzer keine Aktionen auf diesen Seiten ausführen, Zugriff sollte aber dennoch nicht möglich sein. \subsubsection{Cross-Site Requests} -\label{csrf:analyse} +\label{csrf:analyse} Im Rahmen eines Penetrationstest sollte überprüft werden, ob eine Controller-Methode, die JSON zurückliefert über ein script-Tag auf einer Drittseite eingebunden werden konnte. Während dieses Tests wurde eine schwere Sicherheitslücke entdeckt, die sich aus der Play Standard-Konfiguration in Verbindung mit unserem Session-Konzept ergab. Play nutzt für gesetzte Cookies die SameSite-Option \enquote{LAX} \footnote{\url{https://www.playframework.com/documentation/2.6.x/SettingsSession}}. Diese Option bewirkt, dass Requests, die von einer Drittseite stammen (wie z.B. ein script-Tag, dessen src-Attribut auf unsere Anwendung zeigt), das dazugehörige Cookie nicht an unsere Anwendung übertragen. Der Request selbst erreicht jedoch unsere Anwendung. Gleichzeitig generiert Play ein neues Session-Cookie, wenn eine Seite mit einem Formular aufgerufen wird, das über den integrierten CSRF-Schutz verfügt. @@ -207,7 +207,7 @@ \subsection{Eingabevalidierung der HTML-Formulare} Im Zuge des Reviews wurde festgestellt, dass das vorhandene Design Race Condition begünstigt. Die Validierungen im DTO waren nicht ausdrücklich auf \enquote{statische} Tests begrenzt. Es wurden teilweise Validierungen vorgenommen, die Datenbankzugriffe beinhaltet haben, beispielsweise die Prüfung der Existenz eines Benutzernames. Wird im Controller die Formular-Validierung\footnote{boundForm.hasErrors()} aufgerufen, ist die im DTO vorgenommene Validierung sowie der Controller-Code nicht Teil einer Transaktion. D.h. wenn die Formular-Validation meldet, dass der Nutzername noch nicht existiert, ist dieser Zustand nicht mehr garantiert, wenn der Benutzer tatsächlich angelegt wird. -Auch wenn dies im vorliegenden Fall aufgrund der Unique-Constraints in der Datenbank kein Sicherheitsproblem darstellt, haben wir uns dazu entschlossen, von einem solchen Design abzusehen. Ein Design, was in derartiger Weise Race Conditions begünstigt, ist objektiv schlecht. In den DTOs finden inzwischen nur noch \enquote{statische} Tests statt. Diese Entscheidung hat zur Entstehung der Manager-Klassen geführt (siehe Architekturdokument \ref{Arch1-architecture:manager-class-creation}). Diese bieten Methoden, die transaktionssicher sind und werfen beispielsweise eine Exception, wenn der Nutzer bereits existiert. +Auch wenn dies im vorliegenden Fall aufgrund der Unique-Constraints in der Datenbank kein Sicherheitsproblem darstellt, haben wir uns dazu entschlossen, von einem solchen Design abzusehen. Ein Design, was in derartiger Weise Race Conditions begünstigt, ist objektiv schlecht. In den DTOs finden inzwischen nur noch \enquote{statische} Tests statt. Diese Entscheidung hat zur Entstehung der Manager-Klassen geführt (siehe Architekturdokument \ref{architecture:manager-class-creation}). Diese bieten Methoden, die transaktionssicher sind und werfen beispielsweise eine Exception, wenn der Nutzer bereits existiert. \subsection{Bcrypt Password Hashing} Der Code zum sicheren Abspeichern eines Nutzerpassworts in der Datenbank wurde durch eine Person einem Review unterzogen. Die dabei aufgekommene Anregung wurde mit dem ganzen Team diskutiert. Das Passwort wird im Code von lediglich zwei Stellen aus gesetzt. Der \enquote{\texttt{UserManager}} verwendet sie beim Zurücksetzen des Passworts und der \enquote{\texttt{LoginManager}} beim Setzen eines neuen Passworts. In beiden Fällen wird direkt beim Aufruf des Setters der Hash durch die Verwendung des \enquote{\texttt{PasswordSecurityModule}} erzeugt. Somit ist sichergestellt, dass beim aktuellen Codestand keine Klartextpasswörter in der Datenbank abgespeichert werden. BCrypt wird verwendet um den Hash zu generieren und es wurde kurz diskutiert ob man nicht doch auf PBKDF2 wechselt. Da beide aber nicht ohne eine Third-Party-Library auskommen, wurde davon abgesehen. Dem Bcrypt-Code \autocite{BcryptCode} kann entnommen werden, dass das automatisch generierte Salt SecureRandom verwendet und somit ausreichend zufällige Salts für unterschiedliche Passwörter generiert und auch die Rundenanzahl, die explizit festgelegt wurde, ist ausreichend sicher. diff --git a/docs/security-policies.tex b/docs/security-policies.tex index 02e016db..ea0a990b 100644 --- a/docs/security-policies.tex +++ b/docs/security-policies.tex @@ -56,7 +56,7 @@ \chapter{Annahmen} \item Die von Google-Servern eingebundenen reCAPTCHA JavaScript-Dateien werden niemals zur Code-Injection verwendet / Google's reCAPTCHA Server sind grund\-sätzlich vertrauenswürdig. \item Bibliotheksfunktion \texttt{java.security.SecureRandom} \autocite{JavaDocs.SecureRandom} erstellt Zufallszahlen, die kryptografisch sicher sind. \item Einstellung \texttt{ALLOW\_LITERALS=NONE} der Datenbank \enquote{h2} verhindert SQL Injections. - \item \enquote{\gls{jwt}}-Format ist kryptografisch sicher zur Speicherung von Session- sowie Cookie-Daten. + \item \enquote{JSON Web Token}-Format ist kryptografisch sicher zur Speicherung von Session- sowie Cookie-Daten. \item Die von JWT verwendete Signatur (HMAC-SHA256) verhindert, dass eine Manipulation von JWT-Cookies erfolgen kann. \item Applikation kann nur über die definierten Eintrittspunkte verwendet werden. \item Benutzer des HsH-Helpers verraten nicht ihr Passwort an andere. @@ -224,7 +224,7 @@ \chapter{Richtlinien} \begin{itemize} \item Nutzer [U+] können nur mit dem System interagieren, wenn sie authentisiert sind (AK2-4, sowie AK6-21). \item Ein Nutzer [U-] kann sich nur einloggen, wenn er ein eigenes Passwort vergeben hat. - \item Ein Nutzer [U-] kann sein Passwort nur dann zurücksetzen, wenn er ein Authentifizierungsmerkmal angibt, dass er über einen vertrauenswürdigen Zweit-Kanal erhalten hat. + \item Ein Nutzer [U-] kann sein Passwort nur dann zurücksetzen, wenn er ein Authentifizierungsmerkmal angibt, dass er über einen vertrauenswürdigen Zweit-Kanal erhalten hat. \item Nutzer [GM, GO, A] können nur Gruppen sehen, dessen Mitglied sie sind (AK14). \item Ausschließlich Administratoren [A] können alle Gruppen sehen (AK14). \item Nutzer [GO] dürfen nur Mitglieder zu einer Gruppe hinzufügen, wenn sie der Besitzer dieser Gruppe sind (AK11). diff --git a/docs/threat-analysis.tex b/docs/threat-analysis.tex index e01e97d6..07a59c8a 100644 --- a/docs/threat-analysis.tex +++ b/docs/threat-analysis.tex @@ -37,7 +37,7 @@ \chapter{Zur Analyse verwendeten Methoden} \section{Datenflussdiagramm} -Das folgende \gls{dfd} wurde mithilfe des Programms \enquote{OWASP Threat Dragon} \autocite{OWASP.ThreatDragon} erstellt. +Das folgende Datenflussdiagramm (DFD) wurde mithilfe des Programms \enquote{OWASP Threat Dragon} \autocite{OWASP.ThreatDragon} erstellt. Dieses Programm erlaubt leider keine Einfärbung in grün zur Kennzeichnung vertrauenswürdiger Prozesse oder Datenflüsse. Alle schwarz gekennzeichneten Elemente sind daher als vertrauenswürdig zu betrachten. Dieses DFD soll als Übersicht über alle vorhandenen Datenflüsse dienen, ohne dabei jeden Manager oder Controller separat aufzulisten, da für diese der Datenfluss der selbe wäre. @@ -323,18 +323,6 @@ \subsection{Layered Entrypoints} \end{enumerate} \end{enumerate} - \item \texttt{ErrorController} - \begin{enumerate} - \item \texttt{/forbidden} - \begin{enumerate} - \item GET - \texttt{showForbiddenMessage()} - \end{enumerate} - \item \texttt{/badrequest} - \begin{enumerate} - \item GET - \texttt{showBadRequestMessage()} - \end{enumerate} - \end{enumerate} - \item \texttt{NetServiceController} \begin{enumerate} \item \texttt{/netservices/all} @@ -611,13 +599,13 @@ \subsubsection{Mögliche Angriffe auf den Loginprozess} \item \textbf{T35: Hash-Algorithmus als DOS Angriffsvektor missbrauchen} \begin{itemize} \item Zweck: DOS der Applikation - \item Möglichkeiten: Wenige Requests über eine ressourcenintensive Hash-Funktion amplifizieren, um eine hohe CPU-Auslastung des Servers zu erreichen. + \item Möglichkeiten: Wenige Requests über eine ressourcenintensive Hash-Funktion amplifizieren, um eine hohe CPU-Auslastung des Servers zu erreichen \item Risiko: Hoch \item Mögliche Gegenmaßnahmen: \begin{itemize} \item Schnellen Hash-Algorithmus verwenden (z.B. SHA512) - \item Captcha vor Hash-Berechnung schalten. - \item Zugriffe protokollieren und bei Attacke den Angreifer blockieren. + \item Captcha vor Hash-Berechnung schalten + \item Zugriffe protokollieren und bei Attacke den Angreifer blockieren \end{itemize} \end{itemize} @@ -687,7 +675,7 @@ \subsubsection{Mögliche Angriffe auf den \enquote{Passwort zurücksetzen lassen \hypertarget{threat38}{} \item \textbf{T38: Aushebeln der Anforderung zur Offline-Übergabe des Passworts} \begin{itemize} - \item Zweck: Zugriff auf den Benutzeraccount erhalten, bevor er offiziell ausgehändigt wurde. + \item Zweck: Zugriff auf den Benutzeraccount erhalten, bevor er offiziell ausgehändigt wurde \item Möglichkeiten: Administrator legt Benutzeraccount vorab an. Nutzer kennt die zugehörige E-Mail, da er sie der Hochschule mitgeteilt hat. Nutzer kann Passwort-Reset durchführen und das Passwort ändern. Er erhält so Zugriff den Account bevor ihm das Passwort vom Administrator mitgeteilt wurde. \item Risiko: Gering \item Mögliche Gegenmaßnahmen: @@ -704,8 +692,8 @@ \subsubsection{Mögliche Angriffe auf den \enquote{Passwort nach Zurücksetzung \hypertarget{threat36}{} \item \textbf{T36: Passwort-Reset-Token erraten} \begin{itemize} - \item Zweck: Passwort eines Nutzers ändern, ohne Zugriff auf sein E-Mail Konto und derzeitiges Passwort zu haben. - \item Möglichkeiten: Brute-Forcing des entsprechenden Tokens. + \item Zweck: Passwort eines Nutzers ändern, ohne Zugriff auf sein E-Mail Konto und derzeitiges Passwort zu haben + \item Möglichkeiten: Brute-Forcing des entsprechenden Tokens \item Risiko: Hoch \item Mögliche Gegenmaßnahmen: \begin{itemize} @@ -718,8 +706,8 @@ \subsubsection{Mögliche Angriffe auf den \enquote{Passwort nach Zurücksetzung \hypertarget{threat37}{} \item \textbf{T37: Umgehung des zweiten Faktors} \begin{itemize} - \item Zweck: Löschen der Netzdienst-Zugangsdaten. - \item Möglichkeiten: Angreifer erlangt Zugriff auf den Passwort-Zurücksetzen-Link bzw. das E-Mail Konto des Opfers und kann das Passwort ändern. Im gleichen Prozess werden die Zugangsdaten des Opfers gelöscht. Der Angreifer hat mangels zweiten Faktor kein Zugriff auf den Account des Opfers, konnte jedoch die Zugangsdaten löschen. + \item Zweck: Löschen der Netzdienst-Zugangsdaten + \item Möglichkeiten: Angreifer erlangt Zugriff auf den Passwort-Zurücksetzen-Link bzw. das E-Mail Konto des Opfers und kann das Passwort ändern. Im gleichen Prozess werden die Zugangsdaten des Opfers gelöscht. Der Angreifer hat mangels zweiten Faktor kein Zugriff auf den Account des Opfers, konnte jedoch die Zugangsdaten löschen. \item Risiko: Gering \item Mögliche Gegenmaßnahmen: \begin{itemize} @@ -731,7 +719,7 @@ \subsubsection{Mögliche Angriffe auf den \enquote{Passwort nach Zurücksetzung \end{itemize} -\subsection{Mögliche Angriffe auf den \enquote{Datei hochladen}-Prozess} +\subsubsection{Mögliche Angriffe auf den \enquote{Datei hochladen}-Prozess} \begin{itemize} \hypertarget{threat21}{} @@ -748,7 +736,7 @@ \subsection{Mögliche Angriffe auf den \enquote{Datei hochladen}-Prozess} \end{itemize} \end{itemize} -\subsection{Mögliche Angriffe auf den \enquote{Dateien anzeigen lassen}-Prozess} +\subsubsection{Mögliche Angriffe auf den \enquote{Dateien anzeigen lassen}-Prozess} \begin{itemize} \hypertarget{threat22}{} @@ -761,7 +749,7 @@ \subsection{Mögliche Angriffe auf den \enquote{Dateien anzeigen lassen}-Prozess \end{itemize} \end{itemize} -\subsection{Mögliche Angriffe auf den \enquote{Auf Datei zugreifen}-Prozess} +\subsubsection{Mögliche Angriffe auf den \enquote{Auf Datei zugreifen}-Prozess} \begin{itemize} \hypertarget{threat23}{} @@ -942,7 +930,7 @@ \subsubsection{Mögliche Angriffe auf Zusatzfunktionalität: Zwei-Faktor-Authent \item \textbf{T39: Secret für Zwei-Faktor-Authentisierung ist erratbar} \begin{itemize} \item Zweck: Umgehen des intendierten Schutzmechanismus (Zwei-Faktor-Au\-then\-ti\-sier\-ung) - \item Möglichkeiten: Secret basiert nicht auf kryptografisch sicheren Zufallszahlen. Angreifer kann es erraten und selbst in Authentifizierungs-App eingeben. + \item Möglichkeiten: Secret basiert nicht auf kryptografisch sicheren Zufallszahlen. Angreifer kann es erraten und selbst in Authentifizierungs-App eingeben \item Risiko: Mittel \item Mögliche Gegenmaßnahmen: \begin{itemize} @@ -955,23 +943,23 @@ \subsubsection{Mögliche Angriffe auf Zusatzfunktionalität: Zwei-Faktor-Authent \item \textbf{T40: Pin für Zwei-Faktor-Authentisierung ist vorhersehbar} \begin{itemize} \item Zweck: Umgehen des intendierten Schutzmechanismus (Zwei-Faktor-Au\-then\-ti\-sier\-ung) - \item Möglichkeiten: Kryptografisch unsicheres Verfahren für die Zwei-Faktor-Au\-then\-ti\-sier\-ung verwenden. + \item Möglichkeiten: Kryptografisch unsicheres Verfahren für die Zwei-Faktor-Au\-then\-ti\-sier\-ung verwenden \item Risiko: Mittel \item Mögliche Gegenmaßnahmen: \begin{itemize} - \item Time-based One-time Password algorithm (RFC 6238) verwenden. + \item Time-based One-time Password algorithm (RFC 6238) verwenden \end{itemize} \end{itemize} \hypertarget{threat41}{} \item \textbf{T41: Benutzer wird dazu gebracht, unintendiert die Zwei-Faktor-Au\-then\-ti\-sier\-ung zu aktivieren} \begin{itemize} - \item Zweck: Benutzer aus der Anwendung aussperren. + \item Zweck: Benutzer aus der Anwendung aussperren \item Möglichkeiten: Benutzer wird mittels Clickjacking o.Ä. dazu gebracht, die Zwei-Faktor-Authentisierung in Verbindung mit einem zufälligen Secret zu aktivieren. Der Nutzer kennt dieses Secret nicht bzw. hat keine Gelegenheit, dieses zu speichern, da er die Aktivierung unbewusst durchführt. \item Risiko: Mittel \item Mögliche Gegenmaßnahmen: \begin{itemize} - \item Aktivierung der Zwei-Faktor-Authentisierung nur in Verbindung mit einem vom Secret abgeleiteten Pin ermöglichen. + \item Aktivierung der Zwei-Faktor-Authentisierung nur in Verbindung mit einem vom Secret abgeleiteten Pin ermöglichen \end{itemize} \end{itemize} @@ -983,7 +971,7 @@ \subsubsection{Mögliche Angriffe auf Single Sign-On} \hypertarget{threat42}{} \item \textbf{T42: Entwenden des Klartextpassworts durch Administrator} \begin{itemize} - \item Zweck: Umgehen der Verschlüsselung zum Abgreifen des Klartextpassworts. + \item Zweck: Umgehen der Verschlüsselung zum Abgreifen des Klartextpassworts \item Möglichkeiten: Administrator legt den Netzdienst korrekt an. Nutzer hinterlegen ihre Zugangsdaten und verwenden Single Sign-On. Administrator ändert für den Netzdienst hinterlegte URL. Er kontrolliert den Host der neuen Ziel-URL und kann so die Zugangsdaten im Klartext abgreifen. \item Risiko: Mittel-Hoch \item Mögliche Gegenmaßnahmen: @@ -996,36 +984,36 @@ \subsubsection{Mögliche Angriffe auf Single Sign-On} \hypertarget{threat43}{} \item \textbf{T43: Dateiinhalte über Zugangsdaten speichern} \begin{itemize} - \item Zweck: Umgehung des Quota-Limits. - \item Möglichkeiten: Angreifer speichert Dateien nicht über die vorgesehene Funktionalität, sondern codiert die Dateiinhalte in den Zugangsdaten. + \item Zweck: Umgehung des Quota-Limits + \item Möglichkeiten: Angreifer speichert Dateien nicht über die vorgesehene Funktionalität, sondern codiert die Dateiinhalte in den Zugangsdaten \item Risiko: Mittel \item Mögliche Gegenmaßnahmen: \begin{itemize} - \item Längenlimit auf die Zugangsdaten anwenden. + \item Längenlimit auf die Zugangsdaten anwenden \end{itemize} \end{itemize} \hypertarget{threat44}{} \item \textbf{T44: Auslesen von Klartext-Zugangsdaten im Falle einer Datenbank-Kompromittierung} \begin{itemize} - \item Zweck: Erlangen von Klartext-Zugangsdaten zum Anmeldung auf Netzdiensten. - \item Möglichkeiten: Angreifer erlangt Zugang auf Datenbank. + \item Zweck: Erlangen von Klartext-Zugangsdaten zum Anmeldung auf Netzdiensten + \item Möglichkeiten: Angreifer erlangt Zugang auf Datenbank \item Risiko: Mittel \item Mögliche Gegenmaßnahmen: \begin{itemize} - \item Zugangsdaten mit einem Secret verschlüsseln, das ausschließlich der Nutzer besitzt. + \item Zugangsdaten mit einem Secret verschlüsseln, das ausschließlich der Nutzer besitzt \end{itemize} \end{itemize} \hypertarget{threat45}{} \item \textbf{T45: Entwenden des Klartextpassworts aus Speicher} \begin{itemize} - \item Zweck: Umgehen der Verschlüsselung zum Abgreifen des Klartextpassworts. - \item Möglichkeiten: Ein Bug wie Heartbleed, der Zugriff auf den Speicher eines Servers ermöglicht ausnutzen, um im Speicher vorhandene Passwörter auszulesen. + \item Zweck: Umgehen der Verschlüsselung zum Abgreifen des Klartextpassworts + \item Möglichkeiten: Ein Bug wie Heartbleed, der Zugriff auf den Speicher eines Servers ermöglicht ausnutzen, um im Speicher vorhandene Passwörter auszulesen \item Risiko: Gering \item Mögliche Gegenmaßnahmen: \begin{itemize} - \item Passwörter nicht \enquote{unnötig} entschlüsseln. Nur dann entschlüsseln, wenn wirklich ein Single Sign-On erfolgen soll und dann ausschließlich die für diesen Sign-On erforderlichen Zugangsdaten entschlüsseln (so wenig Passwörter wie möglich in den Speicher laden). + \item Passwörter nicht \enquote{unnötig} entschlüsseln. Nur dann entschlüsseln, wenn wirklich ein Single Sign-On erfolgen soll und dann ausschließlich die für diesen Sign-On erforderlichen Zugangsdaten entschlüsseln (so wenig Passwörter wie möglich in den Speicher laden) \end{itemize} \end{itemize} @@ -1158,9 +1146,9 @@ \subsection{Content-Security-Policy} Dadurch kann verhindert werden, dass JavaScript nicht von jeder URL geladen und ausgeführt werden darf, von welchen Quellen Bilder geladen werden dürfen, oder welches CSS eingebunden werden darf. Dieser Header ist dem \enquote{X-XSS-Protection}-Header vorzuziehen. -\externaldocument[QA1-]{quality-assurance} +\externaldocument{quality-assurance} \subsection{Cookie: SameSite-Option} -Standardmäßig wurden Cookies mit der SameSite-Option \enquote{LAX} gesetzt. Diese Option in Verbindung mit unserem Session-Konzept führte zu einem Angriffsvektor über den es möglich war, Nutzer zu einem Logout zu bewegen. Wir verzichten auf die Verwendung dieser Option (siehe \ref{QA1-csrf:analyse}). +Standardmäßig wurden Cookies mit der SameSite-Option \enquote{LAX} gesetzt. Diese Option in Verbindung mit unserem Session-Konzept führte zu einem Angriffsvektor über den es möglich war, Nutzer zu einem Logout zu bewegen. Wir verzichten auf die Verwendung dieser Option (siehe \ref{csrf:analyse}). %\subsection{X-Permitted-Cross-Domain-Policies} %\begin{sloppypar} diff --git a/submissions/third_iteration/architecture.pdf b/submissions/third_iteration/architecture.pdf new file mode 100644 index 00000000..286263dd Binary files /dev/null and b/submissions/third_iteration/architecture.pdf differ diff --git a/submissions/third_iteration/diff-architecture.pdf b/submissions/third_iteration/diff-architecture.pdf new file mode 100644 index 00000000..14f2fa2b Binary files /dev/null and b/submissions/third_iteration/diff-architecture.pdf differ diff --git a/submissions/third_iteration/diff-quality-assurance.pdf b/submissions/third_iteration/diff-quality-assurance.pdf new file mode 100644 index 00000000..559d9034 Binary files /dev/null and b/submissions/third_iteration/diff-quality-assurance.pdf differ diff --git a/submissions/third_iteration/diff-security-policies.pdf b/submissions/third_iteration/diff-security-policies.pdf new file mode 100644 index 00000000..0eecf420 Binary files /dev/null and b/submissions/third_iteration/diff-security-policies.pdf differ diff --git a/submissions/third_iteration/diff-threat-analysis.pdf b/submissions/third_iteration/diff-threat-analysis.pdf new file mode 100644 index 00000000..0864e2fc Binary files /dev/null and b/submissions/third_iteration/diff-threat-analysis.pdf differ diff --git a/submissions/third_iteration/installation-guide-and-manual.pdf b/submissions/third_iteration/installation-guide-and-manual.pdf new file mode 100644 index 00000000..35383c94 Binary files /dev/null and b/submissions/third_iteration/installation-guide-and-manual.pdf differ diff --git a/submissions/third_iteration/quality-assurance.pdf b/submissions/third_iteration/quality-assurance.pdf new file mode 100644 index 00000000..8c1b104c Binary files /dev/null and b/submissions/third_iteration/quality-assurance.pdf differ diff --git a/submissions/third_iteration/requirements-for-additional-features.pdf b/submissions/third_iteration/requirements-for-additional-features.pdf new file mode 100644 index 00000000..908a4709 Binary files /dev/null and b/submissions/third_iteration/requirements-for-additional-features.pdf differ diff --git a/submissions/third_iteration/security-policies.pdf b/submissions/third_iteration/security-policies.pdf new file mode 100644 index 00000000..215a175a Binary files /dev/null and b/submissions/third_iteration/security-policies.pdf differ diff --git a/submissions/third_iteration/threat-analysis.pdf b/submissions/third_iteration/threat-analysis.pdf new file mode 100644 index 00000000..70642b99 Binary files /dev/null and b/submissions/third_iteration/threat-analysis.pdf differ