Dokument-Arbeitsaufteilung

[eloquenza]

Aufteilung:

Von allen gemacht:

Bedrohungsanalyse:

• [x] PW Reset ist nun link-based, daher neu analysieren (evtl Angabe bezueglich Wahrscheinlichkeit zum Knacken des Mechanismus dahinter)
• [x] Single Sign-On Bedrohungen aufschreiben
• [x] Zwei-Faktor-Authentisierung Bedrohungen aufschreiben

Sicherheitsrichtlinien:

• [x] Anpassungen der dritten Iteration (welche neue Aktionen, Assets, Akteure, Policies)

Julius:

• [ ] Akzeptanztests, die die Use Cases beim laufenden System automatisiert durchführen
• [x] Neues Klassendiagramm fuer dritte Iteration

Architekturbeschreibung:

• [x] Zwei-Faktor-Authentisierung als Zusatzfeature
• [ ] Verworfener Ansatz ueber den Google Server das Bild erstellen zu lassen?

Qualitätssicherung:

• [x] Neue Penetrationstests für den Dateiaustausch

Torben:

Qualitätssicherung:

• [x] Beschreibung des "beliebige Datei zu Gruppe hunzufügen" Fehlers
• [x] Transaktionsproblematik
• [x] NetService Seiten waren sichtbar für nicht-Admins

Philip:

Architekturbeschreibung:

• [x] Single Sign-On Feature beschreiben
• [x] "Schluessel"-Management des Single Sign-On Features beschreiben
• [x] Passwort-Blacklist beschreiben
• [x] IP Whitelist beschreiben
• [x] Verworfener Ansatz des alten Reset PW Vorgangs - warum haben wir nun UUID-based URL Token

Dennis:

• [ ] Aufpassen, dass Begrifflichkeiten über alle Dokumente hinweg gleich verwendet werden sowie einheitliche Beschreibung einer Sache (immer Benutzer oder Nutzer, aber nicht beides)
• [ ] Rechtschreibprüfung

Sicherheitsrichtlinien:

• [x] Ggf. Herausnehmen des DA Akteur? Peine zweifelt diesen an, wir haben ihn zur Vollstaendigkeit eingebaut (read only, write only, read AND write)

Bedrohungsanalyse:

• [x] Liste aller Gegenmassnahmen nochmal durchgehen und auf Vollstaendigkeit sowie Implementationsstatus pruefen
• [x] Layered Entrypoints anpassen
• [x] DFD anpassen

Architekturbeschreibung:

• [x] Beschreibung der Limitierung einer Dateigroesse (2.17 GiB)

Installations- & Bedienungsanleitung:

• [x] Installation (Wie wird installiert)
• [x] Konfiguration (Wo liegt config file, welche relevanten options gibt es)
• [x] Bedienungsanleitung (Nur nicht offensichtliche Features - bisher hauptsaechlich Zusatzfeatures)
• [x] Angabe, dass Test reCAPTCHA Keys verwendet werden koennen, falls es fuers Testen noetig ist
• [x] Dateigroesse-Option angeben
• [x] Beschreibung und Nutzung der IP-Whitelist
• [x] Mindestanforderungen, um das Projekt starten
• [x] Private Key Generation

Anforderungsbeschreibung der Zusatzfunktionalitäten:

• [x] Treffend Anforderungen nur für die zweite Gruppe formulieren, da sie nicht Zugriff auf unsere Architektur etc Dokumente haben werden.

Noch keinen zuständigen:

Architekturbeschreibung:

• [ ] Angabe, welche HTTP Status Codes wir in welchen Faellen verwenden?
• [ ] Evtl vollstaendiges Bild des Datenmodells?
• [ ] Kritikpunkt an "Alle Nutzer, die Administrator sind"-Zusatzfunktion
• [ ] T25 - Open Redirect - ggf. nochmal erklaeren, warum wir ueberhaupt eine URL speichern

Qualitätssicherung:

• [ ] Gefundene Fehler erweitern

[eloquenza]

Sollten wir bei der Architekturbeschreibung unter Verworfenen Ideen auch hinschreiben, dass wir zuvor einen Ansatz gewaehlt hatten, bei dem der/die Controller die gesamte Arbeit erledigten?

[juliuszint]

Macht meiner Meinung nach sinn. Könnten dazu dann noch schreiben, dass unsere Anwendung mit der neuen Architektur deutlich einfacher testbar ist.

[eloquenza]

Das war meine Idee da hinter. Ist definitiv ne vernuenftige Begruendung. Zeigt auch, dass wir quasi Prototyping betrieben haben und verschiedene Designs betrachtet haben, und unsere Argumentation nicht auf "Gefuehl" basieren.

