JavaScript y bases de datos

Ya vimos en el capítulo anterior HTML y CSS ahora veremos JavaScript y bases de datos lo que nos permitirá entender mejor ataques como XSS y SQLi, y comprenderás cómo la capa visual (CSS) y la lógica cliente (JS) interactúan con el servidor y la base de datos. Aprenderás a identificar exposición de datos en el frontend, a distinguir cuándo una entrada es peligrosamente refl ejada o almacenada, y a explotar (y mitigar) fallos de inyección tanto en el navegador como en el backend. Esto es esencial para cualquier pentester: saber cómo ver, manipular y abusar la superficie que el usuario ve (HTML/CSS/JS) y cómo esa interacción puede traducirse en acceso a datos o compromiso del sistema (SQLi, XSS). 

JavaScript

JavaScript (JS) es uno de los lenguajes de programación más populares del mundo y permite que las páginas sean interactivas. HTML se utiliza para crear la estructura y el contenido de un sitio web, mientras que JavaScript se utiliza para controlar la funcionalidad de las páginas web. Sin JavaScript, una página no tendría elementos interactivos y siempre sería estática. JS puede actualizar la página dinámicamente en tiempo real, ofreciendo la posibilidad de cambiar el estilo de un botón cuando ocurre un evento específico (como cuando un usuario hace clic en un botón) o de mostrar animaciones en movimiento.

• JavaScript se agrega dentro del código fuente de la página y se puede cargar dentro de las etiquetas o se puede incluir de forma remota con el atributo src:<script><script src=»/location/of/javascript_file.js»></script>
• El siguiente código JavaScript encuentra un elemento HTML en la página con el id «demo» y cambia el contenido del elemento a «Hack the Planet»: document.getElementById(«demo»).innerHTML = «Hack the Planet»;
• Los elementos HTML también pueden tener eventos, como «onclick» o «onhover», que ejecutan JavaScript cuando se produce el evento. El siguiente código cambia el texto del elemento con el ID de demostración a «Botón pulsado»:  Los eventos «onclick» también pueden definirse dentro de las etiquetas de script de JavaScript, y no directamente en los elementos. <button onclick=’document.getElementById(«demo»).innerHTML = «Button Clicked»;’>Click Me!</button>

La exposición de datos confidenciales ocurre cuando un sitio web no protege (o elimina) adecuadamente la información confidencial en texto claro para el usuario final; generalmente se encuentra en el código fuente del frontend de un sitio.

Sabemos que los sitios web se crean con muchos elementos HTML (etiquetas), todos los cuales podemos ver simplemente al ver el código fuente de la página. Es posible que un desarrollador web haya olvidado eliminar las credenciales de inicio de sesión, los enlaces ocultos a secciones privadas del sitio web u otros datos confidenciales que se muestran en HTML o JavaScript.

La información confidencial puede utilizarse para facilitar el acceso de un atacante a diferentes partes de una aplicación web. Por ejemplo, podría haber comentarios HTML con credenciales de inicio de sesión temporales, y si al consultar el código fuente de la página se encuentra esta información, podría usar estas credenciales para iniciar sesión en otra parte de la aplicación (o peor aún, para acceder a otros componentes del backend del sitio). Siempre que evalúe una aplicación web en busca de problemas de seguridad, una de las primeras cosas que debe hacer es revisar el código fuente de la página para ver si puede encontrar credenciales de inicio de sesión expuestas o enlaces ocultos.

Métodos HTML de JavaScript

Uno de los muchos métodos HTML de JavaScript es getElementById().

El siguiente ejemplo «encuentra» un elemento HTML (con id=»demo») y cambia el contenido del elemento (innerHTML) a «Hola JavaScript»:

document.getElementById(«demo»).innerHTML = «Hello JavaScript»;

JavaScript puede cambiar los estilos HTML (CSS)

Cambiar el estilo de un elemento HTML es una variante de cambiar un atributo HTML:

document.getElementById(«demo»).style.fontSize = «35px»;

JavaScript puede ocultar elementos HTML

Se pueden ocultar elementos HTML cambiando el display style:

document.getElementById(«demo»).style.display = «none»;

JavaScript puede mostrar elementos HTML

También se pueden mostrar elementos HTML ocultos cambiando el display style:

Ejemplo

document.getElementById(«demo»).style.display = «block»;

¿Sabías?

• JavaScript y Java son lenguajes completamente diferentes, tanto en concepto como en diseño.
• JavaScript fue inventado por Brendan Eich en 1995 y se convirtió en un estándar ECMA en 1997.
• ECMA-262 es el nombre oficial del estándar. ECMAScript es el nombre oficial del lenguaje.

Secuencias de comandos entre sitios (XSS)

• Las secuencias de comandos entre sitios (XSS) son una vulnerabilidad web del lado del cliente que permite a los atacantes inyectar scripts maliciosos en páginas web.
• Esta vulnerabilidad suele estar causada por la falta de saneamiento/validación de entrada en las aplicaciones web.
• Los atacantes aprovechan las vulnerabilidades XSS para inyectar código malicioso en las aplicaciones web. Dado que XSS es una vulnerabilidad del lado del cliente, estos scripts son ejecutados por el navegador de la víctima.
• Las vulnerabilidades XSS afectan a las aplicaciones web que carecen de validación de entrada y aprovechan lenguajes de scripting del lado del cliente como Javascript, Flash, CSS, etc

Secuencias de comandos entre sitios (XSS)

Las vulnerabilidades/ataques XSS se suelen clasificar en dos categorías principales: almacenadas/persistentes y reflejadas. Los ataques XSS se suelen explotar para los siguientes objetivos:

