Sie sind auf Seite 1von 30

Security on Rails: Darstellung von Sicherheitskonzepten in Ruby on Rails 3.

0 Anwendungen
Christoph Bhm
Universitt Bamberg, Lehrstuhl fr Wirtschaftsinformatik insb. Industr. Anwendungssysteme Feldkirchenstrae 21, 96045 Bamberg, Deutschland christophboehm86@googlemail.com

Abstract. Der Schutz von Webanwendungen vor Angriffen ist als impliziter Bestandteil der Webentwicklung zu verstehen. Fr die Realisierung einer sicheren Anwendungsplattform eignet sich das Web Framework Ruby on Rails 3. Dabei ergibt sich die Sicherheit eines jeden Webframeworks aus dem Zusammenspiel der Systemebene, der eingesetzten Technologien sowie der Qualitt der Implementierung. Jede einzelne Ebene bietet spezifische Herausforderungen, fr dessen Lsung Ruby on Rails vordefinierte, teilweise auch implizite Lsungen anbietet. Vor allem die Einhaltung dieser Programmierschemata untersttzt die schnelle und sichere Umsetzung von webbasierten IT-Verfahren mit Hilfe von Rails 3.0. Stichworte: Ruby on Rails, Web Engineering, Security, Rails Security, Rails 3.0, Web-Application Security, Security-Engineering

1
1.1

Einfhrung
Motivation

Oft liegt der Hauptfokus bei der Entwicklung von Webanwendungen auf der Funktionalitt sowie einer einfach zu bedienenden, interaktiven Benutzeroberflche. Ziel ist es, mit Webanwendungen mglichst schnell Netzwerkeffekte zu nutzen und daraus folgend viele Kunden fr den eigenen Dienst zu gewinnen. Zu kurz kommt dabei hufig der Aspekt der Sicherheit [1, S. 121]. Unzureichend geschtzte Webanwendungen stellen jedoch eine groe Gefahr fr jedes im Internet ttige Unternehmen dar. So stellt Kaspersky im Cyberthreat Forecast for 2012 fest, das Webseitenbetreiber im Internet mittlerweile eine wahre Sammelwut bei der Erfassung von Kundendaten entwickelt haben, diese aber nur unzureichend gegenber Angriffen schtzen knnen [2, S. 3]. Prominentester Fall im Jahr 2011 war der Diebstahl von Kunden- sowie Kreditkarteninformationen von Sonys Playstation Network, was einen groen Image- und Vertrauensverlust fr diese Plattform bedeutete [3, S. 22]. Diese Problematik wiegt umso kritischer, da das prgende Trendthema im Web, das Cloud-Computing, zu groen Teilen von dem Vertrauen der Kunden in die Anbieter und deren Fhigkeiten, die Nutzerdaten vor unberechtigten Zugriff zu schtzen, abhngt [2, S. 3]. Moderne Angriffsformen wie Cross-Site Scripting oder SQL-

Injection, also Angriffsformen, die direkt auf eine fehlerhafte Implementierung von Webanwendungen abzielen, zhlen dabei mittlerweile zu den hufigsten Einfallstoren in Unternehmensnetzwerke [4]. Rails als Framework fr die Entwicklung und dem Betrieb webbasierter Applikationen untersttzt bei der Implementierung sicherer Webanwendung, um den Herausforderungen im Web gerecht zu werden. Dabei gilt aber, dass Webframeworks wie Ruby on Rails nicht per se sicher sind, sondern der Entwickler beziehungsweise Betreiber diesen Aspekt implizit whrend des gesamten Lebenszyklus einer Webanwendung beachten muss. Aufgrund dieser Tatsache ist es Ziel der Ausarbeitung, Gefahren- und Risiken beim Einsatz von Ruby on Rails 3 aufzuzeigen und darauf aufbauend Lsungsanstze fr spezifische Problemstellungen darzustellen. 1.2 Aufbau der Arbeit

Die vorliegende Projektarbeit gliedert sich in sechs Kapitel. Neben dem einleitenden ersten Kapitel befasst sich Kapitel Zwei mit der generellen Darstellung der fr die Sicherheit einer Webanwendung relevanten Inhalte und Prozesse. Hierbei wird ein vom Bundesamt fr Sicherheit in der Informationstechnik verffentlichtes Ebenenmodell zur Absicherung von Webanwendungen vorgestellt, dass als Grundlage fr die Entwicklung sicherer Ruby on Rails Anwendungen dienen soll. Die fr die Entwicklung und Bereitstellung von Rails Applikationen relevanten Ebenen werden in Kapitel Drei, Vier sowie Fnf detailliert dargestellt. Hierbei wird auf die Implementierung, die eingesetzten Technologien sowie die Systemebene detailliert eingegangen. Die Schlussbetrachtung vervollstndigt die vorliegende Projektarbeit.

2
2.1

Grundlagen der sicheren Anwendungsentwicklung


Web Application Security

Bevor konkret dargestellt werden soll, wie sichere Webanwendungen mit Ruby on Rails entwickelt und bereitgestellt werden knnen, ist fr ein gemeinsames Verstndnis der Begriff Web Application Security nher zu definieren. Der Begriff IT-Sicherheit an sich wird in verschiedenen Zusammenhngen und Bedeutungen benutzt. Eine einheitliche Definition des Begriffs gibt es daher in der Literatur nicht [5, S. 265]. Fr die Projektarbeit sollen zwei Definitionen des Institute of Electrical and Electronics Engineers gelten, die sich auf die Sicherheit von ITAnwendungen beziehen. ISO/IEC 25010 sowie ISO/IEC 15026 definieren Sicherheit als the protection of system items from accidental or malicious access, use, modification, destruction, or disclosure[6, S. 218]. Im Mittelpunkt der Betrachtung der Sicherheit steht damit der Schutz von Anwendungssystemen vor beabsichtigten oder unbeabsichtigten Zugriff, Modifikation, Zerstrung sowie Verffentlichung. Ebenfalls definiert ISO/IEC 25010 in diesem Zusammenhang, dass der Begriff Sicherheit in die Charakteristiken Authentizitt, Anonymitt, Integritt, Verbindlichkeit, Verfgbarkeit sowie Vertraulichkeit unterteilt werden kann. Fr eine genaue Beschreibung dieser Teilaspekte sei jedoch auf die einschlgige Literatur verwiesen (vergleiche hierzu [5] sowie [6, S. 218]).

Im Gegensatz zur traditionellen IT-Sicherheit spezialisiert sich das Themengebiet Web Application Security auf Anwendungen, welche auf den Technologien des W3Cs basieren und ber einen Webbrowser abgerufen werden knnen [5, S. 2]. Im Vergleich zur traditionellen Application Security erwhnt Kappel, dass die Herausforderungen auf Grund der Charakteristik von Webanwendungen als verteilte Systeme in einem weltweit verfgbaren Netz sich von den traditionellen Anwendungen klar unterscheiden. So kommt als zu schtzender Bereich nicht nur das eigene ITVerfahren in Betracht. Vielmehr wird ein Ende-zu-Ende-Schutz angestrebt, bei dem der Endanwender, der Diensteanbieter sowie die sichere Kommunikation zwischen beiden Kommunikationspartnern [5, S. 266f] umfassend analysiert werden. Besondere Herausforderung des Web Application Securities ist dessen Vernetzung mit zahlreichen, ebenfalls wichtigen Eigenschaften von Webanwendung [7, S. 4]. So wird die Benutzerfreundlichkeit eingeschrnkt, indem die Webanwendung sich nach einer bestimmten Zeit ohne Benutzerinteraktion automatisch beendet oder doppelte Passworteingaben notwendig sind. Auch die Performance wird negativ beeinflusst, da beispielsweise Verschlsselungsalgorithmen die Datenbertragung verlangsamen. Entsprechend ist zu schlussfolgern, dass Grundlage einer systematischen Absicherung von Webanwendungen immer auch eine Abwgung der Vor- und Nachteile sowie eine dazugehrende systematische Risikoeinschtzung sein muss [7, S. 4][1, S. 120]. 2.2 Security Engineering im Software Entwicklungszyklus

Die Praxis zeigt jedoch, dass Termin- und Kostendruck es hufig nicht zuzulassen, eine fundierte Sicherheitsstrategie zu entwerfen [1, S. 121]. Der Penetrationstest kurz vor Inbetriebnahme als einzige sicherheitsgebende Manahme ist nicht ausreichend. Auch ein Big-Bang-Ansatz, bei dem mit massivem Aufwand am Ende der Softwareentwicklung auf einen Schlag all das, was bei der eigentlichen Implementierung versumt wurde, aufgeholt werden soll, ist meist nicht erfolgreich [8, S. 16f]. Ziel des Security Engineering ist es daher, das alle am Entwicklungsprozess beteiligten Personen die Kriterien der sicheren Anwendungsentwicklung als inhrenten Bestandteilen des Lebenszyklus einer Webanwendung verstehen [8, S. 17]. Je frher im Entwicklungsprozess klare Zielsetzungen und Vorgehensmodelle fr die Sicherheit definiert und kommuniziert werden, desto nachhaltiger und gnstiger knnen sichere Anwendungen realisiert werden [1, S. 121]. Jede Phase des Softwareentwicklungszyklus weist dabei Ansatzpunkte fr die Validierung sowie Steigerung der Sicherheit auf [9, S. 17]. Die folgende Darstellung gibt einen berblick ber Manahmen zur Sicherheitsdefinition:
Abbildung 1. Ttigkeiten im Security-Engineering je Entwicklungsphase (in Anlehnung an [1] sowie [9])
Systematische Schulung aller Prozessbebeteiligten Schutzbedarfsfeststellung Missbrauchsszenarien erstellen Risikoanalyse Security by design Code-Review Tooluntersttzung Penetrationstest Fuzzy-Testing Erstellung von Notfallplnen Monitoring Ausfhrung von Notfallplnen regelmige Systemupdates

Fachabteilung / Business Analyse

Entwicklung

Anwendungsbetrieb

Training

Definition

Design

Implementierung

Test

Betrieb

Reaktion

Die Fhigkeit aller am Prozess der Anwendungsentwicklung beteiligten Personen Sicherheitsrisiken einzuschtzen und geeignete Manahmen zu ergreifen, soll durch regelmige Schulungen gewhrleistet werden. Fr die einzelnen Rollen in einem Web-Projekt mssen entsprechend spezifische Schulungen vorgesehen sein [9, S. 7]. Bereits in der Definitionsphase des Projekts mssen dann Einsatz- als auch Missbrauchsszenarien definieren werden. Je klarer bereits in dieser Phase das Bild des potenziellen Missbrauchs ist, desto besser kann der Entwickler im grundlegenden Entwurf der Anwendung darauf reagieren. Zusammen mit den Informationen aus Schutzbedarfs und Risikoanalyse ergibt sich daraus Sicherheit auf Grundlage des Anwendungsdesigns. Spter im Projektverlauf stattfindende Sicherheitsreviews gewhrleisten, dass die so definierten Richtlinien auch eingehalten werden [1, S. 122]. Die Entwicklungsphase knnen Werkzeuge begleiten, die neben der Qualitt auch die Sicherheit erhhen. Grundlage fr die Entwicklung bilden Secure Coding Guidelines [1, S. 122]. Ein Beispiel, wie toolgesttzt die Einhaltung dieser Richtlinien forciert werden kann, zeigt Microsoft. Jedes Dokument durchluft dabei einen Validierungsprozess, der verhindert, dass Quellcode, welcher gegen die Designrichtlinien verstt, eingecheckt werden kann [9, S. 8]. Ein Code Review wre fr kleinere oder nicht so schutzbedrftige Anwendungen sicher ber das Ziel hinausgeschossen [9, S. 12], aber die stichprobenartige oder auf einige neuralgische Punkte beschrnkte gezielte Inspektion von Code-Teilen, zu nennen ist hier insbesondere der Bereich der Datenvalidierung, kann auf effiziente Weise potenzielle Sicherheitslcher frhzeitig ans Licht bringen [1, S. 122]. Penetrationstests sowie Fuzzy-Tests vor der Produktivschaltung schlielich runden diese Manahmen ab. Da niemals die hundertprozentige Sicherheit erreicht werden kann, macht es Sinn, in der Testphase Notfallplne zu erstellen. Klare Anweisungen und Verfahrensweisen sollen Regeln, was passiert, wenn tatschlich Sicherheitslcken entdeckt beziehungsweise bereits ausgenutzt wurden. Der Lsungsprozess soll damit wesentlich beschleunigt werden [9, S. 11]. Fr den Betrieb wichtig ist eine systematische Systemberwachung. Intrusion Detection Systeme knnen hier wertvolle Dienste erweisen. Zustzlich muss auch sichergestellt werden, dass eingesetzte Software immer aktuell bleibt und regelmig Updates eingespielt werden. Wichtig knnen auch Sicherheitshinweise von auen sein. Von Benutzern gefundene Schwachstellen mssen direkt zur Sicherheitsabteilung gelangen [1, S. 122]. 2.3 Ebenen der Sicherheit von webbasierten IT-Verfahren

