¿Por qué el gobierno de los Estados Unidos no permite los lenguajes dinámicos para proyectos seguros?

120

Conozco a algunas personas que actualmente están trabajando en un proyecto para el ejército de los EE. UU. (Nivel de seguridad bajo, datos de tipo de recursos humanos sin combate).

Se envió un estado inicial del código del proyecto a los militares para su revisión, y ejecutaron el programa a través de algún tipo de herramienta de análisis de seguridad. Devolvió un informe de problemas de seguridad conocidos en el código y requirió cambios que debían implementarse antes de la entrega del producto final.

Uno de los elementos que debía resolverse era la eliminación de parte del proyecto que se escribió en Ruby, ya que es un lenguaje dinámico.

¿Cuál es el trasfondo / razón para no permitir que se use un lenguaje dinámico en una configuración segura? ¿Es este el gobierno que tarda en adoptar nuevas tecnologías? ¿O los lenguajes dinámicos presentan un riesgo de seguridad adicional en comparación con los lenguajes estáticos (ala C ++ o Java )?

Patricio
fuente
56
La única forma de saberlo con certeza es si sus conocidos preguntan a sus empleadores por el motivo. Pero puedo arriesgarme a adivinar: la verificación de tipo estático es otra capa que ayuda a la corrección del software de misión crítica. No eliminará los errores, por supuesto, pero es un paso en la dirección correcta: la computadora está haciendo el trabajo por usted. (Sí, sé que este es un territorio de guerras santas).
Andres F.
44
Posiblemente relevante: williamedwardscoder.tumblr.com/post/42912076785/…
Robert Harvey
75
No quieres un software de control de misiles escrito en PHP + JavaScript.
Tulains Córdova
16
Los datos de recursos humanos no son "bajo nivel de seguridad". Esperaría que una compañía mantenga mi empleo y mis datos personales tan seguros como podrían.
gbjbaanb
55
@gbjbaanb Supongo que el OP significó que la pérdida de vidas no es el peor de los casos aquí.
Andres F.

Respuestas:

126

Hay una serie de cosas 'ordenadas' que se pueden hacer en lenguajes dinámicos que se pueden guardar en partes del código que no son inmediatamente obvias para otro programador o auditor en cuanto a la funcionalidad de un determinado código.

Considere esta secuencia en irb (shell ruby ​​interactivo):

irb(main):001:0> "bar".foo
NoMethodError: undefined method `foo' for "bar":String
        from (irb):1
        from /usr/bin/irb:12:in `<main>'
irb(main):002:0> class String
irb(main):003:1> def foo
irb(main):004:2> "foobar!"
irb(main):005:2> end
irb(main):006:1> end
=> nil
irb(main):007:0> "bar".foo
=> "foobar!"

Lo que sucedió allí es que intenté llamar al método fooen una constante de cadena. Esto falló. Luego abrí la clase String y definí el método fooo return "foobar!", y luego lo llamé. Esto funcionó.

Esto se conoce como una clase abierta y me da pesadillas cada vez que pienso en escribir código en ruby ​​que tenga algún tipo de seguridad o integridad. Claro que te permite hacer algunas cosas ordenadas bastante rápido ... pero podría hacerlo de manera que cada vez que alguien almacenara una cadena, la almacenara en un archivo o la enviara a través de la red. Y esta pequeña parte de la redefinición de la cadena se puede guardar en cualquier parte del código.

Muchos otros lenguajes dinámicos tienen cosas similares que se pueden hacer. Perl tiene Tie :: Scalar que puede cambiar detrás de escena cómo funciona un escalar dado (esto es un poco más obvio y requiere un comando específico que puede ver, pero un escalar que se pasa desde otro lugar podría ser un problema). Si tiene acceso al Perl Cookbook, busque la Receta 13.15 - Creación de variables mágicas con empate.