• Robo de cookies/secuestro de sesiones: robo de cookies de usuarios con sesiones autenticadas, lo que les permite iniciar sesión como otros usuarios aprovechando la información de autenticación contenida en una cookie.
• Explotación del navegador: explotación de las vulnerabilidades del navegador.
• Registro de pulsaciones de teclas: registro de las entradas del teclado realizadas por otros usuarios en una aplicación web.
• Phishing: inyección de formularios de inicio de sesión falsos en una página web para capturar credenciales, y muchos más.

XSS almacenado

Almacenado/Persistente

El scripting entre sitios almacenado es una vulnerabilidad en la que un atacante puede inyectar código Javascript en la base de datos o el código fuente de una aplicación web a través de una entrada que no está desinfectada. Por ejemplo, si un atacante puede inyectar una carga útil XSS maliciosa en una página web de un sitio web sin la desinfección adecuada, la carga útil XSS inyectada en la página web será ejecutada por el navegador de cualquiera que visite esa página web

La imagen muestra, de forma muy clara y lineal, el ciclo típico de un ataque Cross-Site Scripting (XSS): primero un atacante introduce un fragmento de código malicioso (el payload) en la aplicación —por ejemplo en un campo de un formulario que se guarda en la base de datos o en una entrada que el servidor devuelve sin limpiar—; después, cuando una víctima legítima visita la página, el navegador de esa víctima carga y ejecuta ese mismo código malicioso; y finalmente, el código ejecutado en el contexto del navegador del usuario envía información (cookies, tokens, o cualquier dato disponible) de vuelta al atacante. En la práctica, esto significa que una simple caja de comentarios, un perfil de usuario o un campo de entrada mal filtrado pueden convertirse en un vector para robar sesiones, suplantar acciones o inyectar contenido fraudulento en la experiencia de otros usuarios.

Aunque el diagrama ilustra sobre todo el flujo de un XSS almacenado —el payload se introduce y permanece en el servidor o base de datos para ser servido a futuros visitantes— conviene recordar que existen otras variantes: en el XSS reflejado el payload viaja en la URL o en una petición y es devuelto inmediatamente por el servidor (útil para phishing con enlaces), y en el DOM-based XSS la vulnerabilidad ocurre en el lado del cliente cuando JavaScript inseguro manipula datos del URL o del DOM sin saneamiento. En cualquiera de los tres casos el problema raíz es el mismo: datos no confiables se tratan como código ejecutable en el contexto de confianza del sitio.

El impacto para los usuarios y para la organización puede ser severo: un atacante puede robar cookies de sesión (si no están protegidas), realizar acciones en nombre del usuario, instalar malware, redirigir a páginas de phishing o manipular el contenido que otros ven. Por eso, las medidas de mitigación deben ser múltiples y aplicadas en capas.

En primer lugar, siempre hay que tratar las entradas del usuario como datos no fiables: aplicar saneamiento y, sobre todo, codificar la salida en el contexto correcto (HTML, atributo, JavaScript, URL). Las consultas SQL o las plantillas no deben imprimir datos sin escapar. En segundo lugar, políticas adicionales como Content Security Policy (CSP) ayudan a limitar qué scripts pueden ejecutarse y dificultan la carga de payloads externos. También es crítico proteger las cookies sensibles con las banderas HttpOnly, Secure y SameSite para reducir el riesgo de robo por XSS y mitigar su uso en CSRF.

Más medidas operativas útiles incluyen el uso de frameworks que automáticamente hacen escaping contextual (por ejemplo, templates modernos), validación estricta en servidor (no confiar solo en validación cliente), revisiones de código y pruebas de seguridad (scans dinámicos y pruebas de caja negra), y la adopción de pruebas automáticas de detección de XSS en el pipeline de CI/CD. Finalmente, en caso de detección, hay que tener playbooks para respuesta: identificar alcance (qué páginas y usuarios fueron expuestos), rotar credenciales comprometidas y desplegar un parche o filtrado lo antes posible.

En resumen, la imagen ilustra cómo un fragmento de JavaScript malicioso puede viajar desde la entrada de un atacante hasta el navegador de una víctima y devolver datos al atacante; la defensa eficaz combina saneamiento y codificación contextual, políticas de seguridad como CSP, protección de cookies y prácticas de desarrollo seguras para eliminar tanto la superficie de ataque como las consecuencias de una posible explotación.

XSS reflejado

El scripting entre sitios reflejado/no persistente es la forma más común de XSS y consiste en engañar a la víctima para que haga clic en un enlace especialmente diseñado (con una carga útil XSS) al sitio web vulnerable. Cuando la víctima hace clic en el enlace, el sitio web incluye la carga útil XSS como parte de la respuesta al navegador de la víctima, donde se ejecuta la carga útil

Esta imagen representa el flujo de un ataque de Cross-Site Scripting (XSS) reflejado, una de las formas más comunes de explotación en aplicaciones web vulnerables. En este tipo de ataque, el código malicioso no se almacena permanentemente en el servidor, sino que se “refleja” en la respuesta enviada por la aplicación cuando el usuario hace clic en un enlace manipulado.

Todo comienza en el paso 1, cuando el atacante crea un enlace especialmente diseñado que incluye un payload XSS dentro de un parámetro de la URL, por ejemplo:

http://website.com/page.php?<payload>

Este enlace puede ser distribuido a la víctima mediante correos de phishing, mensajes en redes sociales o incluso comentarios en foros.

En el paso 2, la víctima hace clic en el enlace y es redirigida al sitio web legítimo. Sin embargo, la aplicación web, al no validar ni codificar correctamente los parámetros de entrada, inserta el contenido del payload dentro de la página HTML que devuelve al navegador del usuario.