[eloquenza]

Notizen/Gedanken

DFD:

• data flow vom recaptcha response des users zum manager fehlt,
• dank recaptcha darf data flow vom controller zu manager nicht "EntityIDs" heissen, besserer name "Applikationsdaten, reCAPTCHA-Response"?

Threat Analysis:

• layered-entrypoints: ist nicht die session, die wir aus dem HTTP context ziehen auch quasi immer ein datensatz, der bei jedem entrypoint zusaetzlich zu den formdaten angenommen wird?

Quality Assurance: Philip und ich habens heute nochmal besprochen, aber idealerweise sollte am Ende des QA-Docs eine Art Tabelle, in der alle gefundenen Bugs eingetragen werden, ggf. mit Timelogging. Dann gibt es eine "globale" Tabelle, anhand welcher Fehler eingetragen werden koennen, die dann in ihren jeweiligen Kapiteln erklaert werden. Angenehm waere es, wenn dann jegliche Codebeispiele in den Appendix verschwinden, so dass der Fliesstext frei von solchen Bruchstellen ist.

[eloquenza]

Aus Archivierungsgründen hier nochmal niedergeschrieben. Mainpost wird wieder zur Aufteilung verschiedener Sections in den Dokumenten genutzt, diesmal für Iteration 2.

Julius:

• [x] Klassendiagramm (Architekturbeschreibung)
• [x] Sequenzdiagramm fuer Benutzererstellung (Architekturbeschreibung)
• [x] Sequenzdiagramm fuer Login (Architekturbeschreibung)
• [x] Verwendung des Flash-Speichers (Architekturbeschreibung, Cookie/Sessionmanagement)
• [x] QA Doc: Pen-Test hat ergeben, dass CSRF bei Login umgangen werden kann
• [ ] Reviewgetoese

Torben:

• [x] Kryptografische Funktionen [JWT, BCrypt] (Architekturbeschreibung, Sicherheitsmassnahmen)
• [x] CSRF-Token Generation (Architekturbeschreibung)
• [x] Schluesselmanagement - Play Secret, RecaptchaKey, Credentials fuer Mailserver (Architekturbeschreibung)

Philip:

• [x] Verwendung von Cookies (Session bei uns) (Architekturbeschreibung)
• [x] Login-Firewall (Architekturbeschreibung, sonstige Sicherheitsmassnahmen)
• [x] Content-Security-Policy (Architektur)
• [ ] Reviewergebnisse (Qualitaetssicherung)
• [x] Verworfene Ideen (Long statt UUID bei Sessions, Speicherung der IP-Adresse in Cookie [Datenschutzgrund])

Dennis:

• [x] Static Analysis,
• [x] Funktionale Tests,
• [x] Reviewquatsch,
• [ ] Quelltextinspektionen,
• [x] DFD einfuegen
• [x] Security Policies anpassen

Bisher keinen Zustaendigen:

• [ ] CIA triad related Policies (siehe Uebungsmaterial und Skript fuer naehere Infos)

[eloquenza]

Wieder zum Archivieren, damit wir Uebersicht haben, was alles geschafft wurde.

Zweite Iteration:

Julius:

• [x] Anpassung des Klassendiagramms durch die neuen Klassen des Dateiaustausches
• [ ] Akzeptanztests, die die Use Cases beim laufenden System automatisiert durchführen

Torben:

Architekturbeschreibung:

• [x] Eingabevalidierung: Dateiname Regex hinzufügen
• [x] Neues Kapitel bzgl Ausgabekodierung, direkt nach Eingabevalidierung. Sollte Infos bzgl Kommentarfeld enthalten
• [x] Zusatzfunktion: Session-Timeout anpassbar
• [x] Zusatzfunktion: Passwort ändern (nur wenn eingeloggt)
• [x] Neuer Punkt 1.4 Dateiaustausch, sollte enthalten: Wo speichern wir Daten, wie sieht Datenmodell in DB aus, was für extra Bedingungen gelten nun? Stichwort: Kommentarfeld / Dateiname

Philip:

Architekturbeschreibung:

• [x] Verworfene Ideen: TempFiles

Dennis:

Bedrohungsanalyse:

• [x] Layered Entrypoints anpassen
• [x] DFD anpassen

Architekturbeschreibung:

• [x] Zusatzfunktion: Anzeige Login-Attempts
• [x] Zusatzfunktion: Anzeige, die anzeigt, wer Datei als letztes beschrieben hat
• [x] Logging