{"id":30171,"date":"2020-01-14T02:42:14","date_gmt":"2020-01-14T10:42:14","guid":{"rendered":"https:\/\/staging.kinsta.site\/?p=62827"},"modified":"2022-07-27T15:21:19","modified_gmt":"2022-07-27T13:21:19","slug":"inyeccion-sql","status":"publish","type":"post","link":"https:\/\/staging.kinsta.site\/es\/blog\/inyeccion-sql\/","title":{"rendered":"Inyecci\u00f3n SQL: Una gu\u00eda para usuarios principiantes de WordPress"},"content":{"rendered":"

SQL (Structured Query Language) es un lenguaje que nos permite interactuar con las bases de datos<\/a>. Las aplicaciones web modernas utilizan bases de datos para gestionar los datos y mostrar el contenido din\u00e1mico a los lectores.<\/p>\n

La inyecci\u00f3n SQL, o SQLi, es un ataque a una aplicaci\u00f3n web que compromete su base de datos mediante sentencias SQL maliciosas.<\/p>\n

Como se trata de un ataque com\u00fan, tratemos de aprender m\u00e1s sobre lo que es, c\u00f3mo sucede y c\u00f3mo defenderse de \u00e9l.<\/p>\n

\u00bfListo? \u00a1Vamos a sumergirnos!<\/p>\n

<\/div><\/kinsta-auto-toc>\n

\u00bfQu\u00e9 es SQL Inyecci\u00f3n?<\/h2>\n

La inyecci\u00f3n SQL, o SQLi, es un tipo de ataque a una aplicaci\u00f3n web que permite a un atacante insertar sentencias SQL maliciosas en la aplicaci\u00f3n web, obteniendo potencialmente acceso a datos sensibles en la base de datos o destruyendo estos datos, la inyecci\u00f3n SQL fue descubierta por primera vez por Jeff Forristal en 1998.<\/p>\n

En las dos d\u00e9cadas que han transcurrido desde su descubrimiento, la inyecci\u00f3n SQL ha sido sistem\u00e1ticamente la principal prioridad de los desarrolladores web a la hora de dise\u00f1ar<\/a> aplicaciones.<\/p>\n

Barclaycard estim\u00f3 en 2012 que el 97% de las violaciones de datos se inician con un ataque de inyecci\u00f3n SQL<\/a>. Una inyecci\u00f3n SQL es frecuente incluso hoy en d\u00eda y la gravedad de los ataques de inyecci\u00f3n en una aplicaci\u00f3n web es ampliamente reconocida. Es uno de los diez riesgos de seguridad de aplicaciones web m\u00e1s cr\u00edticos de<\/a> OWASP.<\/p>\n

\u00bfC\u00f3mo funciona la vulnerabilidad de inyecci\u00f3n SQL?<\/h2>\n

Una vulnerabilidad de inyecci\u00f3n SQL proporciona a un atacante un acceso completo a la base de datos de su aplicaci\u00f3n mediante el uso de sentencias SQL maliciosas.<\/p>\n

En esta secci\u00f3n, compartimos un ejemplo de c\u00f3mo se ve una aplicaci\u00f3n vulnerable.<\/p>\n

Imagine el flujo de trabajo de una t\u00edpica aplicaci\u00f3n web que implica solicitudes de bases de datos a trav\u00e9s de las entradas del usuario. La entrada del usuario se realiza a trav\u00e9s de un formulario, por ejemplo, un formulario de acceso<\/a>. A continuaci\u00f3n, se consulta la base de datos con los campos enviados por el usuario para autentificarlos. La estructura de la consulta a su base de datos es algo as\u00ed:<\/p>\n

select * from user_table\nwhere\u00a0username = 'sdaityari'\nand\u00a0password = 'mypassword';\n<\/code><\/pre>\n
Para simplificar, supongamos que est\u00e1 almacenando sus contrase\u00f1as como texto claro. Sin embargo, es una buena pr\u00e1ctica cifrar sus contrase\u00f1as<\/a> y luego convertirlas en hash. A continuaci\u00f3n, si ha recibido el nombre de usuario y la contrase\u00f1a del formulario, puede definir la consulta en PHP de la siguiente manera:<\/p>\n
\/\/ Connect to SQL database\n$db_query = \"select * from user_table where\nusername = '\".$user.\"'\nAND password = '\".$password.\"';\";\n\/\/ Execute query\n<\/code><\/pre>\n
Si alguien introduce el valor \u00abadmin’;-\u00bb en el campo de nombre de usuario, la consulta SQL resultante que genera la variable $db_query ser\u00e1 la siguiente:<\/p>\n
select * from user_table where\nusername = 'admin';--' and password = 'mypassword'\n<\/code><\/pre>\n
\u00bfQu\u00e9 hace esta consulta?<\/p>\n
Un comentario en SQL comienza con guiones dobles (–). La consulta resultante filtra s\u00f3lo por el nombre de usuario sin tener en cuenta la contrase\u00f1a. Si no hubiera seguridad para evitarlo, simplemente se le conceder\u00eda acceso administrativo a la aplicaci\u00f3n web con s\u00f3lo usar este truco.<\/p>\n
Alternativamente, un ataque booleano tambi\u00e9n puede ser usado en este ejemplo para obtener acceso. Si un atacante introduce \u00abpassword’ o 1=1;-\u00bb en el campo de la contrase\u00f1a, la consulta resultante ser\u00eda la siguiente:<\/p>\n
select * from user_table where\nusername = 'admin' and\npassword = 'password' or 1=1;--';\n<\/code><\/pre>\n
En este caso, incluso si su contrase\u00f1a es incorrecta, usted se autenticar\u00e1 en la aplicaci\u00f3n. Si su p\u00e1gina web muestra los resultados de la consulta de la base de datos, un atacante puede utilizar el comando show tables, comando para mostrar las tablas en la base de datos, y luego selectivamente dejar caer las tablas si as\u00ed lo desea.<\/p>\n
\"Un
Un dibujo animado en inyecci\u00f3n SQL (fuente de la imagen: XKCD<\/a>)<\/figcaption><\/figure>\n
Exploits of a Mom, una popular tira c\u00f3mica de XKCD, muestra la conversaci\u00f3n de una madre con la escuela de su hijo, donde le preguntan si realmente llam\u00f3 a su hijo \u00abRobert’); DROP TABLE Students; –\u00ab.<\/p>\n
Tipos de Inyecci\u00f3n SQL<\/h2>\n
Ahora que ya conoce los fundamentos de una vulnerabilidad de inyecci\u00f3n SQL, vamos a explorar los distintos tipos de ataques de inyecci\u00f3n SQL y la raz\u00f3n de cada uno de ellos.<\/p>\n
Inyecci\u00f3n SQL en banda<\/h3>\n
La inyecci\u00f3n SQL en banda es la forma m\u00e1s simple de inyecci\u00f3n SQL. En este proceso, el atacante es capaz de utilizar el mismo canal para insertar el c\u00f3digo SQL malicioso en la aplicaci\u00f3n, as\u00ed como para recoger los resultados. Discutiremos dos formas de ataques de inyecci\u00f3n SQL en banda:<\/p>\n
Ataque basado en errores<\/h4>\n
Un atacante utiliza una t\u00e9cnica de inyecci\u00f3n SQL basada en errores durante las fases iniciales de su ataque. La idea detr\u00e1s de una inyecci\u00f3n SQL basada en errores es obtener m\u00e1s informaci\u00f3n sobre la estructura de la base de datos y los nombres de las tablas que sigue la aplicaci\u00f3n web. Por ejemplo, un mensaje de error puede contener el nombre de la tabla incluido en la consulta y los nombres de las columnas de la tabla. Estos datos pueden ser utilizados para crear nuevos ataques.<\/p>\n
Ataque basado en la Uni\u00f3n<\/h4>\n
En este m\u00e9todo, un atacante que utiliza la uni\u00f3n SQL se une para mostrar los resultados de una tabla diferente. Por ejemplo, si un atacante est\u00e1 en una p\u00e1gina de b\u00fasqueda<\/a>, puede a\u00f1adir los resultados de otra tabla.<\/p>\n
select title, link from post_table\nwhere id < 10\nunion\nselect username, password\nfrom user_table; --;\n<\/code><\/pre>\n
Inyecci\u00f3n SQL Inferencial (Blind SQL Injection)<\/h3>\n
Incluso si un atacante genera un error en la consulta SQL, la respuesta de la consulta puede no ser transmitida directamente a la p\u00e1gina web. En tal caso, el atacante necesita investigar m\u00e1s.<\/p>\n
En esta forma de inyecci\u00f3n SQL, el atacante env\u00eda varias consultas a la base de datos para evaluar c\u00f3mo la aplicaci\u00f3n analiza estas respuestas. Una inyecci\u00f3n SQL inferencial es a veces tambi\u00e9n conocida como inyecci\u00f3n SQL ciega<\/strong>. A continuaci\u00f3n veremos dos tipos de inyecciones SQL inferenciales: inyecci\u00f3n SQL booleana e inyecci\u00f3n SQL basada en tiempo.<\/p>\n
Ataque Booleano<\/h4>\n
Si una consulta SQL da como resultado un error que no ha sido manejado internamente en la aplicaci\u00f3n, la p\u00e1gina web resultante puede arrojar un error, cargar una p\u00e1gina en blanco o cargar parcialmente. En una inyecci\u00f3n SQL booleana, un atacante eval\u00faa qu\u00e9 partes de la entrada de un usuario son vulnerables a las inyecciones SQL probando dos versiones diferentes de una cl\u00e1usula booleana a trav\u00e9s de la entrada:<\/p>\n