😎
WEB
YouTubeTwitterLinkedIn
  • La Biblia del Hacking en Web
    • ADVERTENCIA
    • Conoce a tu academia
    • Conoce a tu instructor
    • Aprende Hacking Web con los laboratorios de PortSwigger
  • SQL Injection
    • ¿SQL Injection?
    • Lab 1: SQL injection vulnerability in WHERE clause allowing retrieval of hidden data
    • Lab 2: SQL injection vulnerability allowing login bypass
    • Lab 3: SQL injection attack, querying the database type and version on Oracle
    • Lab 4: SQL injection attack, querying the database type and version on MySQL and Microsoft
    • Lab 5: SQL injection attack, listing the database contents on non-Oracle databases
    • Lab 6: SQL injection attack, listing the database contents on Oracle
  • Cross Site Scripting
    • ¿XSS?
    • Lab 1: Reflected XSS into HTML context with nothing encoded
    • Lab 2: Stored XSS into HTML context with nothing encoded
    • Lab 3: DOM XSS in document.write sink using source location.search
    • Lab 4: DOM XSS in innerHTML sink using source location.search
    • Lab 5: DOM XSS in jQuery anchor href attribute sink using location.search source
  • ClickJacking
    • ¿Clickjacking?
    • Lab 1: Basic clickjacking with CSRF token protection
  • Access control vulnerabilities
    • ¿Control de Acceso?
    • Lab 1: Unprotected admin functionality
    • Lab 3: User role controlled by request parameter
  • Path traversal
    • ¿Path Traversal?
    • Lab 1: File path traversal, simple case
    • Lab 2: File path traversal, traversal sequences blocked with absolute path bypass
    • Lab 3: File path traversal, traversal sequences stripped non-recursively
  • XML external entity (XXE) injection
    • ¿XML external entity?
    • Lab 1: Exploiting XXE using external entities to retrieve files
    • Lab 2: Exploiting XXE to perform SSRF attacks
    • Lab 3: Blind XXE with out-of-band interaction
  • JWT
    • ¿JWT?
    • Lab 1: JWT authentication bypass via unverified signature
    • Lab 2: JWT authentication bypass via flawed signature verification
    • Lab 3: JWT authentication bypass via weak signing key
    • Lab 4: JWT authentication bypass via jwk header injection
    • Lab 5: JWT authentication bypass via jku header injection
  • Server-side request forgery (SSRF)
    • ¿SSRF?
    • Lab 1: Basic SSRF against the local server
  • OS command injection
    • ¿OS Command Injection?
    • Lab 1: OS command injection, simple case
  • Authentication
    • ¿Authentication?
    • Lab 1: Username enumeration via different responses
  • HTTP request smuggling
    • ¿HTTP request smuggling?
    • Lab 1: HTTP request smuggling, confirming a CL.TE vulnerability via differential responses
  • Server-side template injection
    • ¿Server-side template injection?
    • Lab 1: Basic server-side template injection
  • DOM-based vulnerabilities
    • Lab 1: DOM XSS using web messages
    • Lab 2: DOM XSS using web messages and a JavaScript URL
  • WebSockets
    • Lab #1: Manipulating WebSocket messages to exploit vulnerabilities
  • Prototype pollution
    • ¿Prototype Pollution?
    • Lab 1: Client-side prototype pollution via browser APIs
      • Utilizando DOM Invader
    • Lab 2: DOM XSS via client-side prototype pollution
    • Lab 3: DOM XSS via an alternative prototype pollution vector
      • Utilizando DOM Invader
    • Lab 4: Client-side prototype pollution via flawed sanitization
    • Lab 5: Client-side prototype pollution in third-party libraries
    • Lab 6: Privilege escalation via server-side prototype pollution
    • Lab 7: Detecting server-side prototype pollution without polluted property reflection
    • Lab 8: Bypassing flawed input filters for server-side prototype pollution
    • Lab 9: Remote code execution via server-side prototype pollution
    • Lab 10: Exfiltrating sensitive data via server-side prototype pollution
  • GraphQL
    • Lab 1: Accessing private GraphQL posts
  • Web cache poisoning
    • Lab 1: Web cache poisoning with an unkeyed header
  • CORS
    • Lab #2 - CORS vulnerability with trusted null origin
    • Lab 3: CORS vulnerability with trusted insecure protocols
  • API testing
    • Lab #1: Exploiting an API endpoint using documentation
    • Lab #2: Exploiting server-side parameter pollution in a query string
    • Lab #3: Finding and exploiting an unused API endpoint
    • Lab #4: Exploiting a mass assignment vulnerability
    • Lab #5: Exploiting server-side parameter pollution in a REST URL
