Frikandel – Erhöhte Sicherheit

Ruby on Rails Webapplikationen basieren auf dem zustandslosen HTTP. Die gängigen Mittel zur Authentifizierung und Autorisierung einer solchen Anwendung unterscheiden sich wenig von den Mechanismen anderer Web-Frameworks. Nach erfolgter Authentifizierung wird das Autorisierungs-Token mittels Cookie bei jeder Anfrage zwischen dem Browser des Nutzers und dem Server der Anwendung kommuniziert. Somit lässt eine Ruby on Rails Webapplikation auch die im Web gebräuchlichen Angriffsvektoren zu. Um solche Angriffe deutlich zu erschweren sind nur minimale Einbußen bei der Usability nötig.

Üblicherweise läuft die Authentifizierung in einer Ruby on Rails Webapplikation so ab: Der Benutzer wird gebeten, seinen Benutzernamen und sein Passwort einzugeben. Diese Daten werden von der Anwendung einmal überprüft. Wird ein entsprechender Nutzer erfolgreich zugeordnet, speichert die Anwendung z.B. die ID des Nutzer in einem Cookie auf dem Rechner des Benutzers, welches bei jeder weiteren Anfrage zur Autorisierung vom Browser des Nutzers zurück an die Anwendung geschickt wird. So muss bei jedem weiteren Klick nicht mehr Benutzername und Passwort geprüft werden: Der Server bekommt direkt die ID des eingeloggten Nutzer geliefert. Dass dies überhaupt möglich ist, verdanken wir der Tatsache, dass das Cookie fälschungssicher übertragen wird: Es wird von der Anwendung so signiert, dass sie erkennt, wenn man versucht, die ID zu manipulieren. Nur wenn die Signatur stimmt, wird von der Anwendung auch die User-ID verwendet, die übermittelt wurde.

Angriffsvektoren

Auch wir bei Taktsoft verwenden diese Art der Authentifizierung, da sie ressourcensparend und übersichtlich ist. Doch hat diese Art der Speicherung einige sicherheitsrelevante Nachteile. Der signierte Inhalt des Cookies ist durch keine Maßnahme vor neugierigen Blicken oder bösartigen Angreifern geschützt. So ist es möglich sich den Inhalt des Cookies zu kopieren und auf einem anderen System einzufügen. Die Anwendung wird dies nicht bemerken und autorisiert den Benutzer über das kopierte Cookie. Im Folgenden sollen einige Angriffsvektoren kurz erläutert werden.

Man-In-The-Middle-Angriff

Der Man-In-The-Middle-Angriff bezeichnet den Angriff auf die Kommunikation zwischen dem Rechner des Cookie-Inhabers und dem Ziel-Server. Dieser Angriff kann theoretisch auf der gesamten Kommunikationsstrecke erfolgen und ist besonders bei unverschlüsselter Kommunikation sehr erfolgversprechend. Hierbei wird das Cookie aus dem Netzwerkverkehr mit gelesen. Es sind viele Zugriffspunkte denkbar.

Angriff im (ungesicherten) W-LAN

Dieser Angriff ist wohl der gängigste Spezialfall des Man-In-The-Middle-Angriffs. Bei der nichtverschlüsselten Übertragung des Cookies im HTTP-Header kann jeder den Netzwerkverkehr mithören und somit auch das Cookie hieraus extrahieren. Dies ist z.B. bei der Nutzung eines öffentlichen, nicht verschlüsselten WLANs der Fall. Dieser Angriff ist verhälnismäßig trivial und mit einfachen Mitteln möglich. Doch selbst in verschlüsselten WLANs sind solche Angriffe möglich. Z.B. mittels sog. ARP-Injection.

Aber auch die Verwendung einer verschlüsselten Verbindung (z.B. TLS oder HTTPS, die für authentifizierte Bereiche eigentlich Standard sein sollte), bringt keine absolute Sicherheit, solange der Rechner des Benutzers ungenügend geschützt ist. Das Cookie kann auf liegengelassenen, nicht-gesperrten oder gestohlenen Computer abgegriffen werden. Cross-Site-Scripting-Lücken der Anwendung oder gar Schadprogramme auf dem Client-Rechner sind weitere Möglichkeiten eines Angreifers, sich Zugriff auf das gewünschte Cookie zu verschaffen.

Lösungsansätze

Eine mögliche Abwehr dieser Angriffe besteht darin, das Cookie nach einer gewissen Zeit ablaufen zu lassen. Bei jedem Aufruf der Webanwendung, protokolliert der Sicherheitsmechanismus der Anwendung zusätzlich den Zeitpunkt als Zeitstempel in das Cookie. Vorher wird geprüft, ob die Zeitspanne zwischen dem letzten Aufruf, also dem aktuell gesetzen Zeitstempel, größer ist als eine fest definierte Zeit: Die Time-To-Live ("TTL"). Diese ist Beispielsweise auf "60 Minuten" eingestellt. War nun der letzte Aufruf der Webanwendung um 14:20 Uhr, gerade ist es aber schon 15:30 Uhr, so sind mehr als 60 Minuten vergangen und das Cookie wird nicht mehr als gültig anerkannt. Ist jedoch weniger Zeit als die eingestellte TTL vergangen, so wird der Zeitstempel erneuert. Hiermit können die Angriffsverktoren des gestohlenen oder ungesperrten Computers, oder des "Ausloggen vergessen"-Problems drastisch minimiert werden: Wenn nur eine Stunde Zeit bis zum nächsten Anfrage ist, ist die Chance groß, dass der Angreifer einfach zu spät kommt. Eine zusätzliche Beschränkung, die wir für sinnvoll erachten, ist dem Cookie eine maximale, fest eingestellte Laufzeit zu geben, etwa von der Dauer eines Tages. Dies bewirkt, dass mindestens nach einem Tag Benutzername und Passwort neu eingegeben werden müssen. So hat der Angreifer maximal einen Tag zeit, sein Unwesen zu treiben, auch wenn seine normale "60 Minuten"-TTL nicht abläuft, z.B. in dem er ununterbrochen Interaktionen mit der Webanwendung verursacht. Dies soll den Schaden, den ein Angreifer im Ernstfall anrichten kann, begrenzen. Diese Maßnahme führen zwar unter Umständen zu einer Einschränkung der Usability. Der Nutzer ist gezwungen sich nach 60 Minütiger Abstinenz neu zu athentifizieren. Gleichzeitig wird der Wert der durch Angreifer erbeuteten Cookies durch ein zeitnahes Verfallsdatum drastisch reduziert.

FRIKANDEL

Damit wir diese beiden Sicherheitsmaßnahmen in ein gewünschtes Projekt leicht einbauen können, haben wir hierfür ein Gem "frikandel" erstellt. Es lässt sich einfach in jede Ruby on Rails-Anwendung einfügen. In der Anwendung wird dann per include Frikandel::LimitSessionLifetime im Controller dieser Mechanismus aktiviert. Es ist möglich, die Zeitbegrenzungen für beide TTL's in einem Initializer zu konfigurieren. Weitere Infos zur Konfiguration können aus dem README entnommen werden. FORK US ON GITHUB!

Zur Blog-Übersicht