EGIRAFFE Rechner - Und Kommunikationsnetze VO - Mstoeg - Pruefungsfragenausarbeitung - 2019WS

www.egiraffe.
at - Rechner- und Kommunikationsnetze - VO
Prüfungsfragenausarbeitung WS2019
Prüfungsfragenkatalog
Rechner- und Kommunikationsnetze
11. November 2019
3 Network Foundations
Seite 1/31
www.egiraffe.at - Rechner- und Kommunikationsnetze - VO
4 Between Link and Network Layer
1. Explain the ARP protocol:

Why is it needed?
On which layer(s) is it used?
How does it work and how are messages structured?
What are Gratuitous Messages?
Which security problems does it have and which attacks are possible?
ARP wird benötigt, um zu einer gesuchten IP-Adresse die zugehörige MAC-Adresse

innerhalb eines LAN herauszufinden. Es kommt demnach zwischen Link und Net-
work Layer zum Einsatz.
Funktion:
Jeder Host speichert dazu einen ARP-Cache mit dem Mapping von IP-Adressen
zu MAC-Adressen. Ist die gesuchte IP-Adresse des Empfängers nicht im ARP-
Cache, so wird ein Broadcast ARP-Request versandt. Der Host mit der gesuchten
IP-Adresse antwortet dann mit einer ARP-Reply, die seine MAC-Adresse enthält.
⇒ ARP-Cache wird upgedated. Wird der Host mit der gesuchten IP-Adresse nicht
gefunden, so erfolgt eine Vermittlung an den Gateway.
Aufbau:
Die ARP Pakete werden innerhalb von Ethernet-Frames eingekapselt. Sie beinhal-
ten:
• Hardwaretyp- und größe
• Protokolltyp- und größe
• Operation: Request/Reply
• Sender MAC- und IP-Adresse
• Target MAC- und IP-Adresse
[Hardware- bzw. Protokolltyp wäre für Unterscheidung zwischen IPv4 und IPv6]
Gratuitous ARP Messages:
Gratuitous ARP Messages sind unaufgeforderte Nachrichten, die verwendet wer-
den, um z.B. die ARP Caches der Hosts upzudaten, falls sich das Mapping von
IP zu MAC-Adresse eines Hosts verändert hat. (erfolgt typischerweise beim Star-
tup des Computers bzw. auch beim Austausch der Netzwerkkarte ⇒ neue MAC-
Adresse)
Sicherheitsprobleme:
Das Sicherheitsproblem von ARP ist, dass mittels Gratuitous ARP Messages be-
liebig das Mapping von IP-Adressen zu MAC-Adressen in den ARP Caches ma-
nipuliert und somit verfälscht werden kann. ⇒ Gratuitous Messages sind nicht
authenticated!
Attacken:
Dies wird z.B. beim ARP-Poisoning bzw. ARP-Spoofing angewandt, um Daten-
verkehr zum Gateway an den Angreifer umzuleiten (⇒ Man in the middle attack)
Seite 2/31
2. What is ARP poisoning?

What can be done in an open WIFI network to defend against this attack?
Das Sicherheitsproblem von ARP ist, dass mittels Gratuitous ARP Messages be-
liebig das Mapping von IP-Adressen zu MAC-Adressen in den ARP Caches ma-
nipuliert und somit verfälscht werden kann. ⇒ Gratuitous Messages sind nicht
authenticated! Dies wird z.B. beim ARP-Poisoning angewandt, um Datenverkehr
zum Gateway an den Angreifer umzuleiten (⇒ Man in the middle attack)
Verteidigung:
• HTTPS verwenden
• VPN verwenden
• nur vertrauenswürdige und geschützte WLANs verwenden
• Firewall oder Intrusion Detection System verwenden
Seite 3/31
5 Network Layer IPv4
1. To which protocol does the following header belong?

Explain the fields
Version
Identification
Fragment Offset
Time to Live
Protocol
Source/Destination Address (size?)
Header Checksum (What’s the difference to the next version of the shown protocol
header?)
Es handelt sich um einen IPv4 Protokoll Header.

Version: IP Protokoll Version ⇒ 4
Identification: eindeutige Identifikation für die einzelnen Fragmente
Fragment Offset: Offset des aktuellen Fragments bezogen auf das nicht fragmen-
tierte Paket
Time To Live: Gibt die maximal verbleibende Lebensdauer des Pakets in Sekun-
den an; entspricht eigentlich einem Hop Count. (Zähler der bei jedem Knoten im
Netzwerk dekrementiert wird) Ist die TTL = 0 so wird das Paket verworfen.
Protocol: gibt das Protokoll des an, welches im Datenfeld verwendet wird (z.B.
ICMP(Internet Control Message Protocol), TCP, UDP)
Source/Destination Address: 32-bit IP Adresse für Sender und Empfänger (z.B
192.0.2.42 ⇒ 4x8 bit)
Header Checksum: Checksum, die aus dem IPv4 Header berechnet wird. Diese
wird von jedem Router überprüft. Bei Änderungen am Header (z.B. TTL wird
verringert) muss die Checksum jedes Mal neu berechnet werden. ⇒ großer Over-
head. Deshalb gibt es In IPv6 keine Checksum mehr, da dies dort die Aufgabe von
TCP/UDP-Protokollen ist.
Seite 4/31
2. What is MTU Path Discovery?

How does the standard method work, which protocols are used?
Why could the standard method fail (and actually does quite often). If it fails,
explain one other technique that could be used?
What is the difference between IPv4 and IPv6 (in relation to MTU Path Discove-
ry)?
MTU (Maximum Transmission Unit) gibt an wie viele Bytes maximal über einen
Data Link übertragen werden können.
MTU Path Discovery:
Zuerst sendet der Host ein IP Paket mit gesetztem DF-Flag (Don’t fragment).
Kann ein Router die maximal geforderten Bytes nicht übertragen (MTU < packet
size), so wird das Paket verworfen und mittels ICMP-Message (Internet Control
Message Protocol) dem Sender mitgeteilt:
”Destination unreachable - Fragmentation required, and DF flag set”. Dieser Vor-
gang wird solange wiederholt, bis die MTU klein genug ist, um das Paket über den
gesamten Pfad zu übertragen.
Verwendete Protokolle: IP, ICMP (in IP Pakete eingekapselt)
Diese Methode schlägt oft fehl, da Firewalls ICMP-Pakete aus Sicherheitsgründen
oft komplett blockieren (um z.B. DDoS (Denial of Service)-Attacken durch ICMP
Pings zu verhindern). Als Alternative dazu kann das TCP-Protokoll verwendet
werden, bei dem schrittweise versucht wird größere Pakete zu übertragen, bis ein
Paket-Verlust auftritt.
Der Unterschied von IPv4 zu IPv6 besteht darin, dass in IPv6 die MTU Path Dis-
covery verpflichtend ist, da dort durch Router keine Fragmentierung vorgenommen
wird. Als Alternative gibt es bei IPv6 auch eine minimale MTU size (1280 Bytes),
die von jedem Knoten unterstützt werden muss. In IPv6 werden zu große Pakete
mit der ICMPv6-Fehlermeldung ”Packet too big” an den Sender zurückgewiesen.
Seite 5/31
6 Network Layer IPv6
1. Neighbor Discovery Protocol