Con tecnología de GitBook
En esta página
  • ¿Qué es una inyección SQL (SQLi)?
  • Impacto de un ataque de inyección SQL
  • Cómo detectar vulnerabilidades de inyección SQL
  • Puntos de inyección SQL en las consultas
  • Mitigación y prevención de inyecciones SQL

¿Te fue útil?

  1. SQL Injection

¿SQL Injection?

¿Qué es una inyección SQL (SQLi)?

La inyección SQL (SQLi) es una de las vulnerabilidades de seguridad web más críticas y comunes. Permite a un atacante manipular las consultas que una aplicación web envía a su base de datos. Esta manipulación puede permitirle acceder a datos a los que normalmente no tendría acceso, como información de otros usuarios o datos sensibles del sistema. Los atacantes también pueden modificar, eliminar o insertar datos, alterando así la integridad de la información y el funcionamiento de la aplicación.

Impacto de un ataque de inyección SQL

Los efectos de una inyección SQL exitosa pueden ser devastadores. Los atacantes pueden:

  • Obtener acceso a datos confidenciales como contraseñas, números de tarjetas de crédito e información personal de usuarios.

  • Manipular o borrar datos críticos, lo que puede llevar a la corrupción de la base de datos.

  • Realizar ataques de denegación de servicio (DoS) interrumpiendo el funcionamiento normal de la aplicación.

Las consecuencias de estos ataques incluyen pérdidas financieras, daños a la reputación, sanciones legales y regulatorias, y la pérdida de confianza de los clientes.

Cómo detectar vulnerabilidades de inyección SQL

Detectar vulnerabilidades de inyección SQL implica un enfoque exhaustivo y sistemático. Algunas técnicas incluyen:

  • Inyección de caracteres especiales: Introducir caracteres como ' o " para ver si la aplicación genera errores o respuestas inesperadas.

  • Pruebas de lógica booleana: Utilizar condiciones como OR 1=1 y OR 1=2 para identificar diferencias en las respuestas de la aplicación.

  • Inyección de carga útil (payload): Usar comandos SQL específicos para alterar la lógica de la consulta original y observar los resultados.

  • Pruebas de tiempo: Emplear consultas que generen retrasos intencionales (por ejemplo, SLEEP(5)) para ver si la respuesta de la aplicación se retrasa.

  • Pruebas fuera de banda (OAST): Enviar cargas útiles que desencadenen interacciones de red fuera de banda para detectar respuestas no directas de la aplicación.

El uso de herramientas automatizadas como Burp Suite puede facilitar la identificación de estas vulnerabilidades, aunque siempre es recomendable complementarlo con análisis manuales.

Puntos de inyección SQL en las consultas

Si bien la mayoría de las inyecciones SQL se encuentran en la cláusula WHERE de las consultas SELECT, es crucial entender que pueden ocurrir en cualquier parte de una consulta SQL. Algunos lugares comunes incluyen:

  • Consultas UPDATE: Dentro de los valores actualizados o en la cláusula WHERE.

  • Consultas INSERT: Dentro de los valores que se insertan en la base de datos.

  • Consultas SELECT: En los nombres de las tablas o columnas, y en la cláusula ORDER BY.

  • Procedimientos almacenados: En los parámetros de entrada de procedimientos almacenados que no están adecuadamente sanitizados.

Mitigación y prevención de inyecciones SQL

Para protegerse contra las inyecciones SQL, es fundamental implementar medidas de seguridad robustas:

  • Uso de consultas parametrizadas: Evitar la concatenación de cadenas en las consultas SQL y utilizar siempre parámetros preparados.

  • Validación y escape de entrada: Validar y escapar adecuadamente toda la entrada del usuario para asegurar que no contenga caracteres maliciosos.

  • Principio de privilegios mínimos: Asegurar que las cuentas de la base de datos utilizadas por la aplicación tengan los privilegios mínimos necesarios.

  • Monitoreo y registros: Implementar sistemas de monitoreo y registrar las actividades sospechosas para detectar y responder rápidamente a posibles ataques.

La comprensión y aplicación de estas prácticas es esencial para fortalecer la seguridad de las aplicaciones web y proteger los datos sensibles contra accesos no autorizados.

AnteriorAprende Hacking Web con los laboratorios de PortSwiggerSiguienteLab 1: SQL injection vulnerability in WHERE clause allowing retrieval of hidden data

Última actualización hace 1 año

¿Te fue útil?

Page cover image