Wie sieht eine sichere Web Application Security aus?
Irgendwas mit Passwort …
Ne.
Hinter „sicheren“ Web Applikationen steckt mehr als nur ein Passwort-Schutz.
Dieser umfassende, 3-teilige Guide soll Dir einen …
- Einblick in die Web Application Security
- 4 grundlegende Bausteine von Web Application Security
- Ein Praxis-Beispiel von Web Application Security mit SAML
… geben. Beginnen wir!
Geheime Anwendung = Sichere Anwendung?
Eine gute Architektur ist nicht sicher, weil das Unternehmen diese geheim hält, sondern, weil die Architektur einer uneinnehmbaren Festung gleicht. Selbst mit dem Wissen über die gesamte Sicherheits-Architektur können Profi-Hacker nur schwierig agieren.
#1 Gatekeeper – Tür-Steher für Traffic
Ein Gatekeeper gleicht einem Türsteher für den virtuellen Bereich des Unternehmens.
Dieser beobachtet alle ein- und ausgehenden Personen (Datentraffic), fragt nach Ihrer Identifikation (Nutzername und Passwort / Token) und prüft auf die Schnelle, ob die Person (Daten Traffic) böses vorhat.
Aufgaben eines Gatekeepers
Der Gatekeeper kann z. B. ein Validator im Backend sein. Diese überprüfen, welche Daten aus und in das System gehen. Der Gatekeeper prüft mit Validationsregeln, ob die Eingaben des Nutzers einen Sinn ergeben oder ob dieser Schwachsinn ist.
Sichere Gatekeeper arbeiten mit einer Form der Authentifizierung. Die Türsteher müssen wissen, wer gerade mit dem System in Kontakt treten möchte. Die Ausweise können Nutzernamen/Passwort oder Tokens sein.
#2 Proxy – Multifunktionaler Sicherheitsbaustein
Proxys tauchen in verschieden Formen und Funktionen auf. Je nach Anwendung bringt ein Proxy ein Quantum an mehr Sicherheit:
Web-Application-Firewall als Proxy
Ein Proxy kann als Firewall den gefährlichen Traffic herausfiltern. Eine Web Application Firewall überwacht den Datenverkehr. Eine Deep-Inspection Firewall entpackt die IP-Pakete und überprüft, ob die Inhalte den Computer infizieren kann.
Digitaler Schleier für Intranet
Ein Proxy verdeckt die System- und Netzwerklandschaft eines Unternehmens. Kriminelle möchten am liebsten die Netzwerklandschaft kennen, um gezielter anzugreifen.
Ein Frontend darf keine Authentifizierung durchführen, weil der Kriminelle in der Regel volle Kontrolle über die Kontrollflüsse hat (z. B. bei JavaScript). Das Backend kommuniziert mit dem Backend meistens über HTTP. Hacker müssen nur die HTTP-POST-Anfragen so modifizieren, dass der falsche Befehl das Backend beschädigt oder manipuliert.
Kurzzeitgedächtnis-Held – System-Entlasten
Ein Proxy kann Anfragen zwischenspeichern. Wenn z. B. die EU ganz plötzlich beschließt, dass die GDPR in Kraft tritt, dann googelt halb Europa „Was ist die GDPR?“. Der Google Server bereitet das Ergebnis vor und bedient die Anfragen aus dem Cache. Der Google Server bleibt verfügbar und wird nicht überlastet.
Last verteilen – Erhöhung der Verfügbarkeit
Ein Proxy kann die Last der Anfragen verteilen (Load-Balancing).
Sobald die GDPR am 25. Mai 2018 in Kraft tritt, wollen sich Millionen von Personen informieren. Diesen Ansturm kann Google nicht nur mit Caching lösen. Der Google Proxy verteilt die Last auf 1000+ virtuelle Server gleichmäßig.
In der IT-Sicherheit gehört die Verfügbarkeit zu den 3 großen Zielen. Ein Ausfall kostet viel Geld, Zeit und schadet dem Ruf des Unternehmens
#3 Single Sign On – 1 Passwort für alles
Eine Welt ohne Passwörter ist zu schön, um wahr zu sein. Single Sign On (SSO) reduziert das Passwortgetippe auf nur eins.
Du tippst nur einmal 1 Passwort ein und der Computer loggt sich für Dich in alle anderen Systeme sicher und automatisch ein.
Ein Praxis-Beispiel ist das Security Assertion Markup Language Protokoll (SAML). Diese verwendet ein verschlüsseltes Session-Cookie mit einem festgesetzten Ablaufdatum.
Nach dem 1 Login …
… autorisieren sich die Nutzer über Ihr Passwort. Der gültige Login verschafft den Zugang zu dem System, wo der Nutzer freigeschaltet ist.
Der Authentifizierungsserver generiert einen Einmal-Token (Passwort), mit dem sich der Computer bei der Ressource (z. B. Datenbanken) anmeldet.
Funktion von Single Sign On – Erklärt an Praxis-Beispiel
Ein Nutzer möchte die Anzahl der Tabellen aus einer SQL-Datenbank (Ressource) ohne sich anzumelden ausgegeben bekommen.
Schritt 0: Nutzer ist bereit bei Google Authenticator (Identitätsprüfer) angemeldet.
- Nutzer fragt den Zugriff mit dem SAML-Protokoll bei der Datenbank (Ressource) an.
- Die Datenbank (Ressource) legt den Identitätsprüfer fest (z. B. Google).
- Die Datenbank (Ressource) leitet die Anfrage zum Google-Server (Identitätsprüfer) weiter
- Der Computer des Nutzers fragt den Google-Server (Identitätsprüfer) an, ob der Nutzer berechtigt ist auf den Server zuzugreifen.
- Google (Identitätsprüfer) prüft, ob der kürzlich gesetzte Login-Token von der Anmeldung des Nutzers bei Google korrekt ist.
- Google-Server (Identitätsprüfer) antwortet mit einem HTML-Formular, das bestätigt, dass der Nutzer auf die Datenbank (Ressource) zugreifen darf.
- Google (Identitätsprüfer) versichert in einer Anfrage an die Datenbank (Ressource), dass der Nutzer auf die Daten zugreifen darf
- Google (Identitätsprüfer) leitet den Nutzer zur Datenbank (Ressource) weiter.
- Der Nutzer kann die Datenbank (Ressource) anfragen: „Gebe mir die Anzahl der Tabellen aus!“
- Die Datenbank (Ressource) antwortet mit der Zahl 42
#4 Logging Systeme – Beweise sammeln
Logging Systeme speichern sämtliche (nennenswerte) Operationen auf einem System:
Wichtige Beispiele sind das Lesen und das Schreiben von Daten, Veränderungen in den Einstellungen, sowie der Log-in / -out. Diese Systeme stellen für Kriminellen keine Barriere dar. Analysten können Hacks schnell mit den Loggern entdecken.
Die Sicherheitsexperten teilen Logging-Systeme in 3 Kategorien ein: Logging für Betriebssysteme, Anwendungen und Sicherheitsanwendungen
Herausforderung Logs
Beim Loggen können große Datenmengen an Logs entstehen.
Je nach Größe des Unternehmens sind diese für Menschen nicht mehr einsehbar. Die Frage ist wie die Daten analysieren, verstehen und zusammenfassen kann. Die Lösung nennt sich Sicherheits-, Informations- und Event-Management-Tool (SIEM), welches die Logging-Daten speichern und zusammenfassen kann. Dazu habe ich ein ausführliches Tutorial geschrieben.
Das PLUS an Sicherheit
Zentral ist, dass Admin die Daten nicht einfach löschen können.
Bei einer APT versucht der Hacker eine geheime Backdoor zu installieren. Dabei entstehen Logging-Spuren. Kriminelle können bei einem zentralen Logging ihre Spuren nicht so einfach löschen.
Bonus: OWASP Empfehlungen für sicheres Programmieren
- 2-Faktor Authentifizierung: Google und Microsoft bieten ein Authentication-Service an. Mit 2 von 3 Arten von Authentifizierungsstufen erhöht das Unternehmen die Sicherheit: Wissen (z. B. Passwort), Besitz (z. B. USB-Sicherheitstoken) und Biometrie (z. B. Fingerabdruck). Diese verschlechtert das Nutzererlebnis.
- Vertraue nicht Code anderer blind: Schreibe Deine eigenen Bibliotheken. In der Vergangenheit haben Kriminelle in bekannten Open Source Libraries Schadcode hochgeladen (Supply Chain Attack).
- Weniger Features = weniger Angriffsfläche: Jedes ungenutzte (und ungewartete) Features ist ein Scheunentor für Kriminelle.
- IT-Security ist ein Prozess: Deine Web Application Security ist kein Produkt, was Du für 999 € einmalig in einem Laden kaufen kannst – Web Application Security ist ein Prozess. Neue Sicherheitsstandards sind in 1 Jahr unsicher und eine Gefahr für Dein Produkt und Kunden. Bleibe immer auf dem Laufenden.
