Come posso programmare in difesa in Ruby?

Question

Ecco un perfetto esempio di problema: Classificazione gemma pause Guide.

** Domanda originale:**

Una cosa che riguarda me come un professionista della sicurezza è che Ruby non ha un parallelo di Java-pacchetto privacy.Che è, questo non è valido 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

Sarebbe davvero bello essere in grado di prevenire monkey patching dei Foo::BarImpl.In quel modo, le persone che contano su di una biblioteca so che nessuno ha pasticciato con esso.Immaginate se qualcuno ha cambiato l'attuazione di MD5 o SHA1 su di voi!Posso chiamare freeze su queste classi, ma lo devo fare su una classe per classe base, e altri script potrebbe modificarli prima di terminare la sicurezza di applicazione se non sono molto attenti a carico dell'ordine.

Java fornisce un sacco di altri strumenti per la difesa della programmazione, molti dei quali non sono possibili in Ruby.(Vedere Josh Bloch libro per una buona lista.) È davvero questo il problema?Devo solo smettere di lamentarsi e utilizzare Ruby per oggetti leggeri e non speranza "enterprise-ready" soluzioni?

(E no, le classi di base non sono bloccati per impostazione predefinita, in Ruby.Vedi sotto:)

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

Answer 1

Check out Immutabile da Garry Dolley.

È possibile prevenire la ridefinizione dei singoli metodi.

Answer 2

Non credo che questo è un problema.

Sì, il mitico "qualcuno" in grado di sostituire l'attuazione di MD5 con qualcosa di insicuro.Ma per farlo, il mitico qualcuno deve essere in grado di ottenere il suo codice nel processo Ruby.E se riesce a fare questo, allora, presumibilmente, potrebbe anche inserire il suo codice, in un processo di Java e, ad esempio,riscrivere il bytecode per l'MD5 operazione.O solo di intercettare i tasti premuti e non perdere tempo con giocherellare con la crittografia codice.

Uno dei tipici problemi è:Sto scrivendo questo fantastico biblioteca, che è supposto per essere utilizzato in questo modo:

require 'awesome'
# Do something awesome.

Ma cosa succede se qualcuno lo usa in questo modo:

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

E la soluzione è semplice:non farlo!Istruire gli utenti che non dovrebbero eseguire del codice maligno che hanno scaricato dalle oscure origini in loro la sicurezza di applicazioni critiche.E se lo fanno, probabilmente lo meritano.

Per tornare al tuo Java, esempio:e ' vero che in Java si può fare il vostro codice crypto private e final e che cosa non.Tuttavia, qualcuno può ancora sostituire le crypto attuazione!Infatti, qualcuno in realtà ha fatto:molti Java open source implementazioni di OpenSSL per implementare la loro routine di crittografia.E, come probabilmente sapete, Debian fornito con un rotto, insicuro versione di OpenSSL per anni.Così, tutti i programmi Java in esecuzione su Debian per il passato paio di anni in realtà fatto eseguire con insicura crypto!

Answer 3

Java fornisce un sacco di altri strumenti per la difesa della programmazione

Inizialmente ho pensato si trattasse di normale difensiva di programmazione, per cui l'idea è quella di difendere il programma (o il sottoinsieme di esso, o la vostra singola funzione) da voci di dati di input.
Che è una grande cosa, e invito tutti ad andare a leggere l'articolo.

Comunque sembra che in realtà si sta parlando di "difendere il codice da altri programmatori."

A mio parere, questo è un inutile gol, come non importa quello che fai, dannoso programmatore può sempre eseguire il programma in un debugger, o utilizzare dll injection o un qualsiasi numero di altre tecniche.

Se si sta semplicemente cercando di proteggere il codice da incompetenti co-lavoratori, questo è ridicolo. Educare i vostri colleghi, o meglio co-lavoratori.

In ogni caso, se queste cose sono di grande interesse per voi, ruby non è il linguaggio di programmazione per voi.Monkeypatching c'è da disegno, e per impedire va contro il punto di tutta la funzione.

Answer 4

Credo che Ruby ha che una funzione a valori più su di esso di essere un problema di sicurezza.Ducktyping troppo.
E. g.Posso aggiungere le mie metodi per il Ruby classe String anziché estendere o confezionamento.

Answer 5

"Educare i vostri colleghi, o meglio co-lavoratori" funziona alla grande per un piccolo software di avvio, e funziona alla grande per i grossi calibri come Google e Amazon.E ' ridicolo pensare che ogni umile sviluppatore di un contratto per alcune piccole tabelle mediche applicazione in ufficio di un medico nella città minori.

Non sto dicendo che dobbiamo costruire per il minimo comune denominatore, ma dobbiamo essere realistici che ci sono un sacco di mediocre programmatori che sapranno tirare in qualsiasi libreria che ottiene il lavoro fatto, senza prestare attenzione alla sicurezza.Come potrebbe essi prestare attenzione alla sicurezza?Forse ha avuto una algoritmi e strutture di dati di classe.Forse hanno preso un compilatori di classe.Che quasi certamente non ha preso l'protocolli di crittografia di classe.Sicuramente non tutte le leggi di Schneier o di altri là fuori che praticamente necessario implorare e supplicare con anche molto bravi programmatori a considerare la protezione quando la costruzione di un software.

Io non sono preoccupato per questo:

require 'evil_cracker_lib_from_russian_pr0n_site'
require 'awesome'

Sono preoccupato per awesome posto foobar e fazbot, e foobar posto has_gumption, e ...alla fine due di questi conflitti, in qualche oscuro modo che annulla un importante aspetto della sicurezza.

Un importante principio di sicurezza è di "difesa in profondità" -- l'aggiunta di questi livelli di sicurezza aiuterà accidentalmente la ripresa di te stesso in piedi.Essi non impediscono completamente;nulla può.Ma sono di aiuto.

Answer 6

Se monkey patching è il tuo concentrata, è possibile utilizzare il Immutabile modulo (o di una funzione simile).

Immutabile

Answer 7

Si potrebbe dare un'occhiata al Motivo per cui la Lucky Stiff Sandbox progetto, che è possibile utilizzare se si preoccuparti potenzialmente in esecuzione di codice unsafe.http://code.whytheluckystiff.net/sandbox/

Un esempio (online TicTacToe):http://www.elctech.com/blog/safely-exposing-your-app-to-a-ruby-sandbox

Answer 8

Raganwald ha un post recente a proposito di questo.Alla fine, egli costruisce il seguente:

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

Che espone fubar come un metodo pubblico su Acronyms, ma mantiene l'interno budella (fu e bar privato e nasconde helper module da fuori di vista.

Answer 9

Se qualcuno monkeypatched di un oggetto o di un modulo, allora avete bisogno di guardare in 2 casi:Ha aggiunto un nuovo metodo.Se lui è la sola aggiunta di questo meyhod (che è molto probabile), quindi non vi sono problemi.Se egli non è il solo, hai bisogno di vedere se entrambi i metodi di fare lo stesso e raccontare la biblioteca sviluppatore su questo grave problema.

Se si modifica un metodo, si dovrebbe iniziare la ricerca perché il metodo è stato cambiato.Hanno cambiato a causa di qualche caso limite di un comportamento o hanno effettivamente risolto un bug?soprattutto in quest'ultimo caso, il monkeypatch è un dio cosa, perché risolve un bug in molti luoghi.

Oltre a questo, si utilizza un linguaggio dinamico con il presupposto che i programmatori usano questa libertà in un modo sano.L'unico modo per rimuovere questo presupposto non è l'uso di un linguaggio dinamico.