¿Lenguajes de programación para la seguridad? [duplicar]

Los lenguajes de nivel inferior como C y C ++ pueden denominarse lenguajes "inseguros" porque asignan mucha responsabilidad al programador para hacer las cosas bien. Por ejemplo, cuando accede al elemento de matriz arr[i] , el compilador de C asume que el programador sabe lo que está haciendo y que i es un índice válido para la matriz arr .

Los lenguajes de nivel superior como C # y Java tratan al programador como a un idiota y hacen verificaciones en tiempo de ejecución para asegurarse de que arr apunta a una ubicación de memoria válida, que i es un índice válido para esta matriz, etc. los controles de tiempo de ejecución agregan gastos generales, pero en aplicaciones de consumo donde la eficiencia no es tan importante como mantener bajos los costos de desarrollo.

Si está interesado en la seguridad, le sugiero que estudie C y C ++, ya que se encontrará cara a cara con problemas como desbordamientos de búfer, daños en el montón, uso después de liberaciones, etc.

Los lenguajes de nivel superior, como Java, están diseñados para personas que no conocen o no se preocupan por la seguridad y hacen todo lo posible para ocultar estos problemas tanto al usuario como al programador, lo que no lo ayudará a aprender sobre estos problemas. solo te enseño a ignorarlos.

Muchas aplicaciones están escritas en lenguajes de alto nivel, pero los lenguajes de bajo nivel siempre serán relevantes porque alguien necesita construir las plataformas que ejecutan el nivel superior. Casi todos los entornos de tiempo de ejecución de Java están escritos en C ++ y casi todos los sistemas operativos están escritos en C. Los lenguajes de script como Python Ruby y Perl están escritos en C. Ruby puede ser un lenguaje seguro para programar, pero siempre puede haber un error en el máquina virtual subyacente.

Supongo que cada idioma tiene sus pros y sus contras desde la perspectiva de la seguridad, pero no estoy seguro de que puedan clasificarse necesariamente en la escala de peor a mejor.

Muchos idiomas, por ejemplo, son específicos del dominio y, por lo tanto, es posible que no se les aplique una categoría completa de implicaciones de seguridad (o incluso que sean comparables). Por ejemplo, SQL es un lenguaje, pero no está basado en la pila, por lo que no tiene un concepto de pila de llamadas (a pesar de la declaración exec ) y, por lo tanto, los ataques de corrupción de pila no son aplicables al lenguaje SQL en sí (pero aún puede ser aplicable a SQL DB y / o analizador). Así que podría argumentar que es más seguro (es decir, "mejor" como lo definió), aunque realmente no veo cómo puede comparar los dos, ya que los dos tienen capacidades, aplicabilidad, propósito, etc. muy diferentes.

En otros casos, los idiomas pueden depender de la implementación. En otras palabras, depende de que el intérprete / compilador siga las especificaciones del idioma y las especificaciones no sean ambiguas. El mismo puede caer en errores de codificación / lógica.

C # ciertamente tiene algunos mecanismos integrados en el lenguaje / marco que resuelve algunos de los puntos débiles en comparación con C / C ++. El desbordamiento de búfer es ciertamente un vector de ataque popular, ya que es demasiado fácil hacer esta categoría de error en C / C ++, y C # lo hace más difícil (aunque no imposible, ya que permite unsafe construcciones), pero también tiene su trampas . (Dicho esto, dada la elección y la idoneidad de ambos idiomas para una tarea determinada, es probable que elija C # en lugar de C ++, en parte porque hace que algunos de estos aspectos sean más fáciles de tratar.) Sin embargo, las vulnerabilidades como SQLI o XSS no son El lenguaje depende (aunque quizás dependa del marco), sino que son errores de salubridad / lógica de datos. Supongo que un sitio web desarrollado en cualquier idioma (a diferencia del marco) tendría susceptibilidad a XSS / SQLI si no fuera cuidadoso. Ciertamente, ningún lenguaje puede proteger definitivamente de un programador que expone datos que no deberían exponerse debido a errores lógicos.