Entwicklung Sicherer Webanwendungen (Teil 1) Flashcards
Was ist die OWASP?
Steht für:
Open Web Application Security Project
Ist eine Non-Profit Organisation
Ziel: Verbesserte Sicherheit von Anwendungssoftware
Alle Materialien sind frei verfügbar
Nenne die Top 10 Web Application Security Risks
A1 Injection A2 Broken Authentication A3 Sensitive Data Exposure A4 XML External Entities (XXE) A5 Broken Access Control A6 Security Misconfiguration A7 Cross-Site Scripting (XSS) A8 Insecure Deserialization A9 Using Components with Known Vulnerabilities A10 Insufficient Logging & Monitoring
Nenne die Polulärste Injection-Möglichkeit. Gibt es noch weitere?
SQL Injection (sehr populär)
Weitere:
Format String Command Injection Log Injection Reflection Injection Interpreter Injection
Was sind potentiell verwundbare Anwendungen für eine SQL-Injection?
Anwendungen die:
Datenbanken verwenden
Benutzerinputs für Anfragen verwendet
Ein Entwickler behauptet: „SQL Injection kann man am einfachsten verhindern, indem man über JavaScript sicherstellt, dass kein oberes Anführungszeichen eingegeben wird“.
Ist das richtig? Wenn nicht, wie ist es besser?
Stimmt nicht, man kann auch andere Zeichen verwenden: ( ) < >
JavaScript ist auf Client-Seite deaktivierbar / manipulierbar.
Am besten immer Serverseitig abfangen!
Was für Konsequenzen kann eine SQL-Injection mitsich tragen?
Wenn es keine Schutzmechamismen gibt, kann man mit einem einfach Hochkomma prüfen, ob ein Server verwundbar ist.
Wir können beispielsweise über gezielte SQL-Injection verschiedene Tabellenfelder finden.
Wir können den Tabellenhinhalt auslesen, manipulieren oder selbt welchen hinzufügen.
(Anlegen / Manipulieren eines Accounts)
Das führt zu weiteren Konsequenzen
Zusammengefasst:
Ausgabe, Ändern, Löschen aller Daten einder Datenbank
Bietet kein Anzeigen von Fehlermeldungen für Blind-SQL-Injections aussreichend schutz?
Nein, das System ist weiterhin angreifbar.
Beispielsweise kann der Angreifer mit Befehle mit Zeitverhalten agieren und damit die Schwachtstellen überprüfen + angriffe tätigen.
Was sind Sicherheitsmaßnahmen/Techniker gegen SQL-Injections?
Keine dynamischen Abfragen verwenden
Benutzereingabe davon abhalten, Einfluss auf die Logik der auszuführenden Abfrage zu nehmen
Konkrete Techniken:
Prepared Statements (Parameterized Queries) Stored Procedures
Escaping von Benutzereingabe
Weitere Techniken zum Abmildern des Angriffs:
Least Privilege
White List Input Validation
Was ist ein prepared Statement und wie funktioniert es?
Ein Prepared Statement ist eine sogenannte vorbereitete Anweisung für ein Datenbanksystem.
Die Anweisungsmuster arbeiten mit Platzhaltern, die erst innerhalb des Systems durch die tatsächlichen Werte ersetzt werden.
Schritt 1
Hacker gibt Daten auf Webseite ein und sendet an Server
Schritt 2
Server verwendet Prepared Statement, in dem genau angeben wird, wo die Daten einzusetzen sind.
Schritt 3
Library erzeugt aus Daten + Prepared Statement die endgültige Abfrage => schädlicher Inhalt wird ELEMINIERT (Dinge wie Hochkommatas werden gefiltert und codeanteile entfernt)
Schritt 4
Server stellt erzeugte ungefährliche Anfrage an Datenbank
…
Wie kann ein Beispielangriff über Session Fixation aussehen?
- Angreifer beschafft sich eine gültige Session ID der Webanwendung
- Angreifer schieb diese dem Opfer unter
- Opfer authentifiziert sich
- Angreifer hat jetzt eine authentifizierte Session
Wenn die ID in der URL steht, kann der Link an das Opfer gesendet werden
Wenn ID in einem hidden Field ist:
Opfer auf gefälschte Login-Seite locken (dann aber Passwort bekannt)
Opfer loggt sich in HTML-Seite in Mail ein
Wenn ID in Cookie:
XSS um Session ID im Cookie zu fixieren (über document.cookie)
Wie sieht ein sicheres Password Recovery aus?
Dafür im Vorfeld (Account anlegen):
Menge persönlicher Daten sammeln „Geheime Fragen“ abfragen
Dann Password Recovery:
Benutzername + mehrere persönliche Daten auf erster Seite abfragen
Falls eines nicht korrekt: „Sorry, invalid data“ (NICHT MEHR DETAILS)
Falls alles korrekt:
eine einzige Seite, die mindestens zwei der „geheimen Fragen“ erfragt. Antwortfelder in einem einzigen HTML Formular.
Benutzer kann nicht auswählen, welche Fragen er beantworten will.
Benutzername nicht im Formular verwenden (kein Hidden Field o.ä.)!
Benutzername sollte serverseitig in den Session Informationen gespeichert sein, um ihn bei Bedarf zu erhalten.
Über Seitenkanal (E-Mail, SMS) zufällig erzeugtes Passwort mit 8+ Zeichen versenden
Benutzer nach Eingabe neues Passwort zum Wechsel zwingen
Was ist die Multifaktor Authentifizierung?
Welche Multifaktor kenne Sie?
Was sind Vor- und Nachteile? Ist ein Multifaktor immer sinnvoll?
= Zugangsberechtigung durch mehrere unabhängige Merkmale (Faktoren) überprüft wird
Durch kombination aus (mind. 2):
- Wissen
- Besitz
- Eigenschaft
Vorteil: erhöht die Sicherheit der Daten. Für Angreifer schwerer an beide Faktoren zu kommen.
Nachteil: Kostet mehr Zeit und schmälert die Usability
Macht nicht überall Sinn! Im OP-Saal wo man schnell agieren muss - wenig Sinnvoll
Bei einem Politiker sehr sinnvoll
Was gilt es bei Fehlermeldungen zu beachten?
Fehlermeldung bei Authentifizierung generisch halten!
Immer gleiche Fehlermeldung ausgeben, egal ob ID oder Passwort falsch.
Zufällige Verzögerung bei fehlerhaften Login einbauen. Das verhindert Rückschlüsse durch Messung der Anmeldezeit
—> Verhindere Informationsgewinn für Angreifer
Was versteht man unter einer Web Session?
Web Session = Sequenz von HTTP Requests und resultierenden Responses eines Benutzers
Zustand kann innerhalb einer Session gehalten werden.
Beispiel: Zugriffsrechte und Lokalisierungseinstellungen
Mit was ist eine authentifizierte Session ID zu vergleichen?
Session ID nach Authentifizierung gleichwertig mit verwendetem Credential (Passwort)
Angreifer kann danach sämtliche Aktionen durchführen.
Was sind Tipps für gute Session IDs?
Ausreichende Länge Session ID
verwenden
Session ID zufällig wählen
Session ID sollte bedeutunglos sein (keine Informationen eincodieren)
Was sind mögliche Austauschmechanismen für Session ID zwischen Benutzer und Webanwendung?
Viele Möglichkeiten: Cookies URL Parameter URL Arguments bei GET Body Arguments bei POST Hidden Form Fields Proprietäre HTTP Header
Was sollten Web Applications niemals tun?
niemals eine Session von HTTP auf HTTPS oder umgekehrt schalten =>
neue Session öffnen
niemals verschlüsselte und nicht verschlüsselte Inhalte auf gleichem Host mischen (HTML Seiten, Bilder, CSS, JavaScript Files etc)
HTTP zu HTTPS Weiterleitung auf Webseiten vermeiden (realisiert über 30x HTTP Response)
Was sind nützliche Cookie-Attribute zum Schutz von Session IDs?
Path Attribut: Cookie darf nur an angegebenes Verzeichnis oder Unterverzeichnisse gesendet werden
Expire Attribut: Ablaufdatum Cookie, wird danach entfernt
Max-Age Attribut: Maximalalter Cookie, wird danach entfernt (geht vor Expire)
SameSite-Attribut: Übermittlung der Cookies bei Cross-Site-Requests
-Strict (Cookie wird nur an originäre Seite übermittelt)
„Secure“ Cookie Attribut: Session ID nur über mit SSL/TLS verschlüsselten Kanal
Was ist XXS?
Was ist daran gefährlich?
Was für XXS Arten gibt es?
Hier entsteht eine Gefährdung durch ungeprüften Input (ähnlich SQL-Injection).
Gefährdung, wenn dieser Input in dynamische Inhalte eingebunden wird, die an den Browser eines Benutzers gesendet werden
Verschiedene Arten von XSS-Angriffen:
Stored XSS
Reflected XSS
DOM-based XSS
Was sind Gegenmaßnahmen für Stored und Reflekted XSS?
Niemals nicht-vertrauenswürdige Daten einfügen, außer in erlaubten Bereichen
Escaping (Nutzung von Maskierungszeichen um die Funktion von Zeichen oder Zeichenketten mit Sonderfunktion zu entfernen)
HTML Policy Engine um vom Benutzer eingegebenes HTML zu validieren bzw. zu säubern
Was ist Stored , Reflekted und Dome Based XSS?
Wo liegen die Unterschiede?
Stored XSS:
Angriffe, bei denen feindlicher Code permanent auf einem Server gespeichert wird
Reflected XSS:
Angriffe, bei denen feindlicher Code vom Webserver reflektiert wird
Feindlicher Code ist z.B. enthalten in
Fehlermeldungen Ergebnissen einer Suche.
Reflected XSS Angriffe kommen auf anderem Weg zu einem Opfer, z.B. über einen Link in einer E-Mail oder auf einem anderen Web-Server
Dom-based XSS:
XSS Angriff Ergebnis der Modifikation des DOM
Manipuliert DOM Environment beim Opfer
Unterschiede:
Ort der Ausführung, bei der die schädliche Seite entsteht
Reflected und Stored XSS: auf Server-Seite
DOM-based XSS: auf Client-Seite
Was sind Gegenmaßnahmen für DOM-based XSS?
Sinnvolle Reihenfolge Encoding bei dynamischem HTML
Sinnvolle Encoding bei dynamischen HTML Attributen
Vorsichtiges Vorgehen beim Einfügen in Event Handler und JavaScript Code
Encoding bei dynamischem CSS
Encoding bei dynamischem URL Attribut
Behandle nicht-vertrauenswürdige Daten immer als darstellbaren Text
Begrenzung und Encoding verwenden
Vermeide gefährliche Methoden
Vermeide implizites eval()
Verständnis für Datenfluss
Was sind Regeln für eine sichere Konfiguration von Webservern?
Getrennte Verzeichnisse für Programme und Daten:
Vermeidet Zugriff auf Source Code von Programmen Heute nicht mehr so wichtig, da viele dynamische Seiten
Geeignete Protokollierung:
alle Aktionen (Zugriffe) und Transaktionen sollten einsehbar sein Angriffe sollten durch Auswertung Log-Dateien nachvollziehbar sein
