En un artículo anterior, sugerí que el lector sepa cómo se estructura en detalle el lenguaje de consulta SQL, así como también cómo funciona el protocolo HTTP. Pero este no suele ser el caso. E inmediatamente recordé la historia descrita en uno de mis libros favoritos, "Mentes poco confiables", de Rob Brotherton. Describe el siguiente experimento. La psicóloga Rebecca Lawson preguntó a un grupo de sujetos si alguna vez habían montado una bicicleta en sus vidas. La mayoría respondió que sí. Luego preguntó si sabían cómo funciona la bicicleta. Ya había menos respuestas afirmativas, pero aún así la gran mayoría. Y luego sugirió la siguiente imagen y pidió complementarla para que esta bicicleta pudiera andar.
Y luego sucedió lo más interesante: más de la mitad de la gente no podía hacer esto. Esta tarea engañosamente simple muestra que la mayoría de las personas simplemente no pueden imaginar cómo funciona una bicicleta. Pero lo más interesante es que no entienden que no saben esto, pero comienzan a entender esto solo en el momento en que tienen que demostrar este conocimiento.
Con HTTP y SQL, sucede lo mismo. El 90% de los expertos en TI escribieron consultas SQL, al menos en laboratorios de laboratorio en sus instituciones educativas, las personas trabajan con HTTP todos los días como usuarios, y los mismos expertos en TI configuran de vez en cuando servidores web que realmente funcionan con HTTP. Pero cuando tiene que responder una pregunta específica, un estupor ocurre regularmente.
Un analista de seguridad de la información debe conocer la tecnología en detalle, conocer los matices y sutilezas. Si no sabemos cómo debería funcionar esta o aquella tecnología, entonces ¿cómo podemos averiguar qué tiene de malo?
También una "inyección"
Mencioné que la verificación de la entrada debería realizarse en el servidor, pero no en el cliente. De vez en cuando, uno puede encontrar formas de entrada donde los elementos individuales están inactivos. Y se supone que se activarán después de que se cumplan ciertas condiciones. O, por ejemplo, el campo de entrada del nombre de usuario tiene 7 caracteres de longitud, lo que limita la longitud máxima del nombre de usuario. Todo esto es una práctica muy mala y esta es la razón: los elementos de la página que ya se han recibido pueden editarse arbitrariamente antes de enviarlos, sin ningún medio técnico especial. En OWASP Mutillidae II, esto se puede ver en el ejemplo "Otros"> "Controles de" seguridad "del lado del cliente".
Aquí hay un formulario en los campos en el que debe ingresar un número aleatorio, esta vez es 2056694312. La "dificultad" aquí es que los campos tienen limitaciones. Hay un campo "Solo lectura" donde el número 42 no se puede reemplazar, hay un campo demasiado corto "Cuadro de texto corto" donde nuestro número simplemente no puede caber, hay un campo deshabilitado "Cuadro de texto deshabilitado" que está inactivo, y así sucesivamente.
De hecho, la tarea se resuelve de manera muy simple. En el navegador (en mi caso es Mozilla Firefox), vaya a la consola del desarrollador (F12) y comience a inspeccionar los elementos del formulario.
Por ejemplo, un campo de solo lectura se ve así:
<input HTMLandXSSInjectionPoint="1" type="text" name="readonly_textbox" id="id_readonly_textbox" size="15" maxlength="15" required="required" autofocus="autofocus" readonly="readonly" value="42" />
Eliminar readonly = "readonly" y listo: el formulario se puede escribir, podemos ingresar nuestro número.
Nuestro valor simplemente no encaja en el siguiente campo, veamos este elemento:
<input HTMLandXSSInjectionPoint="1" type="text" name="short_textbox" id="id_short_textbox" size="3" maxlength="3" required="required" />
Aquí notamos maxlength = ”3 ″. Reemplace 3 con 333, ahora podemos ingresar nuestro número sin temor a que no encaje.
Y, por cierto, no se trata solo de campos de entrada. Del mismo modo, puede cambiar cualquier elemento, como las casillas de verificación. El código de la página se ve así:
<input type="checkbox" name="checkbox" id="id_checkbox" value="2056694312" required="required" disabled="disabled" />
Aquí es bastante simple, reemplazaremos el valor con nuestro número, y ahora se enviará cuando el usuario haga clic en el botón.
En total, si sabe cómo está estructurado HTML, no será difícil corregir este formulario para que ingrese todos los datos necesarios allí. Simplemente vuelva a leer la sección sobre Síndrome de la bicicleta =)
No solo SQL
La inyección no siempre se trata de bases de datos. En general, de cualquier forma que no filtre los datos entrantes, puede obtener información adicional. En el ejemplo "Inyección de registro de aplicación"> "Búsqueda de DNS" hay un formulario conveniente para consultas DNS:
De hecho, si ingresa la dirección allí, por ejemplo, google.com, obtenemos toda la información necesaria:
Sin embargo, la vulnerabilidad es que, además del primer comando válido, podemos ingresar algo más. Por ejemplo, especifique:
google.com && dir
y ahora la salida del comando es mucho más interesante:
Hicimos una solicitud al servidor DNS, pero además, ejecutamos el comando dir y observamos qué había en la carpeta con nuestro sitio. Combinar diferentes comandos no es difícil deambular por el disco duro del servidor web y buscar lo que está mal.
La próxima vez analizaremos más ejemplos y también veremos cómo puede automatizar su trabajo.
Lea el blog del autor en
este enlace .