No soy técnico y me gustaría su experiencia para entender esto. Recientemente leí un artículo detallado sobre SQLi para un trabajo de investigación.
Me parece extraño. ¿Por qué siguen ocurriendo tantas violaciones de datos a través de la inyección SQL? ¿No hay una solución?
No hay una solución general para SQLi porque no hay una solución para la estupidez humana. Existen técnicas establecidas que son fáciles de usar y que solucionan los problemas (especialmente la vinculación de parámetros) pero aún se deben utilizar estas técnicas. Y muchos desarrolladores simplemente no son conscientes de los problemas de seguridad. Lo más importante es que la aplicación funcione y que no le importe mucho la seguridad, especialmente si hace las cosas (incluso un poco) más complejas y conlleva costos adicionales como las pruebas.
Este tipo de problema no está restringido a SQLi, pero lo encontrará con desbordamientos de búfer, comprobación de certificados, XSS, CSRF .... Es más costoso realizar una programación segura debido a las pruebas adicionales y la experiencia adicional que necesita el desarrollador (por lo tanto, más caro). Y mientras el mercado lo prefiera barato y no le importe mucho la seguridad, obtendrá soluciones baratas e inseguras. Y mientras que la seguridad por diseño ayuda mucho a mejorarlo, los desarrolladores a menudo trabajan en torno a este diseño porque no lo entienden y está en su camino.
Porque no es un problema.
¿Cuándo fue la última vez que una empresa con una vulnerabilidad de inyección de SQL fue arrestada en el tribunal y abofeteada con una gran multa por ser imprudente con los datos del usuario, y los directores advirtieron, multaron o encerraron por negligencia?
¿Cuándo fue la última vez que una empresa perdió un gran contrato porque la página de inicio de sesión del sitio web de su empresa no validó las contraseñas correctamente?
¿Cuándo fue la última vez que un regulador / auditor calificado de una organización profesional tuvo que aprobar y firmar un sistema informático público para poder ponerlo en uso?
Usted pensaría que "la gente morirá" sería una razón suficiente para hacer edificios con materiales ignífugos, alarmas y buenas rutas de escape. No fue . Introdujimos normas para forzar materiales de construcción no inflamables, diseños a prueba de incendios con interrupciones contra incendios, alarmas contra incendios.
Usted podría pensar que "la gente morirá" sería una razón suficiente para que a todos les importe el diseño estructural del edificio. No lo es . Simplemente no lo es . Tenemos que tener un reglamento para que los ingenieros calificados firmen los diseños de los edificios, que se diseñen y construyan para usos específicos, y cuando las cosas fallan, la sociedad lleva a los ingenieros a los tribunales .
Usted pensaría que "la gente morirá" sería una razón suficiente para que el procesamiento de alimentos sea limpio y seguro, pero no fue así. t .
La inyección SQL es menos obvia, menos visible públicamente, tiene menos impacto en la gravedad y se encuentra en una industria completamente no regulada.
Incluso para las empresas que se preocupan por ello, no pueden anunciar " No se conocen vulnerabilidades de inyección SQL en nuestro código " como un punto de bala de marketing que a nadie le importa. No es el tipo de pregunta que los clientes hacen a los vendedores. No es una ventaja competitiva para ellos, es un costo, una sobrecarga. Protegerse contra eso hace que sean menos competitivos, se muevan más lentamente y hagan más trabajo por la misma funcionalidad.
Todos los incentivos están alineados para que se mantenga. Así que sigue existiendo.
Haga que la inyección SQL sea un problema para las empresas, y lo hará desaparecer.
[Editar: Pero hay una regulación de la UE que los sitios web tienen que advertirle si usan cookies. Y lo hacen. Por lo tanto, la regulación de los sistemas informáticos públicos para hacerlos más molestos puede entrar en vigor, incluso si la regulación actual es bastante inútil.]
La inyección de SQL sigue existiendo porque el mundo del software aún no comprende que la generación programática de valores estructurados en árbol (como consultas o marcado) se debe realizar mediante la construcción de árboles de sintaxis como objetos de primera clase , no mediante la concatenación de cadenas que representan fragmentos de un idioma.
Ha habido un poco de progreso en los últimos años con la creciente disponibilidad de herramientas del generador de consultas como LINQ to SQL o SQLAlchemy , pero eso está en el lado del lenguaje de programación. Las bases de datos relacionales aún no ofrecen una interfaz alternativa atractiva y estándar que no se basa fundamentalmente en el envío de consultas como cadenas.
Lasdeclaraciones preparadas con parámetros de consulta son apenas una mejora, porque solo son fáciles de usar si la estructura de sus consultas: qué tablas se unen, qué condiciones de filtrado, qué columnas del proyecto es arreglado . Cuando tiene una aplicación que necesita construir texto de consulta en tiempo de ejecución, los parámetros de consulta preparados son un gran dolor para usar.
Entonces, si se pudiera construir un protocolo estandarizado, no textual y estructurado en árbol para describir y comunicar las consultas a la base de datos, y se diseñó para que fuera más fácil de usar que las consultas textuales, eso resolvería el problema a largo plazo. término. Pero el problema no desaparecerá hasta que la industria adopte algo donde el camino de menor resistencia sea seguro. Mientras insistamos en sistemas no seguros por defecto donde escribir código seguro requiere un esfuerzo innecesario, los problemas estarán con nosotros. (Piense en todos los desbordamientos de búfer que no existen en absoluto en lenguajes administrados por memoria)
Tenga en cuenta que el mismo problema fundamental de la inyección SQL afecta a la Web, bajo el nombre de scripts entre sitios , que en realidad es solo una inyección de Javascript en páginas HTML dinámicas. Un patrón muy común es el de los programadores de Javascript que, en lugar de trabajar con el DOM tratándolo como un árbol de objetos, recurren a the innerHTML property para establecerlo en texto HTML creado por una concatenación de cadenas ingenua. Una gran cantidad de vulnerabilidades XSS nunca habrían existido si la propiedad innerHTML nunca se hubiera colocado en las implementaciones DOM de los navegadores.
Además, para las personas que no han visto la charla de Tony Hoare sobre los punteros nulos, es simultáneamente ortogonal (punteros nulos, no inyección SQL) pero al mismo tiempo es increíblemente relevante:
Al realizar la prueba, es muy fácil probar lo que espera que suceda. Por ejemplo, al completar un campo de "nombre" en una base de datos, es probable que elija algo con lo que esté familiarizado, como "John Doe". Esto funciona, y su aplicación parece funcionar bien.
Entonces, un día, alguien llama a su hijo Robert'); DROP TABLE Students; -- (pequeñas tablas de Bobby).
Porsupuesto,nopruebalaaplicaciónparaobtenernombrescomoesos,porloqueelagujerodeseguridadqueexponedichonombresedeslizaatravésdetodassuspruebas.
Aquíhayuncomentariointeresante:
Es fácil probar que existe un agujero de seguridad (solo prueba un nombre como el anterior). También es fácil probar que un agujero particular ha sido arreglado. Es difícil probar que no existen otros agujeros de seguridad.
Steffen hace buenos puntos en su respuesta, pero me gustaría agregar algo más. El por qué, creo, se puede dividir en los siguientes temas:
Así que vamos a dividirlos.
Hay mucho énfasis en la educación del usuario en estos días. Enseñar a los usuarios cómo mantener contraseñas seguras. Enseñar a los usuarios cómo identificar el phishing. Enseñar a los usuarios cómo ... Tienes la idea. Algunas empresas, probablemente muchas, pero solo puedo hablar de mi experiencia profesional y no he trabajado en muchas empresas;), tengo programas de capacitación. Pero esos programas de capacitación pueden estar incompletos o no alcanzar la profundidad del conocimiento necesario. Eso no es menospreciar el arduo trabajo que implica la creación de esos programas. Pero decir que al igual que en el entorno escolar, diferentes personas aprenden de manera diferente. Y a menos que tenga un programa de educación continua para desarrolladores, será difícil comunicarse "use consultas parametrizadas, y aquí le indicamos cómo hacerlo en PHP, Java, Python, Ruby, Scala, NodeJS, ...". Es un trabajo arduo desarrollar, entregar y mantener programas para desarrolladores que lleguen de manera efectiva a la audiencia.
Arriba, una de las cosas a las que aludí fue llegar a la audiencia de manera efectiva para diferentes tipos de aprendizaje. Una de las razones de esto es que muchas empresas tienen una alta tasa de deserción para los desarrolladores, porque los desarrolladores son contratistas que cambian de proyecto a proyecto en diferentes compañías. Y las empresas no siempre están en la misma madurez de seguridad. Es posible que una empresa no tenga un programa de seguridad, mientras que otra puede tener un excelente programa de seguridad y el desarrollador es repentinamente bombardeado con nueva información que se les solicitará durante los seis meses antes de mudarse a otra compañía. Es triste, pero sucede.
Entrega del proyecto a tiempo, o incluso antes de lo previsto. Lamentablemente, el camino más rápido para completar el proyecto no es completar el proyecto con controles de seguridad. Se está haciendo de la manera más rota que todavía funciona. Sabemos que causará más trabajo, más tiempo y más dinero más adelante cuando llegue el momento de mantener el proyecto y solucionar los problemas, pero la administración solo quiere que el proyecto salga.
Otro tema que mencioné es el desarrollo de programas de capacitación en seguridad para una gran variedad de lenguajes de programación. Muchas empresas no tienen uno o dos idiomas establecidos. Así que a los desarrolladores les gusta (o se les anima) probar el nuevo hotness. Eso incluye lenguajes y marcos. Esto significa que los programas de seguridad deben evolucionar continuamente.
Y aquí estamos en la gestión. Cada vez, parece que en una brecha pública, hubo controles que podrían haberse implementado, que no son tan difíciles, pero que se pasaron por alto. Empuja a entregar productos primero y luego a preocuparse siempre, a pesar de lección tras lección tras lección, las compañías de productos regresan. La administración debe empujar desde la parte superior para tomarse el tiempo de construir seguridad al principio. Deben comprender que se gastará más trabajo, más tiempo y más dinero para solucionar problemas, mantener el producto y pagar multas. Pero los análisis de costo-beneficio apuntan a que el problema es la entrega del producto, no las multas o el trabajo de mantenimiento requerido. Esas ecuaciones deben cambiar, y eso se debe, en parte, a la educación (wooo, círculo completo) a nivel de MBA. Se debe enseñar a los gerentes de negocios que para tener éxito en un panorama de infracciones cada vez mayores, la seguridad debe estar al frente y en el centro.
El por qué, a pesar de que SQLi tiene casi 20 años, está lleno de varias razones. Como profesionales de la seguridad, solo podemos hacer mucho para educar y crear conciencia de lo que sucede cuando la seguridad no se considera parte integral del SDLC.
Estoy de acuerdo con muchas de las respuestas, pero no se menciona un punto muy importante: el código no se arregla mágicamente por sí mismo, y hay muchos códigos que tienen 17 años. He visto a muchas compañías escribir nuevos códigos limpios y seguros, mientras que la aplicación aún podría ser atacada en algunas de sus secciones más antiguas. Y lo peor de todo: reparar el código antiguo es costoso, porque requiere que los desarrolladores profundicen en el código que fue escrito en una era diferente con diferentes estilos de codificación y diferentes tecnologías. A veces, corregir el código antiguo para no causar inyecciones SQL requiere que se vuelvan a crear bibliotecas completas que se compraron en el pasado (esto es algo que tuve que hacer hace un par de años).
No quiere decir que todo el nuevo código esté libre de inyecciones de SQL, pero personalmente no he visto ningún código nuevo escrito profesionalmente en los últimos 4 o 5 años que lo contenía. (La única excepción es cuando los desarrolladores tienen que corregir el código antiguo y usar el mismo estilo / tecnología en el que está escrito el resto del código).
Creo que es porque muchos desarrolladores aprenden lo suficiente como para hacer el trabajo, por algún valor de "hecho". Aprenden cómo crear código SQL, a menudo de tutoriales en línea obsoletos, y luego cuando el código "funciona" en la medida en que pueden decir "Puedo poner cosas en la base de datos, y puedo generar la página de resultados", entonces está satisfecho.
Considera a este tipo en la escalera:
¿Por qué está haciendo eso? ¿Por qué no tiene andamios adecuados? Porque está haciendo el trabajo. Coloque la escalera contra la pared que está sobre las escaleras, y funcionará bien. Hasta que no lo haga.
Lo mismo con INSERT INTO users VALUES($_POST['user']) . Funciona bien Hasta que no lo haga.
La otra cosa es que no son conscientes de los peligros. Con el chico en la escalera inestable, entendemos la gravedad y la caída. Al construir declaraciones SQL a partir de datos externos no validados, no saben qué se puede hacer.
Hablé con un grupo de usuarios de desarrolladores web el mes pasado y, de los 15 desarrolladores de la audiencia, dos habían oído hablar de inyección de SQL.
Creo que la razón principal es que la capacitación para desarrolladores no comienza con las mejores prácticas, sino que comienza con la comprensión del lenguaje. Por lo tanto, los nuevos programadores, creyendo que han sido entrenados con las herramientas para crear algo, proceden a crear las consultas de la forma en que han sido enseñados. El siguiente y más peligroso paso es permitir que alguien desarrolle cualquier cosa sin revisar y, por lo tanto, continúe la oportunidad de tomar decisiones más pobres sin saber que hay algo malo en ello y producir hábitos adicionales que ignoran las mejores prácticas aceptadas en toda la industria. Entonces, para resumir, programadores poco capacitados que operan en un entorno que no valora nada más que el producto final.
No tiene nada que ver con la inteligencia o la "estupidez humana". Existe un enfoque sistemático que ha sido bien definido a lo largo de los años y es negligente para cualquier persona que produce software ignorar ese proceso en nombre de una implementación más rápida o más barata. Quizás algún día, las ramificaciones legales de este comportamiento nos permitan tener más controles implementados, como las industrias médicas o de la construcción, donde el incumplimiento de estas reglas y las prácticas aceptadas resultarán en la pérdida de la licencia u otra sanción.
¿Por qué las vulnerabilidades de inyección SQL aún no se han extinguido? Hablando metafóricamente, por la misma razón que los accidentes automovilísticos siguen existiendo desde el primer automóvil en 1895 e incluso los más Hoy en día, autos innovadores y modernos con manejo propio, Tesla model S ( en el piloto automático) o auto auto-conducido de Google se bloquea de vez en cuando hora.
Los autos son creados (y controlados) por humanos, los humanos cometen errores.
Los sitios web y las aplicaciones (web) están construidos por programadores humanos. Tienden a cometer errores deficientes en el diseño de seguridad o tienden a romper las cosas con "soluciones rápidas y sucias" cuando algo era seguro, pero en realidad introducían una nueva vulnerabilidad, por ejemplo, porque el tiempo / presupuesto para desarrollar una solución era limitado, o el desarrollador tuvo una gran resaca cuando escribió la corrección .
¿Siempre es causada por desarrolladores? Esencialmente sí, pero no siempre por el desarrollador de primera línea . Por ejemplo, un supermercado local le pidió a una empresa de desarrollo web que creara un sitio web para ellos. Los desarrolladores alquilan un espacio de alojamiento compartido de una empresa de alojamiento para alojar el sitio e instalan WordPress y algunos complementos útiles.
Ahora los desarrolladores de la empresa de desarrollo web no necesariamente tienen que cometer un error para introducir una vulnerabilidad de inyección de SQL para ser vulnerables. ¿Qué podría salir mal aquí? Algunos ejemplos:
Ahora la pregunta que se plantea , ¿quién es el responsable? El supermercado, la empresa de desarrollo web, la empresa de alojamiento, la comunidad de WordPress, los desarrolladores de complementos de WordPress o el atacante que hizo un uso indebido de la vulnerabilidad, ¿de forma retórica? : esto no es una afirmación, es exagerado y solo algunas preguntas que es probable que se le pregunte en caso de que algo salga mal.
A menudo, la discusión anterior (las preguntas sobre la responsabilidad, aunque un poco exageradas) también son un factor de riesgo, ya que algunos desarrolladores tienden a tener una "ese no es mi código" -actitud . Puedes imaginar lo complicado que a veces hace la situación.
En primer lugar, nadie escribe los requisitos de seguridad correctamente, dicen algo como "El producto debe ser seguro", que de ninguna manera es verificable
En segundo lugar, los desarrolladores de profesiones no son estúpidos, y decirlo es bastante falso, es probable que todos tengan títulos universitarios y hayan estado resolviendo problemas que ni siquiera hemos empezado a tener en cuenta ... El problema es que tienen Nunca se le ha enseñado qué es desarrollar software de forma segura. Esto comienza en las escuelas, luego en la universidad y luego en cualquier trabajo que realicen, donde la capacitación es "en el trabajo" porque las empresas de software tienen demasiado miedo para capacitar a los desarrolladores en caso de que se vayan.
Los desarrolladores también están bajo una presión cada vez mayor para hacer más trabajo en menos tiempo, están ocupados solucionando un problema y pasando al siguiente, hay poco tiempo para reflexionar a medida que surge el siguiente problema.
Los desarrolladores no están incentivados a realizar pruebas más allá de lo que están desarrollando; si encuentran un problema, es probable que sean los desarrolladores que lo solucionen. El mantra del desarrollador aquí es "No pruebes lo que no estás preparado para arreglar"
En tercer lugar, los evaluadores tampoco están capacitados para encontrar vulnerabilidades de seguridad, por la misma razón que los desarrolladores de software. De hecho, una gran cantidad de pruebas (en mi opinión) simplemente repiten las pruebas que el equipo de desarrollo.
Por último, el tiempo de comercialización es un factor huge , si usted está primero ganando dinero, se considera que desarrollar de manera segura tiene un gran impacto en la velocidad de desarrollo - quiero decir realmente, ¡quién tiene tiempo para un modelo de amenaza! ;)
Finalmente, no se trata solo de inyecciones de SQL, se han conocido desbordamientos de búfer desde la década de 1960 y aún se pueden encontrar con una regularidad alarmante.
Sí, antropológicamente, los seres humanos son estúpidos .
Sí, políticamente, la estructura de incentivos no penaliza suficientemente las aplicaciones vulnerables
Sí, el proceso es defectuoso : el código está escrito a toda prisa; el código incorrecto / antiguo es no siempre se desecha .
Y, sí, técnicamente, tratando y mezclando datos como código es más difícil de hacer por defecto .
Pero hay una vista más positiva (ignoremos el 99% de las vulnerabilidades de SQLi que explican las respuestas anteriores). SQLi aún existe en sitios web extremadamente bien diseñados y cuidadosamente desarrollados porque somos increíbles . Los hackers gobiernan. Solo necesitas mirar los cientos de vectores de ataque y miles de cargas útiles SQLi que se han desarrollado durante los últimos diecisiete años para recuperar algo de fe en la raza humana. Cada año trae consigo nuevas técnicas presentadas DEFCON / BlackHat / RSA / IEEESSP. Los programas de recompensas de errores para Facebook, Google y similares han tenido que pagar al menos una vez para un SQLi crítico.
En parte, es debido a la complejidad y la cantidad de capas en nuestro sistema, cada uno de los datos de mutación en formas más nuevas e interesantes. Cada vez necesitamos más trabajo, más rápido, usando menos recursos. Y mientras no podamos probar todas las rutas dentro del sistema, nadie va a certificar una solución a los problemas de inyección .
Debido a que estos problemas de seguridad no se cubren durante la mayoría de los ciclos educativos de 3 años y estudios equivalentes, y muchos desarrolladores siguieron esa pista (incluyéndome a mí). Teniendo en cuenta la amplitud del campo, en realidad 3 años no son suficientes para hacer frente al programa de estudio real. Por lo tanto, se eliminan cosas como la seguridad.
Es desafortunado, pero dado que algunos de los nuevos desarrolladores nunca intentarán aprender cosas nuevas por sí mismos, esas personas siempre escribirán un código propenso a SQLi hasta que un colega más educado señale el problema (o hasta que aparezca un SQLi real). sucede).
Durante mis estudios (hace muchos años), nuestros profesores siempre nos decían que usáramos PreparedStatements al crear consultas manuales de SQL, porque es una "práctica recomendada", pero no dijeron por qué. Esto es mejor que nada, pero bastante triste, todavía. No estoy seguro de si esos maestros se conocieran a sí mismos.
Aprendimos cómo mostrar cosas en un jsp, pero no lo que es Cross-Site-Scripting ...
Tengo "suerte" de ser un desarrollador apasionado con algo de tiempo en mis manos, así que aprendí todas estas cosas por mi cuenta hace mucho tiempo, pero estoy seguro de que muchos desarrolladores solo hacen sus 8 horas y media. día (por razones legítimas, por cierto), y mientras nadie les muestre lo que está mal, no cambiará.
Si usa instrucciones preparadas correctamente, la inyección de SQL no es posible.
"Si la plantilla de la declaración original no se deriva de una entrada externa, la inyección de SQL no puede ocurrir".
Desafortunadamente, la gente generalmente no usa las declaraciones preparadas correctamente, en todo caso.
La inyección de SQL sería cosa del pasado si lo hicieran.
Y sí, php / MySQL ha tenido una implementación de sentencias preparadas durante mucho tiempo, más de 10 años si la memoria sirve ...
Las otras respuestas han señalado casi todas las razones. Pero hay algo más, que creo que es la preocupación de seguridad más peligrosa de todas. Los desarrolladores intentan agregar más y más características a las tecnologías y, a veces, se desvían del propósito real de la tecnología. Un poco como la forma en que un lenguaje de script del lado del cliente terminó siendo utilizado para la codificación del lado del servidor o se le permitió el acceso a recursos remotos, así como al almacenamiento local del lado del cliente. En lugar de agruparlas como tecnologías separadas, todas se colocaron en un gran honeypot. Al analizar algunas de las inyecciones SQL avanzadas, podemos ver cómo han jugado un papel en el acento constante de los ataques SQLi.
Sin embargo, con SQL, creo que el mayor error fue el acoplamiento de comandos y parámetros. Es un poco como llamar a run(value, printf) en lugar de printf(value) .
Ah, y una última cosa, si bien es bastante fácil convertir entre diferentes tipos de bases de datos, los cambios requeridos en el código del lado del servidor son gigantescos.
Alguien debería abstraer entre diferentes tipos de bases de datos y facilitar el cambio entre diferentes dbs. Diga un complemento de php que incluya como comandos de QL de entrada y el tipo de base de datos, y puede ser un filtro en lista blanca para sanear la entrada.
Personalmente, creo que este es un caso específico de un problema más general en la programación, que los IDE y los lenguajes son demasiado permisivos. Damos a nuestros desarrolladores un inmenso poder en nombre de la flexibilidad y la eficiencia. El resultado es "lo que puede pasar", y los errores de seguridad son inevitables.
La DOP (u otros métodos "seguros") no es más segura que mysql_ (u otros métodos "inseguros"). Hace que sea más fácil escribir código seguro, pero es aún más simple simplemente concatenar las cadenas proporcionadas por el usuario sin escapar en la consulta y no preocuparse por los parámetros.
Lea otras preguntas en las etiquetas web-application data-leakage sql-injection