Eine ganzheitliche Betrachtung der Sicherheitsaspekte einer Webanwendung lsst sich auf unterschiedliche Ebenen durchfhren [10, S. 10]. Eine Unterteilung macht Sinn, da die Anforderungen an die Sicherheitskonzeption sowie Realisierung sich fachlich sowie organisationstechnisch auf den einzelnen Ebenen unterscheidet. Im Hinblick auf eine systematische Herangehensweise verffentlicht das Bundesamt fr Sicherheit in der Informationstechnik ein Ebenenmodell [10, S. 10], welches der Ausgangspunkt der berlegungen fr eine effektive Absicherung von Rails Applikationen darstellen soll. Insgesamt unterscheidet das Ebenenmodell sechs verschiedene Teilebenen.

Tabelle 2. Klassifizierung von Schwachpunkten von Webanwendungen in Ebenen [10, S. 9]

Ebene 5 Semantik

Inhalt und Beispiele Schutz vor Tuschung und Betrug: Informationen ermglichen Social Engineering-Angriffe Gebrauch von Popups erleichtern Phishing-Angriffe Keine Absicherung fr den Fall der Flschung der Website Absicherung von Prozessen und Workflows als Ganzes: Verwendung unsicherer Email in einem gesicherten Workflow Angreifbarkeit des Passworts durch nachlssig gestaltete "Passwort vergessen"-Funktionen Die Verwendung sicherer Passworte wird nicht erzwungen Vermeiden von Programmierfehlern: Cross-Site Scripting SQL-Injection Session Riding Richtige Wahl und sicherer Einsatz von Technologie: unverschlsselte bertragung sensitiver Daten Dem Schutzbedarf angemessene Authentifizierungsverfahren Ungengende Randomness von Token Absicherung der auf der Systemplattform eingesetzten Software: Fehler in der Konfiguration des Applikationsservers Bekannte Fehler in den eingesetzte Softwareprodukten Mangelnder Zugriffsschutz in der Datenbank Absicherung von Host und Netzwerk

4 Logik

3 Implementierung

2 Technologie

1 System

0 Netzwerk und Host

Die semantische Ebene umfasst dabei alle inhalts- und kommunikationsbezogene Aspekte. Sie stellt den Vertrauenskontext fr die Interaktion mit einem Benutzer her. Wird in diesem Bereich nicht ein hohes Ma an Sorgfalt aufgewendet, so kann eine Webanwendung von Dritten missbraucht werden, um einen Benutzer zu tuschen. Dieser Bereich kann selten auf eine einzelne Anwendung beschrnkt bleiben. Vielmehr ist eine Webseiten- oder unternehmensbergreifende Betrachtung notwendig. Zustndig fr die Sicherheitsdefinition in diesem Bereich sind die Fachabteilungen sowie die Geschftszentrale. Meist wird durch ein Corporate Design fr die Entwicklung bereits ein klarer Rahmen vorgegeben [10, S. 10]. Die vierte Ebene betrifft sowohl die Logik der Ablufe innerhalb einer Webanwendung als auch die Interaktion mit dem Benutzer. Ist eine zu zweckorientierte Definition vorgenommen worden, kann dies von Angreifer ausgenutzt werden. Wird etwa zur Verhinderung von Brute-Force Angriffen nach dem fnften fehlerhaften Login-Versuch die entsprechende Benutzerkennung gesperrt, so sind Angriffe denkbar, bei denen Dritte Benutzer gezielt aussperren. Ziel muss es sein, dass in der Pla-

nungs- und Konzeptionierungsphase die definierten Prozesse systematisch auf Missbrauchsszenarien untersucht werden [10, S. 10]. Die Bedeutung der logischen und semantischen Ebene wird vielfach nur unzureichend wahrgenommen. Dennoch haben diese beiden Ebenen eine hohe Bedeutung, wenn man unter der Sicherheit einer Webanwendungen nicht alleine nur den Schutz der auf einem Server bereitgestellten Rails Applikation versteht, sondern wie in Kapitel 2.1 dargestellt, auch den Schutz aller Beteiligten. Auf der Ebene der Logik und der Semantik kommt dieser Aspekt ganz besonders zum Tragen. Die Implementierungsebene umfasst den Bereich der unbeabsichtigten Programmierfehler, aber auch nicht vorhandene oder ungengende Prfung von Eingabedaten. Diese Ebene beinhaltet ferner ungengende Testverfahren und die Vernachlssigung der Qualittssicherung zugunsten der Einhaltung von Meilensteinen beziehungsweise des Projektbudgets. Verantwortlich fr die Herstellung der notwendigen Qualitt in diesem Bereich ist der einzelne Entwickler [10, S. 10]. Die vorletzte Ebene betrifft die Verwendung der fr den jeweiligen Einsatzzweck und Schutzbedarf richtigen Technologie, sowie deren korrekte Nutzung. So zum Beispiel setzt eine Webanwendung, die sensible Daten unverschlsselt ber das Internet transferiert, nicht die richtige Technologie ein. Eine Webanwendung, die Passworte zwar verschlsselt, dafr aber einen zu kurzen Schlssel verwendet, setzt die richtige Technologie falsch ein [10, S. 10]. Die nchste Ebene, auch Systemebene, betrachtet all jene Programme, die fr das Funktionieren der gesamten Webanwendung bentigt werden. Dazu gehren der Webserver und der Applikationsserver, aber auch Datenbank- und Backend-Systeme. Diese Komponenten mssen bei der Sicherheitskonzeption einer Webanwendung mit einbezogen werden [10, S. 10]. Die Ebene von Netzwerk, Server-Hardware und darauf laufendem Betriebssystem wird hem dem Bundesamt fr Sicherheit in der Informationstechnik nicht direkt der Sicherheit der Webanwendung zugeordnet. Diese Ebene schliet sich vielmehr nach unten an. Die Umsetzung grundlegender Sicherheitsmanahmen auf dieser Ebene wird gleichwohl als zwingende Voraussetzung fr sichere Webanwendungen betrachtet [10, S. 10]. Im Mittelpunkt dieser Projektarbeit stehen die Ebenen zwei, drei und vier des Klassifizierungsschemas des BSI. Detailliert dargestellt werden nur diese Phasen, da diese abhngig von der eingesetzten Technologie beziehungsweise den eingesetzten Entwicklungsframework darstellbar sind. Selbstverstndlich mssen bei Webprojekten im Rahmen eines vollstndigen Security Engineering Ansatzes die restlichen Ebenen auch betrachtet werden, jedoch knnen diese generisch und unabhngig von Ruby on Rails umgesetzt werden.

3
3.1

Sicherung der Systemebene


Konfiguration des Webservers

Bevor die sichere Implementierung einer Webanwendung betrachtet wird, ist die zugrundeliegende Infrastruktur vor beabsichtigten sowie unbeabsichtigten Angriffen

abzusichern. Im Rahmen des dritten Kapitels wird dieser Bereich insofern detailliert betrachtet, dass die Spezifika von Rails Anwendungen herausgearbeitet werden. Der Webserver nimmt als Kontaktpunkt mit dem Benutzer hierbei eine wichtige Rolle ein. Zum Entwickeln und Testen bietet sich der zum Ruby-Paket gehrende Webserver WEBrick als Applikationsserver an. Fr den produktiven Einsatz wird hingegen abgeraten, diesen einzusetzen, bietet er doch eine zu schlechte Performance sowie nur geringe Konfigurationsmglichkeiten. Empfohlen wird fr den Einsatz in Produktivumgebungen ein mchtiger Server wie der Apache HTTP Server, NGINX oder Lighttpd. Voraussetzung zur Anbindung eines Webservers an Ruby on Rail ist die Untersttzung von FastCGI oder traditionelles CGI. Eine relativ moderne Form, die in den Foren immer weitere Popularitt erfhrt, ist Phusion Passenger. Dies auch als mod_rails bezeichnete, eine proprietre Schnittstellentechnologie die vor allem das Deployment von Webseiten wesentlich vereinfacht. Grundstzlich ist jeder der oben genannten Webserver immer in Bezug auf Benutzerkennung, Zugriffsrechte auf Prozesse, Verzeichnisse und Dateien, Fehlerausgaben und Protokollierung sicher zu konfigurieren. Folgende Tabelle kann eine sehr gute bersicht ber die durchzufhrenden Rechte haben [10, S. 9]:
Tabelle 3. Berechtigungskonfiguration des Webservers am Beispiel Apache HTTP [11, S. 25]

Zu schtzendes Objekt Binrverzeichnisse des Servers Binrdateien, beispielsweise httpd Konfigurationsverzeichnisse-/dateien Logverzeichnisse-/dateien Verzeichnis der Rails Applikations, normalerweise in /var/www/ Rails Log- und Temporre Verzeichnisse und Dateien

Besitzer (user:group) root:root root:root root:root root:root apache:apache apache:apache

Rechte 755 (rwxr-xr-x) 511 (r-x--x--x) 755 (rwxr-xr-x) 700 (rwx------) 500 (r-x------) 700 (rwx------)

Wie in der Tabelle herausgestellt wird, sollen als Besitzer der allgemeinen Systemverzeichnisse der Root-User verantwortlich sein. Jedoch ist fr die Ausfhrung des Webservers ein eigener Benutzer zu definieren. Dieser soll nur die zwingend fr die Ausfhrung der Webapplikation notwendigen Rechte aufweisen, so dass eine Sicherheitslcke im Kontext der Webanwendung anschlieend nur geringe Auswirkungen auf das Gesamtsystem hat. 3.2 Konfiguration der Datenbank

Die meisten Webanwendungen haben die Anforderung, eine Vielzahl an Daten anzuzeigen, zu erfassen, zu verarbeiten und je nach Anforderung auch zu lschen. Datenbanken, die fr diesen Zweck eingesetzt werden, knnen in Ruby on Rails genau zu diesem Zweck mit Hilfe des objektrelationalen Mapper ActiveRecord angesprochen werden. Das Release 3.0 von Ruby on Rails ermglicht zudem, alternative objektrelationale Mapper wie Sequel oder DataMapper zu nutzen [12]. Jeder einzelne Objektrelationale Mapper bietet darber hinausgehend wiederum Untersttzung fr eine Viel-

