¿Por qué la protección contra la inyección SQL no es una prioridad alta?

En Stack Overflow, veo una gran cantidad de código PHP en preguntas y respuestas que tienen consultas MySQL que son altamente vulnerables a los ataques de inyección SQL, a pesar de que las soluciones básicas están ampliamente disponibles durante más de una década.

¿Hay alguna razón por la cual estos tipos de fragmentos de código todavía se usan hoy?

Creo que se debe principalmente a a) ignorancia b) pereza. Los principiantes generalmente no saben mucho sobre la inyección sql, e incluso cuando lo escuchan, lo ignoran porque es mucho más simple y fácil de codificar de esa manera.

PHP hace que sea muy fácil para las personas que saben muy poco crear páginas web dinámicas útiles. Esto significa que PHP atraerá a muchos principiantes, que crearán algo útil, aprenderán de otros ejemplos útiles y se darán la vuelta para enseñar a otros cómo hacer esta cosa genial y útil. El resultado es una gran cantidad de códigos incorrectos y una oferta de programadores que no conocen mejor.

Solo empeora las cosas que una gran fracción de programadores competentes no quieren tener nada que ver con PHP. Esto reduce la base de personas experimentadas que están dispuestas a enseñar mejor a otros. Pero, ¿por qué evitan PHP? Bien por una combinación de factores. En parte no les gusta lidiar con las verrugas del lenguaje. Y en parte es porque preferirían trabajar con un buen código, y no hay muchos PHP buenos por ahí.

Esta constelación exacta de problemas solía infligir Perl. Como un ejemplo brillante, considere el caso de Matt Wright, un adolescente entusiasta que se propuso proporcionar muchos scripts CGI útiles, bien documentados y fáciles de instalar en la década de 1990. Desafortunadamente no entendió nada sobre seguridad, y tampoco las personas que querían usar sus cosas. El resultado fueron los Archivos de Script de Matt Wright, que era un flujo interminable de problemas de seguridad para los primeros scripts CGI. A pesar de esfuerzos como http://www.scriptarchive.com/nms.html , el problema no mejoró para Perl hasta que los proveedores de alojamiento compartido hicieron PHP más conveniente que cualquier otra cosa. Eso condujo al problema de pasar de Perl a PHP.

Desafortunadamente, hay toneladas de tutoriales PHP más que malos y algunos libros PHP más antiguos también apestan al decirle a la gente que escriba el código adecuado (no usar register_globals, etc.).

Además, al magic_quotes_gpcestar habilitado en el pasado, a las personas no les importaba escapar porque "simplemente funcionaba".

Personalmente, creo que PHP es fácil de usar, por lo que, naturalmente, es fácil de usar mal.

Como humano y programador, me resulta notablemente fácil cometer errores y pasar por alto ciertas cosas, especialmente cuando se me presiona por el tiempo.

Es fácil, y tal vez demasiado tentador, culpar a cierto idioma por ser demasiado accesible por su propio bien. Pero eso sería pasar por alto el gran problema de la falibilidad humana, independientemente del idioma elegido para programar.

De acuerdo, hemos recorrido un largo camino desde el lenguaje ensamblador, y creo que sería una programación mucho más productiva en un lenguaje más moderno, como PHP, Python, Ruby o Java.

PHP (y otros lenguajes de secuencias de comandos) de hecho han reducido la barrera de entrada. Eso puede significar que más recién llegados a la programación prueben PHP primero. Pero eso ciertamente no significa que todos los programadores de PHP estén de alguna manera menos calificados o menos capaces de aprender de sus errores que los programadores de otros lenguajes.

Rasmus Lerdorf creó PHP en su forma original en 1994, ha evolucionado considerablemente desde entonces. En su encarnación más moderna, admite programación orientada a objetos, así como marcos excelentes, como Symfony. PHP como lenguaje se ha liberado de sus restricciones originales y ha crecido para ofrecer una gran flexibilidad en cómo los programadores pueden elegir usarlo. Puede usarlo para crear un script de 9,000 líneas de código de espagueti, o puede usarlo dentro del contexto de un marco MVC moderno, como Symfony: ¡es su elección!

Sospecho firmemente que las vulnerabilidades de seguridad no están restringidas a un solo idioma. Es tentador descartar a todos los programadores PHP como de alguna manera menos capaces o más propensos a escribir código inseguro. Pero me pregunto cuánto de eso es el sesgo del lenguaje, y cuánto de eso es un hecho.

Creo que parte del problema son las personas que simplemente copian el código sin molestarse en aprender lo que están haciendo, pero en mi opinión, la forma en que enseñamos porgamnming está rota y es una de las razones por las que hay tanto código malo. Enseñamos la sintaxis fuera de contexto, por lo que los principiantes no saben cuándo usar algo y cuándo no, o qué problemas se pretende resolver con la sintaxis y qué problemas no se pretende resolver. Entonces usan un martillo cuando una llave inglesa hubiera sido la mejor herramienta.

Entonces, por ejemplo, en lugar de enseñar solo la sintaxis, organiza el curso como (Claramente, habría más pasos, este es solo un ejemplo básico de construcción de problemas básicos a problemas más complejos en lugar de solo enseñar sintaxis):

1. Así es como configuras una página web básica
2. Así es como haces que la página web extraiga datos de una base de datos
3. Así es como se envían datos desde una página web a una base de datos
4. Así es como se asegura de que se envíen los datos correctos.
5. Así es como protege su base de datos contra la entrada de datos maliciosos

Creo que encontrará una cantidad similar de ejemplos de MS SQL + ASP / ASP.NET que son igual de vulnerables.

Creo que el problema se debe en parte al hecho de que cuando intentas enseñar algo, por ejemplo, filtrar datos usando una cláusula WHERE, entonces realmente no quieres saturar tu ejemplo escapando adecuadamente de tu cadena de consulta o usando un comando parametrizado.

He estado entrenando desarrolladores durante muchos años y puedo empatizar con personas que escriben códigos horribles en tutoriales. A veces eso es lo más fácil de entender. Sin embargo, aparte, siempre señalo el código que es vulnerable y lo convierto en un tema secundario interesante.

El autor original de PHP, Rasmus Lerdorf , en su infame entrada de blog aboga por el desarrollo "sin marco" . Aunque para consultas SQL usa PDO, entonces no hay riesgo de inyección SQL. Todavía es bastante feo y obsoleto en comparación con los marcos MVC modernos con capas ORM.

Puede culpar a esta mala práctica en el propio PHP. Las versiones heredadas de PHP (hasta alrededor de 2006) escaparían de todas las variables de entrada GET y POST para que fueran adecuadas para la interpolación de consultas de la base de datos POR DEFECTO. Ver http://php.net/manual/en/security.magicquotes.php

No confunda el propósito de un tutorial, que es demostrar algo simplemente con lo que debe hacerse en un entorno de producción. Por ejemplo, la mayoría del código tutorial que he escrito tiene poca o ninguna verificación de error / excepción. Intento recordarle al lector que el código solo demuestra cómo realizar una tarea específica, no cómo cubrir todos los resultados posibles.

Cuando estaba aprendiendo PHP, miré algunos de estos libros de PHP + MySQL, y sí, siento que contribuye a esa mala práctica. Pero tengo simpatía, porque están enseñando el idioma , no buenas prácticas de programación. De lo contrario, ¿dónde terminaría?