documentation finished

Lab01/app/database/database.go

@@ -104,3 +104,9 @@ func (db *Database) UserIsLoggedIn(username string) bool {
 	}
 	return false
 }
+
+func (db *Database) ChangeUserPassword(username string, password string) {
+	user := User{Username: username}
+	db.ORM.Where("username = ?", username).Find(&user)
+	db.ORM.Model(&user).Update("password", password)
+}

Lab01/app/templates/_base.tmpl

@@ -170,31 +170,15 @@
     <script>
         let form = document.querySelector('.needs-validation')
 
-        function hasWhiteSpace(s) {
-            return s.indexOf(' ') >= 0;
-        }
-
         if (form) {
             form.addEventListener('submit', function (event) {
-                if (!form.checkValidity()) {
+                event.preventDefault();
-                    event.preventDefault();
+                let data = new FormData();
-                    event.stopPropagation();
+                let form_element = document.getElementsByClassName('form-control');
-                } else {
+                for (let i = 0; i < form_element.length; i++) {
-                    let invalid = false;
+                    data.append(form_element[i].id, form_element[i].value);
-                    event.preventDefault();
-                    let data = new FormData();
-                    let form_element = document.getElementsByClassName('form-control');
-                    for (let i = 0; i < form_element.length; i++) {
-                        data.append(form_element[i].id, form_element[i].value);
-                    }
-                    for (let i = 0; i < form_element.length; i++) {
-                        if (hasWhiteSpace(form_element[i].value)) {
-                            form_element[i].classList.add('is-invalid')
-                            invalid = true;
-                        }
-                    }
-                    !invalid && submitForm(data);
                 }
+                submitForm(data);
             }, false);
         }
     </script>

Lab01/app/webpage/webpage.go

@@ -99,6 +99,12 @@ func (wp *Webpage) defineRoutes() {
 			}
 			c.JSON(200, gin.H{"logged_in": false, "username": ""})
 		})
