Una inyección SQL es un ataque cibernético que ocurre cuando código SQL malicioso es insertado en una entrada de datos de una aplicación web de forma que se ejecuta en la base de datos subyacente. Esto puede permitir a un atacante ver datos confidenciales, modificar bases de datos o incluso ejecutar comandos arbitrarios en el servidor de la base de datos. El documento describe cómo funcionan las inyecciones SQL, sus características y consecuencias, y ofrece recomendaciones como el uso de procedimientos almacenados para prevenir

1. INYECCIONES SQL
GRUPO:
ANDY PAÚL GÓMEZ SORIA
KEVIN JEXAEL QUINTEROS CHIRE

2. ¿Qué es una Inyección SQL?
Es un método de infiltración de código intruso que se vale de
una vulnerabilidad informática presente en una aplicación en el
nivel de validación de las entradas para realizar consultas a una
base de datos.
Se dice que existe o se produjo una inyección SQL cuando, de
alguna manera se inserta o “inyecta” código SQL invasor dentro
del código SQL programado, a fin de alterar el funcionamiento
normal del programa y lograr así que se ejecute la porción de
código “invasor” incrustado en la base de datos.

3. Características
 Un programa “arma descuidadamente” una sentencia SQL en tiempo
de ejecución.
 Durante la fase de desarrollo del programa o página web, al
ejecutarse una sentencia T-SQL de una manera abierta, es un bug
que se puede aprovechar por el hacker.
 Siempre que el programador necesite y haga uso de parámetros a
ingresar por parte del usuario, a efectos de consultar una base de
datos; ya que, justamente dentro de los parámetros es donde se
puede incorporar el código SQL intruso.

4. Consecuencias
Algunas de las consecuencias de estas Inyecciones SQL es el
tiempo dedicado al programa o página web, es decir; no tratar
de Encriptar el código usado para el desarrollo, sin la
necesidad de usar la lógica para evitar esos ataques.
Esta dado también, que al realizar una aplicación o pagina web
en mínimo costo, es definido por el desarrollador tratar de
considerar este tipo de seguridad y evitar estos ataques.

5. Recomendaciones
Es recomendable analizar el trabajo para realizar la aplicación
o la página web, es decir, considerar las posibilidades de
ataques al trabajo final.
Es recomendable, también, usar código clasificado al
momento de considerar posibles ataques, y conocer
ampliamente todo tipo de código para que pueda ser de un
funcionamiento eficiente para el cliente, y el servidor.

6. Ejemplo de SQL injection en una Web
Tenemos una aplicación Web (realizada en ASP)
en la que el acceso a ciertas secciones está restringido. Para
restringir
ese acceso creamos una tabla de usuarios y contraseñas y sólo
los usuarios que se validen contra esa tabla podrán acceder a
esos contenidos.
Una manera de que los usuarios se validen será colocar un par
de cuadros
de texto en nuestra página Web (por ejemplo txtUsuario y
txtPassword)
donde puedan introducir su nombre y su contraseña y enviar ese
par usuario/contraseña a la base de datos para comprobar si es

7. Usuarios Password
ADMIN 1234
USUARIO 9876
Primero creamos la tabla que vamos a usar
y la rellenamos con datos:
Si el usuario escribe Admin y 1234 la sentencia creada será:
Como esta sentencia nos devuelve un registro, dejaremos que el
usuario entre en la Web. Si el usuario escribe por ejemplo ‘Admin’ y
de contraseña cualquier otra cosa, la sentencia no nos
devolverá registros y no permitiremos entrar a esa persona.
SELECT Count(*) FROM Usuarios WHERE Usuario=’Admin’ AND Password=’1234’”

8. Pero ¿qué ocurre si el usuario escribe ‘ or ’1′=’1 como usuario y lo
mismo de contraseña?
En este caso la variable Consulta contendrá la cadena:
Y obviamente esta sentencia nos devuelve registros
con lo que el usuario entrará en nuestra Web sin tener permiso.
Pero esto no es lo peor. Lo peor será
que el usuario utilice estos trucos de inyección de SQL para ejecutar
código arbitrario en nuestro servidor. Sentencias DDL, cambiar
permisos,
utilizar procedimientos almacenados, etc.
"SELECT Count(*) FROM Usuarios WHERE Usuario = '' or '1'='1' AND
password = '' or '1'='1'"

9. Otro factor importante en cuanto a la seguridad es limitar al
máximo los permisos del usuario que ejecuta estas sentencias
para evitar posibles problemas. Por ejemplo utilizando un
usuario distinto para las sentencias SELECT, DELETE, UPDATE y
asegurándonos que cada ejecución de una sentencia ejecute una
sentencia del tipo permitido.
Por supuesto utilizar el usuario ‘SA’ o uno que pertenezca al rol
‘db_owner’ para ejecutar las sentencias de uso habitual de la
base de datos debería quedar descartado.
Una solución definitiva sería trabajar con procedimientos
almacenados.
El modo en el que se pasan los parámetros a los procedimientos
almacenados evita que la inyección SQL pueda ser usada. Por
ejemplo utilizando el siguiente procedimiento almacenado:

10. FUENTE: