====== Angewandte IT-Sicherheit ======
**Fach:** Angewandte IT-Sicherheit

**Prüfer:** Prof. Freiling

**Beisitzer:** Hans-Georg Eßer

Angenehme Atmosphäre, Papier und Stift lagen auf dem Tisch. Hinweis, dass man „Weiß ich nicht“ sagen darf; die Note würde sich nicht einfach aus der Zahl der Wissenslücken errechnen.

===== Fragen =====
**F:** Mit was wollen Sie anfangen?

**A:** Softwaresicherheit.

**F:** Gibt es eine Sicherheitslücke, die Sie besonders begeistert?

**A:** Cross-Site-Scripting.

**F:** Erklären Sie mal! Sie sind jetzt der Professor und ich der Student.

**A:** Web-Sicherheitslücke, clientseitig. Keine Trennung von Mark-Up und Content in HTML, (JS-) Code zwischen ''<script>''-Tags wird vom Client ausgeführt. Wenn man Input ungefiltert übernimmt, können Nutzer JS-Code in die Seite einfügen. Reflektiertes, persistentes, DOM-based XSS (jeweils mit Erklärung). [DOM-based XSS war kein Inhalt von AppITSec.]

**F:** Nachfrage, ob ich etwas zu einem bestimmten Aspekt von DOM-based XSS wüsste, den er selbst nicht mehr genau benennen konnte.

**A:** Sagt mir nichts.

**F:** Gegenmaßnahmen gegen XSS?

**A:** Never trust user input. Alles filtern – relativ einfach, wenn gar kein HTML erlaubt ist (Kleiner- und Größerzeichen umwandeln in ''&lt;'' bzw. ''&gt;''). Schwieriger, wenn bestimmte Tags erlaubt sein sollen; bspw. kann ein Link als Ziel auch wieder JS-Code enthalten, man muss also echt aufpassen.

**F:** Vermischung von Logik und Inhalt hat man ja auch in SQL. Was gibt es denn für Maßnahmen gegen SQL-Injections?

**A:** Filtern mit Mitteln der Programmiersprache bzw. des Frameworks oder prepared statements, Erklärung von prepared statements. Sie führen eben eine Trennung von Mark-Up und Inhalt ein.

**F:** Wie funktionieren Drive-by-Downloads?

**A:** Sicherheitslücke in Browser wird benutzt, um Programm ohne Aktion des Nutzers herunterzuladen und auszuführen.

**F:** Hat das etwas mit JS zu tun?

**A:** Sicherheitslücke könnte auch in JS-Engine sein, aber der beim Drive-by-Download heruntergeladene Code ist eher kein JS. Wenn man mit Scripten der Webseite direkt Schaden auf dem Client anrichten könnte, wäre das wieder eine Lücke für sich.

**F:** Muss die Lücke für Drive-by-Download im Browser liegen?

**A:** Nein, könnte auch im Betriebssystem sein und theoretisch auch in der Hardware.

**F:** Plug-Ins zählen Sie dann zum Browser?

**A:** Definitionssache. Auf jeden Fall zeigt die Erfahrung der letzten Zeit, dass Flash, Java und Adobe Reader häufiger Ziele sind, als die Browser selbst.

**F:** Im Kontext von JS fällt auch häufiger der Begriff Heap-Spraying. Können Sie dazu etwas sagen?

**A:** Schon mal gehört, aber erklären kann ich es gerade nicht. [War auch kein Inhalt der Vorlesung.]

**F:** Für die grundlegenden Sicherheitsanforderungen hatten wir ja die Abkürzung CIA. Beim C, also der Vertraulichkeit, unterscheidet man da noch weiter zwischen Unbeobachtbarkeit und Anonymität. Wo liegt der Unterschied?

**A:** Unbeobachtbarkeit: Keine Info, dass Sache passiert ist, und durch wen. Anonymität: Man weiß, dass es passiert ist; allerdings auch nicht, durch wen.

**F:** Wie kann man Anonymität im Internet erreichen?

**A:** Mit einem Anonymisierungsnetzwerk wie Tor.

**F:** Ginge auch Unbeobachtbarkeit?