Wie funktioniert es?
Welche Funktionalitäten ersetzt NDP?
Welche 2 Aufgaben deckt NDP ab? Ausführlich beschreiben.
What are Privacy Extensions for SLAAC?
Für NDP (Neighbor Discovery Protocol) muss jeder Host folgendes speichern:
Neighborhood Cache: speichert von bekannten Nachbarn, die sich im selben
Netzwerk befinden, das Mapping von IPv6 Adressen zu MAC-Adressen.
Default Router List: darin wird eine Liste von bekannten Router gespeichert
(verweist auf Neighborhood Cache)
Destination Cache: darin werden alle Adressen gespeichert, an die schon etwas
gesendet wurde (verweist auf Neighborhood Cache ⇒ nächster Hop auf dem Weg
zur Destination Adresse)
NDP ersetzt die Funktionalität von ARP und DHCP.
NDP Router Discovery
Wenn sich ein Host mit dem Netzwerk verbindet, so sendet er eine ”Router Solici-
tation” via Multicast and alle Router. Die Router antworten daraufhin mit einem
”Router Advertisement” direkt an den Host. Zusätzlich werden periodisch ”Router
Advertisments” an alle Hosts gesendet. ⇒ zum Updaten der Default Router List,
für globalen Präfix
NDP Address Resolution
Dies ersetzt die Funktionalität von ARP. Zuerst sendet der Host eine ”Neighbor
Solicitation” via Multicast an die solicited-node Adresse. (kein Broadcast wie in
ARP) Der Host mit der gesucht IP Adresse antwortet daraufhin mit einem ”Neigh-
bor Advertisement” ⇒ zum Updaten des Neighborhood Caches
NDP Auto Configuration:
Dies ersetzt die Funktionalität von DHCP. Mittels Stateless address auto-configuration
(SLAAC) kann ein Interface direkt eine IPv6 Adresse erhalten, ohne zuvor mit
Router/Server kommunizieren zu müssen. (⇒ plug-and-play)
Dazu wird zunächst aus link-local Prefix, MAC-Adresse und dem Einfügen zweier
festen Bytes (Inteface ID) eine link-local Adresse erzeugt. Danach wird mittels
”Neighbor Solicitation” überprüft, ob diese link-local Adresse bereits existiert. ⇒
Ein”Neigbor Advertisement” wird nur dann zurückgesendet, wenn die link-local
Adresse bereits vergeben wäre.
Um aus der link-local Adresse nun eine globale IPv6 Adresse zu erstellen muss
auf das nächste ”Router Advertisement” gewartet werden, welches den globalen
Präfix enthält. bzw. kann dies auch direkt mittels ”Router Solicitation” angestoßen
werden.
Seite 6/31
Privacy Extensions for SLAAC:

Das Problem von SLAAC ist, dass man durch den Interface ID-Anteil der IPv6
Adresse leicht Rückschlüsse auf die MAC Adresse des Hosts ziehen kann ⇒ Daten-
schutzproblem. Um dies zu verhindern wird bei Privacy Extensions for SLAAC die
Interface ID aus dem 64-bit Hashwert (SHA1) von Zeitstempel und MAC-Adresse
berechnet.
Seite 7/31
7 Transport Layer TCP UDP
1. To which protocol does the following header belong?

Explain the fields:
Source/Destination Port
Sequence Number
Acknowledgement Number
Flags: ACK, SYN, FIN, RST
Window Size
Es handelt sich um einen TCP Protokoll Header.

Source/Destination Port: Portnummer des Senders/Empfängers (0-65535)
Well-known ports (0-1023) sind z.B.:
• 20. . . FTP • 53. . . DNS

• 22. . . SSH • 80. . . HTTP
• 25. . . SMTP • 443. . . HTTPS
Sequence Number:Ist das SYN flag gesetzt, ist die Sequence Number random.
Ansonsten ist die Sequence Number die Position des ersten Datenbytes innerhalb
des Segments.
Acknowledgement Number: Ist das ACK flag gesetzt, entspricht die Acknow-
ledgement Number der nächsten Sequence Number, die sich der Empfänger er-
wartet. ⇒ wird verwendet um den Empfang aller Bytes bis zur Acknowledgement
Number - 1 zu bestätigen
Seite 8/31
Flags:
- SYN: initiiert den Verbindungsaufbau verwendet. (Three-Way-Handshake) ⇒
Synchronisation der Sequence Number
- ACK: wird verwendet, um den Empfang aller Bytes bis zur Acknowledgement
Number - 1 zu bestätigen. Ist immer gesetzt außer im allerersten Segment.
- FIN: zeigt an, dass der Sender keine Daten mehr senden will. Das aktuelle
Segment ist somit das letzte.
- RST: zeigt an, dass der Sender die Verbindung sofort beendet. [RESET]
Window Size: gibt an wieviele Bytes gesendet werden können, bis sich der Sender
ein ACK erwartet (⇒ für Flow Control)
Seite 9/31
2. How is the TCP connection establishment phase called?

Sketch an example that shows this establishment phase. Use adequate values for
the TCP flags, and the sequence/ack numbers for the sender/receiver. Also include
the relevant TCP states and their transitions in your diagram.
Der TCP Verbindungsaufbau wird als Three-Way Handshake bezeichnet.

Ablauf:
1. Zuerst sendet der Client ein Paket mit gesetztem SYN-Flag. Die Sequence
Number wird dabei random gewählt.
2. Der Server antwortet mit gesetztem SYN und ACK-Flag. Die Sequence Num-
ber ist dabei ebenfalls eine random number. Die Acknowledgement Number
entspricht der Sequence Number des Clients + 1.
3. Der Client antwortet mit gesetztem ACK-Flag. Die Sequence Number ist
die Acknowledgement Number des Servers. Die Acknowledgement Number
entspricht der Sequence Number des Servers + 1.
10
Seite 10/31
3. TCP Protocol
On which layer is it located?
Explain 5 services that are offered by TCP on this layer?
Das TCP-Protokoll befindet sich im Transport Layer.

