¿Las pruebas de vulnerabilidades de inyección de SQL siguen siendo relevantes en las aplicaciones web modernas?

9

Primero algunos antecedentes:

Soy un ingeniero de infraestructura con 5 años de experiencia principalmente en virtualización y redes.

El año pasado me dediqué a estudiar mucho sobre seguridad, aprobé Security +, leí el Manual de piratería de aplicaciones web e hice un buen dinero para encontrar errores utilizando Bugcrowd y Hackerone.

Siempre que busco vulnerabilidades, siempre omito la inyección de SQL, ya que la mayoría de las aplicaciones modernas no muestran signos de debilidad frente a los métodos tradicionales de inyección de SQL que se muestran en los libros o en los tutoriales en línea.

Ahora, ¿es este el caso de otros entusiastas de la seguridad? ¿Cómo abordas esto? Intento enviar muchos caracteres inusuales, pero el mejor resultado que obtuve fue el error 500.

Gracias de antemano

    
pregunta Mico 01.05.2015 - 16:24
fuente

9 respuestas

18

En realidad, de acuerdo con OWASP, la inyección SQL se encuentra entre las 10 principales vulnerabilidades a través de aplicaciones web. enlace

y hay muchos artículos, artículos, noticias sobre inquietudes en este tema y todos los días hay noticias sobre ataques de inyección SQL contra aplicaciones web famosas como, por ejemplo, Joomla, Wordpress o sitios web, etc., así que no podemos decir esa "aplicación moderna no muestra ningún signo de debilidad contra los métodos tradicionales de inyección SQL" porque cada día se introduce un nuevo método de inyección SQL.

    
respondido por el Ali 01.05.2015 - 16:40
fuente
4

La inyección de SQL definitivamente no es algo que me saltaría al probar la seguridad. Según el Informe de incumplimiento del Instituto Ponemon , la inyección de SQL representa el 30% de infracciones maliciosas o delictivas, la mayor parte de cualquier vector de ataque que haya provocado una infracción.

Mi empresa utiliza una variedad de métodos para encontrar vulnerabilidades de inyección SQL en nuestras aplicaciones propietarias. Utilizamos una combinación de escaneo del código fuente a través de análisis de código estático y pruebas de penetración en la aplicación en desarrollo, prueba y producción. Esto se combina con controles técnicos como los sistemas de detección de intrusos (IDS) y un servidor de seguridad de aplicaciones web (WAF).

Proveedores / productos de análisis de código estático:

  • Checkmarx
  • Whitehat

Algunos proveedores / tecnologías que realizan pruebas de lápiz:

  • Whitehat
  • Espada y escudo
  • Accuvant
  • Nexpose (Rapid7)
  • Hailstorm (Trustwave, anteriormente Cenzic)

Hay una serie de métodos para detectar y / o bloquear la inyección de SQL que puede revisar aquí: Imperva - Cómo bloquear la inyección de SQL . Si bien el bloqueo puede no ser lo que está buscando, definitivamente tiene algunas buenas herramientas para determinar si es vulnerable.

El método más simple es simplemente ejecutar algunos scripts simples que arrojan basura / ataques en el sitio web, pero yo lo eliminaría primero, obviamente.

    
respondido por el oBreak 01.05.2015 - 16:49
fuente
4

No estoy seguro de qué significa exactamente una aplicación moderna. Sí, muchos marcos, ORM, Entity Framework, etc. descomponen las consultas y pueden aplicar algún filtrado predeterminado. Sin embargo, en escenarios más complejos que requieren codificación personalizada, o donde el ORM o las funciones de la biblioteca no hacen exactamente lo que desea, abrirá la puerta a la inyección de SQL u otros ataques.

Con una gran cantidad de ORM y marcos, la parte de seguridad está integrada. Esto tiene el impacto de atender automáticamente algunos problemas de seguridad, pero al mismo tiempo, muchos desarrolladores pueden no entender qué hacen estas funciones de biblioteca por ellos. y cuando necesitan crear una solución a medida, solo siguen un tutorial y no saben que deben tener en cuenta la seguridad.

Además, cuando se sale de las aplicaciones básicas de tipo CRUD de usuario final, es posible que los desarrolladores necesiten usar bibliotecas que no tengan un buen mantenimiento. Por ejemplo, supongamos que tiene una aplicación de negocios donde alguien puede cargar un archivo CSV y eso se está procesando. Tal vez alguien escribió una biblioteca para manejar esto y no usó el ORM, funciona así que sus desarrolladores lo aceptan. Luego, el CSV se lee línea por línea y se procesa en la base de datos; aquí puede ser posible la inyección de SQL.

La inyección SQL es un síntoma de una falta de validación de entrada adecuada, la probabilidad de que esto aumente en escenarios menos comunes o más complejos en los que no puede integrarse o es un pensamiento posterior. / p>

Además, las aplicaciones "modernas" pueden parecer modernas, pero se basan en una vieja chatarra o en algunas conexiones heredadas extrañas que se salen de lo esperado.

    
respondido por el Eric G 01.05.2015 - 22:33
fuente
3

OWASP tiene información sobre cómo encontrar aletas en las inyecciones de SQL, para no estar presente. Una inyección reciente de Drupal SQL muestra que eso simplemente no es cierto (incluso en un entorno maduro como Drupal).

La forma en la que encuentras estas cosas es a menudo simplemente empleando fuzzers y enviando basura aleatoriamente a la aplicación web.

    
respondido por el LvB 01.05.2015 - 16:37
fuente
2
  

