Evita los ataques de inyección SQL en tu holo Actualizado 26/04/2013
aquí e vuelto con otro tutorial de como evitar los ataques de inyección de SQL .
Los ataques informáticos son nuestro pan de cada día, y entre ellos destaca últimamente los ataques de inyección de SQL
por este motivo tenemos que prevenirnos al máximo de estos ataques que cada vez se está extendiendo más su uso por la facilidad
que tiene de ponerlo en marcha cualquier persona aunque no tenga experiencia en SQL, simplemente sabiendo la cadena de texto adecuada.
Ahora os voy a explicar que medidas básicas podemos tomar para evitar estos ataques.
Como evitar estos ataques
El principal problema de estos ataques es que si dejamos que el usuario del programa introduzca libremente caracteres sin control ninguno
(mediante formularios, por ejemplo) puede llegar a aprovecharse de las comillas (simples y dobles con las que declaramos cadenas de texto o strings).
Os voy a poner un pequeño ejemplo de una consulta SQL a la que le mandamos dos parámetros (independientemente del lenguaje, ya que cualquier
lenguaje que use bases de datos SQL podría ser victima de estos ataques), que mediante el lenguaje que elijamos escribirá tal cual le mandemos los parámetros.
Código pawn.
- #El usuario y la contraseña que mandamos son "Error", y se haría esta consulta:
- SELECT * FROM `Usuarios` WHERE `user`='Error' AND `pass`='Error'
- #Y en este ejemplo veremos el resultado de la inyección del SQL
- SELECT * FROM `Usuarios` WHERE `user`='Error' AND `pass`='' UNION SELECT * FROM `Usuarios` WHERE `id` = '1'
Por lo tanto la solución genérica sería evitar que se pudieran introducir caracteres especiales (como comillas) sin haberlas transformado antes
(por ejemplo, una comilla doble: " debería de transformarse en \" que así interpretará como texto la comilla y no como el carácter que
cierra o abre el una texto en la consulta, pero según el lenguaje se puede implementar de distintas formas y algunas son automáticas y más optimizadas.
Conclusión
Se pueden evitar estos ataques en muchos lenguajes distintos, e incluso hay lenguajes que por defecto hay que complicarse para que exista este fallo
de seguridad, pero lo que tenemos que saber es que donde hay una consulta SQL puede haber una brecha de seguridad.
Salu2.
Comentarios
Publicar un comentario