Si eso te suena bien, empecemos.<\/p>\n\n\n\n
\u00bfQu\u00e9 es un ataque de inyecci\u00f3n SQL en WordPress?<\/h2>\n\n\n\n![\"Hombre](\"https:\/\/wcanvas.com\/wp-content\/uploads\/2023\/02\/WordPress-SQL-injection-attacks_-how-to-protect-your-site.-I-1-1024x743.jpg\")
<\/figure>\n\n\n\nSQL<\/a> es un lenguaje de programaci\u00f3n utilizado para gestionar bases de datos relacionales. Todos los sitios de WordPress utilizan bases de datos relacionales y gestores de bases de datos relacionales como MySQL, MariaDB y AuroraDB.<\/p>\n\n\n\nLas inyecciones SQL son usos maliciosos de SQL para obtener acceso a informaci\u00f3n en el backend que deber\u00eda quedar oculta al p\u00fablico. Las inyecciones SQL en WordPress consisten en hackers que escriben comandos SQL en campos de entrada de usuario con la intenci\u00f3n de ingresar a sitios web. Los campos de entrada de usuario m\u00e1s comunes que los hackers utilizan para inyectar comandos SQL incluyen casillas de inicio de sesi\u00f3n, casillas de b\u00fasqueda o campos de registro.<\/p>\n\n\n\n
Debido a la forma en que las inyecciones SQL explotan vulnerabilidades en los campos de entrada de usuario, en algunos casos, pueden ser similares a los ataques cross-site scripting<\/a> (XSS), otra amenaza cibern\u00e9tica com\u00fan en el ecosistema de WordPress.<\/p>\n\n\n\n\u00bfC\u00f3mo funcionan las inyecciones SQL en WordPress?<\/h2>\n\n\n\n
Los hackers realizan ataques de inyecci\u00f3n SQL interfiriendo con las consultas que una aplicaci\u00f3n (en este caso, un sitio web de WordPress) hace a su base de datos. Una consulta de base de datos es una solicitud de la informaci\u00f3n en la base de datos.<\/p>\n\n\n\n
Una de las formas m\u00e1s comunes en que los hackers inyectan comandos SQL maliciosos es a trav\u00e9s de campos de entrada como los formularios de nombre de usuario y contrase\u00f1a. Un atacante puede, por ejemplo, introducir un nombre de usuario v\u00e1lido para el cual no tiene la contrase\u00f1a y luego enviar un comando SQL en el campo Contrase\u00f1a<\/code> de la siguiente manera:<\/p>\n\n\n\n![\"Captura](\"https:\/\/wcanvas.com\/wp-content\/uploads\/2023\/02\/WordPress-SQL-injection-attacks_-how-to-protect-your-site.-II-1024x408.jpg\")
<\/figure>\n\n\n\nEn lugar de ingresar la contrase\u00f1a, el hacker puede introducir el siguiente comando SQL:<\/p>\n\n\n\n
'OR username username_123 -- <\/code><\/pre>\n\n\n\nTenga en cuenta que despu\u00e9s del -- <\/code> hay un espacio en blanco esencial para que este comando funcione.<\/p>\n\n\n\nEste comando modifica la consulta para indicarle a la base de datos que permita a este usuario iniciar sesi\u00f3n al coincidir el nombre de usuario username_123<\/code> con su contrase\u00f1a correspondiente (la forma tradicional de iniciar sesi\u00f3n) o simplemente ingresando el nombre de usuario correcto y haciendo clic en Iniciar sesi\u00f3n<\/strong>. Este comando hace que el campo Contrase\u00f1a<\/code> sea irrelevante porque el sitio web permitir\u00e1 que el usuario inicie sesi\u00f3n simplemente escribiendo un nombre de usuario v\u00e1lido, sin importar lo que est\u00e9 en el campo Contrase\u00f1a<\/code>.<\/p>\n\n\n\nSin embargo, este ataque no funcionar\u00eda en sitios web que encriptan sus contrase\u00f1as en lugar de pasarlas como texto plano. Para esos casos, un hacker puede usar solo el campo Username<\/code>, ingresando el siguiente comando SQL (con un espacio en el final):<\/p>\n\n\n\nusername_123\u2019 -- <\/code><\/pre>\n\n\n\nEl hacker luego escribir\u00eda cualquier cosa en el campo Contrase\u00f1a<\/code> ya que el comando SQL en el campo Username<\/code> hace que la contrase\u00f1a, una vez m\u00e1s, sea irrelevante.<\/p>\n\n\n\n![\"Captura](\"https:\/\/wcanvas.com\/wp-content\/uploads\/2023\/02\/WordPress-SQL-injection-attacks_-how-to-protect-your-site.-III-1024x426.jpg\")
<\/figure>\n\n\n\nEstos son dos ejemplos sencillos de los muchos m\u00e9todos que los hackers pueden usar para entrar en sitios web al ingresar comandos SQL maliciosos en campos de entrada vulnerables. Los administradores de sitios web con conocimientos toman medidas de seguridad para prevenir estos ataques, pero los propietarios de sitios web no t\u00e9cnicos pueden no ser conscientes de esta vulnerabilidad, abriendo la puerta a m\u00e1s ataques.<\/p>\n\n\n\n
Independientemente del m\u00e9todo, las inyecciones SQL enga\u00f1an a las bases de datos que no validan la entrada del usuario para dar a los hackers informaci\u00f3n destinada a permanecer privada.<\/p>\n\n\n\n
Ahora que entend\u00e9s c\u00f3mo los hackers pueden f\u00e1cilmente vulnerar sitios web no asegurados, exploremos los diferentes tipos de ataques de inyecci\u00f3n SQL.<\/p>\n\n\n\n
Tipos de ataques de inyecci\u00f3n SQL en WordPress<\/h2>\n\n\n\nInyecciones SQL de banda directa o cl\u00e1sicas<\/h3>\n\n\n\n
Las inyecciones SQL de banda directa o cl\u00e1sicas son ataques de inyecci\u00f3n SQL que utilizan el mismo canal para iniciar el ataque y extraer la informaci\u00f3n que desean. Por ejemplo, un hacker puede infiltrarse en un sitio utilizando comandos SQL en un navegador. Los resultados se mostrar\u00e1n en el mismo navegador si utilizan una inyecci\u00f3n SQL de banda directa.<\/p>\n\n\n\n
Existen dos subtipos comunes de inyecci\u00f3n SQL de banda directa.<\/p>\n\n\n\n
Inyecciones SQL basadas en errores<\/h4>\n\n\n\n
En estos ataques de banda directa, los hackers ingresan consultas que producen un error en la base de datos. Por ejemplo, sus comandos SQL podr\u00edan contener una sintaxis deliberadamente incorrecta que cause una respuesta de error.<\/p>\n\n\n\n
Bas\u00e1ndose en los datos que recopilan de los mensajes de error, los hackers pueden obtener informaci\u00f3n sobre la estructura de la base de datos o idear formas de acceder sin autorizaci\u00f3n. Con ataques SQL basados en errores, los hackers pueden enumerar parcial o completamente una base de datos (extraer datos disponibles).<\/p>\n\n\n\n
Inyecciones SQL basadas en UNION<\/h4>\n\n\n\n
En SQL, la declaraci\u00f3n SELECT<\/code> selecciona datos de una base de datos, almacen\u00e1ndolos en una tabla de resultados llamada “conjunto de resultados”. En el caso de una base de datos de WordPress, el conjunto de resultados puede incluir datos relacionados con plugins, comentarios, nombres de usuario, contrase\u00f1as, etc. La declaraci\u00f3n UNION<\/code> combina los datos del resultado de dos o m\u00e1s declaraciones SELECT<\/code> en un solo conjunto de resultados.<\/p>\n\n\n\nLos ataques SQL basados en UNION<\/code> utilizan la declaraci\u00f3n UNION<\/code> para realizar consultas que resultan en una combinaci\u00f3n de tablas de la base de datos del sitio web como respuesta HTTP. Los hackers pueden usar este m\u00e9todo para extraer informaci\u00f3n valiosa.<\/p>\n\n\n\nInyecciones SQL inferenciales o de ciegas<\/h3>\n\n\n\n
Durante los ataques SQL de banda directa, los hackers pueden enviar una consulta y recibir una respuesta en el mismo canal, como el navegador que est\u00e1n utilizando.<\/p>\n\n\n\n
En los ataques SQL “ciegos” o inferenciales, los hackers no reciben informaci\u00f3n directamente de la base de datos. Aun as\u00ed, pueden monitorear la respuesta de la aplicaci\u00f3n a la consulta que enviaron y obtener informaci\u00f3n de ella. Este tipo de ataque SQL tambi\u00e9n tiene dos subtipos.<\/p>\n\n\n\n
Inyecciones SQL ciegas de Booleano<\/h4>\n\n\n\n
Los hackers env\u00edan una consulta SQL y observan la respuesta de la base de datos. El contenido de la respuesta HTTP a la consulta var\u00eda dependiendo de si la consulta devolvi\u00f3 un Booleano true<\/code> o false<\/code>.<\/p>\n\n\n\nAunque la base de datos no devolvi\u00f3 expl\u00edcitamente datos al hacker, este puede inferir si la consulta (como la longitud de una entrada de base de datos) era true<\/code> o false<\/code> en funci\u00f3n del contenido de la respuesta HTTP. Al probar con m\u00faltiples consultas que indagan informaci\u00f3n sobre la base de datos, los hackers pueden lentamente enumerarla.<\/p>\n\n\n\nInyecciones SQL ciegas basadas en tiempo<\/h4>\n\n\n\n
Con este m\u00e9todo, los hackers tambi\u00e9n quieren saber si una consulta devolvi\u00f3 un Booleano true<\/code> o false<\/code>, pero en este caso lo hacen midiendo el tiempo que tarda la respuesta en llegar. Para lograr esto, env\u00edan una consulta que obliga a la base de datos a esperar un n\u00famero espec\u00edfico de segundos para responder.<\/p>\n\n\n\nDependiendo de si la respuesta HTTP lleg\u00f3 de inmediato o con un retraso de unos segundos, los hackers pueden determinar si era verdadero o falso. Pueden utilizar este m\u00e9todo para enumerar la base de datos lentamente.<\/p>\n\n\n\n
Inyecciones SQL fuera de banda<\/h3>\n\n\n\n
Este tipo de inyecciones SQL son menos comunes y se usan como alternativa a los tipos anteriores. Los hackers las utilizan t\u00edpicamente cuando no pueden recibir respuestas de la base de datos por el mismo canal a trav\u00e9s del cual est\u00e1n atacando. En su lugar, ordenan a una aplicaci\u00f3n que env\u00ede datos a una ubicaci\u00f3n remota, como un servidor al que el hacker tiene acceso.<\/p>\n\n\n\n
Los ataques SQL fuera de banda solo funcionan cuando el hacker puede acceder a un servidor con comandos que generan solicitudes DNS y HTTP desde otros servidores, una caracter\u00edstica com\u00fan en servidores SQL populares como Microsoft SQL Server y Oracle Database.<\/p>\n\n\n\n
Al hacer solicitudes DNS y HTTP, los hackers pueden transferir informaci\u00f3n sensible desde la base de datos de la v\u00edctima a su servidor.<\/p>\n\n\n\n
\u00bfQu\u00e9 pueden ganar, robar o lograr los hackers con ataques de inyecci\u00f3n SQL en WordPress?<\/h2>\n\n\n\n![\"Tarjeta](\"https:\/\/wcanvas.com\/wp-content\/uploads\/2023\/02\/WordPress-SQL-injection-attacks_-how-to-protect-your-site.-IV-1-1024x743.jpg\")
<\/figure>\n\n\n\nLos hackers tienen varias razones para realizar ataques de inyecci\u00f3n SQL. Los datos m\u00e1s comunes a los que pueden acceder incluyen los siguientes:<\/p>\n\n\n\n
\n- Informaci\u00f3n privada sobre la estructura de la base de datos.<\/li>\n\n\n\n
- Informaci\u00f3n corporativa sensible como propiedad intelectual y secretos comerciales.<\/li>\n\n\n\n
- Informaci\u00f3n personalmente identificable (IPI) sobre los usuarios del sitio web.<\/li>\n\n\n\n
- Listas de nombres de usuario y contrase\u00f1as.<\/li>\n\n\n\n
- Detalles confidenciales del consumidor.<\/li>\n\n\n\n
- Informaci\u00f3n sobre la versi\u00f3n y otros detalles del software de gesti\u00f3n de bases de datos.<\/li>\n<\/ul>\n\n\n\n
Si su ataque SQL les otorga acceso administrativo directo con credenciales de inicio de sesi\u00f3n robadas, los hackers podr\u00edan:<\/p>\n\n\n\n
\n- Manipular el contenido de la base de datos.<\/li>\n\n\n\n
- Eliminar la base de datos parcial o completamente.<\/li>\n\n\n\n
- Bloquear el acceso a los datos de la base de datos para otros usuarios.<\/li>\n\n\n\n
- Hacer p\u00fablica la informaci\u00f3n privada.<\/li>\n\n\n\n
- Anular y manipular transacciones monetarias.<\/li>\n\n\n\n
- Manipular saldos financieros.<\/li>\n<\/ul>\n\n\n\n
Esto podr\u00eda dejar un impacto duradero en el sitio web y las marcas detr\u00e1s de \u00e9l. Por ejemplo, supongamos que la marca cumple con leyes de protecci\u00f3n de informaci\u00f3n personal como el GDPR de la Uni\u00f3n Europea. En ese caso, podr\u00edan enfrentar multas debido a una violaci\u00f3n de seguridad causada por inyecciones SQL.<\/p>\n\n\n\n
\u00bfC\u00f3mo proteger tus sitios de WordPress de los ataques de inyecci\u00f3n de base de datos?<\/h2>\n\n\n\n![\"pantallas](\"https:\/\/wcanvas.com\/wp-content\/uploads\/2023\/02\/WordPress-SQL-injection-attacks_-how-to-protect-your-site.-V-1-1024x743.jpg\")
<\/figure>\n\n\n\nLos expertos consideran que las vulnerabilidades de inyecci\u00f3n SQL son graves debido a su potencial para interrumpir una aplicaci\u00f3n de WordPress. El hecho de que tambi\u00e9n est\u00e9n muy extendidas no mejora la situaci\u00f3n.<\/p>\n\n\n\n
De acuerdo con el informe<\/a> de seguridad de Wordfence de 2022 sobre WordPress, las vulnerabilidades de inyecci\u00f3n SQL fueron la cuarta categor\u00eda m\u00e1s com\u00fan de vulnerabilidades divulgadas durante el a\u00f1o. Adem\u00e1s, el informe<\/a> de seguridad de Sucuri de 2021 determin\u00f3 que plugins populares con cientos de miles o millones de instalaciones, como WooCommerce, All In One SEO, y WP Statistics, ten\u00edan vulnerabilidades de inyecci\u00f3n SQL que sus respectivos desarrolladores eventuales parchearon.<\/p>\n\n\n\nPuede ser dif\u00edcil proteger tu sitio de ataques de inyecci\u00f3n SQL porque hay muchas v\u00edas para que los hackers exploten, pero los expertos han ideado varias estrategias.<\/p>\n\n\n\n
Sentencias preparadas<\/h3>\n\n\n\n
Las sentencias preparadas o consultas parametrizadas son a menudo consideradas la forma m\u00e1s efectiva de evitar ataques SQL. El problema fundamental que causa la inyecci\u00f3n de c\u00f3digo SQL malicioso en campos de entrada es que mezclan c\u00f3digo y datos, enga\u00f1ando a las bases de datos vulnerables para compartir informaci\u00f3n confidencial.<\/p>\n\n\n\n
Las sentencias preparadas aseguran que el c\u00f3digo SQL se env\u00ede al servidor de la base de datos y se analice por separado de los datos, lo que hace m\u00e1s dif\u00edcil o imposible que un hacker inyecte c\u00f3digo SQL malicioso. Tambi\u00e9n hacen que la base de datos trabaje m\u00e1s eficientemente porque pueden usarse repetidamente sin recompilar.<\/p>\n\n\n\n
Es la primera y m\u00e1s efectiva medida que los administradores de bases de datos deben tomar para prevenir ataques de inyecci\u00f3n SQL.<\/p>\n\n\n\n
Procedimientos almacenados<\/h3>\n\n\n\n
Los procedimientos almacenados son una secuencia de instrucciones que se pueden almacenar en la base de datos para su reutilizaci\u00f3n posterior. A menudo se crean para manejar secuencias de consultas que se aplican con frecuencia al modelo de la base de datos, ejecut\u00e1ndolas siempre que sea necesario.<\/p>\n\n\n\n
Los procedimientos almacenados pueden ser tan efectivos como las sentencias preparadas cuando no incluyen generaci\u00f3n de SQL din\u00e1mico no seguro. En este sentido, cumplen un rol similar a las sentencias preparadas, pero la principal diferencia es que las sentencias preparadas no pueden almacenarse mientras que los procedimientos almacenados s\u00ed.<\/p>\n\n\n\n
No todos los sistemas de gesti\u00f3n de bases de datos permiten procedimientos almacenados, por lo tanto, su implementaci\u00f3n depende de si tu sistema admite esta caracter\u00edstica. Sistemas de gesti\u00f3n populares como los de Microsoft y Oracle los soportan.<\/p>\n\n\n\n
Escanea tu sitio web a menudo<\/h3>\n\n\n\n
Existen pruebas de vulnerabilidad a inyecciones SQL en l\u00ednea que pod\u00e9s ejecutar en tu sitio web (algunas de ellas son solo premium). Estas pruebas te dar\u00e1n una visi\u00f3n general de tus vulnerabilidades actuales junto con descripciones m\u00e1s detalladas de los riesgos que corre tu sitio web y c\u00f3mo corregir sus fallas de seguridad.<\/p>\n\n\n\n
Validaci\u00f3n o saneamiento de entradas<\/h3>\n\n\n\n
Otra medida que debe usarse en combinaci\u00f3n con las sentencias preparadas es la validaci\u00f3n de entradas, que consiste en escribir c\u00f3digo de una manera que identifique las entradas de usuario maliciosas, el m\u00e9todo principal detr\u00e1s de las inyecciones SQL.<\/p>\n\n\n\n
Los expertos consideran que la mejor forma de aplicar la validaci\u00f3n de entradas es aplicando la validaci\u00f3n de “lista preferida” o “lista blanca”. Con este enfoque, la entrada del usuario se compara estrictamente con un conjunto de entradas conocidas, v\u00e1lidas y aprobadas. Si la entrada del usuario no se ajusta a la lista blanca de entradas, se rechaza.<\/p>\n\n\n\n
Aunque la validaci\u00f3n de entradas en lista blanca es una pr\u00e1ctica recomendada, todav\u00eda puede ser vulnerable a lagunas y exploits, dada la dificultad de mapeo de todas las posibles entradas legales. Adem\u00e1s, una validaci\u00f3n de entradas mal aplicada puede interferir en la experiencia del usuario al generar muchos falsos positivos.<\/p>\n\n\n\n
Es mejor combinarla con sentencias preparadas.<\/p>\n\n\n\n
Escapando la entrada del usuario<\/h3>\n\n\n\n
“Escapar” la entrada del usuario implica usar una t\u00e9cnica (generalmente agregando un caracter antes de la cadena proporcionada por el usuario) para evitar que la entrada del usuario sea interpretada como c\u00f3digo en lugar de una cadena de texto. Record\u00e1 que los hackers ingresan comandos SQL en campos de entrada de usuario para eludir la seguridad.<\/p>\n\n\n\n
<\/figure>\n\n\n\nSQL<\/a> es un lenguaje de programaci\u00f3n utilizado para gestionar bases de datos relacionales. Todos los sitios de WordPress utilizan bases de datos relacionales y gestores de bases de datos relacionales como MySQL, MariaDB y AuroraDB.<\/p>\n\n\n\n Las inyecciones SQL son usos maliciosos de SQL para obtener acceso a informaci\u00f3n en el backend que deber\u00eda quedar oculta al p\u00fablico. Las inyecciones SQL en WordPress consisten en hackers que escriben comandos SQL en campos de entrada de usuario con la intenci\u00f3n de ingresar a sitios web. Los campos de entrada de usuario m\u00e1s comunes que los hackers utilizan para inyectar comandos SQL incluyen casillas de inicio de sesi\u00f3n, casillas de b\u00fasqueda o campos de registro.<\/p>\n\n\n\n Debido a la forma en que las inyecciones SQL explotan vulnerabilidades en los campos de entrada de usuario, en algunos casos, pueden ser similares a los ataques cross-site scripting<\/a> (XSS), otra amenaza cibern\u00e9tica com\u00fan en el ecosistema de WordPress.<\/p>\n\n\n\n Los hackers realizan ataques de inyecci\u00f3n SQL interfiriendo con las consultas que una aplicaci\u00f3n (en este caso, un sitio web de WordPress) hace a su base de datos. Una consulta de base de datos es una solicitud de la informaci\u00f3n en la base de datos.<\/p>\n\n\n\n Una de las formas m\u00e1s comunes en que los hackers inyectan comandos SQL maliciosos es a trav\u00e9s de campos de entrada como los formularios de nombre de usuario y contrase\u00f1a. Un atacante puede, por ejemplo, introducir un nombre de usuario v\u00e1lido para el cual no tiene la contrase\u00f1a y luego enviar un comando SQL en el campo En lugar de ingresar la contrase\u00f1a, el hacker puede introducir el siguiente comando SQL:<\/p>\n\n\n\n Tenga en cuenta que despu\u00e9s del Este comando modifica la consulta para indicarle a la base de datos que permita a este usuario iniciar sesi\u00f3n al coincidir el nombre de usuario Sin embargo, este ataque no funcionar\u00eda en sitios web que encriptan sus contrase\u00f1as en lugar de pasarlas como texto plano. Para esos casos, un hacker puede usar solo el campo El hacker luego escribir\u00eda cualquier cosa en el campo Estos son dos ejemplos sencillos de los muchos m\u00e9todos que los hackers pueden usar para entrar en sitios web al ingresar comandos SQL maliciosos en campos de entrada vulnerables. Los administradores de sitios web con conocimientos toman medidas de seguridad para prevenir estos ataques, pero los propietarios de sitios web no t\u00e9cnicos pueden no ser conscientes de esta vulnerabilidad, abriendo la puerta a m\u00e1s ataques.<\/p>\n\n\n\n Independientemente del m\u00e9todo, las inyecciones SQL enga\u00f1an a las bases de datos que no validan la entrada del usuario para dar a los hackers informaci\u00f3n destinada a permanecer privada.<\/p>\n\n\n\n Ahora que entend\u00e9s c\u00f3mo los hackers pueden f\u00e1cilmente vulnerar sitios web no asegurados, exploremos los diferentes tipos de ataques de inyecci\u00f3n SQL.<\/p>\n\n\n\n Las inyecciones SQL de banda directa o cl\u00e1sicas son ataques de inyecci\u00f3n SQL que utilizan el mismo canal para iniciar el ataque y extraer la informaci\u00f3n que desean. Por ejemplo, un hacker puede infiltrarse en un sitio utilizando comandos SQL en un navegador. Los resultados se mostrar\u00e1n en el mismo navegador si utilizan una inyecci\u00f3n SQL de banda directa.<\/p>\n\n\n\n Existen dos subtipos comunes de inyecci\u00f3n SQL de banda directa.<\/p>\n\n\n\n En estos ataques de banda directa, los hackers ingresan consultas que producen un error en la base de datos. Por ejemplo, sus comandos SQL podr\u00edan contener una sintaxis deliberadamente incorrecta que cause una respuesta de error.<\/p>\n\n\n\n Bas\u00e1ndose en los datos que recopilan de los mensajes de error, los hackers pueden obtener informaci\u00f3n sobre la estructura de la base de datos o idear formas de acceder sin autorizaci\u00f3n. Con ataques SQL basados en errores, los hackers pueden enumerar parcial o completamente una base de datos (extraer datos disponibles).<\/p>\n\n\n\n En SQL, la declaraci\u00f3n Los ataques SQL basados en Durante los ataques SQL de banda directa, los hackers pueden enviar una consulta y recibir una respuesta en el mismo canal, como el navegador que est\u00e1n utilizando.<\/p>\n\n\n\n En los ataques SQL “ciegos” o inferenciales, los hackers no reciben informaci\u00f3n directamente de la base de datos. Aun as\u00ed, pueden monitorear la respuesta de la aplicaci\u00f3n a la consulta que enviaron y obtener informaci\u00f3n de ella. Este tipo de ataque SQL tambi\u00e9n tiene dos subtipos.<\/p>\n\n\n\n Los hackers env\u00edan una consulta SQL y observan la respuesta de la base de datos. El contenido de la respuesta HTTP a la consulta var\u00eda dependiendo de si la consulta devolvi\u00f3 un Booleano Aunque la base de datos no devolvi\u00f3 expl\u00edcitamente datos al hacker, este puede inferir si la consulta (como la longitud de una entrada de base de datos) era Con este m\u00e9todo, los hackers tambi\u00e9n quieren saber si una consulta devolvi\u00f3 un Booleano Dependiendo de si la respuesta HTTP lleg\u00f3 de inmediato o con un retraso de unos segundos, los hackers pueden determinar si era verdadero o falso. Pueden utilizar este m\u00e9todo para enumerar la base de datos lentamente.<\/p>\n\n\n\n Este tipo de inyecciones SQL son menos comunes y se usan como alternativa a los tipos anteriores. Los hackers las utilizan t\u00edpicamente cuando no pueden recibir respuestas de la base de datos por el mismo canal a trav\u00e9s del cual est\u00e1n atacando. En su lugar, ordenan a una aplicaci\u00f3n que env\u00ede datos a una ubicaci\u00f3n remota, como un servidor al que el hacker tiene acceso.<\/p>\n\n\n\n Los ataques SQL fuera de banda solo funcionan cuando el hacker puede acceder a un servidor con comandos que generan solicitudes DNS y HTTP desde otros servidores, una caracter\u00edstica com\u00fan en servidores SQL populares como Microsoft SQL Server y Oracle Database.<\/p>\n\n\n\n Al hacer solicitudes DNS y HTTP, los hackers pueden transferir informaci\u00f3n sensible desde la base de datos de la v\u00edctima a su servidor.<\/p>\n\n\n\n Los hackers tienen varias razones para realizar ataques de inyecci\u00f3n SQL. Los datos m\u00e1s comunes a los que pueden acceder incluyen los siguientes:<\/p>\n\n\n\n Si su ataque SQL les otorga acceso administrativo directo con credenciales de inicio de sesi\u00f3n robadas, los hackers podr\u00edan:<\/p>\n\n\n\n Esto podr\u00eda dejar un impacto duradero en el sitio web y las marcas detr\u00e1s de \u00e9l. Por ejemplo, supongamos que la marca cumple con leyes de protecci\u00f3n de informaci\u00f3n personal como el GDPR de la Uni\u00f3n Europea. En ese caso, podr\u00edan enfrentar multas debido a una violaci\u00f3n de seguridad causada por inyecciones SQL.<\/p>\n\n\n\n Los expertos consideran que las vulnerabilidades de inyecci\u00f3n SQL son graves debido a su potencial para interrumpir una aplicaci\u00f3n de WordPress. El hecho de que tambi\u00e9n est\u00e9n muy extendidas no mejora la situaci\u00f3n.<\/p>\n\n\n\n De acuerdo con el informe<\/a> de seguridad de Wordfence de 2022 sobre WordPress, las vulnerabilidades de inyecci\u00f3n SQL fueron la cuarta categor\u00eda m\u00e1s com\u00fan de vulnerabilidades divulgadas durante el a\u00f1o. Adem\u00e1s, el informe<\/a> de seguridad de Sucuri de 2021 determin\u00f3 que plugins populares con cientos de miles o millones de instalaciones, como WooCommerce, All In One SEO, y WP Statistics, ten\u00edan vulnerabilidades de inyecci\u00f3n SQL que sus respectivos desarrolladores eventuales parchearon.<\/p>\n\n\n\n Puede ser dif\u00edcil proteger tu sitio de ataques de inyecci\u00f3n SQL porque hay muchas v\u00edas para que los hackers exploten, pero los expertos han ideado varias estrategias.<\/p>\n\n\n\n Las sentencias preparadas o consultas parametrizadas son a menudo consideradas la forma m\u00e1s efectiva de evitar ataques SQL. El problema fundamental que causa la inyecci\u00f3n de c\u00f3digo SQL malicioso en campos de entrada es que mezclan c\u00f3digo y datos, enga\u00f1ando a las bases de datos vulnerables para compartir informaci\u00f3n confidencial.<\/p>\n\n\n\n Las sentencias preparadas aseguran que el c\u00f3digo SQL se env\u00ede al servidor de la base de datos y se analice por separado de los datos, lo que hace m\u00e1s dif\u00edcil o imposible que un hacker inyecte c\u00f3digo SQL malicioso. Tambi\u00e9n hacen que la base de datos trabaje m\u00e1s eficientemente porque pueden usarse repetidamente sin recompilar.<\/p>\n\n\n\n Es la primera y m\u00e1s efectiva medida que los administradores de bases de datos deben tomar para prevenir ataques de inyecci\u00f3n SQL.<\/p>\n\n\n\n Los procedimientos almacenados son una secuencia de instrucciones que se pueden almacenar en la base de datos para su reutilizaci\u00f3n posterior. A menudo se crean para manejar secuencias de consultas que se aplican con frecuencia al modelo de la base de datos, ejecut\u00e1ndolas siempre que sea necesario.<\/p>\n\n\n\n Los procedimientos almacenados pueden ser tan efectivos como las sentencias preparadas cuando no incluyen generaci\u00f3n de SQL din\u00e1mico no seguro. En este sentido, cumplen un rol similar a las sentencias preparadas, pero la principal diferencia es que las sentencias preparadas no pueden almacenarse mientras que los procedimientos almacenados s\u00ed.<\/p>\n\n\n\n No todos los sistemas de gesti\u00f3n de bases de datos permiten procedimientos almacenados, por lo tanto, su implementaci\u00f3n depende de si tu sistema admite esta caracter\u00edstica. Sistemas de gesti\u00f3n populares como los de Microsoft y Oracle los soportan.<\/p>\n\n\n\n Existen pruebas de vulnerabilidad a inyecciones SQL en l\u00ednea que pod\u00e9s ejecutar en tu sitio web (algunas de ellas son solo premium). Estas pruebas te dar\u00e1n una visi\u00f3n general de tus vulnerabilidades actuales junto con descripciones m\u00e1s detalladas de los riesgos que corre tu sitio web y c\u00f3mo corregir sus fallas de seguridad.<\/p>\n\n\n\n Otra medida que debe usarse en combinaci\u00f3n con las sentencias preparadas es la validaci\u00f3n de entradas, que consiste en escribir c\u00f3digo de una manera que identifique las entradas de usuario maliciosas, el m\u00e9todo principal detr\u00e1s de las inyecciones SQL.<\/p>\n\n\n\n Los expertos consideran que la mejor forma de aplicar la validaci\u00f3n de entradas es aplicando la validaci\u00f3n de “lista preferida” o “lista blanca”. Con este enfoque, la entrada del usuario se compara estrictamente con un conjunto de entradas conocidas, v\u00e1lidas y aprobadas. Si la entrada del usuario no se ajusta a la lista blanca de entradas, se rechaza.<\/p>\n\n\n\n Aunque la validaci\u00f3n de entradas en lista blanca es una pr\u00e1ctica recomendada, todav\u00eda puede ser vulnerable a lagunas y exploits, dada la dificultad de mapeo de todas las posibles entradas legales. Adem\u00e1s, una validaci\u00f3n de entradas mal aplicada puede interferir en la experiencia del usuario al generar muchos falsos positivos.<\/p>\n\n\n\n Es mejor combinarla con sentencias preparadas.<\/p>\n\n\n\n “Escapar” la entrada del usuario implica usar una t\u00e9cnica (generalmente agregando un caracter antes de la cadena proporcionada por el usuario) para evitar que la entrada del usuario sea interpretada como c\u00f3digo en lugar de una cadena de texto. Record\u00e1 que los hackers ingresan comandos SQL en campos de entrada de usuario para eludir la seguridad.<\/p>\n\n\n\n\u00bfC\u00f3mo funcionan las inyecciones SQL en WordPress?<\/h2>\n\n\n\n
Contrase\u00f1a<\/code> de la siguiente manera:<\/p>\n\n\n\n<\/figure>\n\n\n\n'OR username username_123 -- <\/code><\/pre>\n\n\n\n-- <\/code> hay un espacio en blanco esencial para que este comando funcione.<\/p>\n\n\n\nusername_123<\/code> con su contrase\u00f1a correspondiente (la forma tradicional de iniciar sesi\u00f3n) o simplemente ingresando el nombre de usuario correcto y haciendo clic en Iniciar sesi\u00f3n<\/strong>. Este comando hace que el campo Contrase\u00f1a<\/code> sea irrelevante porque el sitio web permitir\u00e1 que el usuario inicie sesi\u00f3n simplemente escribiendo un nombre de usuario v\u00e1lido, sin importar lo que est\u00e9 en el campo Contrase\u00f1a<\/code>.<\/p>\n\n\n\nUsername<\/code>, ingresando el siguiente comando SQL (con un espacio en el final):<\/p>\n\n\n\nusername_123\u2019 -- <\/code><\/pre>\n\n\n\nContrase\u00f1a<\/code> ya que el comando SQL en el campo Username<\/code> hace que la contrase\u00f1a, una vez m\u00e1s, sea irrelevante.<\/p>\n\n\n\n<\/figure>\n\n\n\nTipos de ataques de inyecci\u00f3n SQL en WordPress<\/h2>\n\n\n\n
Inyecciones SQL de banda directa o cl\u00e1sicas<\/h3>\n\n\n\n
Inyecciones SQL basadas en errores<\/h4>\n\n\n\n
Inyecciones SQL basadas en UNION<\/h4>\n\n\n\n
SELECT<\/code> selecciona datos de una base de datos, almacen\u00e1ndolos en una tabla de resultados llamada “conjunto de resultados”. En el caso de una base de datos de WordPress, el conjunto de resultados puede incluir datos relacionados con plugins, comentarios, nombres de usuario, contrase\u00f1as, etc. La declaraci\u00f3n UNION<\/code> combina los datos del resultado de dos o m\u00e1s declaraciones SELECT<\/code> en un solo conjunto de resultados.<\/p>\n\n\n\nUNION<\/code> utilizan la declaraci\u00f3n UNION<\/code> para realizar consultas que resultan en una combinaci\u00f3n de tablas de la base de datos del sitio web como respuesta HTTP. Los hackers pueden usar este m\u00e9todo para extraer informaci\u00f3n valiosa.<\/p>\n\n\n\nInyecciones SQL inferenciales o de ciegas<\/h3>\n\n\n\n
Inyecciones SQL ciegas de Booleano<\/h4>\n\n\n\n
true<\/code> o false<\/code>.<\/p>\n\n\n\ntrue<\/code> o false<\/code> en funci\u00f3n del contenido de la respuesta HTTP. Al probar con m\u00faltiples consultas que indagan informaci\u00f3n sobre la base de datos, los hackers pueden lentamente enumerarla.<\/p>\n\n\n\nInyecciones SQL ciegas basadas en tiempo<\/h4>\n\n\n\n
true<\/code> o false<\/code>, pero en este caso lo hacen midiendo el tiempo que tarda la respuesta en llegar. Para lograr esto, env\u00edan una consulta que obliga a la base de datos a esperar un n\u00famero espec\u00edfico de segundos para responder.<\/p>\n\n\n\nInyecciones SQL fuera de banda<\/h3>\n\n\n\n
\u00bfQu\u00e9 pueden ganar, robar o lograr los hackers con ataques de inyecci\u00f3n SQL en WordPress?<\/h2>\n\n\n\n
<\/figure>\n\n\n\n\n
\n
\u00bfC\u00f3mo proteger tus sitios de WordPress de los ataques de inyecci\u00f3n de base de datos?<\/h2>\n\n\n\n
<\/figure>\n\n\n\nSentencias preparadas<\/h3>\n\n\n\n
Procedimientos almacenados<\/h3>\n\n\n\n
Escanea tu sitio web a menudo<\/h3>\n\n\n\n
Validaci\u00f3n o saneamiento de entradas<\/h3>\n\n\n\n
Escapando la entrada del usuario<\/h3>\n\n\n\n