El paso 3 muestra lo crítico del problema: el navegador interpreta el código malicioso como parte legítima del sitio y lo ejecuta. Este código puede, por ejemplo, robar cookies de sesión, registrar pulsaciones del teclado o redirigir a la víctima a otra página bajo control del atacante. En la imagen, se observa cómo la respuesta del servidor incluye el payload dentro de etiquetas <script>, demostrando que no hubo sanitización del contenido.

El resultado final es que, aunque la víctima está navegando un sitio web legítimo, su navegador ejecuta código controlado por un atacante, lo que convierte este tipo de vulnerabilidad en una amenaza seria para la integridad de los usuarios y de la aplicación.

Para prevenir ataques XSS reflejados, las aplicaciones deben validar y codificar todas las entradas del usuario antes de devolverlas en una respuesta, usar cabeceras de seguridad como Content-Security-Policy (CSP) y restringir el uso de etiquetas peligrosas mediante políticas de saneamiento del lado del servidor y del cliente.

Bases de datos

Una base de datos es una colección de datos que se organiza de forma que facilita su gestión, acceso y actualización. En informática, una base de datos suele ser gestionada por un sistema de gestión de bases de datos (DBMS) que proporciona un conjunto de herramientas e interfaces para interactuar con los datos. Las bases de datos se utilizan en diversas aplicaciones, como aplicaciones empresariales, sitios web y aplicaciones móviles, para almacenar y gestionar grandes cantidades de datos estructurados o no estructurados. Algunos ejemplos de datos que se pueden almacenar en una base de datos incluyen información de clientes, registros financieros, inventario de productos y registros de empleados.

Sistemas de gestión de bases de datos (DBMS)

DBMS significa «Sistema de gestión de bases de datos». Es un sistema de software que permite a los usuarios crear, almacenar, organizar, gestionar y recuperar datos de una base de datos. El DBMS proporciona una interfaz entre el usuario y la base de datos, lo que permite a los usuarios interactuar con la base de datos sin tener que comprender los detalles técnicos subyacentes del almacenamiento, la recuperación y la gestión de datos. El DBMS proporciona varias funcionalidades, como crear, eliminar, modificar y consultar los datos almacenados en la base de datos. También gestiona la seguridad, el control de concurrencia, las copias de seguridad, la recuperación y otros aspectos importantes de la gestión de datos.

Los siguientes son ejemplos de sistemas de gestión de bases de datos (SGBD) populares:

• MySQL: un sistema de gestión de bases de datos relacionales gratuito y de código abierto que se utiliza ampliamente para aplicaciones web.
• PostgreSQL: otro sistema popular de gestión de bases de datos relacionales de código abierto, conocido por sus funciones avanzadas y su fiabilidad.
• Oracle Database: un sistema comercial de gestión de bases de datos relacionales desarrollado por Oracle Corporation que se utiliza ampliamente en aplicaciones empresariales.
• Microsoft SQL Server: un sistema comercial de gestión de bases de datos relacionales desarrollado

Tipos de bases de datos

• Bases de datos relacionales: una base de datos que organiza los datos en una o más tablas o relaciones, donde cada tabla representa una entidad o un concepto, y las columnas de la tabla representan los atributos de esa entidad o concepto.
• Bases de datos NoSQL: un tipo de base de datos que no utiliza las relaciones tabulares tradicionales utilizadas en las bases de datos relacionales. En su lugar, las bases de datos NoSQL utilizan una variedad de modelos de datos para almacenar y acceder a los datos.
• Bases de datos orientadas a objetos: una base de datos que almacena los datos como objetos en lugar de en tablas, lo que permite estructuras y relaciones de datos más complejas

Bases de datos SQL

Las bases de datos SQL son bases de datos relacionales que almacenan datos en tablas con filas y columnas, y utilizan SQL (lenguaje de consulta estructurado) como lenguaje estándar para la gestión de datos. Imponen reglas estrictas de integridad de datos y admiten transacciones para garantizar la coherencia de los datos. Las bases de datos SQL se utilizan ampliamente en aplicaciones que requieren consultas de datos complejas y la capacidad de gestionar grandes cantidades de datos estructurados. Algunos ejemplos de bases de datos SQL incluyen MySQL, Oracle, Microsoft SQL Server y PostgreSQL

Bases de datos relacionales

Una base de datos relacional es un tipo de base de datos que organiza los datos en una o más tablas o relaciones, donde cada tabla representa una entidad o un concepto, y las columnas de la tabla representan los atributos de esa entidad o concepto. Las relaciones entre las tablas se establecen mediante el uso de claves, que vinculan los registros de una tabla con los registros de otra. Las bases de datos relacionales utilizan un lenguaje de consulta estructurado (SQL) para gestionar los datos. SQL es un lenguaje estandarizado que se utiliza para crear, manipular y consultar bases de datos relacionales

RDBMS

• RDBMS significa Sistema de Gestión de Bases de Datos Relacionales.
• Es un sistema de software que permite la creación, gestión y administración de bases de datos relacionales.
• Los RDBMS están diseñados para almacenar, organizar y recuperar grandes cantidades de datos estructurados de forma eficiente.
• Los RDBMS proporcionan un conjunto de características y funcionalidades que permiten a los usuarios crear esquemas de bases de datos, definir relaciones entre tablas, insertar, actualizar y recuperar datos, y realizar consultas complejas mediante SQL.
• También gestionan aspectos como la seguridad de los datos, la gestión de transacciones y el control de concurrencia para garantizar la integridad y la coherencia de los datos

