Security fängt vorne an.

Braucht man Security überhaupt?

“Für Security haben wir keine Ressourcen.”, “Das ist doch nur eine interne Applikation, da brauchen wir keine Security”, “Da müssten wir viel zu viel Logs schreiben, das kann man sich doch sparen”, “Wir schreiben doch guten und sauberen Code, da müssen wir nicht besonders auf Security achten.” haben Sie schon mal eine dieser Aussagen so oder in einer ähnlichen Variante gehört?

Die meisten werden diese Frage sicher mit “Ja” beantworten können, aber leider wird die Security in der Entwicklung oft nicht ernst genug genommen. Dabei ist es immer wichtig schon in den ersten Schritten den Security Aspekt auf dem Schirm zu haben. Je früher man die Weichen stellt, desto einfacher ist es Security Patterns einzubinden.

In diesem Artikel möchte ich nun aber nicht direkt am Code Beispiele wie SQL Injections oder die OWASP Top 10 erklären, sondern eher über ein paar Grundsätze und deren Hintergründe reden.

Zu Beginn möchte ich sagen, ich bin davon überzeugt Security ist wichtig und unumgänglich. Allerdings bin ich genauso davon überzeugt, wenn ein guter Hacker in ein System will und sich das als Ziel setzt, dann findet er die eine Schwachstelle, die wir übersehen haben und kommt rein.

Doch was passiert dann? Das gleiche wie bei einem Einbruch wir haben den Scherbenhaufen und müssen ermitteln. Je mehr Hinweise und Spuren wir aber haben, desto schneller verstehen wir wie wurden wir gehackt, und wer war es überhaupt?
Wenn wir richtig gut sind können wir durch genug Hinweise sogar frühzeitig erkennen, dass wir gerade gehackt werden und schnell darauf reagieren.

Wo fängt Security an?

Wie schon der Titel sagt, Security fängt vorne an, also schon im Frontend. Diese Aussage mag im ersten Moment für manche komisch klingen, schließlich liegt doch das Frontend beim Client und der kann damit machen was er möchte, oder nicht?

Richtig, es gibt keinen sinnvollen oder zumindest mir bekannten Weg eine Webseite und deren Inhalt von Manipulation im Browser zu schützen. Wer möchte kann das mitgelieferte JavaScript anpassen, HTML Elemente manipulieren und das ganze sogar mit im Browser integrierten Tools.

Wo ist also hier die Security?

Klar eine Webseite sollte heute über HTTPS ausgeliefert werden, Cross-Site-Scripting sollte verhindert werden, Eingaben werden validiert und da gibt es noch andere Dinge, die eine gute Anwendung mitbringen sollte. Aber ich habe hier etwas erwähnt, die Validierung im Frontend, diese ist ein wichtiger Security Aspekt, darum werden wir uns diesem etwas genauer widmen.

Validierung im Frontend als Security?

Formulare und andere Arten der Übergabe von Daten aus dem Frontend an ein anderes System sollten vorher im Frontend validiert werden. Somit können wir also fehlerhafte und schädliche Eingaben sofort erkennen und es dem User auch benutzerfreundlich über eine Info direkt anzeigen. Das Ganze verhindert also das wir falsche und schädliche Anfragen und Werte an andere System versenden, dass nennt man Security…  Nicht ganz!

Wie weiter oben schon erwähnt, das Frontend liegt beim Client und dieser kann die Validierungen im Frontend umgehen, ausschalten oder verändern. Fast jeder, der sich damit kurz beschäftigt wird es also schaffen die Validierungen im Frontend zu umgehen und kann uns falsche Inhalte senden. Aber genau, da liegt dann doch wieder der Security Aspekt.

Stellen wir uns das ganze also wie folgt vor, irgendwo kommt ein Hacker auf die Idee sich unsere Webseite genauer anzuschauen und startet mit den einfachsten Methoden – HTML und JavaScript Manipulation.

Die Daten werden, da er die Validierung umgeht, direkt an unser Backend gesendet. Was nun passiert ist aber für uns nicht weiter schlimm, schließlich haben wir ein solides Backend welches die Validierung erneut durchführt und falsche Werte nicht annimmt. Wir sind also davon überzeugt der Hacker konnte uns auf diesem einfachen Weg nicht schaden und der Fall ist abgeschlossen?

Das Problem ist aber, wir wissen nicht welche Informationen der Hacker über unser System sammeln konnte und vermutlich war dies nur sein erster Versuch um zu sehen wie einfach wir es ihm machen. Und genau da sollten wir nun aufpassen, dieser “Angriff” war vermutlich nur ein ausspähen, ähnlich wie ein Bankräuber, der zur Vorbereitung eine Bank beobachtet und schaut wann geht die Wache auf Rundgang oder wer Arbeit von wann bis wann. Wie oft sieht man in Serien oder Filmen, dass ein solcher Bankraub durch die Überwachungskameras um die Bank aufgeklärt wird, weil man den Bankräuber dort beim Observieren wiederfindet. Nichts anderes können wir hier auch machen.