Ahora, ¿es este el caso de otros entusiastas de la seguridad?

En mi experiencia, No - la inyección de SQL aún prevalece .

Realizo un promedio de 30-50 evaluaciones de aplicaciones web por trimestre y puedo responder que la inyección de SQL sigue siendo un problema con las aplicaciones modernas.

Dicho esto, mis evaluaciones son aproximadamente un 85% automatizadas con un 15% de seguimiento / verificación / validación manual (de ninguna manera soy un examinador de lápiz profesional)

Un escáner automatizado tiene la ventaja de encontrar la inyección de SQL en los campos de parámetros que de otra manera podrían haberse pasado por alto.

El inconveniente es que un escáner automatizado no es bueno para explotar fallas lógicas como lo haría un humano.

    
respondido por el k1DBLITZ 01.05.2015 - 20:16
fuente
2

Muchas aplicaciones han crecido a lo largo de los años. A menos que el código sea refactorizado de vez en cuando para reflejar las mejores prácticas actuales (es decir, en el caso de inyecciones SQL: parametrización), muchas aplicaciones contienen bastante código heredado que no se ha tocado en años. Y es probable que no se toque ya que otras partes dependen de ello. La refactorización cuesta tiempo y dinero. Y honestamente, no hay necesidad de refactorizar mientras funcione, ¿no?

Por ejemplo, si miras Wordpress, están usando una función llamada wp_magic_quotes , que básicamente imita el comportamiento de Citas mágicas de PHP , que era una 'característica de seguridad' que automáticamente se escapa de ciertos caracteres en $_GET , $_POST , $_COOKIE , y por lo tanto $_REQUEST . Esta 'característica' ha quedado obsoleta en PHP 5.3.0 y eliminada en PHP 5.4.0, ya que se ha considerado una mala idea por varias razones (también tenga en cuenta los comentarios).

Sin embargo, aunque Wordpress depende e impone citas mágicas, todavía hay un montón de Vulnerabilidades de inyección SQL en complementos o temas .

Otro hecho: CWE-89: Neutralización inadecuada de elementos especiales utilizados en un comando SQL ('Inyección de SQL') se coloca en tercer lugar con un 10% entre los puntos débiles de todas las CVE (consulte CWE general en Tablero de la base de datos de seguridad ).

    
respondido por el Gumbo 01.05.2015 - 20:28
fuente
0

Las inyecciones clásicas y clásicas de 'or 1=1 # de SQL ya han pasado; pero los sofisticados se arrastrarán de vez en cuando. Esa es una forma en la que TrustWaves gana dinero al mantener sus reglas de ModSecurity .

La mayoría de las aplicaciones web modernas pasan por una "lista de verificación de implementación de seguridad" y, por lo general, también se prueban para detectar vulnerabilidades conocidas antes de la implementación de producción. Una vez desplegados, los cazarrecompensas aparecen y ejecutan sus propias pruebas. El sistema se considera "seguro", ya que podría llegar a ese punto en el tiempo.

Las herramientas automatizadas utilizadas por los desarrolladores y cazadores de recompensas, aunque rápidas y útiles, también pierda algunas inyecciones sofisticadas que un determinado atacante humano finalmente descubriría.

    
respondido por el David_Springfield 01.05.2015 - 19:35
fuente
0

Depende de la plataforma en la que se construye una aplicación. No creo que Drupal o Wordpress sean una herramienta de elección desarrollada por un desarrollador maduro para diseñar una aplicación. Y usted, como ingeniero de software con experiencia en su análisis, probablemente no enfrente aplicaciones de baja calidad como esa. No quiero decir que si uno usa Wordpress recibirá una inyección SQL o un ataque XSS con seguridad. Estas plataformas son como Windows, el uso indebido y la popularidad lo convierten en una vulnerabilidad.

Sí, las inyecciones de SQL todavía están presentes y debe tener cuidado con ellas. Por otro lado, cuanto más maduros sean los desarrolladores con los que está tratando, menos tendrá que preocuparse por ello.

    
respondido por el Said Kholov 01.05.2015 - 23:10
fuente
0

Encontrar inyecciones SQL hoy es muy fácil, y cualquiera puede hacerlo.

Muchos desarrolladores e investigadores han pronosticado el fin de la inyección SQL. Sin embargo, año tras año, todavía lo vemos en el Top 10 de OWASP.

La inyección de SQL está en todas partes y la falta de educación o conocimiento (o quizás malos hábitos) sobre cómo escribir código seguro es un problema. Por ejemplo, en este libro "Head First PHP & MySQL" en el capítulo seis, se introduce al lector a la Inyección SQL y cómo frustrarlo con mysqli_real_escape_string (), pero el método de saneamiento no se usa en el resto del libro, dejando a los lectores Eso no se lee de página a página vulnerable. Al no usar el saneamiento adecuado para el resto del libro, los usuarios, por supuesto, también se olvidarán de usar el saneamiento.

Para las contraseñas, el libro introduce el método SHA () de MySQL, sin embargo, no se utilizan las contraseñas o los algoritmos de contraseña adecuados.

En el Apéndice A (llamado "Todos los temas que no cubrimos) encontramos un tema llamado" Protección de su aplicación PHP ". Estas páginas solo contenían un par de páginas sobre la eliminación de scripts phpinfo () y la lucha contra XSS.

Así que sí, la inyección SQL sigue siendo muy relevante.

    
respondido por el Michal Koczwara 02.05.2015 - 11:41
fuente

Lea otras preguntas en las etiquetas