El primero en la lista de las diez
vulnerabilidades más comunes (OWASP) es la inyección. Este tipo de hallazgo es
más como una categoría, e incluye todos los tipos de vulnerabilidades donde una
aplicación envía datos no confiables a un intérprete. Se encuentra a menudo en
las consultas de bases de datos, pero otros ejemplos son los comandos OS, XML
parsers o cuando la entrada del usuario se envía como variables acuerdo con los
consultores de auditoría de base de datos.
Según
maestros de curso de seguridad de base de datos, este es un tipo de
vulnerabilidad muy común, especialmente en código antiguo, ya que era mucho más
común hace unos años cuando estaban menos conscientes del peligro. La
Inyección de SQL debe ser considerada como la más conocida del tipo de
inyección acuerdo con el curso de seguridad de base de datos.
Como se trata de una categoría muy amplia de la vulnerabilidad, el riesgo varía
mucho de un caso a otro. Como la inyección de SQL es el tipo de inyección más
conocida, el impacto es a menudo el robo de datos de la base de datos. Eso
puede incluir nombres de usuario, contraseña y otros datos confidenciales. El
peor de los casos sería una adquisición completa del sistema, lo que
ciertamente es posible dependiendo de dónde se dé la inyección y en qué entorno
mencionan los consultores de auditoría de base de datos.
Este es
un ataque que puede ser automatizado, lo que lo supone en mayor riesgo. Un atacante
no necesita estar tras de ti, el simplemente puede escribir una secuencia que
explota a tantos sitios como sea posible y si el tuyo es uno de ellos es una
coincidencia.
Uno de
los ataques más conocidos realizados por inyección de SQL estuvo dirigido contra
Sony. Otro casi irónico fue cuando MySQL sufrió el mismo una inyección SQL.
Como se puede entender partir de los ejemplos, grandes jugadores también están
en riesgo y el resultado de un ataque puede ser aterrador sin algún tipo de auditoría de base de datos.
*',za
¿CÓMO
DESCUBRIR LA INYECCIÓN DE SQL?
Para
los usuarios más avanzados es una vulnerabilidad que pueden encontrarse a
menudo mientras se está haciendo el análisis de código. Esa es la
identificación de todas las consultas en la aplicación web y siguiendo el flujo
de datos. Ya que a veces no genera ninguna reacción visible y puede ser difícil
de detectar durante black box-test, a pesar de que a algunas veces eso es
posible también. Según el curso de seguridad de base de datos, la inyección es
una definición muy amplia que varía de un caso a otro, pero en general una
inyección SQL clásico es muy fácil de explotar.
Un
ejemplo típico de una inyección de SQL sería en un formulario de acceso, con el
código que se muestra a continuación:
$db = new mysqli(‘localhost’, ‘root’, ‘passwd’,
‘base’); $result = $db->query(‘SELECT * FROM users WHERE
user=”‘.$_GET[‘user’].'” AND pass= “‘.$_GET[‘password’].'”‘);
Supongamos
que el atacante entra “ OR 1– como nombre de usuario y cualquier contraseña de
todo el código y se terminara viendo así:
SELECT * FROM users WHERE user=”” OR 1 — AND pass=”whatever”
Después
de — (lo que se indica el inicio de un comentario en SQL) será desechado e
ignorado. El código será ejecutado cuando se vea de la siguiente manera:
SELECT * FROM users WHERE user=”” OR 1
El
código establece ahora “Obtener todo, desde la lista de usuarios (donde el
nombre de usuario coincide con nada o 1 (lo que se interpretara como cierto)”.
Desde
que la última afirmación siempre resultará en cierto, la mano derecha de la
declaración eliminara con éxito la declaración mano izquierda y la condición
siempre será cierto. El resultado de esta consulta sería algo como éste:
SELECT * FROM users
El cual
sería devolver todos los datos que hay sobre todos los usuarios. Ej., La
inyección en el parámetro $ _GET [‘usuario’] es suficiente para hacer que el
servidor MySQL seleccione el primer usuario y otorgué al atacante acceder a ese
usuario.
REMEDIACIÓN
1.
Mientras las inyecciones son más de una categoría de
vulnerabilidades, las soluciones varían de un caso a otro, dependiendo de qué
tipo de vector y el intérprete que estamos hablando. Acuerdo el curso de
auditoría de base de datos y seguridad de base de datos, la solución óptima es
utilizar un API que, o bien evita el intérprete o proporciona una interfaz con
parámetros. El código con parámetros no es difícil de hacer, y si usas PHP
nosotros te recomendamos PDO. Puede sonar extraño al principio, pero en realidad
no es tan difícil como tú podrías pensar en un principio. Ejemplos en otros
idiomas pueden ser aprendidos durante el curso de seguridad de base de datos.
2.
Si el código parametrizado no es una opción en su caso, en su
lugar debes escapar cuidadosamente de caracteres especiales. ¿Cómo se hace
esto? depende del intérprete utilizado, y algunas veces tendrías que mejorar.
3.
La validación de entrada de la lista blanca es también una
alternativa, pero a menudo no se puede utilizar como aplicación puede requerir
caracteres especiales, como de entrada. Por ejemplo, un blog quiere permitir a
sus visitantes hacer comentarios usando comillas, a pesar de que es carácter
podría ser utilizado para salir de una consulta. En esos casos, es necesario ir
con una solución de uno o dos.
Pueden
aprender todo sobre remediación sobre inyección SQL curso de seguridad de base
de datos y resolver las vulnerabilidades de sus sistemas informáticos.
0 comments:
Post a Comment