Wie kann ich in Ruby defensiv programmieren?

Question

Hier ist ein perfektes Beispiel für das Problem: Klassifikator-Edelstein bricht Schienen.

** Ursprüngliche Frage:**

Eine Sache, die mich als Sicherheitsexperte beunruhigt, ist, dass Ruby keine Parallele zum Paketschutz von Java bietet.Das heißt, das ist kein gültiger Ruby:

public module Foo
  public module Bar
    # factory method for new Bar implementations
    def self.new(...)
      SimpleBarImplementation.new(...)
    end
    def baz
      raise NotImplementedError.new('Implementing Classes MUST redefine #baz')
    end
  end

  private class SimpleBarImplementation
    include Bar
    def baz
      ...
    end
  end
end

Es wäre wirklich schön, das Monkey-Patching von Foo::BarImpl verhindern zu können.Auf diese Weise wissen die Leute, die sich auf die Bibliothek verlassen, dass sich niemand damit beschäftigt hat.Stellen Sie sich vor, jemand würde die Implementierung von MD5 oder SHA1 bei Ihnen ändern!Ich kann anrufen freeze auf diesen Klassen, aber ich muss es auf einer Klasse-für-Klasse-Basis tun, und andere Skripte könnten sie ändern, bevor ich mit der Sicherung meiner Anwendung fertig bin, wenn ich das nicht tue sehr Achten Sie auf die Ladereihenfolge.

Java bietet viele andere Tools für die defensive Programmierung, von denen viele in Ruby nicht möglich sind.(Eine gute Liste finden Sie im Buch von Josh Bloch.) Ist das wirklich ein Problem?Sollte ich einfach aufhören, mich zu beschweren und Ruby für einfache Dinge verwenden und nicht auf „unternehmenstaugliche“ Lösungen hoffen?

(Und nein, Kernklassen sind in Ruby nicht standardmäßig eingefroren.Siehe unten:)

require 'md5'
# => true
MD5.frozen?
# => false

Answer 1

Kasse Unveränderlich von Garry Dolley.

Sie können die Neudefinition einzelner Methoden verhindern.

Answer 2

Ich glaube nicht, dass das ein Grund zur Sorge ist.

Ja, das mythische „jemand“ kann die Implementierung von MD5 durch etwas Unsicheres ersetzen.Aber um das zu tun, muss der mythische Jemand tatsächlich in der Lage sein, seinen Code in den Ruby-Prozess zu bekommen.Und wenn er das kann, dann könnte er seinen Code vermutlich auch in einen Java-Prozess einschleusen und z.B.Schreiben Sie den Bytecode für die MD5-Operation neu.Oder Sie fangen einfach die Tastendrücke ab und machen sich überhaupt nicht die Mühe, mit dem Kryptografiecode herumzuspielen.

Eines der typischen Probleme ist:Ich schreibe diese großartige Bibliothek, die wie folgt verwendet werden soll:

require 'awesome'
# Do something awesome.

Aber was ist, wenn jemand es so verwendet:

require 'evil_cracker_lib_from_russian_pr0n_site'
# Overrides crypto functions and sends all data to mafia
require 'awesome'
# Now everything is insecure because awesome lib uses 
# cracker lib instead of builtin

Und die einfache Lösung ist:Tu das nicht!Informieren Sie Ihre Benutzer darüber, dass sie in ihren sicherheitskritischen Anwendungen keinen nicht vertrauenswürdigen Code ausführen sollten, den sie aus unbekannten Quellen heruntergeladen haben.Und wenn doch, dann haben sie es wahrscheinlich verdient.

Um auf Ihr Java-Beispiel zurückzukommen:Es stimmt, dass Sie in Java Ihren Kryptocode erstellen können private Und final und was nicht.Allerdings kann es jemand Trotzdem Ersetzen Sie Ihre Krypto-Implementierung!Tatsächlich hat jemand Folgendes getan:Viele Open-Source-Java-Implementierungen verwenden OpenSSL, um ihre kryptografischen Routinen zu implementieren.Und wie Sie wahrscheinlich wissen, wurde Debian jahrelang mit einer defekten, unsicheren Version von OpenSSL ausgeliefert.Also eigentlich alle Java-Programme, die in den letzten Jahren auf Debian liefen tat Laufen Sie mit unsicherer Krypto!

Answer 3

Java bietet viele weitere Tools für die defensive Programmierung

Zuerst dachte ich, Sie reden davon normale defensive Programmierung, wobei die Idee ist, das Programm (oder Ihre Teilmenge oder Ihre einzelne Funktion) gegen ungültige Dateneingaben zu verteidigen.
Das ist eine großartige Sache und ich ermutige jeden, diesen Artikel zu lesen.

Es scheint jedoch, dass Sie tatsächlich davon sprechen, „Ihren Code vor anderen Programmierern zu verteidigen“.

Meiner Meinung nach ist dies ein völlig sinnloses Ziel, da ein böswilliger Programmierer Ihr Programm immer unter einem Debugger ausführen oder verwenden kann, egal was Sie tun DLL-Injektion oder eine beliebige Anzahl anderer Techniken.