zahl an Datenbanksysteme wie MySQL, IBM DB2, CouchDB und viele mehr an. Beispielhaft soll auf die weit verbreitetste Kombination in Ruby on Rails, ActiveRecord in Kombination mit MySQL, nher eingegangen werden. Eine sichere Konfiguration von Datenbanken erfordert laut dem Bundesamt fr Sicherheit in der Informationstechnik, dass einerseits die generellen Regelungen zur Ausfhrung von Diensten eingehalten werden mssen. Zustzlich sollen speziell fr Datenbanken Benutzerkennungen sowie Zugriffsrechte auf Datenbanken, Tabellen, Stored Procedures sowie Tabelleninhalte sicher konfiguriert werden [10, S. 87]. Diensteeinrichtung. Verzeichnisse und Dateien des Datenbankservers MySQL mssen so eingerichtet sein, dass nur autorisierte Benutzer Zugriff auf das System haben. Zu empfehlen ist hierbei, dass pro eingerichteten Dienst auf einem Computer jeweils ein eigener Benutzer inklusive Zugriffsgruppe konfiguriert wird. Dies verhindert, dass ein Sicherheitsproblem in einer Anwendung Auswirkungen auf andere ebenfalls auf dem System laufende Dienste hat [10, S. 75]. Idealerweise ist es daher so, dass fr die Ausfhrung der Datenbank ein Benutzer, beispielsweise mit der Bezeichnung MySQL inklusive der Benutzergruppe MySQL eingerichtet wird. Nach Installation von MySQL sollen die Berechtigungen fr Verzeichnisse inklusive Konfigurationsdateien so vergeben werden, dass nur Benutzer der Gruppe MySQL lesen sowie schreibend zugreifen knnen. Ein sicheres Passwort fr den Benutzer MySQL versteht sich dort selbstverstndlich. MySQL sollte anschlieend ber das Konfigurationsskript als Dienst eingerichtet werden, und in einem weiteren Schritt so konfiguriert sein, dass er vom Benutzer MySQL ausgefhrt wird. Benutzerkennungen und Zugriffsrechte. Nach der Installation von MySQL sind mehrere potentiell unsichere Einstellungen zu bereinigen. Dies kann automatisiert mit Hilfe des Skripts mysql_secure_installation.pl im Verzeichnis ./bin/ erfolgen [13]. Dieses Skript lscht einerseits die standardmig vorhandene Testdatenbank. Zustzlich werden alle Datenbankzugnge entfernt, die ein anonymes Einloggen ermglichen wrden. Fr den Root-Zugang muss zustzlich ein Passwort bestimmt werden. Zustzlich weit Webers darauf hin, dass der Benutzer Root umbenannt werden sollte, um Brute-Forcing Angriffe zu verhindern [11, S. 47]. Mit Hilfe des Befehls: Update user SET user="dbadmin" WHERE user="root"; Anschlieend ist fr die Anbindung der auf Rails basierenden Webapplikation ein eigener Rails-User mit eingeschrnkten Zugriffsrechten aufzusetzen. Anstelle der Berechtigung, uneingeschrnkt auf die Datenbank zuzugreifen, werden nur die Rechte dem Benutzer zugestanden, die blicherweise bei der Verarbeitung von Webanwendungen bentigt werden [11, S. 47]. Folgender Befehl setzt die korrekten Werte: CREATE USER 'Rails'@'localhost' IDENTIFIED BY '%QW83XZ'; GRANT DELETE, INSERT, SELECT, UPDATE ON RAILS_DEV.* TO 'rail'@'localhost';

Wird Rake fr die Ausfhrung von Migrationsskripten verwendet, kann ein entsprechend zweiter User konfiguriert werden, der Rechte fr die Erzeugung, Lschung und nderung von Datenbanktabellen hat. 3.3 Einsatz von Anwendungsfirewalls

Neben der Tatsache, dass auch bei der Weiterentwicklung der Anwendung eine inhrente Sicherheitsstrategie verfolgt werden muss, ist es meistens technisch sowie finanziell bei bestehenden Anwendungen schwer mglich, diese sicherheitstechnisch auf dem aktuellen Stand zu bringen. Einen mglichen Ausweg aus diesem Konflikt bieten hufig so genannte Web Application Firewalls [14, S. 52]. Diese wird auf dem Server zwischen der Kommunikation des Browsers mit der Webanwendung geschaltet und ist damit fr die Webanwendung vollkommen transparent [14, S. 52]. Idee dieser Firewalls ist es, direkt auf dem HTTP-Datenstrom zugreifen zu knnen, um schadhafte Inhalte und Muster zu erkennen und diese entsprechend herauszufiltern. Fortgeschrittene Produkte gehen hierbei noch einen Schritt weiter und immunisieren HTTP-Anfragen und -Antworten durch Verschlsselung sensibler Inhalte oder durch das Hinzufgen von Sicherheitsmerkmalen [14, S. 52]. Das fr den Apache-Server und damit ebenfalls fr Ruby on Rails Anwendungen relativ verbreitete Modul mod_security greift zu diesem Zweck auf eine Rules-Engine zurck, die neben vordefinierten, frei zugnglichen Algorithmen auch das Hinzufgen von neuen Beschrnkungen erlaubt. Die Definition von Regeln mit mod_security wird dabei immer nach folgendem Prinzip durchgefhrt: SecFilter AUSDRUCK [AKTION] Sollte ein bestimmter Filter zutreffen, werden die zugehrigen Aktionen zur Ausfhrung gebracht. Aktionen reichen dabei von der Ablehnung der Benutzeranfrage ber Programmaufrufe bis hin zu umfangreichen Fluss-Aktionen, welche die weitere Prfung der einzelnen Filter beeinflussen knnen [15, S. 2]. Wichtig beim Einsatz von Web Application Firewalls ist die Tatsache, dass Sie einen zustzlichen Schutz fr Webanwendungen bieten knnen, jedoch auf keinen Fall einen Ersatz fr die sichere Anwendungsentwicklung, wie Sie beispielsweise in Kapitel 5 beschrieben ist [10, S. 13]. Fr alle Bereiche, die sich jedoch verallgemeinern und auslagern lassen, bieten Web Application Firewalls eine sinnvolle Mglichkeit, um Entwicklungsdauer und -kosten, auch bei neu zu entwickelnden Anwendungen [10, S. 13], positiv zu beeinflussen [14, S. 52].

4
4.1

Sicherung der Technologieebene


Verschlsselung der HTTP-Kommunikation

Secure Sockets Layer ist ein Protokoll zur sicheren Kommunikation zwischen Client und Server. Es ermglicht eine hybride Verschlsselung der Verbindungsinhalte, gewhrleistet die Vollstndigkeit und Korrektheit der bertragenen Daten und bietet darber hinaus auch die Mglichkeit der Identittsprfung aller beteiligten Parteien durch Verwendung von Zertifikaten [16, S. 3546]. SSL setzt fr den Zugriff auf das

TCP-Protokoll auf und kann daher fr eine Reihe von Anwendungsprotokollen genutzt werden. Fr die Einrichtung von SSL zur Absicherung des HTTP-Protokolls sind folgende Schritte durchzufhren [16, S. 3546]: 1. Erzeugung eines privaten Schlssels fr die Zertifikatsgenerierung 2. Erzeugung eines Certificate Signing Requests 3. Beantragung eines Zertifikats bei einer Certificate Authority 4. Konfiguration des Webservers zur Kommunikation via SSL 5. Anpassung der Rails Applikation fr die Nutzung von SSL Fr die zur Zertifikatserstellung notwendigen Schritte eins bis drei sei an dieser Stelle auf die einschlgige Literatur verwiesen (siehe hierzu beispielsweise [17]). Diese Schritte knnen unabhngig von dem genutzten Anwendungsframework und damit Ruby on Rails vorgenommen werden. Auch die Konfiguration des eingesetzten Webservers ist nicht generell fr Ruby on Rails darstellbar, wichtige Grundlage jedoch fr die Anbindung von Rails. Da bereits in Kapitel 3.1 die sichere Konfiguration des Webservers Apache vorgestellt wurde, wird an diesem Anwendungsfall angeknpft. Fr die Nutzung von SSL in einem Apache Server kann das Modul mod_ssl in Kombination mit der Bibliothek OpenSSL genutzt werden. Im Standard hrt der Apache Webserver auf den Port 80, um eingehende HTTP-Verbindungen zu ermitteln. HTTPS verwendet jedoch Port 443, so dass eine Erweiterung der Konfigurationsdatei httpd.conf durchgefhrt werden muss [17]: <VirtualHost *:443> Include conf/apps/domainname.conf.common SSLEngine On SSLCipherSuite RSA:!EXP:!NULL:+HIGH:+MEDIUM:-LOW SSLCertificateFile conf/domainname.com.crt SSLCertificateKeyFile conf/domainname.key RequestHeader set HTTP_X_FORWARDED_PROTO 'https' </VirtualHost> Hierbei wird ein zustzlicher VirtualHost aufgenommen. Durch die Angabe von *:443 wird definiert, dass unabhngig der Ziel IP-Adresse alle Anfragen auf dem Port 443 im Rahmen dieses Hosts verarbeitet werden sollen. Im obigen Beispiel wurde durch eine Include-Anweisung die Konfiguration des Webservers, das heit beispielsweise die Anbindung von Phusion Passenger sowie optionale mod_rewrite Regeln, ausgelagert. Dies macht bei einem Parallelbetrieb von HTTPS sowie HTTP Sinn, da die gleiche Konfigurationsdatei dann auch im Virtuellen Host Eintrag von HTTP verwendet werden kann. Anschlieend erfolgt die Konfiguration von SSL. Neben der Definition, dass die SSLEngine fr diesen Eintrag genutzt werden soll, werden auch die zu verwendenden Verschlsselungsalgorithmen definiert. Zustzlich ist mit Hilfe von SSLCertificateFile sowie SSLCertificateKeyFile der Ablageort des Zertifikats sowie der private Schlssel festzulegen [17]. Der letzte Konfigurationsparameter ist von besonderer Bedeutung. Mit Hilfe von RequestHeader set HTTP_X_FORWARDED_PROTO 'https' wird jedem HTTPRequest ein zustzlicher Parameter hinzugefgt, so dass die Information, ob die Anfrage per HTTP oder HTTPS gestellt wurde, in Ruby on Rails ausgewertet werden

kann. Dies ist besonders dann sinnvoll, wenn nicht die gesamte Webanwendung per HTTPS bereitgestellt werden soll, sondern nur die Bestandteile, die wirklich schtzenwert sind. Klar ist, dass die Ver- und Entschlsselung sowie das komplizierte Handshacking die Webanwendung insgesamt verlangsamt [18]. Mit der Version 3.1 von Ruby on Rails ist implizit die Middleware-Komponente Rack::SSL zur Anbindung von HTTPS integriert. Alternativ kann fr Applikationen basierend auf Ruby on Rails kleiner als 3.1 dieses Plug-in manuell eingebunden werden [19]. Unter Nutzung dieser Komponente ist es mglich, aufbauend auf den im Apache vorgenommenen Konfigurationen, die Verwendung von SSL durch den Client vorauszusetzen. Eine solche Konfiguration kann einerseits in der Datei config/application.rb stattfinden, so dass anschlieend Anfragen alleinig per SSL ermglicht werden. Soll der Einsatz von SSL jedoch granularer geschehen, so ist es zustzlich mglich, auch auf Ebene der einzelnen Controller beziehungsweie Aktionen eine Definition durchzufhren [19]. # Erweiterung der Datei config/application.rb config.force_ssl = false # Anpassung der einzelnen Actions class ForceSSLController < ActionController::Base force_ssl :except => :index def index ... end Ergebnis der Konfiguration ist, dass Anfragen, falls nicht per HTTPS gestellt, umgeleitet werden. Bei der Verwendung von SSL ist herauszustellen, dass wie bei jeder greren nderung der Serverkonfiguration ein umfangreicher Applikationstest notwendig wird. So sind Seiteneffekte, beispielsweise bei der Einbindung von externen Inhalten zu erwarten. So warnt beispielsweise der Internet-Explorer davor, wenn nicht-geschtzter Inhalt in eine HTTPS Seite eingebunden wird. Ebenso sind AJAXbasierte Komponenten nicht nutzbar, wenn sie nicht ebenfalls ber HTTPS zur Verfgung stehen [17]. 4.2 Verschlsselung bei Nutzung einer Datenbank

Wie in Kapitel 3.2 dargestellt knnen Manahmen auf Systemebene ergriffen werden, um Datenbanken vor unberechtigten Zugriffen zu schtzen. Die hundertprozentige Sicherheit, dass Unberechtigte den Zugriff auf die Datenbank nicht doch erhalten, kann jedoch nie ausgeschlossen werden. Aus diesem Grund macht es Sinn, Daten, die einen zustzlichen Schutz bedrfen, zustzlich verschlsselt zu speichern. So schreibt beispielsweise der ein von vielen Kreditkarteninstituten untersttzte PCI DSS Standard klare Regelungen vor, wie Kreditkarteninformationen zu verarbeiten sind [20]. Eine verschlsselte Ablage dieser sensiblen Informationen wird explizit gefordert. Generell kann bei der Verschlsselung von Datenbankzugriffen unterschieden werden zwischen der Verschlsselung der in einer Datenbank gespeicherten Informationen sowie der Verschlsselung von Daten whrend der bertragung zwischen Datenbank und Applikationsserver.