Algunos ejemplos populares de RDBMS incluyen:

• Oracle Database: Desarrollado por Oracle Corporation, es uno de los RDBMS de nivel empresarial más utilizados, conocido por su escalabilidad, fiabilidad y completo conjunto de funciones.
• MySQL: Un RDBMS de código abierto conocido por su facilidad de uso, alto rendimiento y amplia adopción. MySQL se utiliza comúnmente en aplicaciones web y cuenta con el respaldo de Oracle Corporation.
• Microsoft SQL Server: Un RDBMS popular desarrollado por Microsoft. Ofrece una gama de ediciones para diferentes cargas de trabajo y tiene una sólida integración con otros productos de Microsoft.
• PostgreSQL: Un RDBMS de código abierto conocido por su robustez, escalabilidad y cumplimiento de los estándares SQL. PostgreSQL ofrece funciones avanzadas y es altamente extensible

Cómo funcionan las bases de datos relacionales

Tablas: Los componentes básicos de una base de datos relacional son las tablas, también conocidas como relaciones. Una tabla consta de filas (también llamadas registros o tuplas) y columnas (también conocidas como atributos). Cada fila representa un registro o instancia única de una entidad, y cada columna representa un atributo o característica específica de esa entidad.

Claves: Las claves se utilizan para identificar de forma única los registros dentro de una tabla y establecer relaciones entre ellas. La clave principal es una columna o conjunto de columnas que identifica de forma única cada fila de una tabla. Garantiza la integridad y la unicidad de los datos. Las claves externas son columnas de una tabla que hacen referencia a la clave principal de otra tabla, estableciendo relaciones entre las tablas

Relaciones: Las relaciones definen cómo se conectan o asocian las tablas entre sí. Los tipos comunes de relaciones incluyen uno a uno, uno a muchos y muchos a muchos. Estas relaciones se establecen utilizando claves principales y externas, lo que permite vincular y recuperar datos en varias tablas.

Lenguaje de consulta estructurado (SQL): Las bases de datos relacionales suelen accederse y manipularse mediante el lenguaje de consulta estructurado (SQL). SQL proporciona un lenguaje estandarizado para consultar, insertar, actualizar y eliminar datos de bases de datos relacionales. Permite a los usuarios realizar operaciones como recuperar registros específicos, filtrar datos según condiciones, unir tablas para combinar datos y agregar datos mediante funciones.

Bases de datos NoSQL

Las bases de datos NoSQL (no solo SQL) son un tipo de sistema de gestión de bases de datos que se diferencia de las bases de datos relacionales tradicionales (RDBMS) en términos de modelo de datos, escalabilidad y flexibilidad. Están diseñadas para gestionar grandes volúmenes de datos no estructurados, semiestructurados y que cambian rápidamente. Las bases de datos NoSQL se utilizan comúnmente en aplicaciones web modernas, análisis de big data, transmisión en tiempo real, sistemas de gestión de contenido y otros escenarios donde las ventajas de flexibilidad, escalabilidad y rendimiento que ofrecen son valiosas. Hay varias bases de datos NoSQL populares disponibles, cada una con sus propias fortalezas y casos de uso. Estos son algunos ejemplos de bases de datos NoSQL conocidas:

• MongoDB: MongoDB es una base de datos de documentos que almacena datos en documentos flexibles similares a JSON. Proporciona escalabilidad, alto rendimiento y amplias capacidades de consulta. MongoDB se utiliza ampliamente en aplicaciones web, sistemas de gestión de contenido y análisis en tiempo real.
• Redis: Redis es un almacén de datos en memoria que admite diversas estructuras de datos, incluyendo cadenas, hashes, listas, conjuntos y conjuntos ordenados. Es conocido por su rendimiento excepcional y baja latencia. Redis se utiliza a menudo para el almacenamiento en caché, el análisis en tiempo real, la gestión de sesiones y la mensajería de publicación/suscripción.

Introducción a la inyección SQL

La inyección SQL (SQLi) es una vulnerabilidad de inyección en aplicaciones web que se produce cuando un atacante inyecta sentencias SQL maliciosas en los campos de entrada de una aplicación. Esto ocurre cuando una aplicación web no valida correctamente la entrada del usuario, lo que permite a un atacante inyectar código/consultas SQL que pueden manipular la base de datos u obtener acceso a información confidencial. Por ejemplo, supongamos que un sitio web tiene un formulario de inicio de sesión que acepta un nombre de usuario y una contraseña. Si el sitio web no valida correctamente la entrada del usuario, un atacante podría introducir una sentencia SQL maliciosa en el campo de nombre de usuario que le permitiría omitir el proceso de inicio de sesión y obtener acceso a la base de datos del sitio web.

Los ataques de inyección SQL pueden tener graves consecuencias, incluyendo el robo de datos confidenciales, acceso no autorizado a sistemas confidenciales e incluso la vulneración total del sistema. Las aplicaciones web complejas generalmente utilizan una base de datos para almacenar datos, credenciales de usuario o estadísticas. Los sistemas de gestión de contenido (CMS), así como las páginas web sencillas, pueden conectarse a bases de datos relacionales como MySQL, MSSQL, SQL Server, Oracle, PostgreSQL y otras. Para interactuar con las bases de datos, entidades como operadores de sistemas, programadores, aplicaciones y aplicaciones web utilizan el lenguaje de consulta estructurado (SQL).

Esta imagen ilustra de manera clara cómo ocurre un ataque de inyección SQL (SQL Injection), una de las vulnerabilidades más comunes y peligrosas en aplicaciones web. El diagrama muestra paso a paso cómo un atacante puede manipular la comunicación entre el servidor web y la base de datos para obtener información confidencial.