Services:
• Reliable Transmission: mit Hilfe der Sequence Number und Acknowledge-
ment Number wird sichergestellt, dass alle Pakete gesendet und empfangen
werden
• Error Handling: Geht ein Pakete verloren wird dies festgestellt, da kein
ACK vom Empfänger für eine bestimmten Bytebereich zurückkommt. (Re-
transmission Timeout) ⇒ der Sender muss die Bytes erneut senden
• Flow Control: Mittels Flow Control wird verhindert, dass der Sender den
Empfänger mit zu vielen Daten überfluten kann. Der Empfänger könnte be-
reits busy oder under heavy load sein bzw. einen limitierten Buffer haben.
• Congestion Control: Mittels Congestion Control wird verhindert, dass ein
Sender zu viele Daten in ein Netzwerk einbringt und somit Switches/Router
überfluten kann.
• Congestion Avoidance: Während Congestion Control erst bei einer Con-
gestion aktiv wird, wird bei Congestion Avoidance versucht zu verhindern,
dass es überhaupt zu einer Congestion kommt.
11
Seite 11/31
4. Explain how flow control works within TCP:

What is flow control?
Which problem does it solve?
Which protocol is responsible for flow control?
Which header fields play a role?
Explain how the sender gets to know how many packets (bytes) to send?
What’s the difference to congestion control?
Mittels Flow Control wird verhindert, dass der Sender den Empfänger mit zu
vielen Daten überfluten kann. Der Empfänger könnte bereits busy oder under hea-
vy load sein bzw. einen limitierten Buffer haben. Die Sendegeschwindigkeit muss
deshalb an den Empfänger angepasst sein. (Sender Empfänger)
Das TCP-Protokoll ist für Flow Control verantwortlich.
Für die Implementierung der Flow Control spielt das Header Field ”Window Size”
eine große Rolle. Es gibt an wie viele Bytes gesendet werden können, bis sich der
Sender ein ACK erwartet. Die ”Window Size” wird über den Handshake zwischen
Sender und Empfänger vereinbart und kann dynamisch vergrößert bzw. verkleinert
werden.(Sliding Window)
Mittels Congestion Control wird verhindert, dass ein Sender zu viele Daten in ein
Netzwerk einbringt und somit Switches/Router überfluten kann. (Hosts Netz-
werk) Dies wird mittels Congestion Window geregelt, welches jedoch im Gegensatz
zur Window Size für Flow Control kein Teil des TCP Headers ist, sondern beim
Sender verwaltet wird.
12
Seite 12/31
5. Explain congestion control an congestion avoidance within TCP/IP in detail.

How does TCP recognize that the network is congested?
How does the congestion control method work?
How is congestion control related to congestion avoidance? What’s the difference
between them?
What’s RED?
What’s the main idea behind ECN?
Mittels Congestion Control wird verhindert, dass ein Sender zu viele Daten in ein
Netzwerk einbringt und somit Switches/Router überfluten kann. (Hosts Netz-
werk) Dies wird mittels Congestion Window geregelt, welches jedoch im Gegensatz
zur Window Size für Flow Control kein Teil des TCP Headers ist, sondern beim
Sender verwaltet wird. Dazu wird zunächst mit einen kleinen Congestion Window
begonnen und dieses solange additiv erhöht, bis ein Paket-Verlust auftritt. Ist dies
der Fall, so wird das Congestion Window halbiert. Da die additive Zunahme des
Congestion Windows zu Beginn zu langsam wäre wird das Fenster zu Beginn ex-
ponentiell vergrößert.
Während Congestion Control erst bei einer Congestion aktiv wird, wird bei Con-
gestion Avoidance versucht zu verhindern, dass es überhaupt zu einer Congestion
kommt:
• RED(Random Early Detection): Bemerkt ein Router, dass ein Netzwerk kurz
vor der Überlastung ist, so verwirft er random ein Paket, damit die Congestion
Control früher aktiv wird.
• ECN(Explicit Congestion Notification): Bemerkt ein Router, dass ein Netz-
werk kurz vor der Überlastung ist, so setzt er diese Notification, welche ein
Teil des IPv4 Headers ist.
13
Seite 13/31
8 Application Layer HTTP
1. Explain 4 HTTP request types of your choice.
sichere HTTP-Methoden: GET, HEAD, OPTIONS, TRACE ⇒ verändern kei-

ne Ressourcen am Server
unsichere HTTP-Methoden: POST, PUT, DELETE, PATCH ⇒ führen zu Veränderungen
an den Ressourcen
• GET: Anforderung einer Ressource über die URI. Dabei werden keine Res-
sourcen am Server verändert. ⇒ idempotent (mehrmaliges Ausführen führt
zu selben Ergebnis)
• POST: Zum Erzeugen, Hinzufügen oder Updaten von Ressourcen am Ser-
ver. ⇒ nicht idempotent (mehrmaliges Ausführen würde erneut die Aktion
auslösen - z.B. mehrmaliges Hinzufügen)
• PUT: Zum Erzeugen/Ersetzen von Ressourcen am Server. ⇒ idempotent
(da Resource nur beim ersten Mal erzeugt wird und anschließend nur ersetzt
wird)
• HEAD: Entspricht der Funktionalität von GET nur dass hier nur der Header
alleine angefragt wird und der Body nicht enthalten ist.
• OPTIONS: Returniert die erlaubten HTTP-Methoden, die auf eine Res-
source am Server angewandt werden dürfen.
• TRACE: Returniert den HTTP-Request (echo) - kann zum Debuggen ver-
wendet werden. Stellt jedoch ein Sicherheitsproblem dar, da mittles HTTP
TRACE Angreifer z.B. Cookies/Session IDs auslesen können.
2. Explain the REST concept.
REST steht für Representational State Transfer. Bei einer RESTful API handelt
es sich um eine Programmierschnittstelle, die HTTP-Methoden, wie z.B. GET,
PUT, POST oder DELETE verwendet, um auf die Daten eines Webservices zu-
zugreifen. Die URI gibt dabei an mit welcher Ressource gearbeitet werden soll.
Als Rückgabe/Übergabe können dabei Formate wie XML oder JSON verwendet
werden.
14
Seite 14/31
3. Explain the new features introduced by HTTP 2.0?
Bei HTTP 2.0 wurden die Grundkonzepte (Methoden, Status Codes, Header fields)
von HTTP 1.1 übernommen, die Daten werden jedoch nicht mehr im Textformat
übertragen sondern binär. Das Problem von HTTP 1.1 ist, dass für jeden Request
eine eigene Verbindung aufgebaut werden muss. ⇒ großer Overhead. In HTTP
2.0 wird eine TCP-Verbindung für mehrere Requests verwendet. Requests werden
dabei als Streams übertragen, welche priorisiert werden können.
Zudem ist es in HTTP 2.0 möglich, dass der Server Ressourcen an den Client sen-
det, die er noch gar nicht angefragt hat ⇒ Server Push. (Der Server erkennt am
vorherigen Request, welche Ressource der Client als nächstes benötigen wird.)
4. Describe AJAX, AJAX Long Polling and WebSockets and the evolution of these
three protocols (hint: what does Long Polling offer what AJAX doesn’t, what does
a WebSocket offer what Long Polling doesn’t?)
Früher wurden Websiten als statische HTML-Seiten entwickelt, wo jedes mal die
gesamte Seite neu geladen werden musste, wenn sich etwas minimal verändert hat.
Deshalb wurden asynchrone Verfahren entwickelt, die Inhalte dynamisch laden:
• AJAX: (Asynchronous JavaScript and XML) In JavaScript werden mittels
XMLHttpRequest Daten von einem Webserver geladen. Dies passiert asyn-
chron und im Hintergrund, damit die GUI nicht blockiert wird. Die Daten
verändern anschließend den DOM (Document Object Model) des Clients. Das
Problem von AJAX ist, dass der Client in einem periodischen Intervall ständig
den Server nach Updates abfragen muss. (Polling)
• COMET-Long Polling: im Prinzip wie XMLHttpRequest nur dass die Ver-
bindung so lange offen gehalten wird, bis der Server die Daten bereit hat.
• Web Sockets: Web Sockets ermöglichen schließlich eine bidirektionale Kom-
munikation zwischen Server und Client mittels TCP-Verbindung. Web Sockets
ermöglichen auch, dass der Server Ressourcen an den Client sendet, die er
noch gar nicht angefragt hat. Die Verbindung wird dabei im Handshake von
HTTP auf WebSocket upgegraded.
15
Seite 15/31
5. Explain HTML5 cross-document messaging. When using this mechanism as devel-

