OWASP y Programación Segura: SQL Injection

Encargado: Ing. Raúl B. Netto, Mg.

2 de junio del 2021
Introducción Personal
● Ing. Informá,ca 2014 - FIUNI - UNI - PY
● Master en Seguridad Informá,ca - FIT - CTU - CZ
● Desarrollador web y tester en integradevs.com
● Asistente en FIUNI - UNI
● Desarrollador web en SingleCase.cz
● Inves,gador Junior en Stratosphereips Lab. - h"ps://stratosphereips.org
ü Machine Learning en WHOIS Informa,on
ü Analista de Amenazas y Desarrollador - Proyecto Mana,
● Consultor en ingeniería de soTware en diversas empresas
● Supervisor opera,vo de ges,ón de ciber-incidentes para CERT-PY
● Catedrá,co de la FIUNI - UNI
● fotograXa, viajes, ML, Docker, Threat Analyst, IoT
● Contactos: raulbeni@gmail.com
● PD: Las presentaciones no son TED Talks
Tabla de Contenidos
● Repaso
● Arquitectura Web y Aplicaciones web
● Open Web Application Security Project.
ü OWASP TOP 10
● Programación Segura de Alto nivel
ü SQL injection
● Demos prácticos (Solo para que no se duerman)!
Repaso - I
Repaso - II
Repaso- III
Repaso - IV
 Arquitectura Web
● Servidor web: Apache, IIS, nginx
● CMS: Wordpress, Joomla, Concrete5, Alfresco, Liferay
● Plugins y componentes
● Temas y plantillas
● Frameworks y Librerías: PHP, Java, ASP.NET, Ruby On Rails, Python,
PERL
● Base de datos: MySQL, Oracle, MSSQL
Aplicaciones Web
Vulnerabilidades en Aplicaciones web – OWASP TOP 10

● Cross Site Scripting (XSS) ● Inyección de comandos

● Cross Site Request Forgery (CSRF) ● Remote File Inclusion (RFI)

● Inyección SQL (SQLi)

● Local File Inclusion (LFI)
● Inyección LDAP
● Subida arbitraria de archivos
● Inyección XML
● Path Traversal
● Ejecución remota de código (RCE)
Proyecto OWASP

Significa: Open Web Application Security Project - Proyecto abierto de

seguridad de aplicaciones web.

Es un proyecto de código abierto dedicado a determinar y combatir las

causas que hacen que el software sea inseguro.
La Fundación OWASP es un organismo sin ánimo de lucro que apoya y
gestiona los proyectos e infraestructura de OWASP.
La comunidad OWASP está formada por empresas, organizaciones
educativas y particulares de todo mundo, constituyen una comunidad de
seguridad informática que trabaja para crear artículos, metodologías,
documentación, herramientas y tecnologías que se liberan y pueden ser
usadas gratuitamente.
 Recomendaciones OWASP

OWASP recomienda enfocar la seguridad de aplicaciones

informá6cas considerando todas sus dimensiones:
personas, procesos y tecnologías.
Los documentos con más éxito de OWASP incluyen la Guía
OWASP y el ampliamente adoptado documento de
autoevaluación OWASP Top 10.
Vulnerabilidades del OWASP TOP 10 - 2017
1 - Injection 6 - Security MisconfiguraIon
Inyección Configuración de Seguridad Incorrecta

2 - Broken Authentication 7 - Cross-Site ScripIng (XSS)

Autenticación Rota
8 - Insecure DeserializaIon
3 - Sensitive Data Exposure Deserialización insegura
Exposición de Datos Sensibles
9 - Using Components with Known VulnerabiliIes
4 - XML External Entities (XXE) Uso de componentes con vulnerabilidades conocidas
Entidad Externa XML
10 - Insufficient Logging&Monitoring
5 - Broken Access Control Registro y Monitoreo insuficiente
Control de Acceso Roto
1) OWASP TOP 10: InjecEon (Inyección) I
Las fallas de inyección, como SQL, NoSQL, OS o LDAP, entre otras,
ocurren cuando se envían datos no confiables a un intérprete, como
parte de un comando o consulta.
Los datos ingresados por el atacante pueden engañar al intérprete
para que ejecute comandos involuntarios o acceda a los datos sin la
debida autorización.