Todo comienza en el paso 1, cuando el atacante envía una petición HTTP especialmente diseñada hacia el servidor de la aplicación web. Esta solicitud contiene código malicioso incrustado en los campos de entrada, como formularios o parámetros en la URL, con el fin de alterar las consultas SQL que el servidor ejecuta internamente.

En el paso 2, el servidor web recibe la solicitud y, sin una validación adecuada, envía una consulta SQL al sistema de base de datos. Si la aplicación no utiliza mecanismos de protección como consultas preparadas o sanitización de entradas, el código del atacante se ejecuta dentro de la consulta, permitiéndole acceder a datos que normalmente deberían estar restringidos.

A continuación, en el paso 3, la base de datos devuelve la información solicitada, sin distinguir entre una consulta legítima y una manipulada. Esta información —que puede incluir nombres de usuario, contraseñas, correos electrónicos o incluso datos financieros— es enviada al servidor web como parte de la respuesta legítima del sistema.

Finalmente, en el paso 4, el servidor genera una respuesta HTTP que contiene los datos obtenidos y los envía al atacante a través de Internet. De esta forma, el atacante logra extraer información sensible sin necesidad de autenticación, explotando una debilidad lógica en el diseño de la aplicación.

En resumen, este diagrama explica el flujo de un ataque SQLi, donde una simple vulnerabilidad en la validación de entradas puede comprometer toda la base de datos. Para evitar este tipo de ataques, es fundamental implementar consultas parametrizadas, filtros de entrada, control de errores adecuado y limitar los privilegios de las cuentas de base de datos utilizadas por la aplicación web.

Historia de los ataques de inyección SQL

El término «inyección SQL» fue acuñado por Jeff Forristal, también conocido como «Rain Forest Puppy», en un artículo que presentó en la conferencia DefCon 8 en 2000. Forristal fue uno de los primeros investigadores de seguridad en documentar públicamente la vulnerabilidad de la inyección SQL y explicar cómo podría explotarse para obtener acceso no autorizado a bases de datos e información confidencial. Los ataques de inyección SQL han existido desde los inicios de las aplicaciones web y los sitios web basados ​​en bases de datos. Aquí hay una breve historia de los ataques de inyección SQL más notables:

• En 1998, un atacante conocido como «Rain Forest Puppy» utilizó la inyección SQL para obtener acceso a una red informática del Departamento de Energía de EE. UU.
• En 2000, el primer ataque de inyección SQL publicitado ocurrió cuando un hacker utilizó la inyección SQL para robar datos de tarjetas de crédito del sitio web del minorista electrónico CD Universe.
• En 2002, un grupo de hackers rusos conocido como «The Helldiggers» utilizó la inyección SQL para obtener acceso a la base de datos de las Naciones Unidas, lo que resultó en el robo de información confidencial.
• En 2012, se produjo la filtración de datos de LinkedIn, en la que los atacantes utilizaron la inyección SQL para robar 6.5 millones de contraseñas de usuarios.
• En 2015, se produjo la filtración de datos de Ashley Madison, en la que los atacantes utilizaron la inyección SQL para robar datos confidenciales de los usuarios del sitio de citas para infieles.

Impacto de la inyección SQL

• Confidencialidad: dado que las bases de datos SQL generalmente contienen datos confidenciales, la pérdida de confidencialidad es un problema frecuente con las vulnerabilidades de inyección SQL. Integridad: así como es posible leer información confidencial, también es posible realizar cambios o incluso eliminar esta información con un ataque de inyección SQL.
• Autenticación: si se utilizan comandos SQL deficientes para comprobar los nombres de usuario y las contraseñas, es posible conectarse a un sistema como otro usuario sin conocimiento previo de la contraseña.
• Disponibilidad: los ataques de inyección SQL pueden afectar la disponibilidad de una aplicación web y una base de datos, y podrían hacer que el sitio web deje de funcionar debido a la pérdida o el daño de los datos.

Consecuencias de la inyección SQL

Exposición de datos confidenciales/filtraciones de datos: los ataques de inyección SQL pueden resultar en un acceso no autorizado a datos confidenciales almacenados en una base de datos. Los atacantes pueden ver o robar información confidencial, como datos de clientes, información financiera y propiedad intelectual.

• Manipulación de datos: los atacantes pueden modificar o eliminar datos almacenados en una base de datos, lo que podría causar pérdida o corrupción de datos.
• Ejecución de código: si un usuario de la base de datos tiene privilegios administrativos, un atacante puede obtener acceso al sistema objetivo utilizando código malicioso.
• Interrupción del negocio: los ataques de inyección SQL exitosos pueden provocar una interrupción del negocio, ya que las organizaciones trabajan para restaurar los servicios y prevenir nuevos ataques.

¿Qué son los ataques de inyección?

Los ataques de inyección ocurren cuando una aplicación procesa incorrectamente una entrada no confiable, lo que permite a un atacante inyectar código o comandos maliciosos en el flujo de ejecución de la aplicación. Esta explotación manipula la forma en que la aplicación interactúa con sus sistemas subyacentes, como bases de datos, sistemas de archivos o sistemas operativos. Estas son algunas características clave de los ataques basados ​​en inyección:

• Explotación de la validación de entrada: Los ataques de inyección  se dirigen a vulnerabilidades donde los datos de entrada no se desinfectan o validan correctamente.
• Manipulación de consultas o comandos: La carga inyectada altera la lógica de las consultas o comandos enviados a un sistema back-end.
• Amplia gama de objetivos: Estos ataques pueden afectar bases de datos (SQL), servicios de directorio (LDAP), analizadores XML (XXE), bases de datos NoSQL e incluso sistemas operativos (inyección de comandos).

