¿Los lenguajes de programación de alto nivel tienen más vulnerabilidades o riesgos de seguridad que los lenguajes de bajo nivel? [cerrado]

Importante advertencia al frente:

Es posible ser inseguro en cualquier idioma, en cualquier momento, y solo la atención / conciencia del desarrollador puede solucionar este problema. La inyección SQL es sigue siendo una cosa . Los idiomas de nivel superior generalmente tienen eval , y si eres lo suficientemente tonto como para evaluar los comentarios del usuario, obtienes lo que obtienes.

Dicho esto, es al revés. Tener recolección de basura evita clases enteras de riesgos de seguridad relacionados con la administración de la memoria, como los desbordamientos de búfer. Los lenguajes de nivel superior tienden a ser más concisos, menos código significa menos lugares para que se escondan los errores. Cualquier cosa que sea tediosa (y la codificación en lenguajes de bajo nivel es eso) es propensa a errores.

Debido a que los lenguajes de nivel inferior carecen de la misma expresividad, uno tiene que escribir una gran cantidad de código repetitivo no solo al principio sino a lo largo de toda la base de código. Eso significa que, debido a que no siempre es fácil decir de un vistazo lo que se supone que debe hacer el código (en términos de lógica de negocios), será menos autodocumentado y requerirá más documentación en forma de comentarios o documentos externos. . Eso introduce otra fuente de error: si la documentación no se actualiza cuando el código al que hace referencia cambia, puede escribir otro código que sea inseguro debido a las suposiciones obsoletas en la documentación del código relacionado.

Los lenguajes de nivel inferior carecen de escritura fuerte, por lo que hay menos errores que un compilador puede detectar. Ha habido algunos intentos interesantes como Nim y Rust para solucionar este problema, pero ninguno de los dos es súper popular todavía.

Por último, pero no menos importante, la diferencia real entre los idiomas de alto y bajo nivel es que los lenguajes de alto nivel transfieren la carga del programador al intérprete / compilador. Esos intérpretes / compiladores están escritos y mantenidos por algunas de las luces más brillantes de la industria, son auditados rutinariamente para detectar vulnerabilidades, etc. El código de la aplicación, por otro lado, está escrito por los mortales. De modo que pasar la carga de muchos códigos de aplicación escritos por programadores promedio a comparativamente menos código escrito por programadores excepcionales debería mejorar la seguridad porque hay menos código para auditar escritos por personas más capaces. Entonces, ¿en qué preferirías confiar, la gestión manual de búferes de JVM o Joe Blow en C?

Todo esto más bien plantea la pregunta de por qué las personas todavía usan lenguajes de bajo nivel si son más difíciles de usar y menos seguros. Hay una serie de razones:

1) The golden hammer . "Tenemos un montón de programadores de C, y por extraño que parezca, todo nuestro código está escrito en C '.

2) Rendimiento. Por lo general, esto es una pista falsa, casi nunca vale la pena el compromiso de seguridad y velocidad de desarrollo, pero en casos como juegos en los que necesita sacar todo el rendimiento del hardware, puede tener sentido.

3) Plataforma oscura. En las líneas anteriores, es mucho más fácil escribir un compilador de C que un compilador de Rust o una JVM. Si tiene que implementar el compilador primero, comenzar con C parece mucho más atractivo.

Según mi búsqueda extensa en Google, el primer resultado me dio este respuesta .

En resumen: meh.

El estudio es de Veracode, y observan que es principalmente un lavado. Se basan en la vulnerabilidad según la densidad del código, lo que podría ser una buena forma de medirlo, no lo sé. Lo que sí sé es que terminas con un gran sesgo porque C / C ++ tomará 10 veces más líneas de código para escribir una aplicación determinada que otros idiomas.

Además, lo que vemos probablemente no es una medida real de la vulnerabilidad, sino de la posibilidad de encontrar una vulnerabilidad debido a la popularidad o disponibilidad de la (s) aplicación (es) dada (s). El número de vulnerabilidades supuestamente más bajo se encontró en C / C ++, seguido de iOS (probablemente Objective-C?), Pero luego de JavaScript. Pero si tomas el aspecto de la densidad, podrías estar mirando números sesgados.

Aquí está la cosa: las vulnerabilidades son simplemente errores. Los idiomas no escriben errores, pero los desarrolladores sí, por lo que el desarrollador debe producir código libre de errores. Como tal, cuanto más difícil es para el desarrollador producir código libre de errores, es más probable que exista una vulnerabilidad de algún tipo . Por lo tanto, esto significa que es más probable que los lenguajes de bajo nivel tengan vulnerabilidades, independientemente de si realmente lo tienen.