+		auth.PUT("/user", func(c *gin.Context) {
+			username := c.Query("username")
+			password := c.Query("password")
+			wp.Database.ChangeUserPassword(username, password)
+			c.JSON(200, gin.H{"message": "success"})
+		})
 		auth.POST("/logout", func(c *gin.Context) {
 			username, uExisting := c.GetPostForm("username")
 			if uExisting == false || username == "" {

Lab01/documentation/app/app.tex

@@ -4,11 +4,17 @@
 
 Die App soll eine einfache Erstellung von Aufgaben anbieten. Der Task soll erstellt, erledigt und gelöscht werden können. Jeder Benutzer sieht nur seine Tasks und kann auch nur seine eigenen Tasks bearbeiten. Als Frontend wird HTML\footnote{\href{https://developer.mozilla.org/en-US/docs/Web/HTML}{HTML}}, CSS\footnote{\href{https://developer.mozilla.org/en-US/docs/Learn/CSS/First_steps/What_is_CSS}{CSS}} und JavaScript\footnote{\href{https://www.javascript.com/}{JavaScript}} verwendet. Im Backend kommt eine SQLite\footnote{\href{https://sqlite.org/index.html}{SQLite}} und Go\footnote{\href{https://go.dev/}{Go}} zum Einsatz.
 
-\subsection{A01:2021 - Broken Access Control}
+\subsection{OWASP Top Ten}
 
-\subsubsection{Beschreibung der Schwachstelle}
+Im Folgenden werden Schwachstellen in Kategorien der OWASP Top Ten eingeteilt.
 
-Der Benutzer muss sich zuerst Registrieren (Abbildung \ref{fig:Registrieren}). Es wird im Frontend keine Validierung, außer auf Leerzeichen, durchgeführt. 
+\cite[vgl. dazu][]{owasp}
+
+\subsection{A7:2021 - Identification and Authentication Failures} \label{first}
+
+\subsubsection{Beschreibung der Schwachstellen}
+
+Der Benutzer muss sich vor der Nutzung der App Registrieren (Abbildung \ref{fig:Registrieren}).
 
 \begin{figure}[H]
     \begin{center}
@@ -27,7 +33,7 @@ Der Benutzer muss sich zuerst Registrieren (Abbildung \ref{fig:Registrieren}). E
     \label{fig:Authentifizierung}
 \end{figure}
 
-Wenn ein Nutzer schon existiert wird lediglich die Fehlermeldung der Datenbank zurückgegeben und angezeigt. Dadurch kann man schon registrierte Benutzernamen leicht erkennen.
+Wenn ein Nutzer schon existiert wird die Fehlermeldung der Datenbank zurückgegeben und angezeigt. Dadurch kann man schon registrierte Benutzernamen leicht erkennen. Sogar wenn ein Feld leer ist wird es zur Überprüfung an das Backend geschickt.
 
 \begin{figure}[H]
     \begin{center}
@@ -38,15 +44,15 @@ Wenn ein Nutzer schon existiert wird lediglich die Fehlermeldung der Datenbank z
         \end{subfigure}
         \begin{subfigure}[b]{0.48\textwidth}
             \includegraphics[width=\textwidth]{app/app-03}
-            \caption{Leerzeichen}
+            \caption{Keine Eingabe des Passwords}
-            \label{fig:Leerzeichen}
+            \label{fig:Keine Eingabe des Passwords}
         \end{subfigure}
     \end{center}
     \caption{Fehler bei der Authentifizierung}
     \label{fig:Fehler bei der Authentifizierung}
 \end{figure}
 
-Wenn der Benutzer sich anmeldet wir ein Cookie mit dem Nutzernamen im Frontend gespeichert (Abbildung \ref{fig:Gespeichertes Cookie}). Zusätzlich wird im Backend vermerkt, dass der Nutzer angemeldet ist. Somit reicht es im Frontend aus, nur den Benutzernamen als Authentifizierung im Header mitzuschicken. Damit kann durch z.B. das Raten von Nutzernamen mit den Registrierung-Fehlermeldungen, unbefugter Zugriff auf die App erfolgen. CORS im Backend wurde ausgeschaltet um das Entwickeln einfacher zu machen.
+Wenn der Benutzer sich anmeldet, wir ein Cookie mit dem Nutzernamen im Frontend gespeichert (Abbildung \ref{fig:Gespeichertes Cookie}). Zusätzlich wird im Backend vermerkt, dass der Nutzer angemeldet ist. Somit reicht es im Frontend aus, nur den Benutzernamen als Authentifizierung im Header mitzuschicken. Damit kann durch z.B. das Raten von Nutzernamen mit den Registrierung-Fehlermeldungen, unbefugter Zugriff auf die App erfolgen.
 
 \begin{figure}[H]
     \begin{center}
@@ -56,6 +62,8 @@ Wenn der Benutzer sich anmeldet wir ein Cookie mit dem Nutzernamen im Frontend g
     \end{center}
 \end{figure}
 
+\newpage
+
 \subsubsection{Schwachstelle ausbessern}
 
 Bei der Registrierung und dem Anmelden sollte sowohl im Frontend als auch im Backend auf Fehler validiert werden. In Frameworks wie Vue, React oder Angular kann dies einfach gemacht werden. Zusätzlich bieten Backends eine Säuberungsfunktion für Form-Daten an, die unerlaubte Zeichen verhindern.
@@ -69,19 +77,19 @@ Ein Login mit JWT Token\footnote{\href{https://jwt.io/}{JWT}} erscheint hier sin
     \item Verifizierung möglich
 \end{list}
 
-Die Abspeicherung des Login-Status im Backend ist eine große Sicherheitslücke. Damit kann der Angreifer mit einer List von Benutzernamen so lange probieren, bis er sich, als einer der Nutzer der eingeloggt ist, anmelden kann. Durch den JWT Token würde eine der Login-Prozess ohne die Abspeicherung des aktuellen Status des Nutzers ablaufen.
+Die Abspeicherung des Login-Status im Backend ist eine große Sicherheitslücke. Damit kann der Angreifer mit einer Liste von Benutzernamen so lange probieren, bis er sich, als einer der Nutzer der eingeloggt ist, anmelden kann. Durch den JWT Token würde der Login-Prozess ohne die Abspeicherung des aktuellen Status des Nutzers ablaufen.
 
-Cors sollte eingeschaltet und konfiguriert werden, damit Anfragen auch nur von dem als sicher geltenden Frontend verschickt werden.
+\newpage
 
-\subsection{A03:2021 - Injection}
+\subsection{A3:2021 - Injection}
 
-\subsubsection{Beschreibung der Schwachstelle}
+\subsubsection{Beschreibung der Schwachstellen}
 
 Es kann in der App nach Aufgaben gesucht werden (Abbildung \ref{fig:Suchen im Frontend}). Der eingegebene Filter wird dazu an das Backend geschickt und als Antwort kommt eine liste an Aufgaben zurück (Abbildung \ref{fig:Suchen im Backend}). Die eigentliche Suchfunktion wird hierbei von Backend übernommen.
 
 \begin{figure}[H]
     \begin{center}
-        \includegraphics[width=0.6\textwidth]{app/app-07}
+        \includegraphics[width=0.7\textwidth]{app/app-07}
         \caption{Suchen im Frontend}
         \label{fig:Suchen im Frontend}
     \end{center}
@@ -96,7 +104,7 @@ Es kann in der App nach Aufgaben gesucht werden (Abbildung \ref{fig:Suchen im Fr
 
 \newpage
 
-Nun kann allerdings durch eine Injection das Anzeigen aller Aufgaben erzwungen werden (Abbildung \ref{fig:SQL Injection}).
+Nun kann allerdings durch eine Injection das Anzeigen aller Aufgaben erzwungen werden (Abbildung \ref{fig:SQL Injection}). Damit kann der Angreifer alle Nutzernamen und deren Aufgaben sehen.
 
 \begin{figure}[H]
     \begin{center}
@@ -134,14 +142,59 @@ Der Code im Backend ist fehlerhaft. Anstatt die von Go zur Verfügung gestellte
     \end{center}
 \end{figure}
 
-\subsection{A03:2021 - Injection}
+\newpage
 
-\subsubsection{Beschreibung der Schwachstelle}
+\subsection{A1:2021 - Broken Access Control}
+
+\subsubsection{Beschreibung der Schwachstellen}
+
+CORS im Backend wurde ausgeschaltet um das Entwickeln einfacher zu machen.
+
+Es gibt einen API Endpunkt in dem das Benutzerpassword ohne Authentifizierung geändert werden kann (Abbildung \ref{fig:Password geändert ohne Authentifizierung}). Es müssen lediglich der Nutzer und das neue Passwort angegeben werden. Der Endpunkt wurde beim hochladen auf den Server vergessen.
+
+Das Password wird außerdem im Plaintext in der Datenbank gespeichert und kann von jedem mit Datenbank-Zugriff ausgelesen werden.
+
+\begin{figure}[H]
+    \begin{center}
+        \includegraphics[width=0.8\textwidth]{app/app-12}
+        \caption{Password geändert ohne Authentifizierung}
+        \label{fig:Password geändert ohne Authentifizierung}
+    \end{center}
+\end{figure}
+\begin{figure}[H]
+    \begin{center}
+        \includegraphics[width=0.5\textwidth]{app/app-14}
+        \caption{Datenbank}
+        \label{fig:Datenbank}
+    \end{center}
+\end{figure}
 
 \subsubsection{Schwachstelle ausbessern}
 
-\subsection{A03:2021 - Injection}
+Cors sollte eingeschaltet und konfiguriert werden, damit Anfragen auch nur von dem als sicher geltenden Frontend verschickt werden.
 
-\subsubsection{Beschreibung der Schwachstelle}
+Passwortänderungen müssen mit einer eindeutigen Verifizierung über das aktuelle Password, eine E-Mail o.Ä. abgesichert sein. Der Benutzer wird durch die Attacke dauerhaft aus dem System ausgesperrt.
+
+Das Abspeichern der Passwörter darf nur verschlüsselt erfolgen. Zum Beispiel werden im Django Framework\footnote{\href{https://docs.djangoproject.com/en/4.0/topics/auth/passwords/}{Password management in Django}} zu fast jedem Algorithmus Lösungen angeboten.
+
+\subsection{A7:2017 - Cross-Site Scripting (XSS)}
+
+\subsubsection{Beschreibung der Schwachstellen}
+
+Wie schon im Abschnitt \ref{first} beschrieben, findet keinerlei Texteingabe-Validierung statt. Somit kann als Aufgabe beliebiger HTML oder JavaScript Code wie z.B. ein Button, der Cookies anzeigt eingefügt werden (Abbildung \ref{fig:XSS Angriff}). 
+
+\begin{verbatim}
+<button onclick="alert(document.cookie)" class="btn btn-primary">Get Cookie</button>
+\end{verbatim}
+
+\begin{figure}[H]
+    \begin{center}
+        \includegraphics[width=0.8\textwidth]{app/app-13}
+        \caption{XSS Angriff}
+        \label{fig:XSS Angriff}
+    \end{center}
+\end{figure}
 
 \subsubsection{Schwachstelle ausbessern}
+
+Jeglicher Text der eingegeben oder wieder auf der Website angezeigt wird, sollte auf typische Syntax überprüft werden. URLs oder externe Web-Resources sollten außerdem ausgeschaltet werden. Außerdem, wenn möglich die Interaktion des Nutzers durch Kommentare vermeiden oder nur im geringen Maße zulassen. Eine Überprüfung des Kommentars durch eine Person kann außerdem eingebaut werden.

Lab01/documentation/bib/online.bib

@@ -5,3 +5,11 @@
   year    = {2022},
   url     = {https://hub.docker.com/r/bkimminich/juice-shop/}
 }
+
+@online{owasp,
+  author  = {{The OWASP® Foundation}},
+  title   = {OWASP Top Ten},
+  urldate = {2022-03-08},
+  year    = {2022},
+  url     = {https://owasp.org/www-project-top-ten/}
+}

Lab01/documentation/juiceshop/juiceshop.tex

@@ -30,9 +30,9 @@ Es muss nun lediglich ein ``docker-compose up'' ausgeführt werden.
     \end{center}
 \end{figure}
 
-Auf der Startseite (Abbildung \ref{fig:Startseite Juice Shop}) wird man mit verschiedenen Pop-Ups begrüßt. Es beschreibt, das die Seite nicht sicher sei. Die Programmierung wird von der Open Web Application Security Project Foundation\footnote{\href{https://owasp.org/}{https://owasp.org/}} bereitgestellt. Wenn man das Tutorial startet, wird man auf verschiedene Dinge hingewiesen, wie die Sicherheitslücken gefunden werden können.
+Auf der Startseite (Abbildung \ref{fig:Startseite Juice Shop}) wird man mit verschiedenen Pop-Ups begrüßt. Es beschreibt, dass die Seite nicht sicher sei. Die Applikation wird von der Open Web Application Security Project Foundation\footnote{\href{https://owasp.org/}{https://owasp.org/}} bereitgestellt. Wenn man das Tutorial startet, wird durch verschiedene Tipps hingewiesen, wie die Sicherheitslücken gefunden werden können.
 
-So wird zum Beispiel erklärt, dass man mit F12 den Javascript-Code der Seite analysieren könnte (Abbildung \ref{fig:Javascript in den Entwicklertools von Firefox}). Der Vorschlag ist gut, da mit einer Sucher der Pfad entdeckt werden kann (Abbildung \ref{fig:Pfad des Score-Boards}).
+So wird zum Beispiel erklärt, dass man mit F12 den Javascript-Code der Seite analysieren könnte (Abbildung \ref{fig:Javascript in den Entwicklertools von Firefox}). Der Vorschlag ist gut, da mit einer Suche der Pfad des Score-Boards entdeckt werden kann (Abbildung \ref{fig:Pfad des Score-Boards}).
 
 \begin{figure}[H]
     \begin{center}
@@ -71,7 +71,7 @@ Wenn man nun noch nach Admin sucht, kann man eine Route in das Administrations-P
     \end{center}
 \end{figure}
 
-Nun kann man den SQL Befehl so anpassen, damit durch ``OR TRUE --'' immer true zurück kommt und eine Authentifizierung mit dem ersten Nutzer in der Datenbank möglich ist. Glücklicherweise ist das der admin (Abbildung \ref{fig:Login Admin}).
+Man kann den SQL Befehl so anpassen, damit durch ``OR TRUE --'' immer true zurück kommt und eine Authentifizierung mit dem ersten Nutzer in der Datenbank möglich ist. Glücklicherweise ist das der admin (Abbildung \ref{fig:Login Admin}).
 
 \begin{verbatim}
 "SELECT * FROM Users WHERE email = ''' OR TRUE -- AND password =
@@ -98,7 +98,7 @@ Nun können wir das Admin-Panel, welches vorher nicht für uns zur Verfügung st
 
 \newpage
 
-Im Score-Board gibt es ein Tutorial zum Erstellen eines Feedbacks unter einem anderen Account. Dazu gibt man zuerst ein normales Feedback. der Request sieht wie folgt aus (Abbildung \ref{fig:Feedback Request}):
+Im Score-Board gibt es ein Tutorial zum Erstellen von Feedbacks unter einem anderen Account. Dazu gibt man zuerst ein normales Feedback ab. der Request sieht wie folgt aus (Abbildung \ref{fig:Feedback Request}):
 
 \begin{verbatim}
 {
@@ -110,7 +110,7 @@ Im Score-Board gibt es ein Tutorial zum Erstellen eines Feedbacks unter einem an
 }
 \end{verbatim}
 
-Damit kann man in z.B. Postman ein Post Request unter einem anderen Namen mit dem neu vorgeschlagenen Captcha (Abbildung \ref{fig:Captcha Lösung}) machen (Abbildung \ref{fig:Neues Feedback mit falschem Namen}).
+Damit kann man in z.B. Postman ein Post Request unter einem anderen Namen mit dem neu vorgeschlagenen Captcha (Abbildung \ref{fig:Captcha Lösung}) abschicken (Abbildung \ref{fig:Neues Feedback mit falschem Namen}).
 
 \begin{figure}[H]
     \begin{center}
@@ -134,11 +134,11 @@ Damit kann man in z.B. Postman ein Post Request unter einem anderen Namen mit de
     \end{center}
 \end{figure}
 
-Damit haben wir insgesamt 6 Schwachstellen herausgefunden (Abbildung \ref{fig:Score Board Ergebnis}).
+Damit haben wir insgesamt 6 Schwachstellen ausgenutzt (Abbildung \ref{fig:Score Board Ergebnis}).
 
 \begin{figure}[H]
     \begin{center}
-        \includegraphics[width=0.7\textwidth]{juice/juice-12}
+        \includegraphics[width=\textwidth]{juice/juice-12}
         \caption{Score Board Ergebnis}
         \label{fig:Score Board Ergebnis}
     \end{center}