Una inyección SQL es una vulnerabilidad que permite a un atacante

manipular sentencias SQL a través de los parámetros de entrada a
una aplicación web (por ejemplo).
1) OWASP TOP 10: Injection

Existen diferentes técnicas para explotar una

inyección SQL:
• Error-Based
• Boolean-Based Blind
• Time-Based Blind
• Union Query-Based
• Stacked-queries
1) OWASP TOP 10: Injection II
Existen diferentes técnicas para explotar una inyección
SQL:
• Error-Based
• Boolean-Based Blind
• Time-Based Blind
• Union Query-Based
• Stacked-queries
1) OWASP TOP 10: Injection III - Error Based
El obje@vo es manipular los parámetros de entrada
para que la respuesta incluya mensajes de error que
brinden información.
Información que podemos obtener:

• Motor de DB
• Versión de motor DB
• Versión del OS del servidor.
1) OWASP TOP 10: InjecEon IV - Error Based

Errores identificados
● Página de error por defecto de ASP.net
● Avisa que no existe una columna ‘x’, es decir está difundiendo información
que no debería.
● Una vez que el atacante identifica que hay un “pequeño” error se vale de eso
para hacer intentos más peligrosos.
1) OWASP TOP 10: Injection V - Boolean-Based Blind

Inyección ciega basada en expresiones Booleanas.

→ Verdadero

Esta condición es verdadera, y en el si;o web no se ve reflejado ningún ;po de cambio

→ Falso

Esta condición es falsa y en el si;o pueden verse cambios.

Ejemplo: desaparece un botón o se cambia de posición, o se ve la pantalla en blanco, etc.

1) OWASP TOP 10: Injection VI - Time-Base Blind
Inyección ciega basada en !empos de respuesta.

Si la respuesta del servidor demora 5 segundos más que la pe;ción original, es muy
probable que sea vulnerable.
1) OWASP TOP 10: Injection VII - Union Query-Based

Inyección basada en añadir una consulta de unión de

tal forma que los resultados obtenidos se listen en la
página resultante.

La declaración UNION ALL solo funciona cuando la

primera instrucción SELECT @ene el mismo número de
columnas que la segunda.
1) OWASP TOP 10: InjecEon VIII - Stacked-queries

Inyección que permite la ejecución múltiple de consultas (separadas por‘;’), y aprovecha esta
funcionalidad para añadir todo tipo de consultas de ataque después de la consulta válida
enviada.
1) OWASP TOP 10: Injection VIII - Stacked-queries

• No todas las combinaciones de lenguaje y base de datos

soportan stacked queries!

verde: soportado, negro: no soportado, gris: desconocido

2) OWASP TOP 10: Broken AuthenEcaEon
(AutenEcación Rota) - I

Las funciones de la aplicación relacionadas a autenticación y

gestión de sesiones son implementadas incorrectamente,
permitiendo a los atacantes comprometer usuarios y
contraseñas, tokens de sesión, o explotar otras fallas de
implementación para asumir la identidad de otros usuarios.
 2) OWASP TOP 10: Broken AuthenEcaEon - I
