Sicherheit bei Webapplikationen

19. Februar 2012 AirSys Security and Coding

Immer wieder wird durch die Medien und durch “Leaks” deutlich, dass IT-Sicherheit, insbesondere im Bereich der Webapplikationen, massiv vernachlässigt wird, doch dabei ist es gar nicht so schwer von vorn hinein eine gewisse Grundsicherheit zu erreichen. Diese möchte ich im folgenden genauer erläutern und so ggf. dem ein oder anderen Admin noch kleine Denkanstöße geben, mit denen er hoffentlich die Webpräsenz und private Kunden- oder Accountdaten besser vor Angriffen schützen kann.

Zunächst einmal: Automatische Schutzmechanismen (Application Level Firewalls) sind zwar schön und gut, jedoch bieten sie niemals den bestem Schutz und können nur grobe Angriffe (DOS-Attacke) oder einen Scan von einem Security Scanner abhalten indem sie einen automatischen IP Bann oder ähnliches durchführen. Das ist jedoch oft nicht wirkungsvoll. Wenn ein Angreifer manuell und mit Brain gegen eine Website (Applikation) vorgeht kann man diese automatischen Schutzmechanismen vergessen. Ein weiteres Problem ist, dass bei vielen größeren Webprojekten kaum Budget für die Sicherheit eingeplant. Und so musste schon der ein oder andere Großkonzern zugeben in diesem Bereich eingespart zu haben. Hoffentlich haben die Konzerne daraus gelernt, denn immerhin sind es nicht bloß die Kunden- und Kreditkarten die sie verlieren, sondern auch das Vertrauen der Kunden. Und das kann man beim heutigen Wettbewerb vergessen, nach dem Motto, wenn Firma X das nicht kann gehe ich halt zu Firma Y.

Zum Thema:

Nichts geht über die Fähigkeiten des Administrators, er muss besonders sensibel sein und dazu sollte er noch ein möglichst breites Wissen im Bereich der IT Security haben. Außerdem: Keiner ist perfekt, was soviel bedeuten soll, wenn man schon lange Zeit an einem Projekt codet verliert man auf Dauer den Blick für die Einzelheiten und es passieren kleine Fehler, die es einem Angreifer erleichtern in das System einzudringen. Deshalb sollte ein Projekt zunächst immer von jemand anderen noch einmal überprüft werden, oder man sollte selbst noch einmal einen ausführlichen Penetrationstest durchführen, in dem man alle Einzelheiten wiederholt durchgeht.

Architektur: Bei den meisten Online Applikationen handelt es sich um Skripts, die mit dem Client oder anderen Servern kommunizieren. (z.B.: Zugriff auf externe SQL_DB) Webapplikationen oder Anwendungen aus dem Web 2.0 lassen sich also als mehrschichtige Anwendungen betrachten. Die Kommunikation von der ersten zur zweiten Schicht, also vom Frontend des Anwenders werden meist ungefiltert Eingaben (Informationen) weitergegeben. Das System basiert häufig auf dem zustandslosen (stateless) HTTP-Protokoll. Das Problem besteht darin, dass die Eingaben eines Absenders ungefiltert an die Applikation geleitet werden - egal ob diese erwünscht oder unerwünscht sind. (z.B. SQL Injection)

Schichten einer Webapplikation: Es gibt in Webapplikationen wie eben schon kurz angesprochen verschiedene Schichten. Diese Schichten lassen sich recht leicht beschreiben und sind vergleichbar mit dem Aufbau einer Zwiebel. Die äußerste Schicht ist das sogenannte Frontend bzw. die sog. Präsentationsschicht, das ist für jeden User sichtbar und beinhaltet die zusammengesetzte Website, also das was im Webbrowser für den User zu sehen ist. Diese Schicht kommuniziert meist über HTTP-Requests mit dem Webserver und verarbeitet die Antwort (HTTP-Response). Die Logik bzw. Verwaltung übernimmt dabei der Webserver, er verwaltet die Anfragen oder leitet sie ggf. weiter. Die Weiterleitung kann sowohl an andere Server als auch an Skripts des eigenen Servers gehen (Webapplikationen). Die Applikation bearbeitet die Request dann mit einem Interpreter. Diese Schicht wird auch als Logik-Schicht bezeichnet, da in ihr alle wichtigen Prozesse und Vorgänge durchgeführt werden, die eine Website bzw. eine Webapplikation ausmachen. Die innerste Schicht ist die Daten-Schicht in ihr liegen sämtliche Daten und Informationen wie z.B. Bilder oder HTML Datein.

Im überwiegenden Teil der Praxis kommuniziert die Applikation mit einer DB bzw. einem Datenbankserver und einem Dateisystem, um z.B. das Frontend zu generieren. Bei einfachen Applikationen liegen die Logik- und die Daten-Schicht auf einem Server. Bei komplizierteren Applikationen, wie Onlineshops, Communities oder Verwaltungssoftware (große Firmen-DB) werden die einzelnen Schichten getrennt von einander gehostet. Die Verwaltung geschieht dann über Webservices, die wie eine serviceorientierte Architektur (Service Oriented Architecture, SOA) angelegt sind. Dadurch ist eine bessere Verwaltung möglich und es kann noch von mehreren Applikationen auf die Daten zugegriffen werden. Das Prinzip wird auch als Distributed Computing bezeichnet, wird aber häufig wirklich nur von größeren Unternehmen oder Projekten in Anspruch genommen. Ich persönlich hatte mit einem System, was komplett eigene Server nur für die DB nutzt auch noch nicht zu tun, da ich weder im Bereich Key-Account-Management noch in Bereich der Datenbank Administration viel Erfahrung habe (nur Erfahrung für kleinere Boards oder Blogs).

Wenn man sich nun das typische System einer Webapplikation anschaut wird schnell deutlich, dass ein Angreifer eine Vielzahl von Möglichkeiten hat in dieses System einzudringen. Denn grundsätzlich gilt: Jede Webapplikation ist so sicher wie die schwächste Komponente im System. Denn, es muss alles auf dem neusten Stand sein, um eine absolute Sicherheit zu erreichen (auch wenn es die in Wirklichkeit nicht gibt). Was nützt der schönste Webspace, wenn es für das CMS (Content Management System) einem Exploit gibt, oder was bringt das schönste Design + CMS, wenn die PHP Version veraltet ist? Richtig: GAR nichts!

Typisches Vorgehen bei einem Hackerangriff, da werde ich demnächst noch genauer eingehen:

 

So, dass war mal ein kleiner Ausflug in die Websecurity! In nächster Zeit werde ich noch einige von solchen theoretischen Themen besprechen. Erst hatte ich vor das noch mit in diesen Artikel zu packen, aber der wäre sonst zu lang geworden. Deshalb könnt ihr euch in Zukunft noch über Artikel in Richtung: SQL-Injektion, Eingabevalidierung und Sicheres Session-Management sowie Java als Risikofaktor. Vielleicht werde ich auch an Hand von Praxisbeispielen erläutern, wie die Thorie in der Praxis umgesetzt werden muss, da es einen recht zuverlässigen Schutz gibt.

Hoffe der Artikel hat euch gefallen und ihr wisst nun mehr über den theoretischen Aufbau von Webserverstrukturen sowie der Sicherheit von Webapplikationen. Falls es Rückfragen, Anregungen gibt oder Kritik schreibt es bitte in die Kommentare und ich werde es ggf. im nächsten Artikel berücksichtigen.

~AirSys