Tipos de inyecciones

• Inyección SQL (SQLi) Explota fallos en la construcción de consultas de bases de datos, lo que permite a los atacantes ejecutar comandos SQL arbitrarios.
  • Impacto: Robo de datos, acceso no autorizado o manipulación de datos.
• Inyección NoSQL Se dirige a bases de datos NoSQL como MongoDB inyectando consultas maliciosas a través de entradas no validadas.
  • Impacto: Acceso, eliminación o manipulación de datos no autorizados.
• Inyección LDAP Manipula las consultas LDAP para eludir la autenticación o recuperar información de directorio no autorizada.
  • Impacto: Acceso a datos confidenciales del directorio, compromiso del sistema.
• Inyección ORM Explota los marcos de mapeo relacional de objetos (ORM) inyectando consultas maliciosas en el código.
  • Impacto: Acceso, corrupción o divulgación de datos no autorizados.
• Inyección XXE (Entidad externa XML) Inyecta entidades XML maliciosas para explotar los analizadores XML y obtener acceso no autorizado a archivos o sistemas internos.
  • Impacto: Divulgación de archivos, falsificación de solicitud del lado del servidor (SSRF) o denegación de servicio

Prevalencia de ataques de inyección

Clasificación OWASP Top 10: Una de las vulnerabilidades mejor clasificadas en el Top 10 de OWASP durante varios años. (N.° 1 en 2017 y N.° 3 en 2021) Las vulnerabilidades de inyección son muy frecuentes y siguen representando riesgos significativos para las aplicaciones en todo el mundo.

Prevalencia: Las fallas de inyección afectan a aplicaciones de todos los sectores: comercio electrónico, finanzas, atención médica y más. Prevalencia en las API: Las vulnerabilidades de inyección también son comunes en las API RESTful y SOAP.

Explotación a escala Las herramientas automatizadas como SQLMap facilitan a los atacantes la identificación y explotación de fallas de inyección a escala. La simplicidad y la potencia de los ataques de inyección los convierten en un vector de ataque principal

Impacto en el mundo real

TalkTalk (2015): La inyección de SQL provocó la exposición de 157 000 registros de clientes.

Equifax (2017): Las vulnerabilidades, incluida la inyección de SQL, contribuyeron a una filtración que comprometió 147 millones de registros.

Nuestro enfoque

En la imagen vemos la Anatomía de un ataque de inyección SQL. Esta imagen representa una línea de aprendizaje o ruta temática sobre ataques de inyección en aplicaciones web, organizada desde los conceptos más básicos hasta técnicas más avanzadas y específicas. Es una guía visual que muestra cómo un estudiante o profesional puede progresar desde la comprensión inicial de las inyecciones SQL hasta otras variantes menos comunes, como NoSQL, LDAP, ORM y XXE Injection.

El recorrido comienza con los Fundamentos de SQL Injection, donde se introduce el concepto de inyección de código SQL, su funcionamiento y cómo los atacantes logran manipular las consultas a bases de datos. A continuación, se avanza hacia el módulo SQL Injection (SQLi), en el que se exploran diferentes tipos de inyecciones (basadas en error, ciegas, por tiempo, etc.) y se practican técnicas manuales de explotación.

Luego, se pasa a la fase de automatización con SQLMap, una herramienta popular para detectar y explotar vulnerabilidades SQLi de forma automatizada. En esta etapa, también se abordan técnicas avanzadas, como las inyecciones de segunda orden o los ataques OOB (Out-of-Band), que permiten obtener resultados en escenarios más complejos.

Después, la ruta continúa con los ataques SQLi avanzados, donde se profundiza en escenarios reales y se aplican métodos más sofisticados de evasión y explotación. Posteriormente, se introduce la inyección NoSQL, que afecta a bases de datos modernas como MongoDB o CouchDB, y se estudia cómo los principios de la inyección pueden trasladarse fuera del entorno SQL tradicional.

El siguiente módulo cubre la inyección LDAP, utilizada para manipular consultas en sistemas de autenticación basados en directorios. Luego se aborda la inyección ORM, que explota vulnerabilidades en frameworks que manejan bases de datos mediante mapeo objeto-relacional, como Hibernate o SQLAlchemy.

Finalmente, la ruta concluye con XXE Injection (XML External Entity), una técnica que aprovecha vulnerabilidades en el procesamiento de archivos XML para acceder a archivos locales o sistemas internos.

En conjunto, este esquema muestra una evolución lógica del aprendizaje: desde entender los fundamentos de una inyección SQL hasta dominar diferentes tipos de inyecciones en múltiples tecnologías, proporcionando una visión completa del panorama de vulnerabilidades relacionadas con la manipulación de datos y consultas en entornos web.

Diferencia entre XSS y SQLi

🔹 SQLi (SQL Injection)

• Qué es:
  Una vulnerabilidad donde el atacante inyecta código SQL malicioso en una consulta a la base de datos.
• Objetivo del atacante:
  Manipular la base de datos: leer, modificar o borrar información.
• Ejemplo simple:
  
  SELECT * FROM usuarios WHERE usuario = ‘admin’ AND clave = »;
  
  Si la aplicación no valida bien, el atacante puede poner:
  
  ‘ OR ‘1’=’1
  
  Resultado → el sistema devuelve todos los usuarios (bypass de login).
• Impacto:
  Robo de datos sensibles, borrado de información, incluso control total del servidor.

