{"id":27233,"date":"2017-10-31T14:05:41","date_gmt":"2017-10-31T14:05:41","guid":{"rendered":"https:\/\/dev.railscarma.com\/preventing-security-issues-rails\/"},"modified":"2022-09-06T09:26:04","modified_gmt":"2022-09-06T09:26:04","slug":"vermeidung-von-sicherheitsproblemen-schienen","status":"publish","type":"post","link":"https:\/\/www.railscarma.com\/de\/blog\/fachartikel\/vermeidung-von-sicherheitsproblemen-schienen\/","title":{"rendered":"Verhinderung von Sicherheitsproblemen in Rails"},"content":{"rendered":"
\n\t\t\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

Sicherheit ist ein Hauptanliegen f\u00fcr jeden Entwickler, der eine erfolgreiche und nachhaltige Entwicklung von Webanwendungen anstrebt. Jeder Entwickler m\u00f6chte so programmieren, dass seine Anwendungen so sicher wie m\u00f6glich vor Angriffen sind. Allerdings kann kein Code 100% fehlerfrei oder sicher sein. Die Entwickler sind sich also bewusst, dass sie ihr Bestes tun m\u00fcssen, um ihre Anwendungen so wenig anf\u00e4llig wie m\u00f6glich f\u00fcr Angriffe zu machen. Das Aufsp\u00fcren von Schwachstellen ist einfach, aber Sicherheitsverletzungen und Hacks k\u00f6nnen zu Verlusten f\u00fchren. Aus diesem Grund ist es immer besser, bereits zu Beginn der Anwendungsentwicklung nach Sicherheitsproblemen zu suchen und regelm\u00e4\u00dfige Qualit\u00e4tskontrollen durchzuf\u00fchren, um die Dinge auf Kurs zu halten.<\/p>

1] Sitzungen<\/strong><\/h3>

Ein guter Ausgangspunkt f\u00fcr die Bewertung der Sicherheit sind die Sitzungen, die f\u00fcr bestimmte Angriffe anf\u00e4llig sein k\u00f6nnen.<\/p>

session[:user_id] = @current_user.id\nUser.find(session[:user_id])<\/code><\/pre>
- Ruby on Rails verwendet standardm\u00e4\u00dfig einen Cookie-basierten Sitzungsspeicher. Dies bedeutet, dass die Sitzung auf dem Server nicht abl\u00e4uft, solange nichts ge\u00e4ndert wird. Das bedeutet, dass wir niemals sensible Daten wie Passw\u00f6rter, IDs usw. in Sessions speichern sollten.
- Die beste Vorgehensweise ist daher, mit einer datenbankbasierten Session zu arbeiten, was mit Rails sehr einfach ist -<\/p>
Projekt::Application.config.session_store :active_record_store
Die Sitzungs-ID ist eine 32-stellige zuf\u00e4llige hexadezimale Zeichenfolge.<\/p>
Die Sitzungs-ID wird mit SecureRandom.hex generiert, das eine zuf\u00e4llige hexadezimale Zeichenkette mit einer der plattformspezifischen Methoden wie OpenSSL, \/dev\/urandom oder Win32 zur Erzeugung kryptografisch sicherer Zufallszahlen erzeugt. Derzeit ist es nicht m\u00f6glich, einen Brute-Force-Angriff, d. h. einen Angriff durch Ausprobieren, auf die Anmeldedaten in den Sitzungskennungen von Rails durchzuf\u00fchren.<\/p>
Hier sind einige der h\u00e4ufigsten sitzungsbasierten Angriffe:
Session Hijacking:- Dies erm\u00f6glicht es den Angreifern, die Sitzungs-ID eines Benutzers zu stehlen und die Webanwendung im Namen des Opfers zu verwenden.
Sitzungsfixierung: Neben dem Diebstahl der Sitzungs-ID eines Benutzers ist der Angreifer auch in der Lage, eine ihm bekannte Sitzungs-ID zu fixieren. Dies wird als Sitzungsfixierung bezeichnet.
Sitzungsablauf: Die Angreifer versuchen, den Zeitrahmen des Angriffs mit Sitzungen, die nie ablaufen, zu verl\u00e4ngern. Beispiele f\u00fcr solche Angriffe sind Cross-Site Request Forgery (CSRF), Session Hijacking und Session Fixation.<\/p>
2] Befehlsinjektion<\/strong><\/h3>
Eine Anwendung wird anf\u00e4llig f\u00fcr Befehlsinjektion, wenn der Angreifer in der Lage ist, die Befehlszeilenparameter oder die Unix-Befehle als Ganzes zu beeinflussen. Da die Ausf\u00fchrung von UNIX-Befehlen in Rails jedoch nicht \u00fcblich ist, sind diese Angriffe weniger wahrscheinlich.
Andererseits k\u00f6nnen Schwachstellen in einem Hintergrundprozess entstehen, der die Unix-Befehle f\u00fcr die Kundendaten direkt nutzt.<\/p>
Hier sind einige der \u00fcblichen Rails-Befehlszeilenmethoden:
%x[...]
system()
exec()
`…`
Es sollte auch beachtet werden, dass es mehr als eine M\u00f6glichkeit gibt, Befehle aneinander zu ketten, aber das h\u00e4ngt auch vom Host-Betriebssystem ab. Beispiele: \"&\", \"&&\", \"|\", \"||\" usw.
Gesicherte Umgebungsvariablen bei der Ausf\u00fchrung von Befehlen
Die Prozesse, die von Ihren Rails-Anwendungen ausgef\u00fchrt werden, erhalten die Umgebungsvariablen der \u00fcbergeordneten Prozesse, zu denen auch die API-Schl\u00fcssel usw. geh\u00f6ren k\u00f6nnen.<\/p>
3] SQL-Einschleusung<\/strong><\/h3>
Eine SQL-Injektion liegt vor, wenn ein Benutzer in der Lage ist, einen Wert zu manipulieren, der auf unsichere Weise in einer SQL-Abfrage verwendet wird. Dies kann zu Datenverlust, Datenlecks, erh\u00f6hten Rechten und anderen unerw\u00fcnschten Ergebnissen f\u00fchren.<\/p>
SQL-Injection ist ein sehr einfacher und weit verbreiteter Angriff, der in der Regel auftritt und dessen Auswirkungen je nach Website und Situation, in der er auftritt, sehr schwerwiegend sein k\u00f6nnen.<\/p>
Als Entwickler sollten wir uns um all die M\u00f6glichkeiten k\u00fcmmern, bei denen SQL-Injection auftreten kann, und diese entsprechend behandeln.<\/p>
So sieht eine SQL-Injection aus:<\/p>
Employee.all(:conditions => \"Bezeichnung = #{params[:Bezeichnung]}\")<\/code><\/pre>
Der obige Code ist anf\u00e4llig f\u00fcr SQL-Injektion, der folgende Code verhindert die SQL-Injektion.<\/p>
Employee.all(:conditions => ['Bezeichnung = ?', params[:Bezeichnung]])<\/code><\/pre>
ODER<\/p>
Employee.all(:conditions => {:designation => params[:designation]})<\/code><\/pre>
Gegenma\u00dfnahmen gegen SQL Injection in Rails<\/strong><\/h5>
Das Testen jeder Anweisung auf SQL-Injection kann eine m\u00fchsame Arbeit sein, aber wir sollten einige Gegenma\u00dfnahmen ergreifen, wie statische Code-Scanner wie Brakeman und Sie k\u00f6nnen einige Unit-Testf\u00e4lle schreiben.
a) Allgemeine Regel:<\/strong>- Verwenden Sie niemals Parameter in der Stringbeugung (#{}) wie folgt
Zum Beispiel<\/p>
User.where(\"Name = '#{params[:name]}'\")<\/code><\/pre>
b)Achten Sie darauf, dass params z.B. auch ein Array sein kann:<\/strong><\/p>
params[:user], wenn Sie ?user[]=1 zur URL hinzuf\u00fcgen. User.exists? params[:user] wird dann die Abfrage SELECT 1 AS one FROM \"users\" WHERE (1) LIMIT 1 ausf\u00fchren.<\/p>
4] Cross-Site-Scripting (XSS)<\/strong><\/h3>
Mit Hilfe von XSS wird ein Angreifer in die Lage versetzt, Skripte im Sicherheitskontext Ihrer Webanwendung auszuf\u00fchren.<\/p>
Betrachten Sie dieses Rails-View-Snippet: . Wenn der Titel des Flats zusammen mit dem Hinzuf\u00fcgen des HTMLs bearbeitet wird, rendert dieser Rails-View diesen HTML-Code im Sicherheitskontext der Anwendung. Somit w\u00fcrde der Browser den HTML-Code ausf\u00fchren, was ein XSS darstellt.<\/p>
In der Tat funktioniert das in Rails heutzutage noch nicht, in Rails Version 2 m\u00fcsste man jede einzelne Benutzereingabe mit einem Escape versehen:
Heutzutage wird in Rails jeder String mit einem Flag versehen, das ihn als HTML markiert, egal ob er sicher ist oder nicht: @flat.title.html_safe?. Falls er nicht sicher ist (z.B. von einem Parameter, aus der Datenbank, ...), wird er automatisch escaped, wenn man ihn auf diese Weise verwendet:
In Rails 3.0 ist der Schutz gegen XSS ein Standardverhalten.<\/p>
Gegenma\u00dfnahmen<\/strong><\/h3>
a) Eine Strategie der Inhaltssicherheit (CSP)<\/strong><\/p>
A Inhaltliche Sicherheit Politik<\/a> hat im Grunde die Form eines HTTP-Headers, in dem die Regeln f\u00fcr alle zul\u00e4ssigen Quellen f\u00fcr alle Arten von Assets festgelegt sind. Die Befolgung dieser Regeln hat zur Folge, dass alles andere nicht erlaubt ist. Einmal richtig implementiert, k\u00f6nnen damit alle Cross-Site-Scripting (XSS)-Schwachstellen in Ihrer Anwendung beseitigt werden.<\/p>
b) HTML-Safe,ActiveSupport::SafeBuffer<\/strong><\/p>
Das Modul ActiveSupport::SafeBuffer wurde mit Rails 3 eingef\u00fchrt, um ein HTML-sicheres Flag zu Strings hinzuzuf\u00fcgen. Standardm\u00e4\u00dfig ist es false, vor allem, wenn der String eine externe Quelle wie die Datenbank oder die Params hat. Das Flag wird mit \"string\".html_safe? zur\u00fcckgegeben.<\/p>
Die HTML-escape-Methode h(), die eine Zeichenkette als HTML-sicher kennzeichnet, maskiert die Zeichenkette.<\/p>
h(\"html>\").html_safe? #=> true\n(\"html>\").html_safe? #=>false<\/code><\/pre>
c) OWASP (Open Web Application Security Project) XSS-Pr\u00e4vention<\/strong><\/p>
Zur Verhinderung von XSS m\u00fcssen alle nicht vertrauensw\u00fcrdigen Daten verweigert und daran gehindert werden, direkt in den HTML-Code oder einen anderen Kontext (wie JavaScript, CSS, Attributkontexte) eingef\u00fcgt zu werden.<\/p>
d) XSS-Schutz in HAML-Templates<\/strong><\/p>
Bei Verwendung der Haml-Vorlagen anstelle der ERB-Vorlagen werden Strings automatisch auf die gleiche Weise wie in ERB-Vorlagen escaped. Und genau wie bei den ERB-Vorlagen werden HTML-sichere Zeichenketten (string.html_safe? liefert true) nicht automatisch \u00fcbersprungen. Die != Notation in Haml funktioniert so wie  in ERB, d.h. es wird die unescapte Version gerendert.
Standardm\u00e4\u00dfig,<\/p>
=\"betont\"\n!= \"Hervorgehoben\"<\/em><\/em><\/em><\/em><\/em><\/code><\/pre>
kompiliert zu:<\/p>
Hervorgehoben<\/em>\nHervorgehoben<\/em><\/code><\/pre>
Daher ist bei der Verwendung von != in Haml Vorsicht geboten, und es sollte sichergestellt werden, dass keine Benutzerdaten unescaped wiedergegeben werden.
Nachfolgend sind einige vorbeugende Ma\u00dfnahmen aufgef\u00fchrt, die bei der Entwicklung von Schienenanwendungen beachtet werden k\u00f6nnen.<\/p>
1] Authentifizierung<\/strong><\/h5>
Verwenden Sie Device oder Authlogic gem.
- Um die Autorisierung zu aktivieren, vergessen Sie bitte nicht, -> hinzuzuf\u00fcgen.<\/p>
Klasse ProjectController < ApplicationController
vor_filter :authenticate_user
- Standardm\u00e4\u00dfig verlangt Devise nur 6 Zeichen f\u00fcr ein Passwort. Das Minimum kann in: \/config\/initializers\/devise.rb
config.password_length = 8..128
- Sie k\u00f6nnen die Passwortkomplexit\u00e4t \u00e4ndern, indem Sie den folgenden Code in das Benutzermodell einf\u00fcgen.<\/p>
validieren :passwort_komplexit\u00e4t\ndef passwort_komplexit\u00e4t\nif password.present? and not password.match(\/\\A(?=.*[a-z])(?=.*[A-Z])(?=.*\\d).+\\z\/)\nerrors.add :password, \"muss mindestens einen Kleinbuchstaben, einen Gro\u00dfbuchstaben und eine Ziffer enthalten\"\nend\nend<\/code><\/pre>
2] Unsichere direkte Objektreferenz oder erzwungenes Browsing<\/strong><\/h5>
- Ruby on Rails-Anwendungen verwenden eine Restful-URL-Struktur, so dass die verwendeten Pfade meist erraten werden k\u00f6nnen und intuitiv sind. Um also zu verhindern, dass ein Benutzer versucht, auf Daten zuzugreifen oder diese zu \u00e4ndern, die einem anderen Benutzer geh\u00f6ren, m\u00fcssen die Aktionen speziell kontrolliert werden. In einer Vanilla-Rails-Anwendung gibt es von vornherein keinen solchen eingebauten Schutz. Au\u00dferdem kann er manuell auf der Controller-Ebene durchgef\u00fchrt werden.
- Cancancan oder Pandit f\u00fcr die Zugangskontrolle verwenden<\/p>
3] Massenzuordnung und starke Parameter<\/strong><\/h5>
- Klasse Projekt < ActiveRecord::Base\nattr_accessible :name, :admin\nend<\/code><\/pre>
Nach dem obigen Beispiel, bei dem das Attribut admin zug\u00e4nglich ist, k\u00f6nnte Folgendes funktionieren:
- curl -d \"project[name]=triage&project[admin]=1\" host:port\/projects
- config.active_record.whitelist_attributes = true<\/p>
4] Umleitungen und Weiterleitungen<\/strong><\/h5>
- Es ist ratsam, Umleitungen zu vermeiden, die Parameter verwenden
Zum Beispiel:- \/\/www.example.com\/redirect?url=\/\/www.example_commerce_site.com\/checkout
- restriktiver Schutz ist die Verwendung der Option :only_path<\/p>
beginnen\nif path = URI.parse(params[:url]).path\nredirect_to Pfad\nend\nrescue URI::InvalidURIError\nredirect_to '\/'\nend<\/code><\/pre>
- Verf\u00fcgen Sie \u00fcber eine Hash-Datei mit genehmigten Websites und erlauben Sie nur diesen, weitergeleitet zu werden.<\/p>
5] Dynamische Renderpfade<\/strong><\/h5>
- Vorsicht ist geboten, wenn Sie eine Ansicht basierend auf einer Bedingung dynamisch rendern. Dies k\u00f6nnte dazu f\u00fchren, dass die Admin-Ansicht geladen wird.<\/p>
6] Ursprungs\u00fcbergreifende Ressourcennutzung<\/strong><\/h5>
- Wie Datei-Upload.
- Die empfangende Website sollte nur Dom\u00e4nen auf der Whitelist zulassen und sicherstellen, dass die Anfragen auch nur von diesen Dom\u00e4nen kommen.
- Setzen Sie au\u00dferdem den Access-Control-Allow-Origin-Header sowohl in der Antwort auf die OPTIONS-Anfrage als auch auf die POST-Anfrage. Dies liegt daran, dass die OPTIONS-Anforderung zuerst gesendet wird, um festzustellen, ob die entfernte oder empfangende Site die anfragende Dom\u00e4ne zul\u00e4sst.
- Es wird eine POST-Anfrage gesendet. Auch hier muss die Kopfzeile gesetzt werden, damit die Transaktion als erfolgreich angezeigt wird.<\/p>
7] Fehler in der Gesch\u00e4ftslogik<\/strong><\/h5>
- Die Anwendungen k\u00f6nnen unabh\u00e4ngig von der Technologie, auf der sie basieren, Fehler in der Gesch\u00e4ftslogik enthalten, die zu Sicherheitsl\u00fccken f\u00fchren k\u00f6nnen. Es kann sehr schwierig sein, solche Sicherheitsprobleme mit automatisierten Tools zu erkennen. Praktiken wie die regelm\u00e4\u00dfige \u00dcberpr\u00fcfung des Codes, Pair Programming und das Schreiben von Unit-Tests k\u00f6nnen Ihnen helfen, das Auftreten solcher Sicherheitsprobleme zu vermeiden.<\/p>
8] Sensible Dateien<\/strong><\/h5>
Im Folgenden sind einige Dateien aufgef\u00fchrt, auf die wir bei der Entwicklung einer Webanwendung achten sollten.
\/config\/database.yml- Kann Produktionsanmeldedaten enthalten.
\/config\/initializers\/secret_token.rb - Enth\u00e4lt ein Geheimnis, das zum Hashing des Sitzungscookies verwendet wird.
\/db\/seeds.rb - Kann Seed-Daten enthalten, einschlie\u00dflich des Bootstrap-Admin-Benutzers.
\/db\/development.sqlite3 - Kann echte Daten enthalten.<\/p>
9] Verschl\u00fcsselung<\/strong><\/h5>
Ruby on Rails verwendet OS-Verschl\u00fcsselung. Sie sollten fast nie Ihre eigenen L\u00f6sungen f\u00fcr die Verschl\u00fcsselung schreiben.
Rails aktualisieren und einen Prozess f\u00fcr die Aktualisierung von Abh\u00e4ngigkeiten haben.<\/p>
Tools zur Erkennung von Sicherheitsproblemen in Schienenanwendungen<\/strong><\/h4>
  • Bremser<\/li>
  • bundler-audit<\/li>
  • Codesake::Morgend\u00e4mmerung<\/li>
  • Gestell::Attacke<\/li>
  • Vogelspinne<\/li>
  • Hakiri Werkzeugg\u00fcrtel<\/li><\/ul>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t
    \n\t\t\t\t\t\t
    \n\t\t\t\t\t
    \n\t\t\t
    \n\t\t\t\t\t\t
    \n\t\t\t\t
    \n\t\t\t\t\t
    Abonnieren Sie die neuesten Updates<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
    \n\t\t\t\t
    \n\t\t\t\t\t\t\t
    \t\t\t\t\t