Debido a estas cosas (y otras a menudo son parte de lenguajes dinámicos), muchos enfoques para el análisis estático de la seguridad en el código no funcionan. Perl and Undecidability muestra que este es el caso y señala incluso estos problemas triviales con el resaltado de sintaxis ( whatever / 25 ; # / ; die "this dies!";plantea desafíos porque whateverse pueden definir para tomar argumentos o no en tiempo de ejecución derrotando por completo un resaltador de sintaxis o un analizador estático).


Esto puede ser aún más interesante en Ruby con la capacidad de acceder al entorno en el que se definió un cierre (ver YouTube: Mantener a Ruby Razonable de RubyConf 2011 por Joshua Ballanco). Fui informado de este video de un comentario de Ars Technica por MouseTheLuckyDog .

Considere el siguiente código:

def mal(&block)
    puts ">:)"
    block.call
    t = block.binding.eval('(self.methods - Object.methods).sample')
    block.binding.eval <<-END
        def #{t.to_s}
          raise 'MWHWAHAW!'
        end
    END
end

class Foo
    def bar
        puts "bar"
    end

    def qux
        mal do
            puts "qux"
        end
    end
end

f = Foo.new
f.bar
f.qux

f.bar
f.qux

Este código es completamente visible, pero el malmétodo podría estar en otro lugar ... y con clases abiertas, por supuesto, podría redefinirse en otro lugar.

Ejecutando este código:

~ / $ ruby ​​foo.rb 
bar
> :)
qux
bar
b.rb: 20: en `qux ': MWHWAHAW! (Error de tiempo de ejecución)
    de b.rb: 30: en ''
~ / $ ruby ​​foo.rb 
bar
> :)
qux
b.rb: 20: en `bar ': MWHWAHAW! (Error de tiempo de ejecución)
    de b.rb: 29: en ''

En este código, el cierre pudo acceder a todos los métodos y otros enlaces definidos en la clase en ese ámbito. Escogió un método aleatorio y lo redefinió para generar una excepción. (vea la clase Binding en Ruby para tener una idea de a qué tiene acceso este objeto)

Las variables, los métodos, el valor de sí mismo y posiblemente un bloque iterador al que se pueda acceder en este contexto se conservan.

Una versión más corta que muestra la redefinición de una variable:

def mal(&block)
    block.call
    block.binding.eval('a = 43')
end

a = 42
puts a
mal do 
  puts 1
end
puts a

Que, cuando se ejecuta produce:

42
1
43

Esto es más que la clase abierta que mencioné anteriormente que hace imposible el análisis estático. Lo que se demostró anteriormente es que un cierre que se pasa a otro lugar, lleva consigo el entorno completo en el que se definió. Esto se conoce como un entorno de primera clase (al igual que cuando puede pasar funciones, son funciones de primera clase, Este es el entorno y todos los enlaces disponibles en ese momento). Se podría redefinir cualquier variable que se definió en el alcance del cierre.

Bueno o malo, quejándose de rubí o no (hay usos donde uno quieren ser capaces de conseguir en el entorno de un método (véase Segura en Perl)), la cuestión de "¿por qué el rubí estar restringido en un proyecto del gobierno "Realmente se responde en ese video vinculado anteriormente.

Dado que:

  1. Ruby permite extraer el medio ambiente de cualquier cierre.
  2. Ruby captura todos los enlaces en el alcance del cierre.
  3. Ruby mantiene todos los enlaces como vivos y mutables.
  4. Ruby tiene nuevos enlaces que siguen los viejos enlaces (en lugar de clonar el entorno o prohibir volver a enlazar)

Con las implicaciones de estas cuatro opciones de diseño, es imposible saber qué hace cualquier parte del código.

Puede leer más sobre esto en el blog Abstract Heresies . La publicación particular es sobre Scheme, donde se tuvo ese debate. (relacionado con SO: ¿Por qué Scheme no admite entornos de primera clase? )

Con el tiempo, sin embargo, me di cuenta de que había más dificultades y menos poder con entornos de primera clase de lo que había pensado originalmente. En este punto, creo que los entornos de primera clase son inútiles en el mejor de los casos y peligrosos en el peor.

