Warum ist Ruby on Rails die beste Wahl für die Webentwicklung? Rails ist eine ziemlich beliebte Entwicklungsumgebung, die als eine der praktischsten gilt. RoR eignet sich für Teams unterschiedlicher Größe – von kleinen Start-ups bis hin zu großen Unternehmen. Das liegt daran, dass Ruby on Rails eine recht einfache Syntax hat, leicht zu erlernen ist und Teamarbeit unterstützt. Mit dieser Technologie wurden so bekannte Internetplattformen wie Twitter, Airbnb, Github, Groupon, Basecamp, Scribd, Kickstarter, CrunchBase und viele andere entwickelt.
Ruby on Rails Sicherheitsprobleme
RoR erschien erstmals im Jahr 2005 und erlangte schnell große Aufmerksamkeit. Sechs Jahre später war dieses Framework als Webentwicklungstechnologie weit verbreitet. Es ist erwähnenswert, dass die Apple Corporation eine wichtige Rolle bei diesem rasanten Aufstieg spielte. Die ersten größeren Schwierigkeiten traten 2012-2013 auf. Zu dieser Zeit wurde die Frage der Sicherheit von Plattformen, die auf Ruby basieren, akut. Es wurdenzahlreiche Probleme und Ruby-Sicherheitslücken gefunden, die eine Welle von unzufriedenen Kommentaren und Kritik auslösten. Dies lieferte Böswilligen einen Vorwand für Boshaftigkeit: Der Technologieslogan wurde inoffiziell umschrieben – „Web-Entwicklung, die sehr weh tut“ statt „Web-Entwicklung, die nicht weh tut“.
Trotz aller Schwierigkeiten haben die Rails-Entwickler nicht aufgegeben, so dass sie in kürzester Zeit eine Reihe nützlicher Rails-Sicherheitsupdatesidentifizieren und durchführen konnten . Außerdem wird jedes Jahr ein Ruby-Sicherheitsaudit durchgeführt, wodurch die Sicherheit der Plattform verbessert und eine Reihe von Schwierigkeiten vermieden werden kann. Heute enthält RoR standardmäßig einen eingebauten Schutz gegen viele verschiedene Arten von Angriffen wie CSRF, Clickjacking, Massenzuweisung, XSS und eine Reihe anderer. Dank dessen gilt Ruby on Rail zu Recht als eine der sichersten Entwicklungsumgebungen.
Ruby on Rails Sicherheitsschwachstellen
Der Hauptvorteil von RoR ist, dass es perfekt ausbalanciert ist und Anwendung und Sicherheit harmonisch miteinander verbindet. Mit den in Railseingebauten sicheren Passwörtern und Lösungen bietet dieses Framework ein hohes Maß an Schutz vor einer Vielzahl von verschiedenen Angriffen. In Anbetracht der Verbesserungen könnte man sagen, dass die Technologie unverwundbar ist, aber eine unverantwortliche Herangehensweise an die Kodierung wird viele Probleme mit sich bringen, einschließlich der Sicherheit Rails für Windows Fragen.
Die Grundlage von Ruby on Rails ist das System der Module, der sogenannten Gems. Jedes von ihnen enthält den Code und die Metadatei im entsprechenden Format – YAML. Wenn einer der bekannten RCE-Exploits für YAML in die Metadatei eingefügt wird und ein solcher Edelstein auf den RubyGems-Server geladen wird, kann beliebiger Code im Kontext des Haupt-Ruby-Code-Repositorys ausgeführt werden, wodurch das gesamte „Ökosystem“ kompromittiert wird. Wie schützt man sich also vor verschiedenen Angriffen?
Ruby on Rails Sicherheitsleitfaden: Die häufigsten Arten von Angriffen auf Websites
-
XSS
XSS oder sogenannte Cross-Site-Scripting-Angriffe sind das größte Problem. Diese Art von Angriffen ist am schädlichsten und kann Ihren Webdienst leicht zerstören. Es gibt eine Vielzahl von Einfallspunkten, die das Einschleusen von bösartigem Code ermöglichen. XSS-Angriffe können von Suchergebnisseiten, Kommentaren, Nachrichten, Bewertungen, den Namen von Dokumenten, Projekten usw. gestartet werden. Sogar URL-Parameter können den Weg für einen Angriff ebnen. In diesem Fall bleibt das geänderte Element in die Anwendung integriert und wird anschließend von den Benutzern aufgerufen. Das Hauptproblem besteht darin, dass ein bösartiges Element lange Zeit passiv bleiben oder in mehreren Teilen einer Website gleichzeitig aktiviert werden kann, was noch mehr Schaden anrichtet. Aufgrund der komplexen Struktur des Angriffs sollten Sie sich nicht auf Standard-XSS-Filter verlassen. Schwierigkeiten treten auf, sobald ein Programmierer Daten in einem unsicheren Format wie JSON hinzufügt. Es ist besser, die Daten in ein anderes Format zu konvertieren oder die Einbettung von Skripten in die übertragenen Daten zu vermeiden.
Der Schutz vor XSS durch das automatische Screening von potenziell gefährlichen Komponenten ist in RoR gut implementiert. Jede Zeile ist mit einem speziellen Flag html_safegekennzeichnet . Wenn dieses Flag nicht gesetzt ist, dann filtert Rails vor der Ausgabe des variablen Teils diesen.
Für die Ausgabe von sicheren Daten ist es üblich, die folgende Konstruktion zu verwenden:
<% = Rohdaten%>
aber für alles andere:
<% = Daten%>
Die „raw“-Methode markiert die Zeile mit dem html_safe-Flag:
def raw (stringish)
stringish.to_s.html_safe
end
Daher sind viele Entwickler an die Verfügbarkeit von XSS-Filtern gewöhnt, die automatisch eingesetzt werden. Ein guter Rails-Sicherheitsspezialist weißjedoch , dass es sich bei XSS um einen komplexen Angriff handelt, der verschiedene Formen annehmen und in mehreren Schritten durchgeführt werden kann.
Das Problem tritt auf, wenn Entwickler Daten im JSON-Format in die Seite einfügen müssen, die an einen Benutzer gesendet wird. Normalerweise wird der folgende Code zu diesem Zweck implementiert:
<% = data.to_json%>
oder in der HTML-basierten Version:
: javascript
var data = # {data.to_json}
Im ersten Fall wird das ‚<%‘-Konstrukt verwendet. Das bedeutet, dass die Standardfilterung angewendet wird. Im zweiten Fall wird JSON, das HTML-Code enthalten kann, nicht bereinigt. Die Sicherheitslücke wurde in der 4. Version von Rails behoben, in der die Symbole ‚<‚, ‚>‘ und ‚&‘ durch ihre Unicode-Entsprechungen ersetzt wurden.
-
CSRF
Angriffe mit Cross-Site-Request-Forgery oder CSRFs basieren auf einer Schwachstelle im HTTP-Übertragungsprotokoll. Diese Art von Angriffen wirkt sich negativ auf die Leistung und die Arbeit Ihrer App oder Web-Ressource aus und funktioniert unter der Annahme, dass der Benutzer bereits aktive Rechte hat. Rails verfügt über einen vorgefertigten Mechanismus zum Schutz gegen solche Angriffe – die Token-Authentifizierung. Dennoch ist das Vorhandensein eines eingebauten Schutzes kein Grund, die zusätzlichen Sicherheitsempfehlungen nicht zu implementieren. Zuallererst ist es notwendig, POST- und DELETE-Abfragen besondere Aufmerksamkeit zu schenken.
Die Wurzel des Problems liegt in der Verwendung der „match“-Methode in der Datei routes.rb, die das Pfadverarbeitungssystem auf der Website beschreibt. Diese Methode wurde entwickelt, um eine bestimmte Aktion auf alle möglichen HTTP-Anforderungsmethoden abzubilden: GET, POST, PATCH, DELETE, usw. Die „match“-Methode wird überall verwendet, so dass jeder Rails-Sicherheitsscanner vorschlagen würde, die Parameter über alternative HTTP-Methoden zu übergeben und die Serverantworten zu überwachen. Der folgende Ausdruck ist ein klassisches Beispiel für den beschriebenen Fall:
match „/ follow“, to: „followings # create“
-
Massenzuweisung
Die Massenzuweisung ist eine Fähigkeit, die die Erstellung des Codes erheblich vereinfacht. Mit ihr kann der Entwickler gleichzeitig eine Reihe von Attributen setzen. Ohne diese Funktion müsste der Programmierer für jedes Attribut einen eigenen Operator erstellen. In den Anwendungen mit Model-View-Controller (MVC)-Architektur werden Parametersätze in Form eines Hashes übergeben. Wenn der Controller einen solchen Hash erhält, wird er ungeprüft und unverändert in das Modell übertragen. Wenn man in diesem Fall dem Hash die Werte anderer Felder hinzufügt, die von vornherein nicht geändert werden sollten, ist es möglich, sie zu ändern.
Diese Sicherheitslückein Ruby on Rails ist bei vielen MVC-Frameworks zu finden. Sie ermöglicht es Hackern, heimlich Änderungen am Code vorzunehmen. Im Falle von Ruby ermöglicht die Verwendung des „strong_parameters„-Moduls, die Möglichkeit unbefugter Änderungen im Code auszuschließen, indem explizit die Parameter deklariert werden, die nicht durch Massenzuweisung geändert werden können:
class User <ActiveRecord :: Base
attr_protected: can_fire_missiles
end
-
SQL-Einschleusung
SQL-Injection ist die beliebteste Methode für Hackerangriffe. Natürlich erlauben es viele ORMs, unsichere Eingaben zu blockieren, aber mit etwas Mühe kann der Täter immer einen Weg finden, die ungeprüften Daten zu übergeben. Zum Beispiel, wenn wir eine solche Anweisung verwenden:
Order.where (: user_id => 1) .joins (params [: table]),
werden die Tabellenparameter und Daten nicht überprüft. Es sei darauf hingewiesen, dass die SQL-Injektion den Zugang zur Datenbank öffnet, was es ermöglicht, vertrauliche Daten nicht nur zu lesen, sondern auch zu verändern.
Häufig wird diese Angriffsmethode verwendet, um beispielsweise bestimmte Informationen zu erlangen:
def index
@Schreiber = Writer.all
unless params [: query] .blank?
@Autoren = @Autoren.where („Biografie wie ‚% # {Parameter [: Abfrage]}%'“)
end
end
Auf der einen Seite ermöglicht es eine schnelle Suche nach den gewünschten Datensätzen. Andererseits ist es eine gute Möglichkeit, bösartigen Code in das zurückgegebene Ergebnis einzuschleusen. Sie können das Problem mit einer sichereren Array-Deklaration lösen:
def index
@Schreiber = Writer.all
unless params [: query] .blank?
@Autoren = @Autoren.where („Biografie wie“, params [: query])
end
end
Weitere Informationen über SQL-Injection-Angriffe und Möglichkeiten zum Schutz Ihrer Anwendung finden Sie im OWASP Cheat Sheet.
-
Clickjacking
Clickjacking ist eine Art von Netzwerkangriff, bei dem ein Benutzer automatisch auf eine andere Seite umgeleitet wird. Es ist erwähnenswert, dass diese Art von Angriff in der Regel Ihrer Website keinen Schaden zufügt, sondern dazu dient, die Besucherzahlen einer fremden Ressource zu erhöhen. Trotzdem verfügen die neuesten Ruby-Versionen über einen Mechanismus, der diese Weiterleitungen verhindern kann. Dazu muss der Entwickler lediglich den HTTP-Header „X-Frame-Options: SAMEORIGIN“ zu den erstellten Seiten hinzufügen.
-
Session abfangen
RoR-Sitzungen werden standardmäßig in einem signierten Cookie gespeichert, d.h. in einer regulären Zeile, die mit einem geheimen HMAC-Schlüssel signiert ist. Viele Entwickler glauben, dass der Sitzungsinhalt etwas Sicheres und für den Benutzer Unzugängliches ist. Natürlich kann der Benutzer die Werte der Sitzungsparameter nicht ändern, da sie mit dem Sitzungsschlüssel – „session_secret“ –signiert sind, aber es ist möglich, alles herauszufinden, was in das Sitzungsprotokoll geschrieben wird. So sieht zum Beispiel der Cookie „_gh_sess“ auf github.com aus:
BAh7DDoQX2Nzc … AGOgpAdXNlZHsA-
d12b0f42ed9881fbv55cc9559d50adwf5f5638d2
Sie besteht aus zwei Teilen: der erste Teil ist eine mit dem Base64-Algorithmus kodierte Zeile, der zweite Teil ist ihre MD5-Signatur. Versuchen wir, den ersten Teil der Zeile mit den Funktionen„atob (decodeURIComponent ())“zu entschlüsseln:
„{: _csrf_token“ 19yv3VZY8veGCQXyS3dl47XGB9r4rzWVUNZqUFqSmWNI =: session_id „% 76f701b09a1b5a1831a51a309ff8f79d: userieª: contextI“ /: EF: fingerprint „% 5ffecf01f27d79b4ff0dbeaa39568eb7: return_toI“ (https://github.com/settings/profile; TI „
flash; FIC: ‚ActionController :: Flash :: FlashHash {:
@used {„
Offen gesagt bedeutet diese Sicherheitslücke nichts anderes als die Offenlegung von Daten. In der Version Rails 4 wird bereits ein verschlüsselter Sitzungsspeicher zum Speichern von Sitzungen verwendet, was die Möglichkeit, nützliche Daten aus der Sitzung abzurufen, erheblich einschränkt, da sie in verschlüsselter Form gespeichert sind. Erfahrene Entwickler raten in jedem Fall davon ab, solche Daten clientseitig zu speichern. Um die Sicherheit der Sitzungen zu gewährleisten, ist es außerdem ratsam, die Methoden des Gems ‚activerecord-session_store‘ zur Verarbeitung und Speicherung von Sitzungen zu verwenden.
Ruby on Rails Sicherheit: Letztes Wort
Ruby on Rails verfügt über viele eingebaute Mechanismen, die es ermöglichen, eine Webseite oder Anwendung zu schützen. Trotzdem nutzen viele Entwickler diese Mechanismen nicht oder machen es falsch. Aus diesem Grund können viele Probleme entstehen. Um mögliche Probleme zu vermeiden, raten wir Ihnen, sich an unseren Ruby on Rails-Sicherheitsleitfadenzu erinnern , wenn Sie in RoR programmieren. Außerdem ist es wichtig, dass Sie Ihre Anwendungen regelmäßig mit dem Ruby-Sicherheitsscanner, z. B. Brakeman oder Codesake::Dawn, überprüfen .