Verschlsselung von Datenbankinhalten. Fr die Verschlsselung einzelner Feldinhalte auf Datenbankebene ist eine besonders elegante Methode das GEM attr_encrypted. Anstelle selbststndig die Ver- und Entschlsselung in eigenen Funktionen bereitzustellen, wird nach Installation dieses GEM die Mglichkeit gegeben, direkt im Model der Anwendung durchgngig zu definieren, welche Spalten verschlsselt werden. Dies wird ber attr_accessors geregelt [21]. Folgende Definition wrde zur Verschlsselung von Kreditkartendaten in der Datenbank fhren: class CreditCar < ActiveRecord::Base attr_accessible :creditcardnumber, :limit attr_encrypted :creditcardnumber :key => 'SECURE_KEY' end Alle Datenbankzugriffe auf die Spalte creditcardnumber erfolgen nun verschlsselt. Selbst wenn der Anwender Zugriff auf die Datenbank htte, wrde er damit keine Mglichkeit besitzen, an die geschtzten Inhalte zu gelangen. Fr die Verschlsselung der Feldinhalte setzt attr_encrypted auf OpenSSL auf und untersttzt damit eine groe Anzahl von Verschlsselungsalgorithmen. In der Vorkonfiguration ist dies AES 256 [21]. Wesentlicher Vorteil von attr_encrypted ist die Transparenz fr den Anwendungsentwickler. In der Programmierung unterscheiden sich geschtzte Feldinhalte nicht von ungeschtzten Feldinhalten. Mit den Standard Accessor wird der Klartext zurckgegeben, erst mit Verwendung von encrypted_password kann auch der verschlsselte Feldinhalt abgefragt werden. Damit ist auch die Grundlage geschaffen, bestehende Applikationen hierdurch zu schtzen. Verschlsselung der Datenbertragung. Der zweite Aspekt, nmlich die verschlsselte Datenbertragung zwischen Datenbank und Applikationsserver, ist mit Hilfe von Rails im Standard ebenfalls mglich. Voraussetzung hierfr ist, dass sowohl die Datenbank wie auch der eingesetzte Datenbankadapter die Verschlsselung untersttzt. Beides ist bei der Verwendung von MySQL und ActiveRecord gegeben. Weiter ist festzustellen, dass eine Verschlsselung der Datenkommunikation zwischen Applikationsserver und Datenbankserver nur dann sinnvoll ist, wenn die Kommunikation ber ffentliche Netzwerke erfolgt. Sollte der Datenbankserver sowie die Applikationsserver in einem gemeinsamen geschtzten Rechennetz sich befinden beziehungsweise auf einen gemeinsamen Server betrieben werden, so ist auch kein weiterer Schutz notwendig. Fr die Verschlsselung der Datenkommunikation wird das in Kapitel 4.1 bereits vorgestellte SSL Protokoll eingesetzt. Um SSL zu nutzen muss einerseits der Datenbankserver fr die Kommunikation via SSL vorbereitet werden, andererseits aber auch die Rails-Applikation erweitert werden. Fr die Anpassung der RailsApplikation mssen die Konfigurationseinstellungen zum Zugriff auf die Datenbanken in der Datei ./config/Database.yml erweitert werden [22].

sslca: /path/to/rails/app/db/cacert.pem sslkey: /path/to/rails/app/db/mysql-client-key.pem sslcert: /path/to/rails/app/db/mysql-client-cert.pem Hierdurch wird den Datenbankadapter einerseits mitgeteilt, was der ffentliche Schlssel der MySQL Datenbank ist sowie die Zertifikate fr die Certification Authority sowie das Zertifikat des Clients bekannt gegeben. Fr die Anpassung des Datenbankservers MySQL zur Untersttzung von SSL sei auf die einschlgige Literatur verwiesen (vergleiche beispielsweise [23]). Ein weiterer wesentlicher Vorteil dieser Konfiguration ist, dass Angreifer ohne Kenntnis der Verschlsselungsparameter nicht in der Lage sind, eine erfolgreiche Verbindung aufzubauen. Ein zustzlicher Schutz vor Kompromittierung eines Datenbankservers ist damit erzielbar. 4.3 Usermanagement