**A:** Schwierig, der Kommunikationsvorgang lässt sich nicht vor dem Weg zwischen den Kommunikationspartnern verstecken. Man könnte höchstens Tag und Nacht die Leitung maximal nutzen, dann würde die tatsächliche Kommunikation im Rauschen untergehen.

**Kommentar:** Wenn Sie z.B. ein VPN in die Uni machen und dort ständig Daten drüber jagen und der Staat ihren Internetanschluss abhört, würde er trotzdem noch sehen, //dass// Kommunikation stattfindet; er könnte nur nicht mehr den relevanten Teil erkennen. Aber auch gar keine Kommunikation wäre in diesem Sinne natürlich eine Information.

**F:** Wie funktioniert denn die Authentifikation bei verschlüsseltem Web-Browsing mit HTTPS?

**A:** Auf Basis von TLS/SSL. Man muss authentifizieren, damit kein Man in the middle möglich ist. Dazu hat die Webseite ein Zertifikat, in dem eine CA ihre Identität signiert. Der Browser bzw. das Betriebssystem bringt eine Liste von Root-CAs mit.

**F:** Kann man auch selbst CAs entfernen?

**A:** Theoretisch ja, aber zumindest bei Firefox sind einige fest rein kompiliert und lassen sich nicht entfernen.

**F:** Wissen Sie zufällig, welche das sind?

**A:** Nicht wirklich, vermutlich die aus alten Netscape-Zeiten oder so. [Kein AppITSec-Inhalt.]

**F:** Könnte man auch ganz ohne Root-Zertifikate auskommen?

**A:** Ansich ja, man müsste dann halt z.B. Trust on first Use machen, wie bei SSH. Erfordert aber gewissen Aufwand und Beschäftigung mit der Thematik. Will man den allermeisten Leuten also wohl nicht „zumuten“, so kaputt das CA-System auch sein mag.

**F:** Jetzt bin ich mit meinen Fragen schon fast durch. Vielleicht noch etwas zu den rechtlichen Aspekten: Wenn ich eine Sicherheitslücke finde und sie an den BND verkaufe, wie ist das juristisch zu bewerten?

**A:** Am ehesten Verkauf von Schadsoftware nach § 202c; aber schwierig, den Zweck von Software zu bestimmen. Wird ja auch nicht öffentlich angeboten, der BND wird wohl stillhalten. Nicht sicher, ob der Verkauf an Geheimdienste wirklich unter § 202c fällt. [Rückblickend stimmt das so eigtl. nicht ganz: Die Information über die Lücke ansich ist ja weder Passwort/Zugangscode, noch Computerprogramm.]

**F:** Das Ziel müsste ja auch die Begehung einer Straftat sein.

**A:** Hmm, Geheimdienste dürfen das wohl. Sind schließlich Teil des Staats und der hat das Gewaltmonopol. Übertreten von Grenzen wird gerechtfertigt mit parlamentarischer Kontrolle.

**F:** Es gibt ja auch Leute, die das Verkaufen von Lücken an Geheimdienste generell kritisch sehen. Wie bewerten Sie das?

**A:** Bin ich auch dagegen. Wenn die Lücke nicht dem Hersteller gemeldet wird, bleibt sie auch für den Rest der Welt ausnutzbar und wird zum Instrument eines einzelnen Geheimdiensts. Zwar finde ich es grundsätzlich OK, dass der Staat sich im Internet engagiert; aber eher nicht über Exploits gegen ungepachte Lücken. Traue den Diensten bzw. ihrer parlamentarischen Kontrolle auch nicht genug, dass sie nur Dinge tun, die ich auch OK fände.

**F:** Das ist nochmal eine andere Sichtweise als die juristische.

**A:** Ja, ist eine ethische/moralische Frage.

===== Bewertung =====
Wurde schnell wieder rein gebeten und bin sehr zufrieden ;-).

===== Vorbereitung =====
Ich hab mir ca. eineinhalb Tage lang die Folien aus Vorlesung und ggf. Übung angeschaut und rausgeschrieben, was ich für wichtig hielt und nicht eh wusste.

Allerdings kannte den Großteil des Blocks „Softwaresicherheit“ schon aus dem Hackerpraktikum und von [[https://ctftime.org/ctf-wtf/|CTFs]]. Wer sich ersten Mal mit diesen Sachen beschäftigt, sollte sicherlich mehr Zeit einplanen.