¿Cómo puedo programar a la defensiva en Ruby?

Question

He aquí un ejemplo perfecto de el problema: El clasificador de la gema se rompe Rieles.

** Pregunta Original:**

Una cosa que me preocupa, como profesional de la seguridad es que Ruby no tiene un paralelo de Java del paquete de privacidad.Es decir, esto no es válido 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

Sería agradable ser capaz de prevenir monkey patching de Foo::BarImpl.De esa manera, la gente que confía en la biblioteca de saber que nadie se ha metido con ella.Imagino que si alguien ha cambiado la implementación de MD5 o SHA1 en usted!Me pueden llamar freeze en estas clases, pero lo tengo que hacer en una clase por clase base, y otras secuencias de comandos pueden modificar antes de que termine de asegurar mi aplicación si no estoy muy cuidado acerca de la orden de carga.

Java proporciona un montón de otras herramientas para la defensiva de programación, muchos de los cuales no son posibles en Ruby.(Ver Josh Bloch del libro para una buena lista.) Es esto realmente un motivo de preocupación?Debo dejar de quejarse y uso de Ruby para el peso ligero de las cosas y no la esperanza de "listo para la empresa" soluciones?

(Y no, las clases esenciales no están congeladas por defecto en Ruby.Ver más abajo:)

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

Answer 1

Echa un vistazo Inmutable por Garry Dolley.

Usted puede prevenir la redefinición de métodos individuales.

Answer 2

No creo que esta es una preocupación.

Sí, el mítico "alguien" puede reemplazar la implementación de MD5 con algo de inseguridad.Pero para hacer eso, el mítico alguien debe realmente ser capaz de obtener su código en el proceso de Ruby.Y si él puede hacer eso, entonces él probablemente también podría inyectar su código en un proceso Java y, por ejemplo,reescribir el código de bytes para el MD5 de la operación.O simplemente interceptar las pulsaciones de teclas y en realidad no se moleste con jugueteando con la criptografía de código.

Una de las típicas preocupaciones es:Estoy escribiendo este impresionante biblioteca, que se supone que se utiliza así:

require 'awesome'
# Do something awesome.

Pero lo que si alguien lo usa así:

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

Y la solución es simple:no hagas eso!Educar a los usuarios de que no se ejecute código sospechoso que se han descargado de ocultar las fuentes en cuanto a su seguridad en aplicaciones críticas.Y si lo hacen, probablemente se lo merecen.

Para volver a su ejemplo en Java:es cierto que en Java puede hacer que su código crypto private y final y lo que no.Sin embargo, alguien puede todavía reemplace su crypto aplicación!De hecho, alguien lo hizo:muchos de código abierto de Java implementaciones utilizan OpenSSL para implementar sus rutinas de cifrado.Y, como usted probablemente sabe, Debian se entregan con un roto, inseguro versión de OpenSSL para años.Así, todos los programas Java que se ejecutan en Debian para el último par de años en realidad ¿ ejecutar insegura crypto!

Answer 3

Java proporciona un montón de otras herramientas de programación defensivas

Al principio pensé que estaban hablando normal defensiva de programación, en donde la idea es defender el programa (o su subconjunto de la misma, o su función única) a partir de datos no válidos de entrada.
Eso es una gran cosa, y os animo a todos a ir a leer el artículo.

Sin embargo parece que en realidad están hablando de "la defensa de su código de otros programadores."

En mi opinión, este es un completo sin sentido objetivo, como no importa lo que hagas, un programador malicioso, puede ejecutar el programa en un depurador, o el uso inyección dll o cualquier número de otras técnicas.

Si simplemente está buscando para proteger tu código de incompetentes co-trabajadores, esto es ridículo. Educar a sus compañeros de trabajo, o conseguir una mejor co-trabajadores.

En cualquier caso, si tales cosas son de gran preocupación para usted, ruby no es el lenguaje de programación para usted.Monkeypatching está ahí por su diseño, y a no permitir que va en contra de todo el punto de la función.

Answer 4

Supongo que Ruby tiene que una función con valores de más de ser un problema de seguridad.Ducktyping demasiado.
E. g.Puedo agregar mis propios métodos para el Rubí de la clase String en lugar de ampliar o envolver.

Answer 5

"Educar a sus compañeros de trabajo, o conseguir una mejor co-trabajadores" funciona perfecto para un pequeño software de inicio, y funciona muy bien para las armas grandes como Google y Amazon.Es ridículo pensar que todos los humildes de desarrollador contratado para algunos médicos pequeños gráficos de la aplicación en el consultorio de un médico en un menor de edad de la ciudad.

No estoy diciendo que debemos construir para el mínimo común denominador, pero tenemos que ser realistas que hay muchas programadores mediocres por ahí que va a tirar en cualquier biblioteca que hace el trabajo, sin prestar atención a la seguridad.¿ podría que preste atención a la seguridad?Tal vez la tomó de los algoritmos y estructuras de datos de la clase.Tal vez se tomó un compiladores de clase.Casi sin duda no tomar un protocolos de cifrado de la clase.Definitivamente no todos leen Schneier o cualquiera de los otros por ahí que prácticamente tienen que ruego y suplico incluso con muy buenos programadores en cuenta la seguridad cuando la construcción de software.

No estoy preocupado acerca de esto:

require 'evil_cracker_lib_from_russian_pr0n_site'
require 'awesome'

Me preocupa awesome que requieren foobar y fazbot, y foobar que requieren has_gumption, y ...finalmente, dos de estos conflictos en un oscuro camino que deshace un importante aspecto de la seguridad.

Un importante principio de seguridad es la "defensa en profundidad" -- la adición de estas capas adicionales de seguridad ayudar a que usted accidentalmente tiro en el pie.Ellos no pueden evitarlo por completo;nada puede.Pero ayudan.

Answer 6

Si monkey patching es su concen, puede utilizar el Inmutable módulo (o uno de similar función).

Inmutable

Answer 7

Usted puede tomar un vistazo a por Qué la Suerte de Rigidez del "Sandbox"del proyecto, que usted puede utilizar si usted se preocupe acerca de, potencialmente, ejecutar código no seguro.http://code.whytheluckystiff.net/sandbox/

Un ejemplo (en línea TicTacToe):http://www.elctech.com/blog/safely-exposing-your-app-to-a-ruby-sandbox

Answer 8

Raganwald tiene un post reciente acerca de este.Al final, él construye la siguiente:

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

Que expone fubar como un método público en Acronyms, pero mantiene el interior de la tripa (fu y bar) privada y oculta ayudante módulo desde la vista exterior.

Answer 9

Si alguien monkeypatched un objeto o un módulo, entonces usted necesita para buscar en 2 casos:Se ha añadido un nuevo método.Si él es el único que la adición de este meyhod (lo cual es muy probable), entonces no hay de que surjan problemas.Si él no es el único, que necesita para ver si ambos métodos hacen lo mismo, y decirle a la biblioteca desarrollador acerca de este grave problema.

Si cambian de un método, usted debe comenzar a investigar por qué el método fue cambiado.Hicieron cambiar debido a algunos casos de borde comportamiento o hicieron realmente solucionar un bug?especialmente en el último caso, el monkeypatch es una cosa de dios, ya que corrige un error en muchos lugares.

Además de eso, se utiliza un lenguaje dinámico con la suposición de que los programadores utilizan esta libertad de una manera coherente.La única manera de eliminar esta suposición no es el uso de un lenguaje dinámico.