¿Cómo determinar si es vulnerable?
• Permite ataques de fuerza bruta/automaKzados?
ü Bloquear cuentas en caso de X intentos fallidos
• Permite contraseñas por defecto o débiles?
ü Contraseñas como asdf, ASDF123, QWERTY, y otras combinaciones.
• Procesos débiles para la recuperación de credenciales?
ü Al introducir un email para recuperar el sistema no debe confirmar o negar que
el usuario posee una cuenta.(Mensajes como: El usuario no existe o recibirá un
email en la cuenta)
ü Almacena las contraseñas en texto plano o cifradas con métodos de hashing
débiles? (MD5, SHA)
• No posee autenKcación mul5-factor?
ü SMS, Google AuthenXcator
3) OWASP TOP 10: Sensitive Data Exposure
(Exposición de datos sensibles)
Muchas aplicaciones web y APIs no protegen adecuadamente datos
sensibles, tales como información financiera o de salud, entre otras.
Los datos sensibles requieren métodos de protección adicionales,
como el cifrado en almacenamiento y tránsito.
Datos de configuración de las aplicaciones no deben incluirse en el
código.
(User/pass de APIs)
Visiten https://haveibeenpwned.com/
4) OWASP TOP 10: XML External Entities (XXE)
(Entidad Externa en XML)
Muchos procesadores XML anFguos o mal configurados evalúan
referencias a enFdades externas en documentos XML.
- Revelar archivos locales
- Ver URLs de servidores internos
- Escanear puertos de la LAN
- Ejecutar código de forma remota
- Realizar ataques de denegación de servicio.
5) OWASP TOP 10: Broken Access Control (Control
de acceso dañado)
Los usuarios pueden ejecutar funciones fuera de los privilegios asignados.
Ejemplos:
• “Protección” mediante URLs ocultas según perfil de usuario.
• Agregar parámetros. Por ej: “isSuperAdmin=true”.
• Path traversal: www.randomsite.com/descarga.php?f=x.pdf

Insecure direct object reference - Referencia de objetos insegura

Se refiere a cuando una referencia a un objeto de implementación interna, tal como un archivo o llave(key, id)
de base de datos, se expone a los usuarios sin ningún otro control de acceso.

Ejemplo:

üUn siOo que permite publicar posts a los usuarios registrados.

üEn la sección administraOva se listan las noOcias publicadas (por el usuario autenOcado) y se pueden
editar/eliminar.
5) OWASP TOP 10: Broken Access Control

Problemas del Ejemplo:

• Revela los identificadores de los objetos de la base de datos.

• Un usuario malintencionado podría intentar editar/eliminar notas que no son de su
autoría.
• Se puede acceder a otros datos siguiendo el mismo patrón (editarOtraCosa,
eliminarOtraCosa)
5) OWASP TOP 10: Broken Access Control
Casos reales:
En 2010, cuando el iPad era el gadget más cool para los primeros usuarios, AT&T
sufrió de una insegura referencia de objeto directo que expuso los datos
personales de al menos más de 100.000 propietarios. Se expuso la dirección de
correo electrónico de los propietarios, así como las ICC-IDs (el ID de la tarjeta
SIM). A medida que Apple proporcionó los datos a AT&T, a menudo recibió la
culpa de esta vulnerabilidad que afectó protección de datos personales.
Mediante el envío de una solicitud a AT&T, junto con un ICC-ID, el servidor
respondería con la dirección de correo electrónico correspondiente. A medida que
el ICC-IDs se puede enumerar examinado sólo unos idenKficadores, este ataque
pudo ser totalmente automaKzado permiKendo una fuga de datos personales
considerable.
6) OWASP TOP 10: Security Misconfiguration
(Configuración de Seguridad Incorrecta)
Ocurre cuando algún sistema es configurado de tal manera que lo deja vulnerable.
Esto puede ocurrir en cualquier nivel del stack de la aplicación:

• Servidor web • Modo debug habilitado.

• Páginas de error no personalizadas.
• Base de datos
• Puertos abiertos innecesariamente.
• Aplicación web • Servicios de prueba o legado (legacy).
• Sistema operativo • Las cuentas por defecto siguen acXvas.
• Listado de directorios.
• Firewalls
Caso Joomla y su componente com_contact

Este componente permite que un atacante remoto envíe, de manera