Espero que esta sección muestre el aspecto peligroso de los entornos de primera clase y por qué se le pediría que elimine a Ruby de la solución provista. No se trata solo de que Ruby sea un lenguaje dinámico (como se mencionó en otra respuesta, se han permitido otros lenguajes dinámicos en otros proyectos), sino que hay problemas específicos que hacen que algunos lenguajes dinámicos sean aún más difíciles de razonar.

Comunidad
fuente
3
No entiendo el punto de esto. Usted menciona una clase de Perl que permite cambiar el comportamiento de los escalares. Sin embargo, Perl se usa ampliamente, incluso en entornos seguros. Simplemente tener estas capacidades en el idioma no significa que el idioma no se pueda usar. En el caso particular de Ruby, es probable que el entorno de destino no sea compatible con Ruby. Personalmente, nunca he visto a Ruby disponible para su uso en ningún sistema, y ​​ni siquiera estoy seguro de si está en alguna lista de software aprobada.
Thomas Owens
17
@ThomasOwens: entiendo que esta respuesta es la clave "many approaches to static analysis of security in code doesn't work", por lo que se rechaza porque no puede ser analizada (al menos por este grupo). Si lo estoy interpretando bien o si esa es una razón válida para rechazarlo, no lo sé.
Bobson
21
Al carecer de información en las listas de software aprobadas, solo puedo adivinar las dificultades con los lenguajes dinámicos. Sin embargo, he visto problemas similares con el software financiero y los cheques de la industria de tarjetas de pago fallan porque el lenguaje no podía tener un análisis estático realizado por problemas de seguridad. Mostré dos ejemplos en lenguajes dinámicos donde la naturaleza del lenguaje le permite subvertir el análisis estático. También señalé por qué esto, incluso teóricamente, nunca puede ser exacto. Puede ser que perl esté permitido en algunos lugares y no en otros, solo puedo adivinar las razones.
2
También puede redefinir las funciones estándar de la biblioteca en muchos otros idiomas (por ejemplo, Obj-C, C, C ++).
Martin Wickman
12
Bueno, los métodos de extensión .NET NO son los mismos que los de Ruby anteriores. Simplemente crean una forma más fácil de escribir una clase estática. En realidad, no agregan un método a una clase.
Graham
50

Asumiendo que la evaluación fue solo de seguridad, y no solo un escaneo de aceptación (es decir, no aceptan a Ruby porque no quieren apoyar a Ruby) entonces:

Las herramientas de análisis de seguridad suelen tener un mal momento con comportamientos dinámicos.

Por ejemplo:

Ejecute cualquier proyecto .NET escrito con características modernas como ASP.NET MVC y Entity Framework a través de algo como Veracode y vea qué tipo de lista de falsos positivos recibe en su informe.

Veracode incluso enumera muchas técnicas básicas dentro de las bibliotecas principales de .NET 4 como "marcos no compatibles" como no compatibles o beta solo aunque la mayoría de ellos tienen varios años en este momento.

Si se trata de una entidad que tiene una gran dependencia de dicha herramienta, casi se ven obligados a considerar a aquellos inseguros si no tienen la experiencia técnica y los recursos para evaluar manualmente un proyecto y ver si está escrito y seguro.

En las operaciones civiles donde los sistemas informáticos generalmente no controlan nada peligroso o terriblemente costoso, la mitigación es que se discuten los falsos positivos y generalmente se aceptan como tales a granel.

En las operaciones bancarias todavía tiene la posibilidad de una mitigación de falsos positivos, pero va a pasar mucho más tiempo discutiendo las minucias de cada elemento. Esto rápidamente se convierte en un costo prohibitivo y comienza a utilizar métodos más tradicionales.

En el ejército, la aviación, la industria pesada y similares, los sistemas pueden controlar cosas que tienen modos de falla terribles, por lo que pueden tener reglas muy estrictas sobre idiomas, compiladores, etc.

