APSI H22
APSI Prep FHNW
APSI Prep FHNW
Federation
Authentifizierungen, die aus mehreren, unabhängigen Quellen die
Authentifizierungs-Merkmale beziehen, nennt man “federiert”.
Realm
Eine einzelne Authentifizierungsquelle (z.B. alle Benutzername/Passwort-Tupel eines
LDAP-Servers) bezeichnet man typischerweise als “Realm”.
Authentifizierungs-Token
Eine Information, die es erlaubt einen Benutzer unabhängig von der
Authentifizierungs-Quelle anzumelden, nennt man ein “Authentifizierungs-Token”.
Authentifizierungs-Quelle
Eine Datenstruktur oder ein Service, der es erlaubt Benutzer zweifelsfrei zu identifizieren
nennt man eine Authentifizierungs-Quelle (manchmal auch Identitäts-Provider).
Authorisierungs-Quelle
Eine Datenstruktur oder ein Service, der es erlaubt identifizierten Benutzern Rechte
zuzuweisen oder zu entziehen wird als Authorisierungs-Quelle bezeichnet.
Typische Quellen für Authentifizierungen
▸ Hart codierte Logins (NEIN!)
▸ Lokale Files
▸ SQL-Datenbanken
▸ LDAP-Server (z.B. Active Directory, OpenLDAP, OpenDJ)
Authentifizierungs Beispiel Frameworks
Es gibt an vielen Orten Authentifizierungs-Frameworks (im Web, aber auch anderswo):
▸ Microsoft Active Directory Federation Services (AD FS)
▸ Shibboleth
▸ Keycloak
▸ SAML/OIDC/OAuth2 (eigentlich Protokolle)
▸ PAM
Zusammenführen von mehreren Authentisierungs-Quellen
Authentifizierungsquellen können auf verschiedene Weisen zusammengeführt werden:
▸ Konsolidierung in einem einzelnen Authentisierungsraum (Metaverse der
Authentisierungsquellen)
▸ Federation (Delegation) auf Authentisierungsquellen
Authentisierungs-Beispiel -> Ablauf
Das erste Vertrauen -> Arten von CA's
▸ Ein vertrauenswürdiger Schlüssel (sehr starr)
▸ Eine eigene CA
▸ Eine öffentliche CA (nur selten empfehlenswert)
Sie brauchen immer einen Vertrauensanker, mit dem Sie ein Vertrauen aufbauen können.
Im extremen Fall ist ein Vertrauensanker ein Schlüssel, dem Sie direkt vertrauen. Dies wird beispielsweise
bei den Linux-Repositories so gelöst. Das Verfahren ist extremm starr.
Viel besser und effizienter ist es aber einen generischen Vertrauensanker im Sinne einer eigenen CA
aufzubauen.
Bitte Beachten Sie: Eine eigene CA hat nichts(!) mit einem eigenen Kryptoalgorithmus zu tun. Es ist nur
der Vertrauensanker für Ihre Applikation. Es hat nichts mit “Weisheit” zu tun, hier anstelle der eigenen
CA oder des eigenen Schlüssels ein öffentlich signierten Schlüssel zu verwenden.
Kryptoagilität
Unter Kryptoagilität einer Applikation versteht man die Fähigkeit, die Kryptografischen Algorithmen
auszutauschen (ohne Update natürlich) sollte sich ein Algorithmus als unsicher erweisen.
Bei einer Kryptoagilen-Applikation werden typischerweise für jedes Kryptografische Primitiv (Asymmetrische
Verschlüsselung, symmetrische Verschlüsselung, Hashing, Signatur usw.) eine Alternative zur
Verfügung, die mathematisch auf einem anderen Problem basiert (also beispielsweise RSA und eine Elliptische
Kurve oder eine elliptische Kurve und ein gitterbasierter Algorithmus usw.).
Eine Variation der Schlüssellänge wird nicht als ausreichend für Kryptoagilität betrachtet. Unter Umständen
müssen auch Dinge wie das Padding oder der Cipher-Mode für eine ausreichende Kryptoagilität
berücksichtigt werden.
Suply Chain Attacke
Von einer Supply Chain Attacke spricht man in der Cyber Security, wenn über ein
Update-Kanal oder über eine sonstige Vertrauenswürdige Quelle, Schadsostware (Malware)
eingeschleust wird.
Dependency Hijacking
Von Dependency Hijacking (oder auch Dependency Confusion) spricht man, wenn eine
eigene Abhängigkeit in einem Projekt, durch eine öffentlche Abhängigkeit übernommen wird
bei automatischer Auflösung von Abhängigkeiten.
Arten der Upgrades
Es gibt verschiedene Arten von Upgrades, die unabhängig voneinander und selektiv
eingespielt werden können müssen
▸ Sicherheits-Upgrades
▸ Bugfixes
▸ Feature-Upgrades
Upgrade Mechanismen
Ein ideales Upgrade einer idealen Applikation erfüllt folgende Kriterien:
▸ Verfügbar
Upgrade ist immer möglich (typ. online und offline)
▸ Sicher
Es ist unmöglich dass Informationen oder Programme durch Dritte über den Upgrade
eingeschleust werden können.
▸ Vertraulich
Es ist unmöglich, dass Informationen über den Upgrade-Mechanismus exfiltriert
werden können. (Datenschutz)
▸ Selbstheilend
Fehler in den Upgrades und deren Mechanismen können zuverlässig behoben werden.
Kryptoagilität
Wenn ein Programm oder Protokoll in der Lage ist auf mehrere unterschiedliche Arten von
kryptografischem Schutz aufzubauen, dann spricht man von “Kryptoagilität”.
▸ Verschiedene Asymmetrische Verschlüsselungen (z.B.
Zahlenkörper/Kurven/Gitterbasierte-Algorithmen)
▸ Verschiedene Symmetrische Chiffren (Feistel-Chiffren oder “Substitutions und
Permutationsnetzwerke”)
▸ Verschiedene Hashes
Dependency Adoption und Hijacking
Damit der Buildprozess vertrauenswürdig ist, müssen alle Quellen, also auch alle Quellen der
direkten und indirekten Abhängigkeiten kontinuierlich geprüft und überwacht werden.
Die zwei primären Gefahren hierbei sind:
▸ Dependency Adoption
▸ Dependency Hijacking (auch Dependency Confusion)
Signatur von Upgrades
Signierte Upgrades können gewährleisten, dass ein Upgrade aus einer Vertrauenswürdigen
Quelle stammt. Da es sich hier um eine sehr überschaubare Anzahl von Quellen handelt, ist
die Verwendung einer reduzierten Trust-Store (oder besser noch: einer eigenen CA für
Upgrades) sehr empfehlenswert
Hashes zur Überwachung von Upgrades
Hashes sind kein Schutz für die Vertrauenswürdigkeit eines Upgrades. Sie gewährleisten nur
die Integrität der Übertragung.
Secured DNS (DNSSEC)
Secured DNS (DNSSEC) kann verwendet werden um DNS-Einträge signiert über unsichere
Netze zu übertragen. Das bedeutet, dass die Root-Einträge mit einem, auf dem Client
hinterlegten, Root-Schlüssel signiert werden. Diese signieren die Schlüssel der
Top-Level-Domäne, welche die Schlüssel der Second-Level-Domäne (und so weiter) signieren,
bis es einen Schlüssel gibt, der den endgültigen Eintrag signiert.
DNSSEC schützt vor DNS-Spoofing-Attacken. Es kann dies aber nur tun, wenn alle
involvierten Teildomänen vertrauenswürdig sind.
OS Schutz:
Ist bei einem System mit nur einem Benutzer eine Trennung zwischen "user"-Mode und "root"-Mode noch sinnvoll? Warum/warum nicht?
Ja
Der Root-Modus erlaubt alles was im User-Mode verboten ist.
Die meisten Root-Funktionalität wird nur selten und für spezifische Aufgaben benötigt.
Input Validierung und Normalisierung:
Kann Input Normalisierung als Ersatz für Input Validierung benutzt werden? (Ob das sinnvoll ist, ist eine andere Frage...)
Erklären Sie, wie das geht oder warum das nicht geht.
Ja die Normalisierung wird so gestarltet, dass sie fehlschlägt oder leer zurückgibt, wenn die Validierungs-Kriterien nicht erfüllt sind.
Java:
Wenn sie in Java programmieren, sind sie dann prinzipell sicher vor Buffer-Overflows?
Begründen sie warum, oder geben sie 2 Beispiele an wo dies nicht gegeben ist.
1) Java (die JVM) verwendet Basisbibliotheken, die in C geschrieben sind. Und diese Können Buffer-Oberflows beinhalten. (z.B. Regex auswertung)
2) Die JVM slebst kann Bugs haben die Buffer-Overflows ermöglichen.
3) JNI ist enbefalls anfällig für Buffer-Overflows
Code Analyse:
Können Code-Analysetools alle tatsächlich möglcihen Buffer-Overflows fonden? Warum, bzw. warum nicht?
Nein,
Die statische Codeanalyse kann in der Regel keine (kompillierten) Librarys prüfen.
Cloud Storage:
Nennen Sie 2 prinzipielle Probleme der Datenablage in der Cloud.
1) Verschlüsselung: Sollen die Daten verschlüsselt werden braucht der Cloud Anbieter auch den Schlüssel, wenn alle Cloud Funktionen genutzt werden.
2) Wenn der Cloud Anbieter den Schlüssel nicht hat muss ich den Schlüssel auf allen Geräten die auf die Daten zugreifen wollen haben.
Logging:
Nehmen Sie an, Sie konfigurieren das Logging für einen Web-Shop. Spielt der Preis der Einkäufe eine Rolle für das Loggen zum Zweck der Angriffserkennung?
Warum / warum nicht?
Ja, es kann gesehen werden wenn der Preis verändert wurde.
Passwort-Sicherheit
Nehem Sie an, eine Passworteingage zeigt dem Benutzer den Argon2-Hash eines gerade eingegebenen Passwortes an. Ist das ein Sicherheitsrisiko?
Ja, Es gibt öffentliche Tabellen mit denen aus de Hash evt. auf den Klartext geschlossen werden kann. Ein Angreifer der die Session des Benutzers übernommen hat kann so den Hash ebenfalls auslesen.
Same Origin Policy (SOP)
Sie möchten verhindern, dass Kunden Opfer eines erfolgreichen CSRF-Angriffs auf ihre Website siteA.com werden. Nutzt Ihnen SOP dabei und wiese / wieso nicht?
Nein.
SOP verhindert, dass die Applikation Responses von einer anderer Domain lesen. (Browser Feature)
Es verhindert nicht, dass Requests dorthin gesendet werden.
Buffer-Overflow: Eingabe Validierung
Nehmen sie an, Sie können sich darauf verlassen, dass Web-Browser nie URLs länger als 4kB an Web-Server schicken. Können Sie dann auf die EIngabe Validierung bezüglich Länge im Web-Server verzichten und einfach direkt einen 4kB grossen Buffen benutzen?
Nein es gibt neben Webrowesern noch andere möglichkeiten Requests zu senden.:
- Mobile Clients, andere Server-Applikatonen.
Diese könnten immernoch grössere Request schicken.
Ein Angreifer kann den Server mit 4KB grossen URLs bombardieren und so so möglichst viel Speicher blockieren. (DoS)
Wo wird hier Input Validierung benötigt?
Wo wird Input Normalisierung benötigt?
Validierung:
- Gültiges Geld eingeworfen (3)
- Gültiges Produkt gwählt (2)
- Webserver & Steuergerät Daten zu Bestand (7) (2)
- Webserver zu Internet (9)
Normalisierung
Webserver Daten vo Stuergerät
Steuergerät Daten vom Webserver
Welche Logs schreiben sie bei diesem Gerät sinnvollerweise und welche Komponenten machen das?
Zeichnen sie entsprechende Pfeile ein und beschreiben sue kurz was jeweils geloggt wird.
Stuergerät:
- Einwurf von Geld
- Auswahl Dose
- Ausgabe von Dose
- Auslösen Bestandes update & Anfrage
Webserver:
- Web Zugriff Log
- Bestandes Update gemacht
- Bestand abgefragt
Ist Fuzzing geeignet um die Verwundbarkeiten gegenüber Angriffen die algorithmische Komplexität ausnutzen zu ermitteln?
Um die algoritmische Komplexität auszunutzen werden spezifische Daten benötigt, die den Worstcase des Algorithmus ausnutzen. Mit Fuzzing werden aber viele zufällige Daten gesendet.
Fuzzing kann aber als Ablenkung eingesetzt werden, wenn gleichzeitig mit dem Angriff auf die algoritmsche Komplexität Fuzzing gemacht wird.
Ist ein falsches Passwort ein Fehler im Sinne der Fehlerbehandlung?
Nein.
Wenn der Passwortcheck aufgrund einer falschen Eingabe fehlschlägt ist das die Funktion des Passwortchecks.
Zufallserzeugung:
Nehmen Sie an, Sie haben einen Hardware-Zufallsgenerator mit einem kompromittierten Design (z.B. Intel RDRAND) zur Verfügung. Können Sie diesen trozdem sinnvoll und sicher einsetzen? Wie geht das, bzw warum geht das nicht?
Es geht wenn die Entrope nciht nur ausschliesslich von diesem Generator kommt. Er sollte gemeinsam mit anderen generatoren verwendet werden.
Testen von Sicherheit:
Ist ein Pen-Test ausreichend um die Sicherheit einer Server-Software zu beurtelen?
Nein, ein Pentests ist meist nur oberflächlich und eingeschränkt (aufgrund limittierter Zeit)
Werden bei einem Pentest keine Schwachstellen gefunden heisst das noch nicht das es auch keine gibt.
Zusatz:
Welche weiteren Massnahmen sind langfristig sinnvol?
Einen eigenen Wrapper um die Library-Methode bauen welcher die Parameter-Grösse prüft und so einen Buffer-Overflow verhindert.
Zusatz:
- Code auf weitere Fehler prüfen
- Nach einer ERsatz-Library suchen die noch weiterentwickelt wird
- selber bauen
- Erwarte '['
- Erwarte beliebig Space
- Erwarte optional '-'
- Erwarte beliebig Nummern, mind 1x
- Erwarte beliebig Space
- Erwarte Komma oder ']'
- wenn Komma: starte bei 1
- wenn ']' fertig
Entropie:
Nehmen Sie an, Passworte besteh aus 10 zufälligen Ziffern und Kleinbuchstaben.
Berechnen Sie die ENtrope eines Passworts.
Mögliche Kombinationen (26+10)10
Zeichensatz a: 26 Kleinbuchstaben + 10 Ziffern = 36
Anzahl Stellen b: 10
Enthropie = b*log2(a):
10 * log2(36) = 51.7 bit
Was ist Privatsphäre?
Die Möglichkeit eines Individums oder einer Gruppe sich selbst oder INformationen über sich selbst abzugrenzen und sich somit seleketiv zu offenbaren.
Was sind parktische Gründe für die Privatsphäre?
Moderene gesellschaften investieren viel in die Ausbildung von Induvidien. Darum ist das Wohlbefinden des Individums wichtig für den gesamten Wohlstand der Gesellschaft.
Moderene Gesellschaften sind abhängig von ihren Besten und Klügsten. Und diese können an überaschenden Orten zu finden sein.
Indivuen welche Freiheiten geniessen sind weniger gestresst, krank etc. -> Je mehr Repressionen und Überwachung desto geringer die wirtschaftliche Leistung.
-
- 1 / 103
-
Flashcards
Gegen was hilft Disk-Encryption?
- Wenn sie gestohlen werden
- wenn der nicht laufende Computer gestohlen wird.
Hilft nicht gegen:
- gechackt werden wärend die Disk entschlüsselt ist (mapped)
- Die laufende Maschine geklaut wird
(b)Welches sind die zentral wichtigen Eigenschaften einer Hashfunktion, welche für
Hashtables verwendet wird?
(c) Welche Verfahren werden im Umgang mit Kollisionen üblicherweise verwendet?
(d) Weshalb werden nicht einfach kollisionsfreie kryptographische Hashfunktionen verwendet?
(b) a) Performance, b) Gleichverteilung des Outputs um Kollisionen zu vermeiden.
(c) Eine einfache und oft gewählte Möglichkeit um Kollisionen aufzulösen ist die Verkettung,
dabei werden die kollidierenden Einträge einfach in eine Liste eingetragen.
Eine weitere Möglichkeit ist aber anhand einer Strategie nach einer freien Position
weiterzusuchen. Hier gibt es verschiedene Verfahren, wie lineares oder quadratisches
Sondieren oder doppeltes Hashen.
(d) Kryptographische Hashfunktionen haben eine wesentlich schlechtere Performance,
weshalb sie für den Anwendungsfall von Hashtables in der Regel nicht geeignet
sind.
Überlegen Sie sich, wie Sie die Eingabe-Daten validieren würden
(a) Text der in einem Web-Forum gepostet wird
(b) Eine Sequenz von Floating-point Zahlen als Text, getrennt mit Leerzeichen
(c) Die Eingabe des Alters einer Person
(d) Ein SQL-Statement
(a) Hier wollen Sie verhindern, dass Markup in die Beiträge gelangt. Dazu können Sie
minimal alle schauen ob < enthalten sind. Sie können Validierung aber komplexer.
(b) Siehe https://en.wikipedia.org/wiki/IEEE_754
(c) Ganze Zahl, positiv, und Maximum so bei 150.
(d) Schlechte Loesung: Versuchen ”böses” SQL zu identifizieren,. z.B. DROP TABLE
Bessere Lösung: Nur bestimmte Statements erlauben und diese mittels ”Prepared
Statement” realisieren, d.h. es werden nur noch Werte für bestimmte Variablen
eingegeben.
Wie wurden Sie die folgenden Normalisierungen implementieren?
(a) Entfernen aller Bilder aus einem HTML Dokument
(b) Farbbilder nach Schwarz/Weiss (keine Graustufen)
(c) MS Word, Libre Office, Google Docs nach Email ohne Attachment (HTML Email
erlaubt, aber keine Links)
(a) Suchen nach <img Tags und diese bis zum > entfernen. Achtung, auch JavaScript
kann Bilder anzeigen.
(b) Es gibt verschidene Möglichkeiten, z.B. Rastern, Dithern, Vektorisieren.
(c) Dazu muss man erstmal die Scripting-Interfaces benutzen damit das ueberhaupt
geht. Via dieses Interfaces kann man dann nach HTML konvertierne. Get fuer alle
drei Beispiele anders...
Aufgabe 6-1: Entropie
In der Vorlesung haben Sie gesehen, wie sich informationstheoretische Entropie berechnen
lässt. Gehen Sie jetzt von einer Quelle aus, die 256 Zeichen mit Gleichverteilung
erzeugt.
(a) Berechnen Sie die Entropie pro Zeichen.
(b) Wie würde sich die Entropie bei einer anderen Verteilung verhalten? Sinkt oder
steigt die Entropie wenn eine Gleichverteilung nicht mehr gegeben ist?
(c) Warum ist eine hohe Entropie so wichtig für kryptographische Anwendungen?
(c) Kryptographische Protokolle basieren auf Zufallszahlen, beispielsweise für die Erstellung
von Schlüsseln um eine Verbindung abzusichern, etc. Sind diese Zufallszahlen
vorhersehbar für einen Angreifer, kann er die kryptographischen Funktionen
nachvollziehen und deren Schutz umgehen.Werden beispielsweise gleich nach einem
Systemstart, wenn noch wenig Entropie zur Verfügung steht, Schlüssel generiert, so
stellen diese unter Umständen Schlüssel aus einer kleinen Menge möglicher Schlüssel
dar und dies unabhängig von der Länge der Schlüssel selbst.
Definition der Privatsphäre
Von Privatsphäre spricht man Grundsätzlich, wenn eine Entität A ein Attribut B hat, von dem niemend (oder nur direkt Eingeweihte) wissen.
Anonymität (Definition)
Von Anonymität eines Subjektes spricht man, wenn ein Subjekt nicht identifizierbar ist innerhalb eines Sets von
anderen Subjekten (Anonymitätsset).
Pseudonymität
Ein Subjekt ist Pseudonym, wenn ein Pseudonym anstelle eines Realnamens für das Subjekt verwendet wird. Wobei
ein Pseudonym eine beliebige Identifikation ist, die nicht dem realen Namen des Subjektes entspricht.
Anonymität vs Pseudonymität
Bei der Anonymität sehen wir, dass eine Aktion oder Begebenheit stattfindet, können Sie
aber nur einem Set von Subjekten zuordnen. Die Zuordnung zu einem einzelnen Subjekt
innerhalb des Sets ist nicht möglich.
Bei der Pseudonymität können wir ein Set von Aktionen oder Begebenheiten einem einzelnen
Subjekt zuordnen, können dieses aber nicht in einem Set von Subjekten identifizieren.
Transportverschlüsselung (P2PE)
Von Transportverschlüsselung spricht man, wenn der Verkehr zwischen zwei Entitäten in
einem Netzwerk Verschlüsselt wird.
Transportverschlüsselung bietet einen Schutz vor passiven Angreifern (die nicht
Netzwerkverkehr beeinflussen).
vor aktiven Angreifern kann nur geschützt werden, wenn:
▸ Die Verschlüsselung nicht in einen Unsicheren Zustand manipuliert werden kann (z.B.
Downgrade-Attacke (BEAST bei TLSv1.0))
▸ Beide Parteien die Identität ihres Gegenübers mit nicht-transferierbaren Tokens
authentifizieren. (Zertifakte -> Domäne welche aufgerufen wird steht im Zertifikat)
Transportverschlüsselung wird heute gängigerweise mit dem Wrapping einer TCP-Session
mit dem TLS-Protokoll erzeugt.
Ende zu Ende Verschlüsselung (E2EE)
Von einer Ende-zu-Ende-Verschlüsselung (E2EE) spricht man, wenn Daten nicht nur während
des Transportes sondern immer bis hin zum finalen Empfänger einer Mitteilung verschlüsselt
bleiben. Bei einer “richtigen” Ende-zu-Ende-Verschlüsselung kann der Provider von
Routingdienstleistungen (z.B. ein Chatserver oder ein Mailserver) nicht den
Mitteilungsverkehr mitlesen.
Grundsätzlich sollte also der Client nicht vom selben Hersteller wie der Routingdienstleister kommen.
Bei Zoom wurde z.B. einfach gesagt "unser Server ist auch ein Ende"
Was bleibt bei E2EE sichtbar?
Typischerweise sind aber Metadaten sichtbar. Diese Umfassen Beispielsweise:
• Die Identität des Senders
• Die Identität des Empfängers
• Die Häufigkeit von gesendeten Daten
• Der Umfang der gesendeten Daten
• (möglicherweise) den Typ der eingesetzten Verschlüsselung.
Ist E2EE automatisch immer sinnvol?
Eine E2EE ist nur sinnvoll, wenn beide Endpunkte auch sicher Authentisiert werden (also z.B. unter einbezugnahme
des Sessions-Schlüssel und mit einem anderen Token pro Authentisierung). Ein Problem ist
immer die Initiale Erstellung des Vertrauens. Bei vielen Messengern erfolgt dies über ein Token, das über
einen separaten Kanal übermittelt wird (z.B. QR-Code zum Scannen).
HTTP Protokoll in zwei Sätzen
Das HTTP-Protokoll (bis HTTP/1.1) ist in reines Textprotokoll, das zuerst einen Header mit
Key-Value-Pairs und anschliessend (durch eine Leerzeile getrennt) einen Body ohne
formatierung übermittelt.
Zwischen einzelnen abrufen eines Dokumentes gibt es keinen Kontext, der durch das
Protokoll aufrecht erhalten wird!
Was ist das? :
1 GET / gwerder . html HTTP / 1 . 1
2 User −Agent : Mo z i l l a / 4 . 0 ( c omp a t i b l e ; MSIE5 . 0 1 ; Windows NT)
3 Host : www. fhnw . ch
4 Accept −Language : de −ch
5 Accept − Encoding : gz ip , d e f l a t e
6 Connec t ion : Keep − Al i v e
Anfrage an einen HTTP-Server
Was ist das?
1 HTTP / 1 . 1 200 OK
2 Date : Mon , 14 Nov 2022 1 2 : 2 8 : 5 3 GMT
3 S e r v e r : Apache / 2 . 2 . 1 4 (Win32 )
4 Las t −Modi f i ed : Thu , 20 J u l 1972 0 4 : 2 5 : 0 0 GMT
5 Content − Length : 88
6 Content −Type : t e x t / html
7 Connec t ion : Clos ed
8
9 <html >
10 <body >
11 <h1 >He l lo , World ! < / h1 >
12 </
Antwort eines HTTP-Servers
Erkläre HTTPS
Nach einem TCP-Handshake besteht eine Verbindung, die keine Pakete verliert oder diese in falscher Reihenfolge
erhält.
Anschliessend wird die Verschlüsselung initiiert beim Klassischen TLS (bis und mit version 1.2) werden dabei 9-10
Mitteilungen ausgetauscht. Bei der neuen TLSv1.3 Variante werden nur noch 5 Mitteilungen ausgetauscht.
Ablauf des TLS-Handshakes
▸ C: Client Hello message (Zufällige Daten, Liste der unterstützten Cypher-Suiten)
▸ S: Server Hello message (Zufällige Daten, Wahl der Cypher-Suite)
▸ S: Server Zertifikat
▸ S: Server Key Exchange message (Schlüsseltausch-Daten)
▸ S: Server Hello Done message (Hinweis, dass der Server jetzt auf den Client wartet)
▸ C: Client Key Exchange message (Schlüsseltausch-Daten)
▸ C: Change Cipher Spec message
▸ C: Encrypted Handshake Message
▸ S: Change Cipher Spec
▸ S: Encrypted Handshake Message
▸ . . . verschlüsselte Kommunikation. . .
Wie funktioniert Basic Auth?
Grundsätzlich wird bei einer Seite, die Passwortgeschützt wird die erste Übertragung
abgelehnt mit einem "401 UnauthorizedHeader und einem Hiweis in den K/V-Paaren der
etwa folgendermassen aussieht:
1 WWW− Au t h e n t i c a t e : Ba s i c realm= " Gwerders ␣ s i c h e r e ␣ Zone "
Daraufhin fragt der Webbrowser nach einem Passwort (oder nimmt ein gecachtes) und
sendet Benutzername und Passwort (mit einem Doppelpunkt zusammengeführt und in Base64 codiert) an den Server.
1 Au t h o r i z a t i o n : Ba s i c R3dl cmRl c jpTdXBl cnNpY2hl cg
Probleme bei Basic Auth?
Es ist ganz einfach herauszufinden , dass der Benutzername “Gwerder” und das Passwort “Supersicher”
war. Wenn also jemand Ihren Traffic mitlesen kann, dann hat er bei jedem mal, wo Sie eine gesicherte
Seite Anforden die Möglichkeit ihr Passwort mitzulesen. Es macht also nur (wenn überhaupt) Sinn Basic-
Authentication bei verschlüsselten Verbindungen zu verwenden. Aber sogar das ist sehr “old school” und
sollte eigentlich nicht mehr gemacht werden.
Desweiteren hat das verfahren einen schweren Fehler: Es kann nicht ausgelogt werden. Der Browser
liefert immer das letzte Passwort für diesen Server/Zone automatisch. (Es gibt ein Verfahren zum Löschen
des Caches das manchmal angewendet werden kann).
Wie funktioniert Digest auth?
Bei der Digest-Authentifizierung wird nicht das Passwort, sondern ein wechselndes Token,
das aus dem Passwort berechnet werden muss, übertragen:
1 HTTP / 1 . 1 401 Unauthor i z ed
2 WWW− Au t h e n t i c a t e : Di g e s t
3 realm= " Gwerders ␣ s i c h e r e ␣ Zone " ,
4 qop= " auth , ␣ auth − i n t " ,
Es gibt hier ganz viele Nebenbedingungen aber Grundsätzlich gilt hier: Das Passwort kann nicht berechnet
werden und das Token ändert bei jedem Anmeldevorgang.
Auch hier gilt dasselbe wie bei der Basic-Authentifikation: Kein Logout-Vorgang nach Standard möglich.
5 a l g o r i thm=SHA−2 5 6 ,
6 nonce= " 7 ypf / xlj9XXwfDPEoM4URrv / xwf94BcCAzFZH4GiTo0v " ,
7 opaque= " FQhe / qaU925kfnzjCev0ciny7QMkPqMAFRtzCUYo5tdS "
Die Antwort ist ähnlich komplex:
1 Au t h o r i z a t i o n : Di g e s t username= "Mufasa " ,
2 realm= " ht tp −auth@example . org " ,
3 u r i = " / d i r / inde x . html " ,
4 a l g o r i thm=SHA−2 5 6 ,
5 nonce= " 7 ypf / xlj9XXwfDPEoM4URrv / xwf94BcCAzFZH4GiTo0v " ,
6 nc =0 0 0 0 0 0 0 1 ,
7 cnonce = " f 2 / wE4q74E6zIJEtWaHKaf5wv /H5QzzpXusqGemxURZJ " ,
8 qop=auth ,
9 r e s p ons e = " 753927 f a 0 e 8 5 d 1 5 5 5 6 4 e 2 e 2 7 2 a 2 8 d 1 8 0 2 c a 1 0 d a f 4 4 9 6 7 9 4 6 9 7 c f 8 d b 5 8 5 6 c b 6 c 1 " ,
10 opaque= " FQhe / qaU925kfnzjCev0ciny7QMkPqMAFRtzCUYo5tdS "
Form Based HTTP-Authentication
Bei der Form-basierten HTTP-Authentifikation wird eine einfache HTML-Form für die
Passworteingabe verwendet.
▸ . . . sieht “fancy” aus.
▸ . . . ist (ohne Sicherheit) sehr einfach zu programmieren.
Leider ist es aber so, dass dies ja nur für eine Seite gilt. Deshalb wird in subsequenten
Requests entweder ein unsichtbares Token mitgeliefert oder ein Cookie gesetzt, damit der
Benutzer sich nicht auf jeder Seite neu anmelden muss. Diese Token oder das Cookie ist ein Stellvertreter für den
Benutzernamen und das Passwort.
TLS-Based Authentication
Bei der TLS-basierten Authentifikation gibt es kein Benutzername oder Passwort. Stattdessen wird mit
Zertifikaten gearbeitet. Das TLS-Protokoll übernimmt die Authentifizierung. Einmal aufgesetzt ist der
Prozess der TLS-Authentifizierung super einfach und übertrifft in Sachen Sicherheit alle vorgängigen
Verfahren um ein Vielfaches (viele!).
Aber:
• Ein Zertifikat zum Benutzer zu bringen ist ein komplexer Vorgang.
• Zertifikatslogins werden (speziell von mobilen Browsern) nur schlecht unterstützt.
• Die Benutzer sind sich nicht den Umgang mit Zertifikaten gewohnt
Vereinfachter Ablauf eines HTTP-Requests
Grundsätzlich findet eineHTTP-Anfrage immer in Stufen statt. Für uns von Belang sind der DNS-Request
(Auflösen des Hostnamens) und die eigentliche HTTP-Anfrage. Die Stufen davor (z.B. ARP-Request) betrachten
wir nicht, weil die Integritätsprüfung bei den Antworten frühestens beim DNS-Protokoll einsetzt.
Alles vorher betrachten wir als unsicher.
HTTPS = HTTP + TLS Wrapping
Nach einem TCP-Handshake besteht eine Verbindung, die keine Pakete verliert oder diese in falscher Reihenfolge
erhält.
Anschliessend wird die Verschlüsselung initiiert beim Klassischen TLS (bis und mit version 1.2) werden dabei 9-10
Mitteilungen ausgetauscht. Bei der neuen TLSv1.3 Variante werden nur noch 5 Mitteilungen ausgetauscht.
Sinn der Authentifizeirung
Eine Transportverschlüsselung ohne Authentifizierung ist nutzlos, weil es nichts nutzt, wenn
Sie eine perfekte Verschlüsselung aushandeln und dann nicht prüft, mit wem man
Informationen austauscht.
Dumme formen der Authentifizierung (98% in der realen Welt):
▸ Das Passwort wird übermittelt
▸ Ein Token (z.B. Hash), dass stellvertretend anstelle eines Passwortes wird übermittelt.
Etwas besser:
▸ Passworte werden nicht übermittelt sondern im Stile einer Challenge mit zugehöriger
Response geprüft.
State-of-the-Art:
▸ Die Authentifizierung wird gegenseitig gemacht mit Hilfe von nicht transferierbarer
Tokens.
OWASP Top 10
Stand und Beispiele
A01: Broken Access Control -> Wichtige API's sind nicht geschützt
A02: Cryptographic Failures -> Transportverschlüsselung ohne Authentifizierung
A03: Injection -> SQL-Injection und XSS zusammengelegt
A04: Insecure Design -> halt keine Least privilege etc. Eingesetzt
A05: Security Misconfiguration -> Falsche Anwendung
A06: Vurlnerable and Outdated Components -> Asset Management
A07, A09: Identifaction and Authentication & Logging Monitoring Failiruers -> Data Leackege
A10: Serverside Request Forgery (SSRF)
Security Misconfiguration
Nennen sie Beispiele
▸Missing appropriate security hardening across any part of the application stack or improperly configured
permissions on cloud services.
▸ Unnecessary features are enabled or installed (e.g., unnecessary ports, services, pages, accounts, or privileges). -> Siehe Log 4j
▸ Default accounts and their passwords are still enabled and unchanged.
▸ Error handling reveals stack traces or other overly informative error messages to users.
▸ For upgraded systems, the latest security features are disabled or not configured securely.
▸ The security settings in the application servers, application frameworks (e.g., Struts, Spring, ASP.NET),
libraries, databases, etc., are not set to secure values. -> z.B. XML-Entities nicht deaktiviert
▸ The server does not send security headers or directives, or they are not set to secure values.
▸ The software is out of date or vulnerable (see A06:2021-Vulnerable and Outdated Components).
Angriff mittels XSS
Cross-Site Scripting (XSS) Angriffe gehören zu den Injektions-Attacken. Typischerweise wird
“Schadcode” in eine legitime Seite eingefügt. Dies erfolgt typischerweise aufgrund
mangelhafter Eingabeprüfung.
Ursache:
XSS ist zumeist die Folge aus einer unzureichenden Input-Prüfung. Anders ausgedrückt
könnte man auch sagen es ist die Inklusion von Code aus nicht vertrauenswürdigen Quellen.
Angriff mittels CSRF
Cross-Site Request Forgery (CSRF) ist eine Attacke, welche Enduser dazu bringt, unbeabsichtigte
Befehle in einer (Web-)Applikation abzusetzen, in der sie gegenwärtig Authentifiziert sind.
Ursachen
Es gibt mehrere Schwachstellen, die eine solche Attacke begünstigen:
▸ Cookie-Based Authentifizierung.
▸ Keine “nicht-voraussagbaren” Parameter in der URL
▸ Es ist möglich innerhalb der Applikation relevante Operationen auszuführen
Es gibt verschiedene Formen. Meistens funktioniert sie wie folgt: Über eine Mail wird eine Person
aufgefordert in eine bestimmte, ihr bekannt Applikation einzulogen. Die Link-URL ist aber speziell.
Beispielsweise:
https://vulnerable.example.com/account/add?username=newuser&
password=pwned
Wenn der ausführende Benutzer die entsprechenden Rechte hat, wird die Applikation typischerweise
den Request sofort ausführen.
Abwehrmechanismen: SOP (Same Origin Policy)
Die Same-origin Policy (SOP) ist ein Sicherheitskonzept in heutigen Webbrowsern. Sie
besagt, das Skripte und CSS-Objekte in HTML-Seiten nicht auf Orte zugreifen dürfen, von
denen sie nicht selber geladen wurden.
Das heisst: Ein Skript kann nur auf Ressourcen zurückgreifen die mit demselben Protokoll,
Hostname und Port (falls angegeben) erreicht werden können.
SOP ist heute in allen gängigen Webbrowsern standardmässig unterstützt.
Nachteile von SOP
Mit SOP ist es plötzlich nicht mehr möglich auf andere Quellen als den eigenen Ursprung
zuzugreifen. Das ist gewollt, aber manchmal sörend. Deshalb gibt es CORS, mit dem einem
Browser mitgeteilt werden kann, was dennoch erlaubt ist.
Bis 2014 war CORS ein eigenständiger Standard. Heute ist es in das FETCH Framework
integriert (https://fetch.spec.whatwg.org/#http-cors-protocol)
Abwehrmechanismen:
CSP (Content Security Policy)
Bei der Content Security Policy (CSP) werden Teile der SOP wieder aufgehoben oder anders spezifiziert. Dies kann
über zwei Arten erfolgen:
▸ Über das Header-Feld Content-Security-Policy (veraltet auch über
X-Content-Security-Policy)
▸ Über den Metatag <meta http-equiv="Content-Security-Policy" content="..."/>
Policies welche in CSP genutzt werden
Eine Policy ist eine Anhäufung von restriktiven Regeln, die durch ein Semikolon (;) getrennt sind.
Gängige Policys sind:
▸ default-src
▸ script-src
▸ style-src
▸ img-src
▸ media-src
▸ frame-src
▸ form-action
▸ (es gibt noch viele mehr
und nicht alle enden auf
“src”)
Content Security Policy (CSP)
Source Listen
Bei den erlaubten Quellen sind folgende Quellen möglich:
▸ 'self': Nur Nachladen vom selben Protokoll/Host/Port-Tupel (bei den meisten der Default-Wert).
▸ *: erlaubt alle Domänen (ausser den speziellen tags data:, blob: und filesystem:)
Zugriff auf Dateien im lokalen Filesystem
▸ 'none': Kein nachladen erlaubt
▸ apsi.example.com: Nur nachladen von der vorgegebenen Domäne erlaubt (Irgendein Port oder
Protokoll).
▸ *.example.com: Nur nachladen von der vorgegebenen Domäne und deren Subdomänen erlaubt
(Irgendein Port oder Protokoll).
▸ (es gibt auch noch viele mehr; Kurzübersicht:
https://content-security-policy.com/#source_list)
Same Origin Policy
Einfache Funktionsweise und Problem
Die Same Origin Policy ist der Versuch die Missbrauchsmöglichkeiten einzuschränken. So
werden die Möglichkeiten zum Nachladen auf den Ursprung einer Ressource eingeschränkt.
Sie helfen aber nicht, wenn die Quelle schon nicht vertrauenswürdig ist oder wenn der
Zeiger auf die Quelle manipulierbar ist (nur DNS statt DNSSEC).
Sie können Inklusionen in Ihre Seiten schützen, indem Sie den Hash einer Ressource
festlegen (Subressource Integrity). Das nützt aber nur etwas, wenn dies auch für alle
inkludierten Ressourcen der Abhängigkeiten gemacht wird (und natürlich deren
Abhängigkeiten)
Auch DNSSEC schützt nicht notwendigerweise vor Akteuren mit privilegiertem Zugriff auf
Top- und First-Level-Domänen.
Was ist Subressource Integrity
Bei der Subressource-Integrity geht es darum, dass eine Subressource, die einen
vertrauenswürdigen Zustand hat, aber keine vertrauenswürdige Quellen, abzusichern.
Dies erfolgt über einen Hash, der in einem html-Attribut eingefügt werden kann.
Unterstützte Hashes sind derzeit: sha256, sha384 und sha512.
Das Attribut heisst integrity und wird in den Tags <skript> und <link>
unterstützt.
Was ist eine Bug Bounty
Ein Betrag, der von einem Hersteller oder einer Organisation gezahlt wird, damit Sie als erste
von Schwachstellen oder Fehlern erfahren. Meistens sind Bug Bounties an ein Set von
Bedingungen geknüpft.
Typen von Bruteforcing Attacken
Bruteforcing kann auf zahlreiche Arten erfolgen. Eigentlich müsste es längst (seit über einem
Jahrzehnt) veraltet sein. Es ist aber auch heute noch aktuell.
Beispiele sind:
▸ Reines Bruteforcing
▸ Wörterbuch/Dictionary-Attacken
▸ Credential Stuffing
▸ Rainbow-Tables (eigentlich veraltet)
Gegenmassnahmen zu Bruteforcing Attacken
• Reputations-basierte Gegenmassnahmen
Es wird eine Reputation des Clients auf der Basis eines Attributes aufgebaut (z.B. IP).
• Verzögerungs-basierte Gegenmassnahmen
Hierbei wird die Zeit bis zum Prüfen des nächsten Passwortes variiert.
• MFA-basierte Ansätze
Hierbei wird das Username/Passwort-Tupel (oder eine andere Authentifikation) mit einem weiteren
Authentifikationsmerkmal ergänzt (z.B. TOTP).
Eine sehr komplexe Form der Gegenmassnahme sind Captchas. Sie vereinigen typischerweise Fingerprinting
mit Massnahmen aus dem Reputativen-Bereich und ergänzen diese mit einer Form eines Turing-
Tests.