Wenn Sie lediglich Ihren Code vor inkompetenten Kollegen schützen möchten, ist das lächerlich. Bilden Sie Ihre Kollegen weiter oder gewinnen Sie bessere Kollegen.

Wenn Ihnen solche Dinge am Herzen liegen, ist Ruby jedenfalls nicht die richtige Programmiersprache für Sie.Monkeypatching ist beabsichtigt und es zu verbieten, widerspricht dem Sinn und Zweck der Funktion.

Answer 4

Ich denke, Ruby hat diese Funktion – sie wird mehr geschätzt als ein Sicherheitsproblem.Ducktyping auch.
Z.B.Ich kann der Ruby-String-Klasse meine eigenen Methoden hinzufügen, anstatt sie zu erweitern oder zu umschließen.

Answer 5

„Schulen Sie Ihre Kollegen oder holen Sie sich bessere Kollegen“ funktioniert hervorragend für ein kleines Software-Startup und auch für große Unternehmen wie Google und Amazon.Es ist lächerlich zu glauben, dass jeder bescheidene Entwickler einen Vertrag für eine kleine Krankenaktenanwendung in einer Arztpraxis in einer Kleinstadt abgeschlossen hat.

Ich sage nicht, dass wir auf den kleinsten gemeinsamen Nenner bauen sollten, aber wir müssen realistisch sein, dass dies der Fall ist viele Es gibt viele mittelmäßige Programmierer da draußen, die jede Bibliothek nutzen, die ihre Arbeit erledigt, ohne auf Sicherheit zu achten.Wie könnte Sie achten auf Sicherheit?Vielleicht haben sie einen Kurs über Algorithmen und Datenstrukturen belegt.Vielleicht haben sie einen Compiler-Kurs besucht.Sie haben mit ziemlicher Sicherheit keinen Kurs über Verschlüsselungsprotokolle besucht.Sie haben definitiv nicht alle Schneier oder einen der anderen gelesen, die es praktisch tun müssen betteln und flehen Selbst sehr gute Programmierer müssen beim Erstellen von Software auf Sicherheit achten.

Darüber mache ich mir keine Sorgen:

require 'evil_cracker_lib_from_russian_pr0n_site'
require 'awesome'

ich mache mir Sorgen über awesome erfordern foobar Und fazbot, Und foobar erfordern has_gumption, Und ...Letztendlich stehen zwei dieser Konflikte auf irgendeine undurchsichtige Weise in Konflikt, die einen wichtigen Sicherheitsaspekt zunichte macht.

Ein wichtiges Sicherheitsprinzip ist die „Tiefenverteidigung“ – das Hinzufügen dieser zusätzlichen Sicherheitsebenen verhindert, dass Sie sich versehentlich selbst ins Bein schießen.Sie können es nicht vollständig verhindern;nichts kann.Aber sie helfen.

Answer 6

Wenn Sie Affen-Patches bevorzugen, können Sie das Immutable-Modul (oder eine ähnliche Funktion) verwenden.

Unveränderlich

Answer 7

Schauen Sie sich das „Sandbox“-Projekt von Why the Lucky Stiff an, das Sie nutzen können, wenn Sie befürchten, dass möglicherweise unsicherer Code ausgeführt wird.http://code.whytheluckystiff.net/sandbox/

Ein Beispiel (online TicTacToe):http://www.elctech.com/blog/safely-exposed-your-app-to-a-ruby-sandbox

Answer 8

Raganwald hat eine letzter Beitrag darüber.Am Ende baut er Folgendes auf:

class Module
  def anonymous_module(&block)
   self.send :include, Module.new(&block)
  end
end

class Acronym
  anonymous_module do
    fu = lambda { 'fu' }
    bar = lambda { 'bar' }
    define_method :fubar do
      fu.call + bar.call
    end
  end
end

Das entlarvt fubar als öffentliche Methode auf Acronyms, aber behält die inneren Eingeweide (fu Und bar) privat und verbirgt das Hilfsmodul vor der Sicht von außen.

Answer 9

Wenn jemand ein Objekt oder ein Modul gepatcht hat, müssen Sie sich zwei Fälle ansehen:Er fügte eine neue Methode hinzu.Wenn er der Einzige ist, der diesen Meyhod hinzufügt (was sehr wahrscheinlich ist), entstehen keine Probleme.Wenn er nicht der Einzige ist, müssen Sie prüfen, ob beide Methoden dasselbe bewirken, und den Bibliotheksentwickler über dieses schwerwiegende Problem informieren.

Wenn sie eine Methode ändern, sollten Sie damit beginnen zu recherchieren, warum die Methode geändert wurde.Haben sie es aufgrund eines Randfallverhaltens geändert oder haben sie tatsächlich einen Fehler behoben?Gerade im letzteren Fall ist der Monkeypatch eine gute Sache, da er an vielen Stellen einen Fehler behebt.

Darüber hinaus verwenden Sie eine sehr dynamische Sprache mit der Annahme, dass Programmierer diese Freiheit auf vernünftige Weise nutzen.Die einzige Möglichkeit, diese Annahme zu beseitigen, besteht darin, keine dynamische Sprache zu verwenden.