En Stack Overflow, veo una gran cantidad de código PHP en preguntas y respuestas que tienen consultas de MySQL que son altamente vulnerables a los ataques de inyección de 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 que estos tipos de fragmentos de código aún se estén utilizando en la actualidad?
Creo que se debe principalmente a a) la ignorancia b) la pereza. Los principiantes generalmente no saben mucho acerca de la inyección de SQL, e incluso cuando se enteran, lo ignoran porque es mucho más simple y fácil de codificar de esa manera.
PHP deliberadamente hace que sea muy, 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 crean algo útil, aprenden de otros ejemplos de apariencia útil y se vuelven para enseñar a otros cómo hacer esta cosa genial y útil. El resultado es una gran cantidad de código incorrecto y una cantidad de programadores que no conocen nada mejor.
Solo empeora las cosas, ya que una gran parte de los 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? Bueno para 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 un montón de PHP bueno por ahí.
Esta constelación exacta de problemas utilizados para infligir Perl. Como 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 entendía nada acerca de la seguridad, y tampoco la gente que quería usar sus cosas. El resultado fue el Matt Wright Script Archives, que fue un flujo interminable de problemas de seguridad para los primeros scripts CGI. A pesar de esfuerzos como enlace , el problema no mejoró para Perl hasta que los proveedores de alojamiento compartido hicieron que PHP fuera más conveniente que cualquier otra cosa. Eso llevó al problema de pasar de Perl a PHP.
Desafortunadamente, hay toneladas de tutoriales de PHP más que malos y algunos libros de PHP más antiguos también apestaron a las personas para que escriban el código correcto (sin usar register_globals, etc.).
Además, con magic_quotes_gpc habilitado en el pasado, a las personas no les importaba escapar porque "simplemente funcionó".
Personalmente, creo que PHP es fácil de usar, así que, naturalmente, es fácil de usar mal.
Como humano, y como programador, encuentro que es muy fácil cometer errores y pasar por alto ciertas cosas, especialmente cuando se presiona por el tiempo.
Es fácil, y quizás demasiado tentador, culpar a cierto lenguaje, por ser demasiado accesible para su propio bien. Pero eso sería pasar por alto el problema más amplio de la falibilidad humana, independientemente del lenguaje elegido para programar.
Por supuesto, hemos avanzado mucho 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.
De hecho, PHP (y otros lenguajes de script) han reducido la barrera de entrada. Eso puede significar que más recién llegados a la programación prueben PHP primero. Pero eso 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 idiomas.
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 la forma en que los programadores pueden elegir usarlo. Puedes usarlo para crear un script de código de espagueti de 9,000 líneas, o puedes usarlo dentro del contexto de un marco MVC moderno, como Symfony: ¡es tu elección!
Sospecho firmemente que las vulnerabilidades de seguridad no están restringidas a un solo idioma. Es tentador descartar a todos los programadores de PHP como algo menos capaces, o más propensos a escribir código inseguro. Pero me pregunto cuánto de eso es sesgo de lenguaje y cuánto de eso es un hecho.
Creo que parte del problema está en las personas que simplemente copian el código sin molestarse en aprender lo que están haciendo, pero realmente, en mi opinión, la forma en que enseñamos que se está rompiendo el porgamnming es una de las razones por las que hay tanto código malo. . Enseñamos la sintaxis fuera de contexto y, por lo tanto, los principiantes no saben cuándo usar algo y cuándo no o qué problemas pretende resolver la sintaxis y qué problemas no pretende resolver. Así que usan un martillo cuando una llave hubiera sido la mejor herramienta.
Entonces, por ejemplo, en lugar de solo enseñar la sintaxis, organiza el curso de la siguiente manera (Claramente, habría más pasos, esto es solo un ejemplo básico de la construcción de problemas básicos a problemas más complejos en lugar de solo enseñar sintaxis):
Creo que encontrará una cantidad similar de ejemplos de MS SQL + ASP / ASP.NET que son igualmente vulnerables.
Creo que el problema se debe en parte al hecho de que cuando intenta enseñar algo, por ejemplo, filtrar datos con una cláusula WHERE, entonces realmente no desea abarrotar su ejemplo al escapar de la cadena de consulta o usar un parámetro parametrizado. comando.
He estado formando desarrolladores durante muchos años y puedo identificarme con las personas que escriben código horrible en tutoriales. A veces eso es lo más fácil de entender. Sin embargo, aparte de eso, siempre señalo el código que es vulnerable y lo convierto en un tema interesante.
El autor original de PHP, Rasmus Lerdorf , en su infame entrada de blog aboga por el desarrollo "no-framework" . Aunque para consultas SQL utiliza PDO, no existe riesgo de inyección SQL. Sigue siendo bastante feo y obsoleto en comparación con los marcos MVC modernos con capas ORM.
Puedes culpar a esta mala práctica del propio PHP. Las versiones heredadas de PHP (hasta el año 2006) escaparían de todas las variables de entrada GET y POST, de modo que fueran adecuadas para la interpolación de consultas de la base de datos POR DEFAULT. Consulte enlace
No confunda el propósito de un tutorial, que es demostrar algo de manera simple, con lo que debe hacerse en un entorno de producción. Por ejemplo, la mayoría de los códigos de tutoriales que he escrito tienen poca o ninguna comprobación de errores / excepciones. 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í creo que contribuye a esa mala práctica. Pero tengo simpatía, porque están enseñando el lenguaje , no buenas prácticas de programación. De lo contrario, ¿dónde terminaría?