🔹 XSS (Cross-Site Scripting)

• Qué es:
  Una vulnerabilidad que permite al atacante inyectar código JavaScript malicioso en una página web que otros usuarios visitan.
• Objetivo del atacante:
  Robar cookies, tokens de sesión, redirigir al usuario, mostrar contenido falso o ejecutar acciones en nombre del usuario.
• Ejemplo simple:
  En un campo de comentarios:
  
  <script>alert(«Hackeado!»);</script>
  
  Si la app no lo filtra, cualquier usuario que abra la página verá ejecutarse ese script.
• Impacto:
  Robo de sesiones, phishing, manipulación de la interfaz, escalamiento de privilegios en apps web.

🔑 Diferencias clave

Aspecto	SQLi 🗄️	XSS 💻
Dónde ocurre	En la base de datos	En el navegador del usuario
Qué se inyecta	Código SQL	Código JavaScript/HTML
A quién afecta	Al servidor / base de datos	A los usuarios que visitan la web
Impacto típico	Robo o modificación de datos	Robo de sesión, phishing, manipulación visual

👉 Resumen corto:

• SQLi = atacar la base de datos.
• XSS = atacar a los usuarios de la aplicación.

Resumen del artículo — Lo esencial, organizado por temas

JavaScript — Interactividad y riesgo

• JS hace la página dinámica: modifica DOM, estilos y comportamientos en tiempo real.
• Métodos importantes: document.getElementById(), innerHTML, .style.*.
• JS puede ocultar/mostrar elementos, gestionar eventos y realizar peticiones AJAX.
• Exposición accidental: credenciales, endpoints o claves mal colocadas en código JS son información sensible.

Exposición de datos en frontend

• Revisar código fuente y archivos JS puede revelar credenciales, endpoints o rutas privadas.
• Las referencias en comentarios, ficheros .map o listados de directorio son vectores de hallazgos.

XSS — Secuencias de comandos entre sitios

• XSS ocurre cuando datos no confiables se interpretan como código en el navegador.
• Clasificación:
  • Almacenado (persistente): payload guardado en servidor y ejecutado por visitantes.
  • Reflejado (no persistente): payload en URL/entrada que se devuelve y ejecuta.
  • DOM-based: la vulnerabilidad está en el JS que manipula el DOM sin sanear.
• Impactos: robo de cookies, secuestro de sesión, keylogging, phishing in-page, redirección maliciosa.
• Mitigaciones: escape contextual, validación server-side, HttpOnly/Secure/SameSite para cookies, CSP, usar frameworks/templates que escapen por defecto.

Bases de datos y SQLi

• DBMS almacena datos; RDBMS (MySQL, PostgreSQL, Oracle, SQL Server) usa SQL.
• SQL Injection (SQLi): inyectar código SQL malicioso por entradas no validadas.
• Consecuencias: lectura/alteración/borrado de datos, bypass de auth, elevación de privilegios, ejecución remota si la DB tiene privilegios.
• Variantes y técnicas: inyecciones basadas en error, ciegas, por tiempo, OOB; NoSQL injection, LDAP/ORM/XXE como otras familias de inyección.
• Prevención: consultas parametrizadas (prepared statements), validación y saneamiento del lado servidor, principio de privilegios mínimos.

Diferencias clave entre XSS y SQLi

• XSS ataca a los usuarios (browser), inyectando JS/HTML.
• SQLi ataca al servidor/BD, inyectando SQL.
• Ambos comparten raíz: confianza en datos no controlados.

Preguntas clave sobre HTML, CSS, JS, XSS, SQLi y bases de datos

1. ¿Qué diferencia existe entre JavaScript y Java?
2. ¿Qué función cumple getElementById() en JavaScript?
3. ¿Qué es una vulnerabilidad XSS y cómo se diferencia de una inyección HTML?
4. ¿Qué tipos de ataques XSS existen y cuál es su diferencia principal?
5. ¿Qué es una base de datos y para qué se utilizan en las aplicaciones web?
6. ¿Cuál es la diferencia entre una base de datos relacional y una NoSQL?
7. ¿Qué es una inyección SQL (SQLi) y cómo se puede explotar?
8. ¿Cuáles son las principales diferencias entre una vulnerabilidad XSS y una SQLi?

Respuestas detalladas a las preguntas

1. ¿Qué diferencia existe entre JavaScript y Java?

Aunque tienen nombres similares, JavaScript y Java son lenguajes completamente diferentes:

• JavaScript es un lenguaje de programación interpretado y se usa en el navegador web para crear interactividad.
• Java es un lenguaje compilado que se utiliza en múltiples plataformas (apps, backend, etc.).
  No comparten ni sintaxis ni propósito real.

2. ¿Qué función cumple getElementById() en JavaScript?

Es un método que permite seleccionar un elemento HTML por su atributo id. Una vez seleccionado, se puede modificar su contenido, estilo o visibilidad. Ejemplo:

document.getElementById(«demo»).innerHTML = «Texto modificado»;

3. ¿Qué es una vulnerabilidad XSS y cómo se diferencia de una inyección HTML?

XSS (Cross-Site Scripting) es una vulnerabilidad donde un atacante inyecta código JavaScript malicioso en una página web, que luego es ejecutado en el navegador de otros usuarios.

• Inyección HTML altera la estructura visual (etiquetas <h1>, <form>, etc.).
• XSS busca ejecutar código, como robar cookies, hacer redirecciones o registrar pulsaciones.

4. ¿Qué tipos de ataques XSS existen y cuál es su diferencia principal?

Tipos:

• XSS almacenado: el código malicioso queda guardado en el servidor.
• XSS reflejado: el código se refleja en la respuesta inmediata del servidor.
• XSS basado en DOM: ocurre solo en el navegador por mal manejo del DOM.

Diferencia principal: si el payload queda almacenado o se ejecuta al momento.

5. ¿Qué es una base de datos y para qué se utilizan en las aplicaciones web?

Una base de datos es un sistema para almacenar, organizar y recuperar datos. En aplicaciones web, se usan para:

• Guardar información de usuarios, productos, compras, etc.
• Proveer datos dinámicos a las páginas web.
• Facilitar búsquedas, actualizaciones y operaciones complejas con datos.

6. ¿Cuál es la diferencia entre una base de datos relacional y una NoSQL?

• Relacional (SQL): usa tablas con filas y columnas. Usa consultas SQL. Ej: MySQL, PostgreSQL.
• NoSQL: no usa tablas tradicionales. Usa documentos, grafos, clave-valor, etc. Más flexible. Ej: MongoDB, Redis.

7. ¿Qué es una inyección SQL (SQLi) y cómo se puede explotar?

Es una vulnerabilidad donde un atacante inyecta comandos SQL maliciosos en campos de entrada para:

• Leer, modificar o borrar datos.
• Omitir autenticación.
• Acceder a información sensible.

Ejemplo de ataque:

SELECT * FROM usuarios WHERE usuario = » OR ‘1’=’1′

8. ¿Cuáles son las principales diferencias entre una vulnerabilidad XSS y una SQLi?

Característica	SQLi	XSS
Afecta a…	Servidor / Base de datos	Navegador del usuario
Qué se inyecta	Código SQL	Código JavaScript
Impacto	Robo / modificación de datos	Robo de sesión, phishing
Objetivo	Sistema backend	Usuarios de la web

10 ejercicios prácticos

1. Identifica qué tipo de inyección es más peligrosa: ¿Reflejada o almacenada? Justifica.
2. Modifica con JavaScript el texto de un párrafo con id=»demo» a “Modificado con JS”.
3. Inyecta un HTML en un campo vulnerable para mostrar <h2>Inyectado</h2>.
4. Escribe un ejemplo de HTML injection reflejada usando el método GET.
5. Agrega un evento onclick a un botón que oculte un elemento con id=»box».
6. Crea una consulta SQL vulnerable a inyección donde el atacante puede entrar sin contraseña.
7. Explica qué haría este payload de XSS: <script>alert(‘Hack’);</script>
8. Decodifica esta cadena: Hola%20Mundo%20%3Cscript%3E
9. Enumera 2 bases de datos relacionales y 2 NoSQL.
10. Escribe un ataque de inyección SQL para evadir login si el formulario usa esta consulta:

SELECT * FROM users WHERE username = ‘$user’ AND password = ‘$pass’;

Respuestas explicadas a los ejercicios

1. Más peligrosa: Inyección almacenada, porque:

• El código malicioso se guarda en el servidor.
• Afecta a todos los usuarios que acceden a la página.
• Puede ser persistente y más difícil de detectar.

2. JavaScript que modifica el texto:

<p id=»demo»>Texto original</p>
<script>
  document.getElementById(«demo»).innerHTML = «Modificado con JS»;
</script>

3. Inyección HTML en campo vulnerable:

<h2>Inyectado</h2>

Si no hay filtrado, el título aparece en la página.

4.

URL:

https://vulnerable.site/page?name=<h1>Inyectado</h1>

Si el sitio no filtra, mostrará un título con el texto «Inyectado».

5. Evento onclick para ocultar un div:

<div id=»box»>Contenido</div>
<button onclick=»document.getElementById(‘box’).style.display=’none’;»>Ocultar</button>

6. Consulta vulnerable:

SELECT * FROM users WHERE username = ‘$user’ AND password = ‘$pass’;

Entrada maliciosa:

user: ‘ OR ‘1’=’1
pass: (lo que sea)

7. ¿Qué hace <script>alert(‘Hack’);</script>?

Muestra una alerta en el navegador con el mensaje «Hack». Es un ejemplo clásico de XSS reflejado o almacenado.

8. Decodificar Hola%20Mundo%20%3Cscript%3E:

Resultado:

Hola Mundo <script>

Es una forma de inyectar scripts codificados por URL.

9. Ejemplos:

• Relacionales: MySQL, PostgreSQL
• NoSQL: MongoDB, Redis

10. Inyección SQL para evadir login:

Entrada del usuario:

Username: admin’ OR ‘1’=’1
Password: cualquier

Consulta generada:

SELECT * FROM users WHERE username = ‘admin’ OR ‘1’=’1′ AND password = ‘cualquier’;

El OR ‘1’=’1′ hace que siempre sea verdadero → acceso concedido.

Despedida — Qué aprendiste y cómo te sirve en tu camino como hacker

Has aprendido a:

• distinguir estructura (HTML), presentación (CSS) y lógica (JS);
• buscar y explotar fugas de información en el frontend (comentarios, JS, listados);
• reconocer y explotar XSS (reflejado, almacenado y DOM) y comprender su impacto práctico;
• entender cómo la manipulación de entradas puede llevar a SQLi y comprometer la base de datos.

Estas habilidades te permiten comprobar vulnerabilidades que los escáneres ven, construir pruebas reproducibles y evaluar el riesgo real para usuarios y datos. Practícalas en laboratorios autorizados (bWAPP, DVWA, TryHackMe), incorpora siempre mitigaciones recomendadas y documenta tus hallazgos con pasos claros. Con esto te acercas a ser un pentester más eficaz: rápido para detectar, preciso para explotar y responsable para reportar.