Las organizaciones también generalmente escriben su política de seguridad para el peor de los casos que conocen, por lo que incluso si está escribiendo algo trivial, si lo está escribiendo para una organización que tiene sistemas no triviales, el valor predeterminado generalmente será retenerlo. un estándar más alto a menos que alguien solicite una excepción específica.

Cuenta
fuente
44
Y esos son solo los falsos positivos. Lo realmente preocupante es el potencial de falsos negativos.
Stephen C
3
Honestamente, mi experiencia con estas herramientas en general ha sido horrible. Probablemente algo a lo largo de una tasa de 1/200 a 1/1000 de encontrar algo realmente digno de discusión. Además, cuando obtengo un falso positivo que sé que es algo usado en miles de puntos en la base de código o el marco y solo lo ha identificado un puñado de veces, no estoy exactamente lleno de confianza. El problema es que está implementando efectivamente una prueba negativa cuando crea una de estas herramientas, a menos que comience con un lenguaje formal como spec #.
Bill
33

Se pueden usar lenguajes dinámicos en aplicaciones militares y de defensa. Personalmente he usado y entregado Perl y Python en aplicaciones DoD. También he visto PHP y JavaScript utilizados y desplegados. En mi experiencia, la mayoría del código no compilado que he visto ha sido scripts de shell y Perl porque los entornos requeridos están aprobados e instalados en una variedad de posibles sistemas de destino.

El hecho de que estos lenguajes sean dinámicos probablemente no sea el problema. Los intérpretes para estos idiomas deben estar aprobados para su uso en los sistemas de destino. Si el intérprete no está aprobado para su uso (o tal vez sí, pero no está implementado en los sistemas de destino), entonces no se puede usar el idioma. El uso de un intérprete determinado (o cualquier aplicación) en un sistema seguro requiere cualquier número de obstáculos de seguridad: análisis de la fuente, la capacidad de compilar desde la fuente para entornos de destino, análisis adicional de los binarios, garantizar que no haya conflictos con la infraestructura existente, etc.

Thomas Owens
fuente
32

Pasé algún tiempo entrevistando con el Departamento de Defensa (DOD), para obtener un código de posición para la MMU del F-16 . Sin violar ninguna divulgación: la MMU es la unidad de computadora que controla casi todas las funciones del F-16. Es (obviamente) crítico que no se produzcan errores, como errores de tiempo de ejecución, durante el vuelo. Es igualmente crítico que el sistema realice operaciones informáticas en tiempo real.

Por esta y otras razones históricas, todo el código para este sistema está escrito o compilado en ADA, un lenguaje de programación estático orientado a objetos .

Debido a las características de soporte críticas de seguridad de Ada, ahora se usa no solo para aplicaciones militares, sino también en proyectos comerciales donde un error de software puede tener graves consecuencias, por ejemplo, aviónica y control de tráfico aéreo, cohetes comerciales (por ejemplo, Ariane 4 y 5), satélites y otros sistemas espaciales, transporte ferroviario y banca. Por ejemplo, el software del sistema de vuelo por cable en el Boeing 777 fue escrito en Ada.

Odio citar demasiado, pero esto explica muy bien por qué se usan exactamente lenguajes estáticos (como ADA) para proyectos como este:

Se admite una gran cantidad de comprobaciones en tiempo de compilación para ayudar a evitar errores que no serían detectables hasta el tiempo de ejecución en otros idiomas o requerirían que se agreguen comprobaciones explícitas al código fuente. Por ejemplo, la sintaxis requiere el cierre explícito de bloques para evitar errores debido a tokens finales no coincidentes. La adherencia al tipeo fuerte permite la detección de muchos errores comunes de software (parámetros incorrectos, violaciones de rango, referencias no válidas, tipos no coincidentes, etc.) ya sea durante el tiempo de compilación o durante el tiempo de ejecución. Como la concurrencia es parte de la especificación del lenguaje, el compilador puede en algunos casos detectar posibles puntos muertos. Los compiladores también suelen buscar identificadores mal escritos, visibilidad de paquetes, declaraciones redundantes, etc. y pueden proporcionar advertencias y sugerencias útiles sobre cómo solucionar el error.

