Ruby on Rails ist ein Web Application Framework, das nach dem Prinzip “Don’t Repeat Yourself” (DRY) arbeitet, und damit eine agile Softwareentwicklung ermöglicht. Basierend auf Ruby implementiert Rails eine Model-View-Controller-Architektur (MVC), wodurch sich sehr zügig bestimmte Web-Anwendungen mit Datenbank-Anbindung entwickeln lassen. Kürzlich ist eine Sicherheitslücke in Ruby on Rails entdeckt worden, über die ein entfernter Angreifer Cross-Site-Scripting-Attacken durchführen kann.
Ruby on Rails bietet einen integrierten Schutzmechanismus gegen solche Cross-Site-Scripting-Attacken (XSS), der es dem Programmierer einfacher, macht sicheren Code für seine Webapplikationen zu schreiben. Die Idee beruht darauf, Rubys String-Klasse eine extra Eigenschaft zu geben, die besagt, ob ein String sicher ist oder nicht. Falls er sicher ist, darf die Zeichenkette einfach an den Client (Browser) weitergeleitet und angezeigt werden. Anderenfalls muss sie vorher noch verarbeitet werden, um mögliche XSS-Attacken zu verhindern. Einige Rails-Helper-Funktionen wie “link_to()” beispielsweise liefern automatisch HTML-sichere (“html_safe”) Strings zurück:
<%= link_to('hello world', @user) %>
Dieser Code zeigt den Link tatsächlich an und maskiert ihn nicht vorher. Das ist sinnvoll, denn der Programmierer möchte ja mit “link_to()” einen anzeigbaren Link erzeugen. Das Problem besteht nun darin, dass sich als HTML-sicher markierte Strings weiterverarbeiten lassen:
<%= link_to('hello world', @user).sub!(/hello/, params[:xss]) %>
Hier wird “hello” durch den nicht vertrauenswürdigen String “params[:xss]” via “sub!()” ersetzt. Dieser String sollte jetzt besser nicht mehr als HTML-safe markiert sein. Noch besser: Rails sollte bei einer solchen Aktionen eine Exception auslösen. Leider wurde daran nicht gedacht, und stattdessen wird “hello” ersetzt, doch der gesamte String ist immer noch als “html_safe” markiert. Das eröffnet einem entfernten Angreifer die Möglichkeit, einfache XSS-Attacken durchzuführen. Nicht nur In-Place-Funktionen sind betroffen. So liefert beispielsweise
<%= link_to('hello world', @user).sub(/hello/, params[:xss]) %>
ebenfalls einen als “html_safe” markierten String zurück.
Die neue Ruby-on-Rails-Version korrigiert Probleme dieser Art. Im ersten Beispiel würde jetzt eine Exception ausgelöst, und im zweiten Beispiel ist der zurückgegebene String jetzt nicht mehr als HTML-safe markiert. Bleibt noch das Problem, wie der Entwickler denn jetzt das obige Beispiel umsetzen soll. Wie kann er einen Safe Buffer, wie die HTML-sicheren Strings auch genannt werden, modifizieren? Um die ausgelöste Exception zu vermeiden, muss er den HTML-sicheren String nun zunächst via “to_str()” in einen unsicheren String umwandeln. Danach kann er In-Place-Substitution anwenden:
<%= link_to('hello world', @user).to_str.sub!(/hello/, params[:xss]) %>
Betroffen von der Schwachstelle sind die Ruby-on-Rails-Versionen 2.3.11, 3.0.7, 3.1.0.rc1 und älter.
Rails kommt beispielsweise bei Xing zum Einsatz. Ursprünglich wurden auch große Teile von Twitter in Ruby on Rails geschrieben, aber mittlerweile verwendet der Dienst aufgrund von Skalierungsproblemen Java und Scala.