In nahezu jedem Projekt ist es notwendig, ein Benutzer- und Rechtekonzept zu pflegen und zu warten. Da unterschiedlichste Anforderungen hinsichtlich Umfang sowie Komplexitt dieses Themenbereichs existieren, kann keine Einheitslsung vorgestellt werden. Eine Vielzahl an Plug-Ins wie das sehr bekannte Authorization_Plugin (https://github.com/DocSavage/rails-authorization-plugin/) aber knnen im Internet gefunden und je nach Projektanforderung genutzt werden. Nichts desto trotz bietet Rails und hier vor allem Versionen grer als 3.1 ebenfalls Mglichkeiten, dieses Thema bereits im Standard effektiv anzugehen. Die einfachste Mglichkeit einen Schutz einzelner Programmbestandteile sicherzustellen wird in Rails durch die Methode http_basic_authenticate_with geboten. Diese kann im Kopf eines jeden Controllers eingesetzt werden, und fordert bei Aufruf dem Benutzer dazu auf, sich entsprechend am System zu authentifizieren [24]: http_basic_authenticate_with :name => "User", :Password => "Po Als Grundlage fr die Authentifizierung wird dabei das im RFC 2617 spezifizierte Basic- und Digest-Authentifizierungsverfahren verwendet [24, 25]. Eine weit elegantere Mglichkeit, die neu in Rails 3.1 hinzugekommen ist, stellt die Methode has_secure_password dar, die in Klassen abgeleitet vom Typ ActiveRecord::Base bereitsteht [26]. Voraussetzung fr die Verwendung ist, dass ein Model erstellt wird, dass eine Spalte mit der Bezeichnung password_digest aufweist. Folgender Befehl erstellt eine Tabelle fr Benutzer: Rails g model user email:string password_digest:string Im so erzeugten Model kann anschlieend definiert werden, dass in dem entsprechenden Feld ein geschtztes Passwort abgespeichert wird: class User < ActiveRecord::Base has_secure_password validates :password, :presence => { :on => :create } end

Die Auswirkungen dieser nderung sind umfassend. Konkret wird durch diese Definition folgende Elemente festgelegt [26]: 1. Neuer Attr_Accessor :password 2. Confirmation Validator auf dem Attribut :password 3. Presence Validator auf dem Attribut :password 4. Automatische Verschlsselung des Attributs :password durch Nutzung von bcryptruby falls :password gesetzt wird 5. Neue Methode authenticate, welche eine berprfung des unverschlsselten Passworts ermglicht. Anschlieend kann im Controller ber Anfrage von user.authenticate(params[:password]) die Korrektheit der Benutzereingabe berprft werden. Durch diese neu geschaffenen Mglichkeiten lassen sich Authentifizierungskonzepte auch ohne die Einbindung von Drittsoftware relativ einfach umsetzen. 4.4 Schutz von Cookie-Informationen

Mit einem Cookie kann man auf dem System des Web-Browsers Informationen in Form von Strings als Schlssel-Wert-Paaren speichern, die der Webserver vorher an diesen Browser geschickt hat. Die Informationen werden spter im HypertextTransfer-Protocol-Header wieder vom Browser an den Server geschickt [5]. Der Zugriff auf Cookies erfolgt in Rails mit der Klasse ActionController#cookies [27]. Cookies sind grundstzlich als nicht vertrauenswrdig und damit als unsicher einzustufen. Ein Benutzer ist in der Lage, die auf dem Client gespeicherten Informationen nach seinen Wnschen zu manipulieren, und damit dem Server falsche Informationen vorzutuschen. Rails bietet genau fr diese Problematiken ab Version 3.0 die Mglichkeit von signierten und verschlsselten Cookies, welche in diesem Kapitel nher betrachtet werden. Grundstzlich wird bei Nutzung der Cookies-Variable ein Session-Cookie angelegt, das auch nur solange verfgbar ist, wie der Browser geffnet ist [27]. Mit Beendigung der Session sind damit alle im Cookie gespeicherten Informationen verloren. In Rails 3 wird der Prozess der Erstellung dauerhafter Cookies beziehungsweise signierter Cookies vereinfacht. Folgendes Code-Beispiel stellt die entsprechende Verwendung dar: # Setzen von Cookies mit einer Laufzeit von 20 Jahren Cookies.permanent[:last_product_id] = @product.id # Setzen signierter Cookies Cookies.signed[:last_product_id] = @product.id Der Vorteil von signierten Cookies ist, dass eine Manipulation der Cookies durch die Anwender weitestgehend ausgeschlossen ist, da eine implizite Prfung auf Korrektheit der Signatur angewandt wird. Zur Verschlsselung wird auf die Konfigurationsdatei config/initializers/secret_token.rb zugegriffen. Diese Datei wird inklusive des Geheimnisses Initial bei der Erstellung eines Rails-Projekts generiert. Die Methode signed kann auch fr permanente Cookies genutzt werden [27].

5
5.1

Sicherung der Implementierungsebene


Session Management

Session Management in Ruby on Rails. Wie das BSI feststellte, ist das Session-Management eine der wichtigsten und problematischsten Stellen der Sicherheit von Webanwendungen [10, S. 40]. Grundstzlich wird dieses bei Webanwendungen notwendig, um seitenbergreifend den Zustand eines Benutzers nachverfolgen zu knnen. Anwendungsgebiete fr das seitenbergreifende Speichern von Inhalten sind vielfltig, beginnend bei einem Benutzernamen bis hin zu bei eShops eingesetzte Warenkrbe. Idee des Session-Managements ist es, dass mit der ersten Anfrage des Clients an die Webapplikation ein Sitzungsschlssel erzeugt wird. Dieser wird bei jedem neuen Kontaktversuch mit dem Server ebenfalls bertragen, so dass eine eindeutige Zuordnung einer Anfrage zu einem Benutzer sowie dessen Datenkontext mglich ist. HTTP als zustandsloses Protokoll wird mit Hilfe des Session-Managements so zu einem zustandsbasierten Verfahren [5, S. 114]. Die folgende Darstellung zeigt die Initialisierung von Sessions durch Clients:
Abbildung 4. Zuweisung von Sessions zu Clients

:Client
Initiale Serveranfrage

:Server

Antwort mit Session Id = H9KYPgh bertragung Session Id = H9KYPgh bei jeder weiteren Anfrage

Erzeuge Session mit Id = H9KYPgh

Ein positiver Seiteneffekt der Generierung des Session-Konzepts ist die Tatsache, dass es sehr einfach dadurch ist, die Authentifizierung des Benutzers am System festzustellen. Anstelle der bei jeder Seitenanfrage neuen Eingabe der Benutzerinformationen, dient die zu einem Client zugewiesene Session-Id implizit auch als Authentifizierungstoken [5, S. 114]. Rails 3.0 bernimmt in der Standardkonfiguration das Session-Management vollstndig und fr den Anwendungsentwickler weitgehend transparent. Hierfr generiert Rails einen so genannten Session Identifier, der sowohl am Server wie auch am Client als Cookie mit der Bezeichnung _session_id gespeichert wird. Der von Rails generierte Session Identifier setzt sich zusammen aus einem 32 Byte langen MD5 Hash des aktuellen Datums sowie der aktuellen Zeit, einem konstanten Wert, der Prozess Id des Interpreters sowie einem zufllig gewhlten Wert zwischen 0 und 1 [11, S. 9]. Zum Zeitpunkt der Erstellung der Projektarbeit kann die von Rails vergebene Session Id als sicher angesehen werden. Der MD5 Hashwert ist grundstzlich mittlerwei-

le als unsicher einzustufen [28, S. 1ff], da die Kollisionsresistenz des Algorithmus nicht mehr gegeben ist. Diese Schwche hat jedoch keine Auswirkung auf die Sicherheit des in Ruby on Rails verwendeten Session-Konzepts, da die Kollisionsresistenz bei der Erzeugung eines eindeutigen Authentifizierungstoken nicht relevant ist [11, S. 9]. Fr den komfortablen Zugriff auf die zu einer Session zugeordneten Inhalte hlt Rails die Session-Variable bereit. In Ruby on Rails kann mit folgenden Befehlen auf den Session-Kontext zugegriffen werden: # Speicherung der eindeutigen Id des Benutzers session[:userid] = user.id # Ermittle den Userdatensatz ausgehend von der # in der Sessionvariablen gespeicherten User Id @user = User.find(session[:userid]) Die Session-Variable kann grundstzlich alle Arten von Objekte aufnehmen. Inhalte der Session-Variable werden in Ruby on Rails in einem so genannten Session Storage gespeichert. Die Auswahl des Session Storage hat Auswirkungen auf die maximal abspeicherbare Datengre, auf das Speicherungsverfahren sowie auf die Sicherheit der Webanwendung. Zur Verfgung dienen standardmig die Klassen ActiveRecord::SessionStore, ActionDispatch::Session::CookieStore [11, S. 11] sowie ActionDispatch::Session::CacheStore. Die Einstellung, welche Art von Session-Store genutzt wird, kann in der Datei config/initializers/session_store.rb definiert werden. Hierfr sind folgende Einstellungen vorzunehmen: # Use the database for sessions instead of the cookie# based default, which shouldnt be used to store highly # configdential information (create the session table # with script/rails g session_migration) App::Application.config.session_store :active_record_store Wie bereits der Kommentar innerhalb der Datei session_store.rb andeutet, sollte bei der Nutzung des Cookie Stores sichergestellt werden, dass vertrauliche Informationen nicht innerhalb des Session-Objekts abgespeichert werden. Da bei diesem Verfahren alle Inhalte der Session-Variable unverschlsselt in einem Cookie auf dem Client gespeichert werden [11, S. 11], sind Inhalte von Angreifern auslesbar. Bei der Nutzung des CacheStores hingegen werden die Inhalte der Session-Variable nicht auf dem Clientsystem gespeichert, sondern im Cache des Servers. Bei der Nutzung des Active_Record_Store werden die Inhalte in der Anwendungsdatenbank gespeichert [29]. Session Hijacking. Die implizite Verwendung der Session-Id zur Authentifizierung eines Benutzers am System ist sicherheitstechnisch kritisch. Hat ein Angreifer Kenntnis einer aktuell von einem Benutzer verwendeten Session-Id, so erhlt dieser implizit auch Zugang zu einer Webanwendung inklusive der mit dem Benutzerkontext einhergehenden Rechte [11, S. 9].

Zur Erlangung der Session-Id eines Benutzers gibt es eine groe Anzahl an Angriffsformen. Eine erste Mglichkeit stellt das Abhren des Netzwerkverkehrs zwischen Client und Server dar. Wird eine Kommunikation zwischen Client und Server unverschlsselt vorgenommen, knnen auch bertragene Session-Ids ausgelesen werden und fr einen Angriff genutzt werden. Um diese Mglichkeiten zu vermeiden, knnen wie bereits in Kapitel 4.1 dargestellt, eine Verschlsselung der Datenkommunikation eingefhrt werden. Um weitergehend sicherzustellen, dass die Session-Id immer verschlsselt bertragen wird, knnen in der Datei conig/environment.rb folgende Anpassung vorgenommen werden [30]: # Session-Austausch nur ber HTTPS erlauben ActionController::Base.session_options[:session_secure]= true Neben dem sicheren Austausch der Session-Id an sich bietet die Verknpfung dieser mit weiteren Merkmalen, wie beispielsweise der IP-Adresse des Systems eine Mglichkeit zur Sicherung der Session [11, S. 9f]. Anfragen eines Rechners mit nicht zur Session zugeordneten Adressen knnen so erkannt und abgelehnt werden. Problematisch bei diesen Vorgehen ist jedoch, dass viele Anwender beispielsweise geschtzt durch Proxy-Server auf die Webanwendung zugreifen, so dass mglicherweise einige Anwender gar nicht oder nur eingeschrnkt die Webanwendung nutzen knnen. Eine weitere Mglichkeit zur Erlangung einer gltigen Session-Id besteht darin, alle mglichen Kombinationen systematisch auszuprobieren, bis eine aktuell aktive Session-Id gefunden wird [11, S. 9]. Diese in der Praxis auch als Brute-Forcing bezeichnete Angriffsform hat in der Praxis jedoch keine Relevanz. Die Anzahl der mglichen Kombinationen an Session-Ids ist zu gro, um einen effektiven Angriff ber das Anwendungsprotokoll HTTP zu erlauben. Fr die Generierung des Session Keys verwendet wie bereits oben dargestellt Ruby on Rails eine Kombination aus mehreren Werten. Whrend dieser Session-Key je nach verwendeter Systemeinstellung vor der Verschlsselung mit MD5 77 bis 85 Bytes umfasst, stellen nur 24-32 Bytes wirklich generische Werte dar. Die generischen Bestandteile wie die Uhrzeit, die Zufallszahl sowie die Prozess-Id sind weitergehend nur Nummern, so dass auch hier der Ergebnisraum weiter eingeschrnkt werden muss. Somit ist die Anzahl an mglichen Werten fr einen Angreifer zwischen 1024 1032 im Rahmen eines Brute-Forcing Angriffs zu prfen [31, S. 53]. Zusammenfassend lsst sich feststellen, dass der Ergebnisraum, auch unter Beachtung der Schwchen von MD5 sowie der verwendeten Generierungsalgorithmen, aktuell ausreichend ist, um Bruteforcing zu verhindern. Session Fixation. Anstelle die Session-Id eines Benutzers zu ermitteln, versucht der Angriff der Session-Fixation den Sessionschlssel vor der Anmeldung am System den Benutzer vorzugeben [11, S. 13]. Hierzu lsst sich der Angreifer im ersten Schritt von der anzugreifenden Webanwendung eine gltige Session-Id zuweisen. Dies geschieht wie oben beschrieben mit dem ersten Aufruf einer Rails-basierten Webanwendung. Anschlieend versucht der Angreifer die so erhaltene Session-Id dem Opfer zuzuweisen. Die Zuweisung erfolgt auf dem Client-Rechner zumeist mit JavaScript. Mglichkei-

ten, dem Anzugreifenden eine solchen Java-Script Code unterzuschieben, knnen mit Cross-Site-Scripting oder anderen Angriffsformen erfolgen. <script> document.cookie="session_id=167832d6206b60f22a03c8d9"; </script> Gelingt es dem Angreifer, die oben dargestellte Code-Zeile auf dem Client-Rechner zur Ausfhrung zu bringen, benutzen sowohl Angreifer wie auch Opfer den gleichen Session-Kontext. Sollte sich der Anwender nun an die Anwendung anmelden, gehen auf dem Angreifer alle Rechte des Angemeldeten ber. Der Angriff war damit erfolgreich. Eine einfache Mglichkeit um das Problem der Session Fixation zu lsen, kann erfolgen in dem wie bereits im vorgehenden Kapitel dargestellt in einer Session selbst weitergehende userspezifische Inhalte wie die IP-Adresse des Aufrufenden zu speichern und diese dann bei jeder Serveranfrage zu validieren. Auch hier ist wiederum mit Zugriffsproblemen bei Anwender zu rechnen, die Proxy-Server fr den Zugriffnutzen. Zustzlich wrde das Problem entstehen, dass regulren Anwendern in dem Moment der Zugriff auf die Anwendung verwehrt wird [11, S. 14]. Die zweite und weit elegantere Mglichkeit Session Fixation zu vermeiden ist nach der Anmeldung durch den Benutzer diesen automatisiert eine neue Session Id zuzuweisen [11, S. 14]. Dies kann durch die Anweisung reset_session, durchgefhrt nach der erfolgreichen Authentifizierung des Benutzers am System, erfolgen. Geflschte Sessions werden damit ungltig, der Angreifer hat niemals die Mglichkeit an die Benutzerrechte des regulren Angreifers zu kommen, da die Zuweisung einer Session-Id per JavaScript nach Anmeldung zerstrt wird. Session Expiry. Ein wichtiges Thema, dass bergreifend fr das Session-Management betrachtet werden muss, ist der Verfall von Sessions. Je lnger Sessions gltig bleiben, desto grer ist auch die Gefahr eines erfolgreichen Angriffs. Ziel muss es sein, bei der Verfallszeit von Sessions einen Kompromiss zwischen Sicherheit aber natrlich auch Benutzerfreundlichkeit zu erreichen. Eine erste Mglichkeit, automatisiert Sessions zu beenden, ist das Setzen von einem Verfallsdatum des Session-Cookies. Dies ist jedoch als problematisch anzusehen, da auch hier die Mglichkeit der Manipulation durch den Benutzer besteht [31, S. 52]. Besser ist, Sessions auf dem Server zu beenden [31, S. 52]. Da Ruby on Rails keinen standardisierten Mechanismus hierfr bietet, sind je nach eingesetzten SessionStorage-Verfahren unterschiedliche Vorgehensweisen vorstellbar. Bei Nutzung der Klasse ActiveRecordStore fr die Speicherung von Session-Inhalten, macht es Sinn ein Model Session zu definieren, dass folgende Methode beinhaltet: class Session < ActiveRecord::Base def self.sweep self.destroy_all(:coditions => ["updated_at < ?", 30.minutes.ago] end end

ber einen Task kann dann regelmig der Befehl ruby script/runner "Session.sweep" aufgerufen werden, der alle Sessions, die innerhalb der letzten 30 Sekunden nicht aktualisiert wurden, lscht. Um weitergehend auch Angriffe durch Session-Fixation zu verhindern, kann die oben dargestellte Bedingung zum Lschen so erweitert werden, dass ebenfalls Sessions, die vor einem bestimmten Zeitraum erstellt wurden, ebenfalls gelscht werden [11, S. 15]. Bei Nutzung andersartiger Speicherverfahren kann hnlich vorgegangen werden und eine regelmige Lschung der Dateien per Skript erfolgen. 5.2 SQL Injection-Angriffe

Die Injection-Angriffe subsummieren eine Angriffsform, die auf das Einschleusen von Schadcode in nicht oder nicht ausreichend geprften Eingaben abzielt. Hierdurch knnen Angreifer erreichen, dass der eigene Quellcode im Sicherheitskontext der Webanwendung ausgefhrt wird um Anwendungsfehler auszulsen, Schadcode innerhalb der Anwendung oder auf dem Client auszufhren oder den Anwender auf fremde Webseiten zu leiten [11, S. 30]. Ein erstes Beispiel fr Injection Angriffe zielen auf Sicherheitslcken ab, die aus dem Zusammenspiel zwischen Anwendung und SQL-Datenbank entstehen. Nahezu alle Anwendungen nutzen SQL als Abfragesprache fr Datenbanken. Die Interaktivitt von Webanwendungen wird erreicht, in dem vorgegebene SQL-Fragmente mit Benutzereingaben komplettiert werden [14, S. 50]. Durch mangelnde Maskierung oder berprfung von Metazeichen in Benutzereingaben erhlt der Angreifer jedoch die Mglichkeit, ber die Anwendung Datenbankbefehle einzuschleusen. Dieses Einschleusen von Code wird als SQL-Injection bezeichnet [5, S. 287 f]. Auch auf Ruby on Rails basierende Webanwendungen machen sich Datenbanken zu nutzen. Jedoch erfolgt die Kommunikation zwischen Datenbank und Anwendung zumeist nicht wie gewhnlich ber SQL-Anweisungen direkt, sondern vielmehr erfolgt die Implementierung von Datenbankabfragen zumeist mit einen objektrelationale Datenmapper wie ActiveRecord. Durch die Kapselung des Datenbankzugriffs wird implizit ein weitreichender Schutz vor SQL-Injections erreicht, da durch diese Zwischenschicht automatisierte Validierungen der Eingaben durchgefhrt werden und nicht-gltige Zeichen automatisiert gefiltert werden [11, S. 35]. Voraussetzung fr den Schutz der Anwendung ist jedoch, dass auf die von ActiveRecord zur Verfgung gestellten Methoden wie beispielsweise where oder find aufgebaut wird. bergabeparameter dieser Methoden werden durch Nutzung der Klasse ActiveRecord::Sanitization automatisiert validiert. Sollten SQL-spezifische Zeichen wie OR, AND beziehungsweise Kommentarkennzeichnungen wie -- vorhanden sein, werden diese implizit gefiltert [32]. Sobald jedoch eigene Bedingungen oder ganze SQL-Abfragen selbst definiert werden, muss zwingend eine manuelle Validierung der Parameter durchgefhrt werden. Dies kann durch die bereits oben dargestellte Filterklasse ActiveRecord::Sanitization geschehen [32]. Folgendes Beispiel zeigt die Implementierung sicherer beziehungsweise unsicherer ActiveRecord-Zugriffe [33]:

class User < ActiveRecord::Base def self.authenticate_unsafe (name, pw) where("name = '#{ name}' AND pw ='#{pw}'").first end def self.authenticate_safe (name, pw) where("name = ? AND pw = ?", name, pw).first end def self.authenticate_safe_simple(name, pw) where(:name => name, : pw => pw).first end end Im obigen Beispiel ist die Implementierung der Methode self.authenticate_unsafe anfllig fr SQL-Angriffe. Durch direkte Einbindung der Variablen in den QueryCode versagt die automatische Validierung. Ein Angreifer, der in das Eingabefeld fr den Benutzernamen den Wert ' OR 1)-- eintrgt, erhlt automatisch Zugriff auf die Anwendung, da die angegebene Bedienung damit immer wahr ist [33]. Die Methoden zwei und drei implementieren dieselbe Anforderung auf sichere Art und Weise. Anstelle der direkten Eingabe der Parameter in die Filterung, werden diese ber eine Parametrisierung mitgegeben. Hier greift die automatische Filterung, SQL-Angriffen sind nicht mglich. 5.3 Cross-Site Scripting

Bei der Entwicklung von Rails ist festzustellen, dass in den einzelnen Major-Releases intensiv auch an der Sicherheit des Web-Frameworks gearbeitet wurde. Whrend mit dem in Rails 1 realisierten ActiveRecord-Modul ein impliziter Schutz vor SQLInjection verfgbar ist, brachte Rails 2 wesentlichen Fortschritt bei dem Schutz vor Cross-Site Request Forgery. In Version 3 von Rails wurde der Kreis geschlossen und der Schutz vor Cross-Site Scripting Angriffen, kurz XSS, wesentlich verbessert [34]. Um XSS-Angriffe zu vermeiden, ist ein grundlegendes Verstndnis ber die Sicherheitsstrategien in modernen Browsern notwendig. Die grundlegende Idee zur Herstellung von Sicherheit in Browsern ist, dass die Ausfhrung jeglicher Skripte in so genannten Sandboxes stattfindet. Damit werden unter anderem die Mglichkeiten eines Skriptes eingeschrnkt, auf grundlegende Systemoperationen zuzugreifen. Noch wichtiger aber ist, dass ein webseitenbergreifender Datenaustausch unterbunden wird, da pro Webseite eigenstndige Sandboxes existieren. Cookie-Informationen, Session-Ids und weitergehende zu schtzende Informationen knnen damit nur dann ausgelesen werden, falls Sie auch von der gleichen Webseite erstellt wurden. Dieses Verfahren wird auch in der Literatur unter dem Begriff Same Origin Policy subsummiert [35, S. 276]. Cross-Side Scripting Angriffe zielen nun darauf ab, schadhaften Java-Script- oder HTML-Quellcode in eine anzugreifende Webanwendung einzubringen und damit dessen Ausfhrung im Sicherheitskontext der Webseite zu erzwingen. Im Moment der Ausfhrung knnen diese Skripte dann auf alle Daten des Anwenders in der jeweiligen Sandbox der Webanwendung zugreifen [35, S. 276].

Ein Beispiel soll helfen Cross-Side Scripting basierte Angriffe zu verdeutlichen. Sollte bei der Neuerfassung von Daten durch den Benutzer diese nicht ausreichend durch die Webanwendung geprft, sondern direkt verarbeitet und gespeichert werden, knnen systematisch Script-Blcke eingebracht werden. Ein Angreifer, der es schafft, den folgenden Code durch ein Eingabefeld in eine Webanwendung einzupflegen, wird die Mglichkeit haben, auf der Webseite evil.com alle Cookieinformationen der Anwendungsbenutzer auszulesen. <script> d = document; s = d.createElement("script") s.src = "http://evil.com/payload?d.cookie; d.body.appendChild(script); </script> Die Webseite ist damit kompromittiert. Diese oben beschriebene Angriffsform stellt einen so genannten persistenten Cross-Side Scripting Angriff dar. Grundstzlich sind zwei Typen von Cross-Side Scripting Angriffen praktikabel, nmlich persistente sowie reflexive Angriffe [35, S. 276]. Reflexive Angriffe haben pro Ausfhrung das Ziel, grundstzlich nur einem einzigen Opfer zu schaden. Dabei wird der clientseitige Code durch das Opfer selbst an die verwundbare Seite geschickt und anschlieend dieser im Rahmen der Anfrage verarbeitet [35, S. 276f]. Ganz im Gegensatz hierzu haben persistente Angriffe das Ziel, mglichst viele anonyme Anwender zu treffen, in dem der Code direkt auf eine verwundbare Seite eingebettet wird, beispielsweise in dem eine Abspeicherung in der Anwendungsdatenbank erfolgt. Die Infizierung des Anwenders passiert dann mit dem Laden der Seite durch das Opfer selbst [35, S. 276f]. Gegenmanahmen gegen Cross-Site Scripting sind vielfltig, wobei aber die Praxis zeigte, dass nur ein relativer Schutz gegen XSS-basierte Angriffe erreicht werden kann und auch groe Webplattformen immer wieder Probleme mit dieser Art von bswilligen Code haben [36]. Vorkehrungen knnen einerseits von den Anbietern von Webanwendungen ergriffen werden, in dem diese systematisch ein- und ausgehende Daten filtern und verdchtige Elemente entfernen. Andererseits sehen sich aber auch Browserhersteller in der Verpflichtung, ber das Sandbox-Konzept hinausreichende Sicherheitskonzepte zum Schutz vor XSS zu realisieren [37, S. 1f]. Betrachtet werden anbei nur die serverseitig zu realisierenden Manahmen. Safe-String Konzept. Wie bereits angedeutet, hat sich der Schutz vor XSS-Attacken ab Ruby on Rails 3.0 wesentlich verndert. Whrend in lteren Versionen Eingaben explizit durch Verwendung der Methoden escapeHTML() oder h() Daten als unsicher markiert werden mussten, ist es in Rails 3.0 so, dass grundstzlich alle Inhalte als unsicher eingestuft werden, und der Entwickler explizit aufgefordert ist, sichere Inhalte im Rahmen eines Whitelistings zu kennzeichnen [34]. Grundkonzept bei der Behandlung von XSS in Rails 3.0 ist eine klare Trennung zwischen sicheren und unsicheren Inhalten. Aus diesem Grund wurde die Klasse ActiveSupport::SafeBuffer implementiert, welche fr die interne Verarbeitung stan-

dardmig genutzt wird und sich aus der Klasse String ableitet. Die Methoden +, concat sowie << wurden berschrieben [38]. Objekte dieser Klasse werden grundstzlich als vertrauenswrdig eingestuft. Ergebnis dieser Trennung ist, dass grundstzlich alle Daten, die mit der Klasse String erstellt werden, automatisch bei der Verkettung oder Anzeige transponiert werden. Hierzu werden fr HTML reservierte Zeichen wie < oder > durch das entsprechende HTML-Pendant ersetzt, also beispielsweise &lt; beziehungsweise &gt;. Somit ist es nicht mglich, Fremdcode in Webanwendung zur Ausfhrung zu bringen[38]. Soll anstelle der Maskierung dem Inhalt vertraut werden und eine automatische Entfernung von HTML-Spezifischen Tags verhindert werden, so kann dies geschehen durch Verwendung der neuen Helper-Methode raw beziehungsweise html_safe bei der Ausgabe. Folgendes Code-Beispiel zeigt die Auswirkung der Verwendung von raw in einer .erb-Datei, wobei in dem Attribut name der Wert <b>XSS</b> gespeichert ist: <%= booking.name %> # => Ausgabe in HTML: &lt;b&gt;XSS&lt;/b&gt; <%= raw booking.name %> # => Ausgabe in HTML: <b>XSS</b> Die folgende Darstellung gibt ein Beispiel der Konsequenzen dieser Trennung:
Tabelle 5. Konsequenz Verwendung SafeBuffer

Anwendungsfall 1 "XSS".html_safe?

Erluterung Ergebnis: false. Standardmig werden alle Objekte der Klasse String als Nicht-Sicher angesehen 2 xss = "XSS".html_safe Ergebnis: true. Mit Aufruf der String-Methode xss.html_safe? html_safe wird ein SafeBuffer Objekt zurckgeliefert. Daher gibt die Methode html_safe? auch entsprechend true zurck. 3 xss = "".html_safe Ergebnis: "&lt;script&gt;". Als Ergebnis des Aufrufs xss xss << "<script>" = "".html_safe wird ein SafeBuffer-Objekt zurckgeliefert. Bei der Verknpfung des SafeBuffers mit einem Objekt vom Typ String wird eine automatische Ersetzung ungltiger Zeichen durchgefhrt. Wichtig ist, dass sich die Nutzung des Konzepts von html_safe alleinig auf die Anzeige selbst bezieht. Eingaben werden nach wie vor ungefiltert abgespeichert und erst bei der Anzeige konvertiert. Sanitization. Es gibt immer Anwendungsflle, bei denen es aber durchaus gewnscht ist, auch eine weitergehende Formatierung der Benutzereingabe zu erlauben. Um dies zu ermglichen ist fr viele Anwendungsflle die Nutzung des Safe_Buffer Konzepts zu restriktiv. Anstelle einfach alle mglichen HTML-Tags automatisiert zu ersetzen, ist es das Ziel, eine Filterung der Benutzereingaben durchzufhren und solche Tags zu entfer-

nen, die wirklich Schadcode enthalten knnen. Um dies auf sichere Weise zu ermglichen, gibt es in Rails den Themenkomplex Sanitization. Konkret zu betrachten sind hierbei die Klassen Helpers::SanitizeHelper [39] sowie Helpers::TextHelper [40]. Die Klasse TextHelper bietet hierzu die Methode simple_format. Sie entfernt automatisiert alle mglicherweise gefhrlichen HTML-Tags. Nicht gefhrliche Tags wie <b> werden jedoch weiterhin nicht gefiltert und dargestellt. Zustzlich wird aber auch fr die Textbearbeitung weitergehende Funktionalitt angeboten. So wird beispielsweise das Tag \n automatisiert in <br/> umgewandelt. Auch die Methode simple_format greift fr die Filterung auf die Klasse SanitizeHelper intern zu. Sollten weitergehende Anforderungen bestehen, beispielsweise eine klare Liste an erlaubten Tags, so ist diese Klasse zu nutzen. Folgendes Quellcodebeispiel soll die Verwendung der Sanitization Helper noch einmal verdeutlichen: # Nutzung der Klasse TextHelper fr die automatisierte # Filterung gefhrlicher Eingaben simple_format('<a href="http://test.com/">Test</a>') # => "<p><a href=\"http://test.com/\">Test</a></p>" simple_format('<a href="javascript:alert(\No!\)">No</a>') # => "<p><a>No</a></p>" # Nutzung von SanitizeHelper fr die gezielte Einschrnk# ung der Tags sanitize @article.body, :tags => %w(table tr td) Textile Auszeichnungssprachen. Neben dem oben dargestellten Konzept der Sanitization, also der gezielten Filterung von Eingaben, gibt es weitergehend auch die Mglichkeiten so genannte Textile Auszeichnungssprachen zum Einsatz zu bringen, die gezielt auf die Verwendung von HTML-Pattern verzichten und eine eigene Auszeichnungssprachen bereitstellen [11, S. 42]. Neben den Vorteilen der einfacheren Erlernbarkeit der Auszeichnungssprache fr den Endanwender ist vor allem in Bezug auf die Sicherheit der Vorteil, dass Eingaben in einen textilen Format an die Webanwendung bertragen werden und damit weitergehend voll auf dem oben dargestellten Konzept der automatisierten Entfernung von Strings gesetzt werden kann. Prominentestes Beispiel fr eine solche Auszeichnungssprache im Ruby-Umfeld stellt RedCloth dar [41], welches ebenfalls ber GEM in Rails eingebunden werden kann. Wichtig beim Einsatz ist jedoch, dass es auch hier notwendig ist, eine Filterung der Eingaben vorzunehmen, da auch RedCloth in der Vergangenheit nicht zuverlssig vor XSS geschtzt hat [11, S. 42]. Hier kann auf das SafeBuffer Konzept zurckgegriffen werden. 5.4 Cross-Site Request Forgery

Wie bereits in Kapitel 5.2 dargestellt, handelt es sich bei HTTP um ein zustandsloses Protokoll. Das Konzept der Sessions in Webanwendungen adressiert dieses Dilemma und ermglicht so, seitenbergreifend Daten und Zustnde zu speichern. Neben den

oben aufgezeigten Problemen des Session Managements ist das Cross-Site Request Forgery eine weitere Mglichkeit, den mit dem Sessionkonzept einhergehende Sicherheitskontext auszunutzen und dem Anwender bsartige Anfragen unterzuschieben [14, S. 49][42, S. 1]. Cross-Site Scripting wird in der Fachliteratur als ein Sleeping Giant eingeschtzt, da Untersuchungen zeigen, dass viele Webseiten anfllig fr Angriffe dieser Art sind [42, S. 1]. Um Cross-Site Request Forgery ganzheitlich zu verstehen, muss zuerst verstanden werden, wie sich URLs in Ruby on Rails zusammensetzen. In dem Web-Framework wird das Routing zwischen der einzelnen Serveranfrage sowie den entsprechenden Servercontroller durch die Datei routes.rb durchgefhrt. Die Konvention in Rails sagt, dass jede Action auch immer auf eine so genannte CRUD-Operation in der Datenbank weist. Ein Eintrag in der routes.rb wie resources :bookmarks erzeugt damit grundstzlich sieben verschiedene Standard-Routen [43].
Tabelle 6. Standardrouten in Ruby on Rails [43]

HTTP-Verb GET GET POST GET GET PUT DELETE

Path /bookmarks /bookmarks/new /bookmarks /bookmarks/:id /bookmarks/:id/edit /bookmarks/:id /bookmarks/:id

action index new create show edit update destroy

Beschreibung Liste aller Lesezeichen Maske zur Erfassung eines Lezeichens Anlage eines Lesezeichens Anzeige eines Lesezeichens Maske zur Editierung eines Lezeichens Aktualisierung eines Lesezeichens Lschung eines Lesezeichens

Mit Hilfe dieser Schemata lassen sich so beispielsweise ber Eingabe der URL Daten abrufen, ndern aber auch lschen. Die Eingabe der URL http://railsapp.org/bookmarks/3/destroy lscht zum Beispiel einzelne Bookmarks in der Datenbank. Diese Eigenschaft macht sich nun Cross-Site Request Forgery zu Nutze, um vom Anwender ungewollte Aktionen auszulsen. Der Ursprung des Aufrufs der Seite muss dabei nicht innerhalb der Rails Webanwendung sein, sondern kann genauso gut in einem parallel geffneten Browserfenster, beispielsweise durch einen E-Mail Client geschehen. Fr das Unterschieben bsartige Serveranfragen sind Image-Tags, XSS, Injection, Social Engineering sowie viele weitere Angriffsmglichkeiten vorstellbar. Anhand eines Beispielszenarios soll nun noch einmal ein mglicher Angriff durch Cross-Site Request Forgery dargestellt werden:

Abbildung 7. Zuweisung von Sessions zu Clients


:Browserfenster 1 :Browserfenster 2
Serveranfrage Erzeuge Session mit Id = 12345

:Rails Server

:HTML Mail Server

Antwort mit Session Id = 12345 Email im HTML-Client abrufen

<html>...<img src:http://railsapp.org/bookmarks/3/destroy/></html> Abruf img: http://railsapp.org/bookmarks/3/destroy mit Session Id = 12345 Lsche Bookmark mit ID=3

Der Anwender selbst hat zwei Browserfenster geffnet. Mit dem ersten wird eine auf Rails basierende Webanwendung geffnet und eine Session erzeugt. Mit einem zweiten Browser befindet sich der Anwender gerade in einen HTML-basierenden EmailClient. ber diesen wird eine E-Mail abgerufen, in welcher aber ein Bild eingebunden ist, dass auf eine URL der Rails-Applikation verweist. Der Browser versucht nun das Bild abzurufen und schickt automatisch ebenfalls die Session Id an dem Server. Der Browser hat grundstzlich keine Mglichkeit zu entscheiden, welche Anfrage gltig ist oder nicht. Damit befindet sich der Angriff im Sicherheitskontext der Webseite und eine Lschung, ohne dass es dem Benutzer bekannt ist, von einzelnem BookingIds wird durchgefhrt. Gegenmanahmen. Um Angriffe gegen Cross Site Request Forgery entgegenzuwirken, stehen in Ruby on Rails drei mehr oder weniger effektive Schutzkonzepte zur Verfgung. Einen migen Schutz bietet die Mglichkeit, anstelle beim Aufruf von Methoden die bergabe von Parameter mittels GET zu vermeiden und anstelle immer dann, wenn kritische Daten zwischen dem Client und dem Server durchgefhrt werden POST-Requests zu verwenden [11, S. 17f]. Idee ist, dass POST-Requests nicht mittels einer einfachen URL-Einbindung erreicht werden knnen. Jedoch stellt Webers ebenfalls fest, dass die Nutzung von Post-Variablen keinerlei Schutz an sich bietet, da sich ebenfalls Post-Anfragen sich programmtechnisch generieren lassen. Damit stellt diese Schutzmanahme nur eine Erschwerung des Angriffs, jedoch keine Verhinderung dar [11, S. 18]. Eine weitere prventive Manahme zur Verhinderung von Cross-Site Request Forgery ist die systematische berprfung aller Controller sowie Actions auf tatschliche Verwendung durch den Benutzer. Actions und Controller, die fr dem Test sowie der internen Verarbeitung alleine bentigt werden, sollten nach Mglichkeit durch Verwendung des Keywords protected bei der Methodendefinition nicht von auen aufrufbar sein. Fr das Debugging oder Unit-Tests einer Rails-Applikation knnen Ac-

tions durch Verwendung folgender Anweisung auf der Test sowie Produktionsumgebung gesperrt werden: if (ENV['RAILS_ENV'] == 'development') then #Nur auf der Entwicklungsumgebung aufrufbarer Code end Fr den effektiven Schutz der Webanwendung vor CSRF bietet Ruby on Rails ein interessantes Feature, welches in Version zwei eingefhrt wurde und in Version 3 nun standardmig auch aktiviert ist [44]. Dieses Feature kann, bei konsistenter Anwendung, das Problem des Cross-Site Request Forgery weitgehend lsen. ber die Angabe des Parameters protect_from_forgery im Application Controller wird ein SessionToken erzeugt, dass benutzerindividuell aus der Session-Id sowie einen Serverseitigen Schlssels generiert wird. Ziel dieses Tokens ist, dass alle mit Ruby on Rails generierten Formulare ein verstecktes Feld beinhalten, in welcher diese eindeutige Kennzeichnung hinterlegt ist. Auf dem Server angekommen, wird dieser Schlssel mit dem ursprnglich fr diese Anfrage definierten Parameter abgeglichen und falsche Anfragen mit einer Exception vom Typ ActionController::InvalidAuthenticityToken abgelehnt. Ab Version 3.0.4 fhrt Rails anstelle einen Fehler zu werfen implizit ein session_reset() aus [45]. Zu erwhnen ist, dass beispielsweise Ajax-Aufrufe oder Webservices ebenfalls hierdurch geschtzt werden [44]. 5.5 Mass-Assignment

Das so genannte Mass-Assignment ist ein hilfreiches Feature in Ruby-On-Rails, um einem Objekt alle bentigten Attribute auf einmal zuzuweisen. Dies kann vor allem dann eingesetzt werden, wenn beispielsweise bereits zur Instanziierung eines Active Record Modells eine Vielzahl an Attributen gewnschten Attribute aus den Request Parametern bergeben werden [11, S. 25]. Mit Hilfe von Mass-Assignment in Ruby on Rails kann beispielsweise aufbauend auf den oben dargestellten Beispielen folgendermaen durchgefhrt werden: # Methode zur automatisierten Anlage eines Bookmarks # unter Nutzung des Mass-Assignment def create @bookmark = Bookmark.new(params[:bookmark]) ... end Oben genannte Zeile kann aber durchaus problematisch gesehen werden. Geht man davon aus, dass manipulierte Anfragen sowohl per GET- wie auch POST an die Anwendung bermittelt werden knnen, so knnten von einem Angreifer ebenfalls ohne Probleme das Mass-Assignment genutzt werden, um Datenstze und Felder, die aus sicherheitstechnischen Anforderungen eigentlich nicht fr die Bearbeitung durch den Nutzer vorgesehen sind, bearbeitet werden [11, S. 25]. Die Erkenntnis aus dieser Problematik ist, dass ein Angreifer durch das MassAssignment Felder bearbeiten kann, die ihm so nicht zugestanden sind. Im schlimms-

ten Fall knnen nicht geschtzte Mass-Assignment Anweisungen genutzt werden, um die Berechtigungen eines Benutzers zu manipulieren [11, S. 25]. Mgliche Anstze, dass Mass-Assignment fr bestimmte Felder zu deaktivieren (so genanntes Blacklisting) oder zu aktivieren (so genanntes Whitelisting) kann ber die Implementierung der Attribute attr_protected sowie attr_accessible durchgefhrt werden. Nicht explizit fr das Mass-Assignment ausgewiesene Attribute mssen dann entsprechend individuell zugewiesen werden. Das Whitelisting ist hufig in der Praxis zu empfehlen, da nderungen und menschliche Fehler dazu fhren knnen, dass beim Blacklisting wichtige geschtzte Attribute vergessen werden. In Version 3.0 ist Rails ist so vorkonfiguriert, das zwingend ein Whitelisting durch den Entwickler in allen Model-Klassen durchgefhrt werden muss. Hierfr zustndig ist ein Konfigurationsparameter in der Datei application.rb [46]. Eine Implementierung eines Whitelistening kann folgendermaen durchgefhrt werden: # Whitelisting des Attributs name in der von ActiveRecord # abgeleiteten Klasse Bookmark class Bookmark < ActiveRecord::Base attr_accessible :name end Die Gefahr bei Mass-Assignment liegt daher nicht in der technischen Machbarkeit der Implementierung, sondern in der Konzeption. Es bedarf einer intensiven Auseinandersetzung mit dem Thema um zu bestimmen, welche Attribute beschreibbar sein sollen und welche nicht. 5.6 Logging

Im Standard wird Ruby on Rails alle Anfragen von Benutzern protokollieren. Dies kann ein groes Sicherheitsproblem darstellen, falls Informationen wie Passwrter, Kreditkarteninformationen und weitergehende sensitive Informationen ebenfalls im Log-Verzeichnis abgespeichert werden [45]. Um dieses Problem zu umgehen, wurde in Rails 3.0 die Mglichkeit gegeben, in der Datei config/application.rb Parameter zur Filterung bei Logging-Ausgaben anzugeben: # Configure sensitive param which will be filtered from # the log file. config.filter_parameters += [:password] Diese oben dargestellte Zeile ist im Standard vorhanden und muss entsprechend erweitert werden, je nachdem welche Informationen aus Log-Files zu entfernen sind. Anstelle des Passworts wird anschlieend im Logging der Wert [FILTERED] dargestellt.

Fazit und Ausblick

Im Rahmen dieser Ausarbeitung konnte im ersten Schritt ein generelles Modell zur Ableitung der Sicherheitsebenen von Webanwendungen vorgestellt werden. Dieses

generelle Modell wurde anschlieend genutzt, um systematisch realistische Angriffsszenarien vorzustellen, die Ruby on Rails-basierte Webseiten im Internet ausgesetzt sein knnen. Zielsetzung war es dabei immer, dass neben der Schilderung der konkreten Gefahren auch detailliert Lsungsanstze diskutiert und gegeneinander abgewogen werden. Es wurde festgestellt, dass mit Hilfe von Ruby on Rails auch sicherste Webanwendungen erstellt werden knnen und bereits im Standard zahlreiche Funktionalitten zur Verfgung stehen, die den Weg zur sicheren Webanwendung vereinfachen. Vor allem die Sicherheit hat mit der Version 3.0 des Web Application Framework noch einmal zugenommen, da die Ergnzungen zum Schutz vor Cross Site Scripting einen weitgehend vollstndigen Schutz vor den grten Sicherheitsherausforderungen im Web ermglicht [4][34]. Trotz aller Automatisierung ist es aber fr alle an dem Prozess der Softwareentwicklung beteiligten Personen nach wie vor wichtig, dass auch bei so mchtigen Framewoks wie Ruby on Rails nach wie vor die Fhigkeit vorhanden sein muss, Sicherheitsrisiken bei der Umsetzung von Lsungen zu erkennen und diese zu bewerten. Natrlich untersttzt Rails dabei, sichere Webanwendungen umzusetzen, die Entscheidung aber beispielsweise welches Attribut geschtzt sein soll, welche Folgen ein bestimmter Prozess oder ein bestimmtes Vorgehen in der Implementierung nach sich zieht, muss der Entwickler individuell abschtzen und entsprechend den optimalen Weg zur Umsetzung finden. Die Fhigkeit hierzu ist vor allem deshalb so wichtig, da das Thema WebApplication-Security extrem schnelllebig und entsprechend komplex ist. Dies lsst sich alleine schon daran feststellen, dass der auf der offiziellen Webseite des Ruby on Rails Projekt bereitgestellte Security Guide seit dem Jahr 2009 kaum berarbeitungen mehr erfahren hat [11] und dieser damit Neuentwicklungen in Version 3 nicht mehr wiederspiegelt. Deshalb ist es neben den allgemeinen vorgeschlagenen Hinweisen in diesem Dokument ratsam fr Ruby on Rails Entwickler, aktuelle sicherheitsrelevante Neuigkeiten im Internet, beispielsweise ber die Plattform http://www.rorsecurity.info/ oder den zahlreichen Blogs im Internet zu beziehen. Bugs und Sicherheitslcken in der Software Ruby on Rails werden entsprechend offen kommuniziert und Workarounds beziehungsweise Fixes angeboten.

Referenzen
1. 2. 3. 4. Schreiber, T.: Best Practices fr sichere Webanwendungen. iX 03/2007: 119122 (2007). Kaspersky Lab ZAO: Cyberthreat forecast for 2012. http://www.kaspersky.com/images/ Kaspersky%20report-10-134377.pdf (2011). Abgerufen am: 02.03.2012. Gieselmann, H.: Der Millionen Hack. Datendiebe brechen in Sonys Netzwerk ein. c't 11/2011 (2011). OWASP Foundatoin: Top 10 2010-Details About Risk Factors. https://www.owasp.org/ index.php/Top_10_2010-Details_About_Risk_Factors (2010). Abgerufen am: 02.03.2012. Kappel, G.; Prll, B.; Reich, S.; Retschitzegger, W.: Web engineering. The discipline of systematic development of web applications. John Wiley & Sons, Hoboken, NJ (2006). Lew, P.; Olsina, L.; Zhang, L.: Quality, Quality in Use, Actual Usability and User Experience as Key Drivers for Web Application Evaluation. In: Benatallah B (ed) Web engi-

5. 6.

7. 8. 9.

10.

11. 12. 13. 14. 15. 16.

17. 18. 19. 20.

21. 22. 23. 24.

25. 26.

27.

neering. 10th International Conference, ICWE 2010, Vienna Austria, July 5-9, 2010. Proceedings. Springer-Verlag, Berlin ;Heidelberg, Seite 218232 (2010). Ferner, J.: PHP Security Guide. http://www.tu-chemnitz.de/urz/www/php/rsrc/ phpsec.pdf (2006). Abgerufen am: 22.01.2012. Meier, J.: Web Application Security Engineering. IEEE Security and Privacy 07/2006: S. 1624, (2006). Microsoft Corporation: Simplified Implementation of the Microsoft SDL. http://www.microsoft.com/download/en/details.aspx?id=12379 (2010). Abgerufen am: 18.03.2012. Bundesamt fr Sicherheit in der Informationstechnik: Sicherheit von Webanwendungen. Manahmenkatalog und Best Practices. https://www.bsi.bund.de/SharedDocs/Downloads/ DE/BSI/Publikationen/Studien/WebSec/WebSec_pdf.pdf?__blob=publicationFile (2006). Abgerufen am: 22.01.2012. Webers, H.: Ruby on Rails Security. https://www.owasp.org/images/2/26/Owasp-railssecurity.pdf (2009). Abgerufen am: 26.03.2012. Ruby on Rails: Ruby on Rails 3.0 Release Notes. http://guides.rubyonrails.org/ 3_0_release_notes.html (2012). Abgerufen am: 15.04.2012. Oracle Corporation: Securing the Initial MySQL Accounts. http://dev.mysql.com/doc/ mysql-security-excerpt/5.1/en/default-privileges.html (2012). Abgerufen am: 14.04.2012. Krautgartner, T.; Hlterhoff, M.: Web Application Security. Niemals ungeschtzt. javaMagazing 6/2009: S. 4655 (2009). Rtten, C.: Web-Server mit mod_security absichern. http://www.heise.de/security/artikel/ Die-Apache-Firewall-270782.html (2006). Abgerufen am: 11.03.2012. Bundesamt fr Sicherheit in der Informationstechnik: IT-Grundschutz-Katalog. https:// gsb.download.bva.bund.de/BSI/ITGSK12EL/IT-Grundschutz-Kataloge-12-EL.pdf (2011). Abgerufen am: 18.03.2012. Slater, M.: Using SSL in Rails Applications. http://www.buildingwebapps.com/articles/ 6401-using-ssl-in-rails-applications (2008). Abgerufen am: 18.03.2012. Rack: Request.rb. https://github.com/rack/rack/blob/master/lib/rack/request.rb (2012). Abgerufen am: 15.04.2012. Morrison, D.: SSL with Rails. http://collectiveidea.com/blog/archives/2010/11/29/sslwith-rails (2010). Abgerufen am: 07.04.2012. PCI Security Standards Council: Payment Card Industry (PCI) Data Security Standard. Requirements and Security Assessment Procedure. https://www.pcisecuritystandards.org/ documents/pa-dss_de-de_v2.pdf. Abgerufen am: 15.04.2012. Huber, S.: attr_encrypted. https://github.com/shuber/attr_encrypted/blob/master/ README.rdoc (2011). Abgerufen am: 15.04.2012. Harding, B.: Guide to Setup Rails with MySQL SSL. http://www.williambharding.com/ blog/rails/guide-to-setup-rails-with-mysql-ssl/ (2008). Abgerufen am 08.04.2012. Oracle Corporation: Using SSL for Secure Connections. http://dev.mysql.com/doc/ refman/5.6/en/secure-connections.html (2012). Abgerufen am: 25.03.2012. Ruby on Rails: ActionController:HttpAuthentication:Basic. http://api.rubyonrails.org/ classes/ActionController/HttpAuthentication/Basic.html (2012). Abgerufen am: 15.04.2012. Network Working Group: HTTP Authentication: Basic and Digest Access Authentication. http://www.ietf.org/rfc/rfc2617.txt (1999). Abgerufen am: 15.04.2012. Cardella, B.: Exploring Rails 3.1 - ActiveModel:SecurePassword. http://bcardarella.com/ post/4668842452/exploring-rails-3-1-activemodel-securepassword (2011). Abgerufen am 08.04.2012. Ruby on Rails: ActionDispatch:Cookies < Object. http://api.rubyonrails.org/classes/ ActionDispatch/Cookies.html (2012). Abgerufen am: 25.03.2012.

28. Wang, X.; Feng, D.; Yu, H.: Collision for Hash Functions. http://eprint.iacr.org/2004/199.pdf (2004). Abgerufen am: 09.04.2012. 29. Ruby on Rails (2012) Active Record Session Store. http://api.rubyonrails.org/classes/ ActiveRecord/SessionStore.html. Abgerufen am: 15.04.2012. 30. Ruby on Rails: ActionController:SessionManagement:ClassMethods. http:// rails.rubyonrails.org/classes/ActionController/SessionManagement/ClassMethods.html (2012). Abgerufen am: 15.04.2012. 31. Webers, H.: Security and Safety of Ruby on Rails in regard to a project management software. http://pi1.informatik.uni-mannheim.de/filepool/theses/bachelorarbeit-2007webers.pdf (2007). Abgerufen am: 15.04.2012. 32. Ruby on Rails: ActiveRecord:Sanitization:ClassMethods. http://api.rubyonrails.org/ classes/ActiveRecord/Sanitization/ClassMethods.html (2012). Abgerufen am: 14.04.2012. 33. Ruby on Rails: Active Record. http://api.rubyonrails.org/classes/ActiveRecord/ Base.html (2012). Abgerufen am: 14.04.2012. 34. Katz, Y.: Secure by Default: Rails 3 Security Strategy. http://www.railsdispatch.com/ posts/security (2010). Abgerufen am: 15.04.2012. 35. van Tilborg, H., Jajodia. S.: Encyclopedia of Cryptography and Security. Springer US, Boston, MA (2011). 36. heise Security: Twitter fixt erneute XSS-Lcke. http://www.heise.de/security/meldung/ Twitter-fixt-erneute-XSS-Luecke-1315670.html (2011). Abgerufen am: 09.04.2012. 37. Louw, M.; Venkatakrishnan, V.: Blueprint: Robust Prevention of Cross-site Scripting Attacks for Existing Browsers. 30th IEEE Symposium on Security and Privacy. http:// www.cs.uic.edu/~venkat/research/papers/blueprint-oakland09.pdf (2009). Abgerufen am 15.04.2012. 38. Katz, Y.: SafeBuffers and Rails 3.0. http://yehudakatz.com/2010/02/01/safebuffers-andrails-3-0 (2010). Abgerufen am: 09.04.2012. 39. Ruby on Rails: ActionView:Helpers:SanitizeHelper. http://api.rubyonrails.org/classes/ ActionView/Helpers/SanitizeHelper.html (2012). Abgerufen am: 09.04.2012. 40. Ruby on Rails: ActionView:Helpers:TextHelper. http://api.rubyonrails.org/classes/ ActionView/Helpers/TextHelper.html (2012). Abgerufen am 09.04.2012. 41. Garber, J.: RedCloth - Textile parser for Ruby. https://github.com/jgarber/redcloth/blob/ master/README.rdoc (2011). Abgerufen am: 15.04.2012. 42. Zeller, W.; Felten, E.: Cross-Site Request Forgeries: Exploitation and Prevention. http://www.cs.utexas.edu/users/shmat/courses/library/zeller.pdf (2008). Abgerufen am: 09.04.2012. 43. Ruby on Rails: Rails Routing from the Outside In. http://guides.rubyonrails.org/ routing.html (2012). Abgerufen am: 28.01.2012. 44. Daigle, R.: What's New in Edge Rails: Better Cross-Site Request Forging Prevention. http://archives.ryandaigle.com/articles/2007/9/24/what-s-new-in-edge-rails-better-crosssite-request-forging-prevention (2007). Abgerufen am: 14.04.2012. 45. Korziarski, M.: CSRF Protection Bypass in Ruby on Rails. http://groups.google.com/ group/rubyonrails-security/browse_thread/thread/2d95a3cc23e03665 (2011). Abgerufen am: 15.04.2012. 45. Ruby on Rails: Configuring Rails Applications. http://guides.rubyonrails.org/ configuring.html (2012). Abgerufen am: 09.04.2012.