4 grundlegende Bausteine von Web Application Security

Was ist eine sichere Web-Application-Architektur?

Irgendwas mit Passwort …

Ne.

Hinter „sicheren“ Web Applikationen steckt mehr als nur ein Passwort-Schutz.

Dieser umfassende, 3-teilige Guide soll Dir einen …

  1. Einblick in die Web Application Security
  2. 4 grundlegende Bausteine von Web Application Security
  3. Ein Praxis-Beispiel von Web Application Security mit SAML

… geben. Beginnen wir!

Vorstellung einer sicheren Web-Application-Architektur

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 – der Server-Tür-Steher für Daten-Traffic

Ein Gatekeeper gleicht einem Türsteher für den virtuellen Bereich des Unternehmens.

Dieser beobachtet alle ein- und ausgehenden Personen (Daten Traffic), 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. eine REST-Instanz im Backend sein. Diese überprüfen, welche Daten aus und in das System gehen. Der Gatekeeper prüft mit Validations-Regeln, 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. Entweder sind des Nutzernamen und Passwörter oder Tokens (Single Sign On siehe unten).

#2 Proxy – Multifunktionaler Sicherheitsbaustein

Proxy nutzt fast jedes Unternehmensnetz.

Web-Application-Firewall als Proxy

Ein Proxy kann als Firewall, um den Großteil an gefährlichen Traffic zu filtern. Eine Web Application Firewall überwacht den Datenverkehr. Dazu packt die Firewall die Pakete aus und überprüft, ob in den Paketen Schadcode den Computer Infizieren kann.

Digitaler Schleier für Intranet

Ein Proxy kann verdeckt die System- und Netzwerklandschaft im Hintergrund. Bei der Arbeit haben es Hacker schwieriger, wenn sie nicht den Aufbau des Systems kennen. Das Frontend ist Re-kompilierbar und kann von den Hackern eingesehen werden. 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. der EU ganz plötzlich beschließt, dass die GDPR in Kraft tritt, dann googelt halb Europa „Was ist die GDPR?“. Der Google Server crawlt aber nur einmal und lädt die Ergebnisse in einen Cache. Damit kann Google Rechenleistung und Strom sparen

Traffic-Last verteilen – Erhöhung der Verfügbarkeit

Ein Proxy kann 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 100te andere Server gleichmäßig (DDoS). 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, der Computer loggt sich für Dich in alle anderen System sicher und automatisch ein.

Ein Praxis-Beispiel das Security-Assertion-Markup-Language-Protokoll (SAML). Diese verwendet ein verschlüsseltes Session-Cookie mit festgesetzten Ablaufdatum.

Nach dem 1 Login …

… autorisieren sich die Nutzer über Ihr Windows-Domain-Passwort. Der gültige Login verschafft den Zugang zu dem System, wo der Nutzer freigeschaltet ist.

Der Authentifizierungsserver geniert einen Einmal-Token (Passwort), mit dem sich der Computer bei der Ressource 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.

  1. Nutzer fragt den Zugriff mit dem SAML-Protokoll bei der Datenbank (Ressource) an.
  2. Die Datenbank (Ressource) legt den Identitätsprüfer fest (z. B. Google).
  3. Die Datenbank (Ressource) leitet die Anfrage zum Google-Server (Identitätsprüfer) weiter
  4. Der Computer des Nutzers fragt den Google-Server (Identitätsprüfer) an, ob der Nutzer berechtigt ist auf den Server zugreifen.
  5. Google (Identitätsprüfer) prüft, ob der kürzlich gesetzte Login-Token von der Anmeldung des Nutzers bei Google korrekt ist.
  6. Google-Server (Identitätsprüfer) antwortet mit einem XHTML Formular, das bestätigt, dass der Nutzer auf die Datenbank (Ressource) zugreifen darf.
  7. Google (Identitätsprüfer) versichert in einer Anfrage an die Datenbank (Ressource), dass es der Nutzer auf die Daten zugreifen darf
  8. Google (Identitätsprüfer) leitet den Nutzer zur Datenbank (Ressource) weiter.
  9. Der Nutzer kann die Datenbank (Ressource) anfragen: „Gebe mir die Anzahl der Tabellen aus!“
  10. Die Datenbank (Ressource) antwortet mit der Zahl 42

#4 Logging Systeme – Indizien sammeln

Logging Systeme speichern sämtlich (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 Hacker keine Barriere dar. Analysten können Hacks schnell mit den Loggern entdecken.

Die Sicherheitsexperten teilen Logging-Systeme in 3 Kategorien ein: Logging für Betriebssystem, 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 einem Rootkit-Angriff / ATP-Angriff versucht der Hacker eine geheime Backdoor zu installieren. Dabei entstehen Logging-Spuren. Ein zentrales Log-System erschwert es Hackern die produzierenden Spuren zu 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 Authentifizierungen erhöht das Unternehmen die Sicherheit: Wissen (z. B. Passwort), Besitz (z. B. USB-Stick) und Biometrie (z. B. Fingerabdruck). Diese verschlechtert das Nutzererlebnis.
  • Vertraue nicht Code anderer: Schreibe Deine eigenen Bibliotheken. Viele Fälle von Backdoors und Remote Code Ausführung. Einbauen nicht nur von Funktionen, sondern weiteren Fehlerquellen und ungenutzten Code
  • Weniger Features = weniger Angriffsfläche: Qualität geht vor Quantität – gut (gegen Hackangriffe) getestete Web Applications ist stabiler und zuverlässiger
  • Verantwortlichkeiten trennen: Admin nur Admin – soll nicht Sachen nach Hause bestellen, Nutzer nur Nutzer soll bestellen können, aber nicht die Nutzerlisten einsehen können
  • Aktuellen Verschlüsselung und Protokoll-Standards: Web Application Security ist kein Produkt, was Du für 999 € bei Media Markt kaufen kannst – Web Application Security ist ein Prozess. Neue Sicherheitsstandards sind in 1 Jahr unsicher und eine Gefahr für Deine Produkt und Kunden. Bleibe immer auf den Laufenden
  • So wenig Rechte wie möglich: – selbst der Super-Admin eines Systems braucht nicht im Frontend-Code rum fuschen
  • Kein Remote Exekution: ist nicht möglich – keine (un)absichtlichen Remote-Execution-Backdoors in den Code integrieren – Mitarbeiter können ausgenutzt, missbraucht und falsch verwenden.
1 Star2 Stars3 Stars4 Stars5 Stars (No Ratings Yet)
Loading...

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.