arbitraria, a través del método POST ciertos parámetros en los que se
le indica un mensaje, un asunto de correo y una dirección de correo
arbitraria, simulando un envío mediante el formulario de contacto
web.
Este componente, además, cuenta con un campo contact_email_copy
en el que se indica que el servidor web enviará una copia del mensaje
a la dirección de correo indicada.
https://github.com/joomla/joomla-cms/issues/24187
7) OWASP TOP 10: Cross-Site Scripting (XSS)

XSS ocurre cuando un atacante es capaz de inyectar código

JavaScript para que se ejecute en el navegador del cliente.
Es un ataque dirigido al usuario pero se origina a causa de un
servidor vulnerable.
8) OWASP TOP 10: Insecure Deserialization
(Deserialización Insegura)
Por medio de la serialización es posible copiar el estado de un objeto
para ser transportado o almacenado.
La deserialización permite obtener esta representación y restaurar el
estado del objeto original.

El problema
Cuando la aplicación toma un objeto especialmente modificado y
serializado, podría procesarlo de tal manera que al deserializarlo se
ejecute código en el servidor.
9) OWASP TOP 10: Using components with known
vulnerabilities (Uso de componentes con vulnerabilidades
conocidas)
Los componentes como bibliotecas, frameworks y otros módulos se ejecutan con los
mismos privilegios que la aplicación.

Si se explota un componente vulnerable, el ataque puede provocar una pérdida de

datos o tomar el control del servidor.

La mayoría de las fallas de seguridad en CMS tales como WordPress o Joomla se dan
debido a que se han instalado plugins con vulnerabilidades.

Por ejemplo, dos herramientas que buscan vulnerabilidades en estos CMS:

● joomscan
● wpscan
10) OWASP TOP 10: Insufficient Logging & Monitoring
(Registro y Monitoreo insuficiente)

El registro y monitoreo insuficiente, junto a la falta de respuesta

ante incidentes permiten a los atacantes mantener el ataque en
el tiempo, pivotear a otros sistemas y manipular, extraer o
destruir datos.
Los estudios muestran que el tiempo de detección de una brecha
de seguridad es mayor a 200 días, siendo típicamente detectado
por terceros en lugar de por procesos internos.
Programación Segura
Seguridad a nivel de Base de Datos
 Programación Segura
Recomendaciones básicas para el manejo de datos ingresados por el
usuario:
• Todos los campos que permitan el ingreso de datos (texto,
numérico) DEBEN ser validados (cliente & servidor).
• Si no cumple con las validaciones, se rechaza.
• Letras en un campo numérico.
• Texto de longitud mayor a la esperada.
 SQL Injection I

Happy Path
Usuario ejecuta el script de la siguiente manera:

Consulta SQL generada:

 SQL Injection II

Non happy path

Usuario ejecuta el script de la siguiente manera:

Consulta SQL generada:

 SQL Injection III

Resultado: En el segundo caso, la consulta se ejecuta correctamente

y si el usuario de DB www Kene los suficientes permisos (roles y
auth) todo el contenido de la tabla se ha borrado.
Qué se hizo mal?
- Falta de verificación de parámetros en el código que envía las
instrucciones al conector de DB.
- Los parámetros deben validarse tanto en el cliente (navegador) como en el
servidor.
- Los campos deben restringirse lo más posible en la base de datos (campos
que solo aceptan números no deberían ser de Xpo VARCHAR, TEXT, etc.).
Y qué MÁS se hizo mal?
- No se tuvo en cuenta el Principio del menor privilegio (least privileges).
El usuario ‘www’ es muy poderoso. Si sabemos que recibirá datos de un
entorno inseguro (toda la web) es mejor que tenga menos
responsabilidades. Idealmente solo hacer SELECT y no
DELETE/CREATE/UPDATE.
Programación Web Segura I
La vulnerabilidad del ejemplo presentado fue “parcheada” en las versiones
más recientes de PHP. (Pero sabemos que no todos los siXos usan las úlXmas
versiones)

mysql_query y mysqli::query actualmente no permiten la ejecución de