Ada también admite comprobaciones en tiempo de ejecución para proteger contra el acceso a la memoria no asignada, errores de desbordamiento del búfer, violaciones de rango, errores fuera de uno, errores de acceso a la matriz y otros errores detectables. Estas comprobaciones pueden desactivarse en aras de la eficiencia del tiempo de ejecución, pero a menudo pueden compilarse de manera eficiente. También incluye instalaciones para ayudar a la verificación del programa. Por estas razones, Ada se usa ampliamente en sistemas críticos, donde cualquier anomalía puede tener consecuencias muy graves, por ejemplo, muerte accidental, lesiones o pérdidas financieras graves. Los ejemplos de sistemas donde se usa Ada incluyen tecnología de aviónica, ferrocarriles, banca, militar y espacial.

La gestión dinámica de la memoria de Ada es de alto nivel y de tipo seguro. Ada no tiene "punteros" genéricos (y vagos); ni declara implícitamente ningún tipo de puntero. En cambio, toda la asignación y desasignación de memoria dinámica debe realizarse a través de tipos de acceso declarados explícitamente. Cada tipo de acceso tiene un grupo de almacenamiento asociado que maneja los detalles de bajo nivel de la administración de memoria; el programador puede usar el grupo de almacenamiento predeterminado o definir otros nuevos (esto es particularmente relevante para el acceso no uniforme a la memoria). Incluso es posible declarar varios tipos de acceso diferentes que todos designan el mismo tipo pero usan diferentes agrupaciones de almacenamiento. Además, el lenguaje proporciona comprobaciones de accesibilidad, tanto en tiempo de compilación como en tiempo de ejecución, que aseguran que un valor de acceso no pueda sobrevivir al tipo de objeto al que apunta.

Michael Jasper
fuente
3
"Debido a las características de soporte críticas de seguridad de Ada, ahora [se utiliza en] cohetes comerciales (por ejemplo, Ariane 4 y 5)" , por supuesto, el primer Ariane 5 explotó debido a un error de software , por lo que no hay bala de plata.
Andrew Marshall
55
@ AndrewMarshall: "Aunque el informe identificó un error de software como la causa directa, otros investigadores ven las causas como fallas de diseño del sistema y problemas de administración". Dudo seriamente que el código escrito en un lenguaje diferente (por ejemplo, Java o C ++) haya recibido cohete a órbita.
Martin Schröder
@ MartinSchröder Oh, no dudo que Ada aún sea superior a los demás para esta aplicación, solo noto que no es infalible. Otro idioma podría haber dejado pasar innumerables errores que simplemente no hubieran sido posibles en Ada.
Andrew Marshall
13

Tanto DoD como NASA tienen una larga historia con fallas de programación que les costaron miles de millones de dólares. Ambas instituciones han aceptado procesos que deberían protegerlos de la repetición de los mismos errores.

Is this the government being slow to adopting new technologies?

Esta es una idea errónea: los lenguajes dinámicos no son una tecnología nueva, son bastante antiguos. El problema es que si alguna vez tuvo un problema causado por un lenguaje dinámico (por ejemplo, por un tipeo débil / dinámico) y ese problema le costó mucho dinero, podría aceptar una política que le impediría volver a cometer el mismo error, por ejemplo Prohibir el uso de lenguajes dinámicos en sistemas sensibles.

Los lenguajes dinámicos a menudo "tragan" errores y terminan con un comportamiento inesperado. Esto es muy peligroso en sistemas sensibles. Si sucede algo incorrecto, desea saberlo lo antes posible.

Si se trata de seguridad, sería necesario ver el caso de uso real. Por ejemplo, no creo que una página web de Ruby on Rails sea automáticamente menos segura que una página web de Java.