Jedes Mal, wenn wir eine Anfrage aus unserem Frontend am Backend entgegennehmen und die Validierung im Backend anschlägt sollten wir dies in die Logs schreiben. Natürlich kann es sein, dass wir verschieden starke Validierungen verwendet haben oder einen ganz simplen Grund dafür gibt, aber die Wahrscheinlichkeit ist doch hoch, dass jemand wissen wollte was passiert, wenn ich etwas herumspiele. Vor allem wenn aus unserem Formular Select Feld ein Wert kommt, den wir nicht kennen sollte klar sein, da schaut jemand was möglich ist.

Wann fange ich an ein Security Log zu schreiben?

Ganz einfach, so früh wie möglich!

Wie im Beispiel oben erläutert, jeder falsche Wert aus dem Frontend sollte uns komisch vorkommen. Ein gutes Frontend validiert und sendet nur korrekte Daten, daher ist ein falscher Wert immer etwas für das Security Log.

Wenn ein Nutzer Endpunkte aufruft, die wir gar nicht haben. Hier muss es nicht ein “dev.virtual7.de/-system/info” sein, dass uns komisch vorkommt es reicht auch wenn der User statt www.dev.virtual7.de/blog/ etwas wie www.dev.virtual7.de/blogger/ aufruft. Es kann hier Zufall sein oder jemand will wissen wie unsere Seite sich verhält, wenn er falsche Endpunkte aufruft, mit dem Ziel über Header Informationen oder ähnliches weitere Informationen zu sammeln. Das einfachste was wir machen ist eine Weiterleitung oder sogar eine eigene 404-Seite anzeigen. Was wir aber auch machen sollten ist einen Eintrag im Security Log zu schreiben.

Grundsätzlich sollte jeder Aufruf unseres Systems, der nicht so vorgesehen ist in einem Security Log landen.

Ich höre nun schon die Aufschreie, aber das ist doch viel zu viel Arbeit so viel zu loggen, da wir das Log doch schnell unübersichtlich.
Zum einen, wie viel Aufwand ist es wirklich ein Log zu schreiben? Ich glaube das ist ein Methoden Aufruf und wenn man das von Anfang an macht, ist das kein nennenswerter Mehraufwand.
Mit den Tools, die wir heute haben und einer vernünftigen Struktur im Log (Log-Tags, etc.) sollte niemand ein Problem haben auch eine große Log-Datei vernünftig zu verarbeiten.

Was bringen mir diese Logs?

Wie bereits erwähnt, ist es vor allem als Informationssammlung zu sehen, wenn unser System gehackt wurde, sollten wir auch verstehen können was passiert ist. Diese Logs dienen nun sozusagen als Brotkrümel um eine Spur zum Ausgangspunkt zu finden.

Es ist wichtig zu verstehen, was passiert ist, wo war die Schwachstelle wo hat der Angreifer die nötigen Informationen erhalten. Mit guten Logs können wir versuchen seine Schritte nachzuvollziehen.

Wir haben vermutlich auch die Möglichkeit den Angreifer zu identifizieren, wir können seine IP ermitteln, sein Betriebssystem oder andere Merkmale, die uns helfen ihn zu identifizieren.

Und sollten wir wirklich gut sein, können wir eben durch diese Logs auch bemerken, dass gerade ein Angriff läuft und uns verteidigen.
Stellen wir zum Beispiel fest, in der letzten Stunde wurden hunderte Anfragen von derselben IP mit falschen Daten gesendet, können wir die IP blocken für einen gewissen Zeitraum.

Sind unsere Logs so gut, dass wir auch sehen auf welches System der Hacker sich eingeschossen hat können wir auch dort Anfangen unsere Verteidigung aufzubauen.

Unsere Logs sind also eigentlich eine Art Aufklärung, diese kann mit den richtigen Mitteln ein Frühwarnsystem sein, oder eben im Nachgang zur Spurenanalyse verwendet werden.

Zusammengefasst: Logs sind wichtig!

Logs helfen uns Daten zu sammeln und wir brauchen Informationen um zu wissen was passiert.
Nur wenn wir wissen wo wir Schwachstellen haben oder wie wir angegriffen werden können wir unsere Security darauf anpassen.

Und wichtig ist, Security ist eben nicht nur das Einhalten der OWASP Top 10 oder das filtern von SQL Injections, das Einstellen von Firewalls, sondern auch die Analyse.
Da draußen gibt es Hacker, die entwickeln sich immer weiter und wir müssen dies auch, mit den Informationen, die wir haben.