consultas múlXples (query1;query2;queryTOKILLDB).
Pero (siempre hay un pero), si hubiera sido un caso un borrado
DELETE FROM table WHERE name=’’ or ’1’ = ’1’;
(esto es muy mala prácRca, pero sucede)
Programación Web Segura II

Una inyección SQL solo puede ocurrir si el código valida de manera

insuficiente la entrada externa entrante de una fuente no confiable. El
atacante obliga a nuestro programa a ejecutar comandos SQL propios
en nuestra base de datos
 DEMO – DVWA 1

• UFlizaremos las herramientas DVWA y Docker

• Ejecutamos el comando:
• docker run --rm -it -p 80:80 vulnerables/web-dvwa
• Nos vamos a hVp://localhost
• Inicialmente nos pide un login:
• Username: admin
• Password: password
• Le damos en Create/Reset Database
 DEMO – DVWA 2 - PoC

• Averiguar la versión de la BD
• Listar todos los usuarios y sus respectivas columnas (no hace
falta en el mismo query)
• Extraer las contraseñas y armar una base de datos de hashes
• “Descifrarlas” J pueden utilizar cualquier recurso
Programación Segura
 Programación Segura

En ambos casos, veremos (SIEMPRE en los logs del servidor, NUNCA debe
llegar al lado del cliente) el conocido error:

You have an error in your SQL syntax; check the manual that corresponds to
your MySQL server version for the right syntax to use near ’delete from
table’ at line 1
 MulHple Consultas

Pero (efectivamente, siempre hay un pero) si de verdad

necesitamos/queremos ejecutar múltiples consultas (ya sea por
performance)

mysqli::multi_query → Debe usarse con un estricto control de parámetros

previamente a la ejecución de la consulta, considerar los permisos del
usuario de la DB, y considerar los riesgos.
 Prevención

Como defenderse de las Inyecciones SQL?

• Muy común, no debemos pensar que a nosotros no nos pasará.
• Combinar:
ü el principio de menor privilegio;
ü validación rigurosa de datos;
ü caracteres de escape que pueden alterar una forma de la consulta SQL;
ü mediante el uso de placeholders.
 Prevención II

Como defenderse de las Inyecciones SQL?

• Bajo ninguna circunstancia otorgue a los usuarios más privilegios de los
que realmente necesitan tener:
ü El usuario www de nuestro ejemplo solo necesita el privilegio SELECT
sobre la tabla y no debe tener privilegios adicionales.
ü Incluso se puede otorgar privilegios SOLO para ciertas columnas de la
tabla.
 Más prevenciones
Como defenderse?
• ¿El servidor de base de datos se ejecuta solo localmente, es decir, en
127.0.0.1, o es accesible a través de interfaces adicionales? ¿Es accesible a
través de LAN y / o incluso WAN?
• Restricción de acceso por VPN, IP estática de usuarios permitidos y
conocidos)
• Se pueden restringir las interfaces en las que se ejecuta el servidor.
MySQL puede ejecutarse en un socket local, que es inaccesible a través de
la red (mysql_connect (': / tmp / mysql.sock', 'www')).
• BORRAR LOS USUARIOS POR DEFECTO.
 Escape de caracteres

Manejo de Caracteres de Escape (o secuencias de escape)

Las secuencias de escape se utilizan para definir ciertos caracteres especiales
dentro de cadenas de texto.
 Manejo de Caracteres de Escape (o secuencias de
escape)

Las secuencias de escape se uXlizan

para definir ciertos caracteres
especiales dentro de cadenas de
texto
 Escaping” solo las comillas simples y dobles no es suficiente.

PHP puede ayudarnos aquí con la siguiente instrucción, aunque