Sulthan
fuente
2
En mi humilde opinión, más errores han sido "tragados" por desbordamientos de búfer no detectados que cualquier otra cosa, que es precisamente algo que la mayoría de los lenguajes dinámicos no permitirán en primer lugar ... solo digo
miraculixx
@miraculixx Es cierto, hay una razón por la cual Java / C # y lenguajes similares se usan mucho más que Ruby. Están a la defensiva, comprueban todo. En C / C ++, la defensa puede hacerse cumplir mediante el uso de un buen estándar de codificación. También puede aplicar controles para todo. Pero, ¿te imaginas escribir una aplicación sensible en ruby ​​o javascript? La posibilidad de errores ocultos es genial.
Sulthan
De hecho, puedo. Es probable que estemos de acuerdo en que el software debe probarse a fondo, independientemente del lenguaje de programación. Para evitar regresiones, las pruebas se automatizan mejor utilizando, por ejemplo, pruebas unitarias, BDD et al. Presumiendo un enfoque profesional (aplicación sensible, ¿verdad?), Lograr una cobertura de prueba suficiente es un proceso administrado, no dejado al azar. Con eso, dudo que C / C ++, Java tenga una ventaja sobre los gustos de ruby ​​o javascript en términos de errores ocultos. Habilidades de programador? Probablemente más técnico con C ++, dudoso con Java, pero difícilmente un problema de lenguaje. Más técnico! = Calidad del producto.
miraculixx
6

Me gustaría agregar a las respuestas existentes describiendo SA-CORE-2014-005 de Drupal , que es una vulnerabilidad muy crítica que permite la inyección de SQL y, en última instancia, la ejecución de código arbitrario. Está causada por las reglas de tipeo dinámico y tipeo de ejecución laxa de PHP.

La totalidad del parche para este problema es:

-      foreach ($data as $i => $value) {
+      foreach (array_values($data) as $i => $value) {

Este código es parte de una capa de abstracción de SQL diseñada para evitar la inyección de SQL. Toma una consulta SQL con parámetros con nombre y una matriz asociativa que proporciona un valor para cada parámetro con nombre. Se permite que el valor sea una matriz, en casos como WHERE x IN (val1, val2, val3), donde los tres valores se pueden pasar como un solo valor de matriz para un único parámetro con nombre.

La vulnerabilidad se produce porque el código se supone que $ien $i => $valuedebe haber un índice entero del valor. Continúa y concatena este "índice" directamente en la consulta SQL como parte del nombre de un parámetro, porque los enteros no necesitan ningún escape, ¿verdad?

Desafortunadamente para Drupal, PHP no ofrece tal garantía. Es posible pasar otra matriz asociativa, cuyas claves son cadenas, y este bucle concatenará felizmente la clave de cadena en la consulta, tal como está (recuerde que el código cree que solo puede ser un entero).

Si bien hay formas de tener un error similar en un lenguaje de tipo estático, es poco probable. Un buen desarrollador consideraría las posibles cosas $iantes de concatenarlo en la consulta. Con un lenguaje tipado estáticamente, es muy fácil hacer cumplir que $idebe ser un número entero, y en un código sensible a la seguridad como este, seguramente se haría.

Además, el código realmente comprueba si el valor es una matriz antes de iterar sobre los elementos. Y aquí se encuentra una segunda parte de la falla que habilita esta vulnerabilidad: tanto una matriz asociativa como una matriz "normal" son verdaderas para is_array. Si bien también es cierto que en C #, tanto los diccionarios como las matrices lo son IEnumerable, es difícil construir código que combine las claves del diccionario con índices de matrices como este, incluso intencionalmente, y mucho menos accidentalmente.

Roman Starkov
fuente
2

Si una base de código es segura o no depende de cómo escriba su código, cómo lo pruebe y cómo valide y monitoree su proceso de desarrollo e implementación. Los idiomas no son seguros ni inseguros, así es como codifica.

La mayoría de los incidentes de seguridad debidos a entradas maliciosas (inyecciones de sql, desbordamientos de búfer), virus, rootkits y troyanos. Ningún idioma puede protegerte de eso.

Por lo tanto, prohibir las clases de idiomas por ser "inseguros" no es una razón válida.

Sospecho que alguien, por cualquier razón, informado o no, decidió prohibir estos idiomas. Después de un tiempo se convirtió en una verdad organizacional . Puede haber sido cierto en ese momento para algunos proyectos, pero las culturas de control no están interesadas en cambiar las decisiones (admitir que estaban equivocadas) y prefieren reglas simples. Prosperan con las reglas y regulaciones y no importa si tienen sentido o no, lo que cuenta es la seguridad percibida .

Esto sucede todo el tiempo en las culturas de control. Lo veo más o menos a diario. No tiene sentido, pero así es como funciona. Si desea leer más sobre este tema tan relevante, le recomiendo el libro de Schneider " La alternativa de reingeniería ". Aquí hay un diagrama de cultura de Michael Sahoto / Agilitrix , basado en el libro de Schneider: ingrese la descripción de la imagen aquí

Martin Wickman
fuente
18
-1 Existen muchas razones técnicas válidas por las que se elegiría un idioma sobre otro (verificación en tiempo real, tipeo estático, tiempo de ejecución) para sistemas críticos de seguridad. Usted implica que los motivos son 100% culturales, nosotros contra ellos, y arbitrarios, lo cual es totalmente incorrecto en este caso.
Michael Jasper
8
"Los idiomas no son seguros ni inseguros": consulte stackoverflow.com/a/14313277/602554 . Algunos idiomas son definitivamente "más seguros" que otros.
Michael Jasper
2
Actualicé mi respuesta, tal vez a tu gusto. Todavía creo que la seguridad de un sistema es que depende más del código que escribes que del idioma que utilizas, aunque algunos idiomas ayudan a evitar ciertos problemas (mientras que posiblemente introducen otros).
Martin Wickman
2
@MartinWickman: a) Algunos sistemas de tipo resuelven las inyecciones SQL / HTML y los desbordamientos del búfer: tiene diferentes tipos de entrada con escape y sin escape para que sepa cuál debe tratarse de qué manera. b) no todos los problemas de seguridad en 'proyectos seguros' necesariamente significan compromiso. No quiero que el software que ejecuta el avión tenga ningún error, incluso si no es un problema de "seguridad" (es decir, no se puede utilizar para hacerse cargo del sistema).
Maciej Piechotka
55
-1 para problemas de precisión fáctica. Las vulnerabilidades de desbordamiento del búfer son un problema muy específico del lenguaje C; nunca escuchas sobre ellos en idiomas que no te permiten asignar un búfer de cadena en la pila. Y no es del todo difícil imaginar un dialecto hipotético de SQL en el que el uso de parámetros no se permitía simplemente sino que se requería . La inyección de SQL sería imposible en este lenguaje. Entonces, sí, un lenguaje diseñado adecuadamente puede protegerlo de varios tipos comunes de ataques.
Mason Wheeler
2

Por lo que puedo decir, la política oficial del Departamento de Defensa generalmente no prohíbe los lenguajes dinámicos.

Las normas para el software desarrollado o adquirido por el DoD son promulgadas por la Agencia de Sistemas de Información de Defensa (DISA). Su seguridad de las aplicaciones - Seguridad de Aplicaciones y Desarrollo guía de implementación técnica de seguridad (STIG) no prohíbe cualquier idioma en particular. No menciona a Ruby, pero menciona a Perl y Python que son igualmente dinámicos. Los menciona en el contexto de varios temas (siguiendo los estándares de codificación establecidos, evitando vulnerabilidades de inyección de comandos, etc.).

Probablemente lo que está viendo es una herramienta de escaneo demasiado estricta (hay varias diferentes mencionadas en el STIG, cada una puede tener su propia interpretación de las reglas) y / o una interpretación demasiado estricta de su salida.

Andrew Medico
fuente