oper, which aspects are important for security?
Die Same Origin Policy ist ein Sicherheitsmechanismus, der verhindert, dass ei-
ne Website potentiell schädliche Ressourcen von einer anderen Origin dynamisch
laden kann. In manchen Anwendungsfällen ist es aber notwendig Daten zwischen
zwei Windows/Frames über verschieden Origins hinweg zu versenden. Dies kann
mithilfe von HTML5 postMessages erreicht werden. Die Nachricht enthält dabei 3
Felder:
• Data: Inhalt der Nachricht
• Origin: Window, dass die Nachricht gesendet hat (in der Form scheme://host:port)
• Referenz auf das Source Window
Sicherheitsaspekte:
• als Client sollte man nie * als Target Origin angeben ⇒ ein Angreifer könnte
so die Nachricht abfangen
• als Empfänger von HTML5 postMessages sollte man immer die Origin des
Senders überprüfen ⇒ ansonsten kann jedes beliebige Window potentiell
schädliche Messages senden
6. Session IDs:
What’s the problem of the Referer Header when using URL rewriting for session
handling in HTTP?
Explain some other problems associated with URL rewriting.
Why do we need cookies for HTTP/HTTPS
Explain their basic structure
Explain two options that are highly relevant for security
Explain the PROs and CONs of using cookies (in context of session IDs)
How could HTTP TRACE be used by an attacker to get access to the session id?
HTTP ist ein zustandsloses Protokoll, das heißt, dass jeder Request unabhängig
vom vorherigen ausgeführt wird. Der Server speichert dabei keinerlei Session-
Informationen über den User. (z.B. ist er eingeloggt oder nicht) Um also einen
User bei einem erneuten Request wieder identifizieren zu können wurden Session
IDs eingeführt. Es gibt 4 Möglichkeiten Session IDs an den Server zu senden:
• URL Rewriting: Session ID ist Teil der URL
• Cookies: in HTTP Header gespeichert
• Hidden Fields: innerhalb eines HTTP POST Requests
• Bearer Tokens: Client authentifiziert sich zuerst beim Server. Dieser schickt
daraufhin ein Bearer Token zurück welches der Client speichert und dann bei
Requests auf geschützte Ressourcen wieder mitschickt ⇒ optimal für SSO
16
Seite 16/31
Referer Header: Bei einem HTTP GET Request wird typischerweise ein Referer
Feld im Header mitgeschickt, dass die URL des Origins beinhaltet. Enthält die
Origin URL z.B. eine Session ID (wie bei URL Rewriting) so wird diese Session
ID auch an die angeklickte Seite weitergeleitet.
weitere Probleme von URL Rewriting:
• Webserver loggen Requests ⇒ und damit auch Session IDs
• Browserverlauf enthält auch die Session IDs
• Benutzer die die URL kopieren, können unbeabsichtigt auch die Session ID
mitkopieren
Warum Cookies? siehe erster Absatz
Struktur von Cookies:
• Daten sind in Name/Value Pairs gespeichert
• zugehörige Domain und Path des Cookies
• Expiration: Wenn keine Expiration gesetzt ist handelt es sich um ein Session
Cookie, das beim Schließen des Browsers wieder gelöscht wird.
• Secure: falls gesetzt → das Cookie wird nur bei Verwendung von HTTPS an
den Server gesendet
• HttpOnly: falls gesetzt → es kann nur von HTTP/HTTPS aus auf das
Cookie zugegriffen werden und nicht von anderen scripts, wie z.B. JavaScript
(document.cookie ist nicht mehr möglich) ⇒ Verhinderung von XSS Attacken
Vorteile von Cookies:
• die Cookies tauchen in Server Logs nicht auf
• der Benutzer kann nicht eingreifen (z.B. das Cookie mit Session ID versehent-
lich kopieren)
Nachteile von Cookies:
Mittels Cookies kann nachverfolgt werden, welche Seiten ein Benutzer in welcher
Reihenfolge und für wie lange besucht hat. ⇒ Tracking und Privacy Problem
HTTP TRACE:
Ist bei einem Cookie das HttpOnly-Falge gesetzt, kann nur von HTTP aus auf
das Cookie zugegriffen werden und nicht von anderen scripts, wie z.B. JavaScript.
(document.cookie ist nicht mehr möglich) Dies kann umgangen werden, indem ein
HTTP TRACE Request durchgeführt wird. Dieser returniert dann nämlich den
HTTP-Request (echo) mitsamt Cookies, die der Angreifer dann auslesen kann.
17
Seite 17/31
9 Application Layer Web Technologies
1. Same Origin Policy (SOP): Explain the SOP details for two different technologies:
Web Applications:
Which elements does the browser consider when comparing two ”Origins”?
Which communication methods/html tags/etc. does the SOP consider in a Web
application?
Which are not subject to SOP? Give some examples.
Cookies:
How does the SOP work for cookies?
laden kann. Skripten dürfen somit nur auf DOM, Cookies und Windows zugreifen,
die sich am selben Origin befinden. Selber Origin bedeutet gleiches/r
• scheme
• host
• port
Form: scheme://host:port
Die Same Origin Policy verbietet:
• direkter Zugang zu DOM, Cookies und Windows von anderen Origins
• direkte HTTP/S Requests an andere Origins (z.B. XMLHttpRequest)
Erlaubt sind jedoch:
• <img> . . . einfügen von externen Bildern
• <script> . . . einfügen von externen JavaScript libraries
• <iframe> Seiteninhalt einer anderen Origin innerhalb eines iframes
• HTML5 postMessages zu anderen Windows/Frames
• verbleibende HTML Tags
Bei Cookies müssen domain und path übereinstimmen damit man vom sel-
ben Origin spricht. Zudem wird mittels (gesetztem) Secure-Flag sichergestellt,
dass das Cookie nur bei Verwendung von HTTPS and den Server gesendet wird.
Ebenso kann mittels (gesetztem) HttpOnly-Flag nur von HTTP/S aus auf das
Cookie zugegriffen werden und nicht von anderen scripts, wie z.B. JavaScript
(document.cookie ist nicht mehr möglich) ⇒ Verhinderung von XSS Attacken
18
Seite 18/31
2. Explain JSONP.
Why do we need it and why is it used?
How does it work?
What are its problems?
Name other methods you know.
Give an overview over another method (of your choice) that could be used instead
of JSONP.
laden kann. In manchen Anwendungsfällen ist es aber notwendig Daten über ver-
schiedene Origins hinweg zu versenden. ⇒ JSONP ist eine Möglichkeit um die
SOP zu umgehen.
Funktion: Das <script> Tag ist trotz SOP erlaubt, um z.B. externe JavaScript
libraries einzubinden. Deshalb kann der Client im <script> Tag eine Callback-
Funktion bereitstellen:
< s c r i p t type=t e x t / j a v a s c r i p t
s r c=” http : / / t h i r d p a r t y . com/ U s e r s /1234? j s o n p=p a r s e R e s p o n s e ”>
</ s c r i p t >
Nun kann der Server die angefragten Ressourcen an den Client senden und der
Client kann dann die Daten in seiner Callback-Funktion weiterverarbeiten.
Probleme: Bei JSONP kann der Server beliebige Daten an den Client senden. So
kann ein bösartiger Web-Server über die zurückgesendeten Daten z.B. schadhaften
Content in die Seite injizieren bzw. private Informationen aus dem Browser des
Clients auslesen. Zudem kann der Server nicht kontrollieren welche Origins auf die
bereitgestellte JSONP API zugreifen.
andere Methoden:
• HTML5 postMessages
• AJAX Proxy
• CORS
Overview over another method: CORS
Bei CORS (Cross-Origin Resource Sharing) kann der Server festlegen, welche Orig-
ins auf seine Ressourcen zugreifen dürfen. Die Permissions werden dabei über den
HTTP Header definiert.
Ablauf:
Der Client besucht die Website http://example.com auf der via AJAX eine exter-
ne Ressource von http://thirdparty.com/resource.js angefordert wird. Der Client
erzeugt dazu einen GET-Request indem er den eigenen Origin mit angibt.
GET / r e s o u r c e . j s HTTP/ 1 . 1
Host : t h i r d p a r t y . com
O r i g i n : http : // example . com
19
Seite 19/31
Der Server überprüft nun ob er dem Origin http://example.com vertrauen kann

und sendet einen HTTP Response Header mit den Origins denen er vertraut.
(*. . . alle Origins erlaubt) Der Browser checkt dann, ob die eigene Origin mit den
erlaubten übereinstimmt:
• JA. . . die Response wird durchgestellt
• NEIN. . . die Response wird wegen SOP blockiert
3. What is CORS?
How does it work?
Why do we need it?
Is it possible to send cookies to CORS enabled hosts?
How is it related to other mechanisms like the Same-Origin-Policy or CSP?
ne Website potentiell schädliche Ressourcen von anderen Origins dynamisch laden
kann. In manchen Anwendungsfällen ist es aber notwendig Daten über verschie-
dene Origins hinweg zu versenden. ⇒ CORS ist eine Möglichkeit um die SOP zu
umgehen. Dabei kann der Server festlegen, welche Origins auf seine Ressourcen
zugreifen dürfen. Die Permissions werden dabei über den HTTP Header definiert.
Ablauf:

Die Basisimplementation von CORS erlaubt es nicht, dass Cookies mitübertragen
werden. Abhilfe → CORS Preflight: Es kann mittels eines HTTP OPTION -
Requests angefragt werden, welche Permissions für die Origin erlaubt sind. Für
Cookies wäre dies z.B. Access-Control-Allow-Credentials = True.
SOP (Same Origin Policy): siehe oben
CSP (Content Security Policy) ist ein Sicherheitsmechanismus, der verhindert,
dass lokale JavaScript Injection z.B. mittels XSS (Cross-Site Scripting) möglich ist.
20
Seite 20/31
4. Explain the Content Security Policy (CSP).

Why do we need it?
How is it related to other mechanisms like the Same Origin Policy (SOP) or Cross-
Origin Resource Sharing (CORS)
CSP (Content Security Policy) ist ein Sicherheitsmechanismus, der verhindert,

dass lokale JavaScript Injection z.B. mittels XSS (Cross-Site Scripting) möglich
ist. Dies wird zusätzlich benötigt, da die SOP (Same-Origin-Policy) nur verhindert,
dass eine Website potentiell schädliche Ressourcen von anderen Origins dynamisch
laden kann. Grundidee bei CSP ist dabei, dass der Webserver dem Browser in ei-
nem zusätzliches HTTP-Header field bei der Response mitteilt, dass er gewisse
Richtlinien(Policies) einhalten muss. So kann z.B. folgendes eingeschränkt werden:
• Ressourcen dürfen vom Browser nur von spezifischen, vertrauenswürdigen
Quellen angefordert werden
• AJAX Requests sind nur an bestimmte Domains erlaubt
• Verbot von HTTP-Kommunikation ⇒ nur HTTPS ist erlaubt
• Verhinderung von unsicherem Code, wie z.B. inline code oder die JavaScript
eval() Funktion
SOP (Same Origin Policy): siehe oben
CORS (Cross-Origin Ressource Sharing) ist eine Möglichkeit um die SOP
(Erklärung siehe oben) zu umgehen. Dabei kann der Server festlegen, welche Orig-
ins auf seine Ressourcen zugreifen dürfen. Die Permissions werden dabei über den
HTTP Header definiert.
Ablauf:

21
Seite 21/31
5. What is Cross-Site Scripting (XSS)?

How does it work?
Explain Persistent XSS, Reflected XSS
How can a website owner defend against XSS?
Cross Site Scripting (XSS) ist eine Injection attack, die verwendet wird, um schad-
haften JavaScript-Code lokal im Browser des Opfers auszuführen. Dabei wird SOP
umgangen, da es sich ja um dieselbe lokale Origin handelt. XSS kann z.B. genützt
werden, um:
• den DOM zu manipulieren und z.B. fake Logins einzuschleusen
• Cookies auszulesen (mit document.cookie)
• Keylogger einzuschleusen (mittels EventListener)
Es wird unterschied zwischen:
• Persistent XSS: Eine Injection wird dauerhaft in eine Website eingeschleust.
Dies kann z.B. über einen Forumpost, Kommentar, Blog, etc. erfolgen. Bei
jedem Benutzer, der die Website aufruft, wird dieser schadhafte Code dann
ausgeführt.
• Reflected XSS: Die Injection wird nur für einen Benutzer in die Website
eingeschleust. Dies erfolgt über eine manipulierte URL, die dem Opfer z.B.
mittels phising-mail zugesendet wird. + zusätzliche Verwendung von URL
Shortener
• DOM XSS: Ähnlich wie Reflected XSS nur, dass hier der Server gar nicht
beteiligt ist. Dies erfolgt wieder über eine manipulierte URI, wobei hier der
Teil der URI nach einem # nicht mehr an den Server gesendet wird.
Verhinderung von XSS:
• HttpOnly Flag von Cookies verwenden (document.cookie ist nicht mehr
möglich)
• Escaping: problematische Zeichen/Paramter werden herausgefiltert/ersetzt
• Verwendung von CSP (Content Security Policy) ⇒ der Webserver teilt
dem Browser in einem zusätzliches HTTP-Header field bei der Response mit,
dass er gewisse Richtlinien (Policies) einhalten muss.
• Websiten mit Tools wie z.B. Burp Proxy testen
22
Seite 22/31
10 Application Layer TLS
1. Explain the TLS handshake. (in detail)
Zuerst initiiert der Client mittels ClientHello den TLS handshake (TCP Connec-
tion auf Port 443). Dieses Client Hello enthält u.a.:
• höchste unterstützte TLS Version
• random number (für den Key Exchange)
• vorgeschlagene Cipher Suites
• unterstütze Kompressions-Methoden
• Extensions
Der Server antwortet daraufhin mit einem ServerHello. Dieser Server Hello enthält
u.a.:
• gewählte TLS Version
• random number (für den Key Exchange)
• nur eine gewählte Cipher Suite
• gewählte Kompressions-Methode
• gemeinsame Extension
Falls es bei TLS-Version bzw. bei den Cipher Suites zu keiner Übereinstimmung
kommt so wird der Handshake abgebrochen.
23
Seite 23/31
Ansonsten schickt der Server sein X.509 Certificate mitsamt Zertifizierungsliste.

Mittels ServerKeyExchange kann der Server noch zusätzliche Parameter sen-
den, sofern dies für den Key Exchange erforderlich ist. (diese Parameter sind aber
zumeist schon im Zertifikat enthalten) Zum Schluss signalisiert der Server mittels
ServerHelloDone, dass er vorerst fertig ist.
Anschließend sendet der Client mittels ClientKeyExchange je nach verwendeter
Verschlüsselung (RSA, DH, ECDH) die notwendigen Parameter. Bei RSA sendet
der Client hier z.B. das mit dem public key verschlüsselte preMaster secret. Nun
erfolgt ein ChangeCipherSpec von Client und Server, welches signalisiert, dass
beide Parteien alle notwendigen Parameter für die Verschlüsselung erhalten haben.
Zum Schluss wird beim Finish von Client und Server noch die Integrität des ge-
samten Handshakes mittels MAC (Message Authentication Code) überprüft. Der
Client berechnet dazu aus allen Handshake Messages und dem gemeinsamen mas-
terSecret einen Hashwert und sendet diesen an den Server. Der Server überprüft
dann die Integrität indem er seinerseits den MAC berechnet und vergleicht.
2. Explain the three TLS principles.
• Authenticity: Informationen sind wirklich von dem angegebenen Sender ⇒

mittels Zertifikat
• Data Integrity: Die Daten dürfen von unautorisierten Personen nicht verändert
werden ⇒ mittels MAC
• Confidentiality: mittels Encryption
24
Seite 24/31
3. What is a cipher suite? Explain the name convention.

Explain the Perfect Forward Secrecy (PFS) Concept for TLS.
Give examples for cipher-suites that offer PFS and that don’t. Give a short expla-
nation why the chosen examples have/don’t have the PFS property.
Cipher Suite:
Cipher Suites geben an, wie die drei TLS-Properties (Authenticity, Data Integrity
und Confidentiallity) sichergestellt werden. Darin wird folgendes definiert:
• SSL oder TLS
• Key exchange:
– RSA
– DH (Diffie Hellman)
– DHE (Diffie Hellman Ephemeral)
– ECDH (Elliptic Curve Diffie Hellman)
– ECDHE (Elliptic Curve Diffie Hellman Ephemeral)
[ephemeral . . . kurzlebig]
• Authentication: RSA, DSA, DSS, ECDSA
• Verschlüsselungs-Algorithmus/Stärke/Modus: RC4, DES, AES
• Hash-Funktion für MAC: MD5, SHA-1, SHA-256
z.B. IANA-Notation
TLS ECDHE RSA WITH AES 128 CBC SHA256
• Verwendung von TLS
• Key Exchange: ECDHE (Elliptic Curve Diffie Hellman Ephemeral)
• Authentication: RSA
• Verschlüsselung: AES (Advanced Encryption Standard) mit 128 bit key im
CBC(Cipher Block Chaining) Mode [oder GCB (Galois Counter Mode)]
• Hash Funktion für MAC: SHA-256
z.B. OpenSSL-Notation [keine Angabe, ob TLS oder SSL ⇒ Standard TLS]:
ECDH-RSA-WITH-AES-128-GCM-SHA256
25
Seite 25/31
Perfect Forward Secrecy

Ohne Perfect Forward Secrecy hängt die Sicherheit der gesamten Verbindung nur
von der Sicherheit des private keys des Servers ab. Der Client erstellt während
des TLS Handshakes im State ClientKeyExchange ein preMaster secret und ver-
schlüsselt dieses mit dem public key des Servers aus dem Zertifikat. Der Server
entschlüsselt das preMaster secret anschließend mit seinem private key, um das
gemeinsame preMaster secret zu erhalten. ⇒ Wird der private key des Servers
gestohlen/gebrochen (Key Compromise), so kann damit jegliche (vergangene als
auch zukünftige) Kommunikation entschlüsselt werden.
Verwendung von PFS:
• der Server erzeugt ein kurzlebiges (ephermeral) Diffie Hellman Schlüsselpaar
(DHE, ECDHE)
• der Server signiert den public Key des DH Schlüsselpaars mit dem private
key seines Certificates und sendet ihn an den Client
• der Client überprüft die Signatur des public DH Keys durch Entschlüsseln
mit dem public key des erhaltenen Server Certificates
⇒ Key Agreement anstelle von Key Transport
Eine Cipher Suite erfüllt Perfect Forward Secrecy:
• Minimum TLS-Version 1.2
• nur bei Key Exchange mit DHE oder ECDHE (Ephemeral . . . kurzlebig)
Cipher Suite mit PFS:
TLS ECDHE RSA WITH AES 128 CBC SHA256
⇒ da für den Key Exchange ECDHE verwendet wird.
Cipher Suite ohne PFS:
TLS RSA WITH AES 128 CBC SHA256
⇒ da für den Key Exchange RSA verwendet wird.
26
Seite 26/31
4. When using cookies, why do we need to be careful when switching from HTTPS to
HTTP in the same session? Which Proctection can be used to avoid this problem?
Loggt sich ein Benutzer z.B. zuerst über HTTPS auf einer Seite ein und wird
anschließend in der selben Session die Verbindung auf HTTP abgestuft, so könnte
ein Angreifer, der sich im selben Netzwerk befindet, die unverschlüsselte HTTP
Kommunikation des Opfers und damit auch das Session-Cookie auslesen. (über
eine Man-In-The-Middle Attack mittels ARP Poisoning) Mit dem Session Cookie
kann er dann ohne Login auf die Website zugreifen. Abhilfe: HSTS (HTTP Strict
Transport Security)
Mittels HSTS teilt der Server dem Browser mit, dass auf die Webseite nur mit-
tels HTTPS zugegriffen werden darf. (wird in HTTP Header spezifizert). Dies
gilt dann für einen bestimmten Zeitraum (max-age period) und optional auch für
subdomains.
5. TLS: HTTP Strict Transport Security (HSTS) is a rather new method that offers
additional protection for TLS-based communication.
How does it work?
Which problems does it address?
Why do browsers already come with pre-loaded HSTS-enabled host lists?
Mittels HSTS (HTTP Strict Transport Security) teilt der Server dem Browser
mit, dass auf die Webseite nur mittels HTTPS zugegriffen werden darf. (wird in
HTTP Header spezifizert). Dies gilt dann für einen bestimmten Zeitraum (max-
age period) und optional auch für subdomains.
gelöste Probleme
verhindert SSL Stripping Attacken:
• Variante A: Eine Website kann sowohl über HTTP als auch HTTPS erreicht
werden. Der Angreifer könnte nun z.b. HTTP Links verbreiten, um das Opfer
dazu zu zwingen die unsichere HTTP Verbindung zu verwenden.
• Variante B: Eine Website kann nur über HTTPS erreicht werden. Der An-
greifer verwendet einen Proxy Server (über eine Man-In-The-Middle Attack
mittels ARP Poisoning) und täuscht damit dem Opfer vor, dass die Seite nur
HTTP unterstützt. Der Angreifer kopiert/ersetzt dazu alle Links der Seite
durch HTTP Links und übernimmt selbst die HTTPS-Kommunikation mit
dem echten Server.
preloaded HSTS lists
Kommuniziert der Browser das erste Mal mit einem bestimmten Server, könnte
ein Angreifer den HSTS Header löschen. Der Browser wüsste dann nicht, dass
HSTS aktiv sein sollte. Browser werden deshalb mit einer preloaded HSTS list
ausgeliefert, damit der Browser schon bei der ersten Kommunikation weiß, dass
diese Seite immer HTTPS benötigt.
27
Seite 27/31
6. TLS: Explain how Certificate Pinning works and why it is needed?
Certificate Pinning ist ein Sicherheitsmechanismus, der verhindern sollte, dass

ein Angreifer ein Zertifikat fälschen kann bzw. sich selbst als CA (Certification
Agency) ausgeben kann. Dazu wird der Hashwert (Pin) von public key und zu-
gehörigem Zertifikaten im Browser gespeichert. Wenn sich nun der PIN verändert
(bei Veränderung des Zertifikates) so wird die Verbindung beendet.
11 Application Layer TLS Attacks
1. Explain the SSLStrip attack. What can we - as developers/site owners - do to

protect the users from this attack?
• Variante A: Eine Website kann sowohl über HTTP als auch HTTPS erreicht
werden. Der Angreifer könnte nun z.b. HTTP Links verbreiten, um das Opfer
dazu zu zwingen die unsichere HTTP Verbindung zu verwenden.
• Variante B: Eine Website kann nur über HTTPS erreicht werden. Der An-
greifer verwendet einen Proxy Server (über eine Man-In-The-Middle Attack
mittels ARP Poisoning) und täuscht damit dem Opfer vor, dass die Seite nur
HTTP unterstützt. Der Angreifer kopiert/ersetzt dazu alle Links der Seite
durch HTTP Links und übernimmt selbst die HTTPS-Kommunikation mit
dem echten Server.
Abhilfe: HSTS (HTTP Strict Transport Security)
Mittels HSTS teilt der Server dem Browser mit, dass auf die Webseite nur mittels
HTTPS zugegriffen werden darf. (wird in HTTP Header spezifizert). Dies gilt dann
für einen bestimmten Zeitraum (max-age period) und optional für subdomains)
28
Seite 28/31
12 Application Layer DNS
1. DNS - Funktionsweise
Funktionsweise (Address Resolution)
Wie sehen die Protokolle aus? Protokoll Header erklären
Hierarchie aufzeichnen (at tugraz iaik teaching)
Erklären sie Root Server? Wie wird der Root-Server von einem DNS-Server gefun-
den?
Welche zwei Nameserver gibt es? (Unterschied zwischen Authorative und Non-
Authorative NS erklären)
Welche Schwächen hat DNS? (Sicherheitsprobleme)
Welche Attacken gibt es? Wie funktionieren sie? Wie können Sie verhindert wer-
den?
DNS (Domain Name System) wird zur Namensauflösung einer Domain (z.B. http://example.com)
in eine IP-Adresse (z.B. 192.0.2.42) verwendet.
Address Resolution:
Der Host sendet zuerst einen DNS Request an den lokalen Name-Server (UDP Connec-
tion auf Port 53). Hat der lokale Name-Server die angefragte Domain nicht im Cache,
so leitet er die Anfrage an den nächsthöheren Name-Server weiter. Jeder Name-Server
kennt dazu höhere Name-Server. Sobald nun ein Name-Server einen Eintrag zur ange-
fragten Domain gefunden hat, sendet er diesen rekursiv zurück, bis wieder der lokale
Name Server erreicht ist. Dieser gibt dann die Antwort an den ursprünglichen Host.
Jeder Name-Server speichert zudem die Antworten für eine gewisse Zeit (TTL . . . Time
To Live) in seinem Cache.
Protokolle
• Für den Transport werden hauptsächlich UDP (User Datagram Protocol) Pakete
auf Port 53 verwendet
• Es gibt 2 Typen von DNS Nachrichten: Query & Reply
• DNS Query: Beinhaltet die Domain zu der man die IP Adresse anfragen möchte
• DNS Reply: Beinhaltet die IP Adresse zur angefragten Domain und eine Lis-
te von nächsthöheren Name Servern und deren IP, die für die Adressauflösung
zuständig waren. (wenn vorherige Name-Server die angefragte Domain nicht im
Cache hatten)
• Als grundlegende Informationseinheit werden in DNS Nachrichten sogenannte RR

(Resource Records) verwendet. Diese bestehen aus:
– Name
– Value (z.B. IP Adresse)
– Type (z.b. A. . . IPv4, AAAA . . . IPv6)
29
Seite 29/31
– TTL (maximale Zeit die ein Non-Authorative Server diesen Eintrag im Cache
wiederverwenden darf)
– Class (Protokollgruppe - optional)
Baumstruktur
• Root Server bilden die Spitze
• darunter kommen TLDs (Top Level Domain)
– Generic Domains: com, org, net, . . .
– Country Domains: at, de, . . .
– Special Domains: example, localhost, arpa, . . .
• die Tiefe des Baumes ist willkürlich (bis 128 Einträge)
• die Domänen sind Teilbäume (at, tugraz.at, a-sit.at)
• Namenskollisionen werden dadurch vermieden (tugraz.at und tugraz.org können
beide existieren)
Root Server
Es gibt insgesamt 13 logische Root Server (a.root-servers.net, . . . , m.root-servers.net),
aber hunderte physische Server (Verteilung mittels IPv4 Anycast). Die Root Server ken-
nen alle Authorative Server für eine spezifische TLD ⇒ mit einem einzigen Root-Server
kann also jede Domain rekursiv aufgelöst werden. Damit ein DNS Server einen Root
Name Server finden kann, hat er ein ”Root Hints File” vorkonfiguriert, welches die Root
Name Server und deren IP-Adresse beinhaltet.
30
Seite 30/31
Authorative Server
• sind für eine Zone (z.B. .at oder .iaik.tugraz.at) verantwortlich
• es gibt mindestens einen Authorative Server pro Zone, diese sind normalerweise
als redundante Cluster aufgebaut
Non-Authorative Server
• erhält die Information über Domains von anderen Name Servern rekursiv oder
iterativ
• speichert die Antworten für eine gewisse Zeit (TTL . . . Time To Live) in seinem
Cache
• Non-Authorative Server ermöglichen eine schnellere Antwort, da es nicht mehr

notwendig ist den gesamten Baum zu durchlaufen
Sicherheitsproblem:
Befindet man sich in einem fremden WLAN-Netz, kann man nicht sichergehen, dass der
lokale DNS-Server vertrauenswürdig ist. Dieser könnte z.B. gefährliche IP-Adressen für
eine angefragte Domain returnieren. (z.B. für Man-in-the-middle attack)
Attacken auf DNS Server:
• Dos (Denial of Service Attack) bzw. DNS Amplification Attack: Der An-
greifer fälscht dazu die Source IP Adresse indem er die IP Adresse des Opfers darin
angibt und macht dann eine DNS Anfrage, die eine viel größere DNS Response zur
Folge hat. Das Opfer wird dadurch mit der DNS-Response überflutet.
• Cache Poisoning: Der Angreifer manipuliert den Cache eines DNS Servers, um
auf eine gefälschte Website umzuleiten
Verhinderung: DNSSEC (DNS Security Extensions)

Bei DNSSEC kommen Signaturen ins Spiel, um die Authentizität von DNS Servern zu
garantieren. Die Name Server signieren dazu alle ihre Responses mit dem privaten RSA
key und die DNS Resolver überprüft die Signatur wieder mit ihrem public RSA key.
⇒ wird der DNS Content manipuliert so kann dies nun detektiert werden.
31
Seite 31/31

EGIRAFFE Rechner - Und Kommunikationsnetze VO - Mstoeg - Pruefungsfragenausarbeitung - 2019WS

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

EGIRAFFE Rechner - Und Kommunikationsnetze VO - Mstoeg - Pruefungsfragenausarbeitung - 2019WS

Hochgeladen von

Copyright:

Verfügbare Formate

www.egiraffe.

at - Rechner- und Kommunikationsnetze - VO

11. November 2019

4 Between Link and Network Layer

1. Explain the ARP protocol:

ARP wird benötigt, um zu einer gesuchten IP-Adresse die zugehörige MAC-Adresse

2. What is ARP poisoning?

5 Network Layer IPv4

1. To which protocol does the following header belong?

Es handelt sich um einen IPv4 Protokoll Header.

2. What is MTU Path Discovery?

6 Network Layer IPv6

1. Neighbor Discovery Protocol

Privacy Extensions for SLAAC:

7 Transport Layer TCP UDP

1. To which protocol does the following header belong?

Es handelt sich um einen TCP Protokoll Header.

• 20. . . FTP • 53. . . DNS

2. How is the TCP connection establishment phase called?

Der TCP Verbindungsaufbau wird als Three-Way Handshake bezeichnet.

Das TCP-Protokoll befindet sich im Transport Layer.

4. Explain how flow control works within TCP:

5. Explain congestion control an congestion avoidance within TCP/IP in detail.

8 Application Layer HTTP

1. Explain 4 HTTP request types of your choice.

sichere HTTP-Methoden: GET, HEAD, OPTIONS, TRACE ⇒ verändern kei-

2. Explain the REST concept.

3. Explain the new features introduced by HTTP 2.0?

5. Explain HTML5 cross-document messaging. When using this mechanism as devel-

9 Application Layer Web Technologies

Der Server überprüft nun ob er dem Origin http://example.com vertrauen kann

Der Server überprüft nun ob er dem Origin http://example.com vertrauen kann

4. Explain the Content Security Policy (CSP).

CSP (Content Security Policy) ist ein Sicherheitsmechanismus, der verhindert,

Der Server überprüft nun ob er dem Origin http://example.com vertrauen kann

5. What is Cross-Site Scripting (XSS)?

10 Application Layer TLS

1. Explain the TLS handshake. (in detail)

Ansonsten schickt der Server sein X.509 Certificate mitsamt Zertifizierungsliste.

2. Explain the three TLS principles.

• Authenticity: Informationen sind wirklich von dem angegebenen Sender ⇒

3. What is a cipher suite? Explain the name convention.

Perfect Forward Secrecy

6. TLS: Explain how Certificate Pinning works and why it is needed?

Certificate Pinning ist ein Sicherheitsmechanismus, der verhindern sollte, dass

11 Application Layer TLS Attacks

1. Explain the SSLStrip attack. What can we - as developers/site owners - do to

12 Application Layer DNS

• Es gibt 2 Typen von DNS Nachrichten: Query & Reply

• Als grundlegende Informationseinheit werden in DNS Nachrichten sogenannte RR

• sind für eine Zone (z.B. .at oder .iaik.tugraz.at) verantwortlich

• Non-Authorative Server ermöglichen eine schnellere Antwort, da es nicht mehr

Verhinderung: DNSSEC (DNS Security Extensions)

Das könnte Ihnen auch gefallen