esto no es totalmente Seguro!
mysql_real_escape_string() y un falso
sen;miento de seguridad
• Hay una forma de esquivarlo
mysql_real_escape_string()
• mysql_query('SET NAMES gbk’);
• Selecionamos el enconding gbk
• $var = mysql_real_escape_string("\xbf\x27 OR 1=1 /*");
• La carga o payload que vamos a usar comienza con 0xbf27. En gbk, es un invalid character de varios bytes;
en latin1, es el string ¿’. Nota: En latin1 y gbk, 0x27 tienen sus propio character ‘ (comilla simple).
• mysql_real_escape_string inserta un \ (backslash) y temenos un caracter ‘ (comilla simple) limpio! Dando como
un output algo asi: 縗' OR 1=1 /*
• mysql_query("SELECT * FROM test WHERE name = '$var' LIMIT 1");

• SELECT * FROM test WHERE name = '縗' OR 1=1 /*' LIMIT 1

 Placeholders
El reemplazo de parámetros generalmente ocurre después de pasar una plantilla
del comando a la base de datos, y los parámetros a ser reemplazados en
placeholders, a menudo se usa ? . A veces también podemos especificar un tipo
de parámetro.
El sistema de base de datos construye la consulta final que contiene los valores de
los parámetros reales.
 ORM - Object-Rela-onal mapping
• Ayuda a olvidarse de las consultas (armarlas) y evitar mas errores
humanos!
• Ejemplos:
ü AcKveRecord – Ruby On Rails
ü Hibernate – Java Web
ü QuerySet (???) – Django o Pewee ambos en Python
• Muchos traen capas de seguridad contra XSS, SQLi
• Usan placeholders o uno puede especificarlos como manipular inputs
• Nunca es suficiente!! Y siempre hay formas de evitarlos! (Veremos al
final de la clase)
Programación Segura
Placeholders
DEMO 2 – Point Of View

üVayan a www.segurilock.com
üEncontrarán el desaKo en Canvas
üDiviértanse J
 Bibliografía I
• OWASP Top 10, OWASP FoundaXon. 2017 https://owasp.org/www-pdf-
archive/OWASP_Top_10-2017_%28en%29.pdf.pdf

• OWASP Top 10, OWASP Patagonia Chapter, Gastón Toth https://csirt-

nqn.neuquen.gov.ar/wp-content/uploads/2019/06/Charla-OWASP-TOP10-Nqn.pdf

• ¿Qué es insecure direct object reference y cómo solucionarlo?, Jarvis Wagner.

https://noticiasseguridad.com/importantes/que-es-insecure-direct-object-reference-y-como-
solucionarlo/

• Everything you wanted to know about SQL injecXon (but were afraid to ask), Troy
Hunt. 2013 https://www.troyhunt.com/everything-you-wanted-to-know-about-sql/
• Example of a Error-Based SQL InjecXon, Ninja Hatori. 2019
https://medium.com/@hninja049/example-of-a-error-based-sql-injection-dce72530271c
Bibliografía II
ü Security and Secure programming - Database Security., Ing. Tomáš Zahradnický, EUR ING,
Ph.D., Czech Technical University in Prague, Faculty of Informa,on Technology, Department
of Computer Systems.
ü Security and Secure programming - Security of Web Applica,on., Ing. Tomáš Zahradnický,
EUR ING, Ph.D., Czech Technical University in Prague, Faculty of Informa,on Technology,
Department of Computer Systems.
ü Common SQL Injec,on Aeacks, Satyam Singh. 2019
https://pentest-tools.com/blog/sql-injection-attacks/
ü Presentación “Seguridad en Aplicaciones” Módulo 3 – Ing. Gabriela Rak
ü Presentación “OWASP, SQL Injec,on y XSS” – Materia: Seguridad Informá,ca – Carrera Ing.
Informá,ca – Univ. Nacional de Itapua – Febrero 2020 – Ing. Tanía Paiva y Ing. Raúl B. Neeo
ü heps://stackoverflow.com/ques,ons/5741187/sql-injec,on-that-gets-around-mysql-real-
escape-string
Gracias por su atención J

Preguntas?

Contactos: raulbeni@gmail.com