Interesante compendio de tips y recomendaciones para mejorar la seguridad de sistemas y aplicaciones informáticas. Consejos para proteger los datos, SQL Injection, XSS Injection, gestión y uso de contraseñas, encriptación de los datos, aplicaciones web, redes y comunicaciones, autenticación, sesiones de usuario, etc. Enlaces a herramientas de footprinting, analizadores de vulnerabilidades, exploits, etc.

1. Recomendaciones de Seguridad
2019 por Rafael Hernampérez

2. Indice
• Base de datos
• Datos
• Contraseñas
• Sitios Web
• Autenticación y sesión
• Proxies y firewalls
• Anexo

3. Base de datos
Usuarios, contraseñas, puertos y carpetas por defecto
Un hábito pernicioso es no cambiar o crear una contraseña para el usuario root ó admin.
Otro hábito es el uso del usuario root de base de datos para las aplicaciones. Es recomendable crear un usuario
específico para la aplicación, con permisos restringidos (no otorgar permisos de administrador) y crear un
esquema específico para cada aplicación.
En MongoDB se utiliza el usuario admin por defecto y sin contraseña. Es recomendable asignar una contraseña a
este usuario, y crear un usuario para el uso de la base de datos para la aplicación.
Otro hábito común es conservar los puertos por defecto de la base de datos. Los hackers conocen los puertos de
base de datos por defecto y pueden aprovecharlos para realizar exploits. Cambiando el puerto, será más
complicado saber que un determinado puerto corresponde a una base de datos.
Otro hábito común es usar la comunicación de la base de datos sin securizar. Es conveniente utilizar siempre una
comunicación securizada mediante SSL o TLS, especialmente, en producción.
Por último, es recomendable también cambiar la carpeta de trabajo de la base de datos, ya que los hackers
también conocen dónde se alojan los datos de ésta.

4. Base de datos
IDs
Uso de IDs alfanuméricos, basados en hashes únicos.
En tablas maestras, con pocos registros o registros controlados, mejor usar IDs numéricos.
ID de 32 caracteres:
- ISO Date: YYYYMMDDhhmmssnnn
- Literal o firma: WGO
- Número aleatorio entre 0 y 999
Transformación a hexadecimal:
- Fecha:
- YYYY. Hexadecimal de 4 dígitos
- MM, DD, hh, mm y ss. Hexadecimal de 2 dígitos
- nnn. Hexadecimal de 4 dígitos
- Literal o firma: ‘WGO’. 2 dígitos hex por carácter.
- Número aleatorio:
- Parte entera. Hexadecimal de 4 dígitos
- Parte decimal. Hexadecimal de 4 dígitos
ID de 10 caracteres:
- Literal o firma: WGO
- Número aleatorio entre 0 y 999
Transformación a hexadecimal:
- Literal o firma: ‘WGO’. 2 dígitos hex por carácter.
- Número aleatorio:
- Parte entera. Hexadecimal de 4 dígitos
- Parte decimal. Hexadecimal de 4 dígitos

5. Base de datos
Encriptación de datos sensibles
Encriptación de campos con datos sensibles, para cumplir con RGPD y LOPD:
No utilizar MD5 ni SHA1. Mejor utilizar SHA256 ó AES256
- Nombre
- Apellidos
- Sexo
- Raza
- Religión
- Ideología política
- Gustos, intereses, opiniones
- Dirección
- Población
- Provincia
- País
- Código postal
- Posición GPS
- Email
- Número de teléfono
- Cuenta bancaria
- Tarjeta de crédito
- URLs a contenidos personales (fotos, vídeos…)

6. Base de datos
Clave dinámica de encriptación
Si bien la base de datos puede incorporar funciones de encriptación, es mejor encriptar la información con una
clave dinámica, es decir, que cada registro posea una clave distinta para encriptar los datos sensibles.
Esto obliga que la encriptación se realice desde código, no desde la base de datos.
Se puede utilizar el ID alfanumérico como parte de la clave, y se añadirá algún elemento fijo. Una idea es usar el
id de usuario único asociado al registro, junto con una firma.
Ejemplos (ID: 07e30c0a081a38003757474f25e90d4d):
- WGO-07e30c0a081a38003757474f25e90d4d
- 07e30c0a081a38003757474f25e90d4dWGO

7. Base de datos
Ofuscación de tablas y campos sensibles
Si un hacker llegase a acceder a la base de datos, es conveniente complicarle la labor de acceder a datos
sensibles, tales como datos financieros o las tarjetas de crédito.
Para ello, además de la encriptación, será necesario ofuscar las tablas y los campos sensibles. Para ello,
convendría cambiar el nombre de las tablas y de los campos por algo completamente diferente pero coherente,
de forma que, si ve dicho nombre, no lo relacione con los datos que contiene.
Por ejemplo, el campo para el número de cuenta bancaria podría llamarse “id revendedor” o “referencia de
producto”.

8. Base de datos
SQL Injection
SQL Injection es una vulnerabilidad que permite enviar sentencias SQL maliciosas a través de campos de
formulario o de parámetros en llamadas web, las cuales se ejecutarán y permitirán obtener datos o realizar
cambios en la base de datos.
Para evitar el SQL Injection, es necesario, en la parte de backend, realizar una validación de los parámetros e
identificar si vienen sentencias SQL en lugar de datos y actuar en consecuencia.
Un método es utilizar sentencias preparadas en SQL, en lugar de sentencias SQL normales que concatenen los
valores que vienen en los parámetros.
Otra forma más efectiva y sencilla es el uso de ORMs (Object-Relactional Mapping), los cuales ya se encargan de
discriminar SQL Injection. Un ORM permite el uso de objetos de datos en los lenguajes de programación,
mapeando automáticamente los datos y las operaciones con la base de datos.
Existen multitud de ORMs. En NodeJS, el más común es Sequelizer. Para PHP, depende del framework. Synfony,
Zend Framework y CodeIgniter soportan Doctrine ORM. Laravel utiliza Eloquent ORM. CakePHP utiliza su propio
ORM. Otro ORM popular que puede adoptarse en varios frameworks es Propel ORM.

9. Indice
• Base de datos
• Datos
• Contraseñas
• Sitios Web
• Autenticación y sesión
• Proxies y firewalls
• Anexo

10. Datos
Configuración
Los ficheros de configuración son muy golosos para los hackers, pues en éstos se encuentra información vital
sobre nuestros sistemas y pueden abrirles las puertas para entrar.
Recomendaciones:
- Ofuscar el nombre de las carpetas o de las tablas. A un hacker no lo costaría trabajo encontrar carpetas o
tablas que contengan un literal como ‘config’, ‘setup’, ‘setting’ ó ‘param’.
- Ofuscar las extensiones de los archivos. No utilizar las extensiones ‘json’, ‘xml’, ‘yml’, ‘cfg’ ó ‘param’.

11. Datos
Logs y monitorización
Los ficheros de monitorización y de log son fuentes ricas de información para un hacker, y debería evitarse el
acceso a los mismos.
Recomendaciones:
- Ofuscar el nombre de las carpetas o de las tablas. A un hacker no lo costaría trabajo encontrar carpetas o
tablas que contengan un literal como ‘log’ ó ‘trace’.
- Ofuscar las extensiones de los archivos. Utilizar extensiones diferentes a ‘json’, ‘log’ ó ‘trace’.
- Ofuscar nombres de campos. Si se almacenan en tablas de base de datos, es mejor utilizar nombres muy
diferentes para no dar pistas.
- Encriptar datos que pongan en riesgo la seguridad. Los logs y datos de monitorización suelen estar en crudo,
exponiendo la información sin más. Podemos estar exponiendo datos sensibles, tales como nombres de
usuario, nombres de tablas, nombres de métodos, nombres de servicios en las apis, nombres de dispositivos,
nombres de máquinas, ips, etc.

12. Datos
Imágenes
Consejos para almacenamiento de imágenes:
- Eliminar metadatos (EXIF ó EXchangeable Image File). Las cabeceras de las imágenes almacenan mucha
información sobre la imagen: localización, dispositivo, etc.
- En imágenes sensibles (documentos de identificación, retratos, etc), aplicar filtros de ofuscación.
- Almacenar las imágenes en servicios cloud especializados, como Cloudinary. Estos servicios, además de
gestionar filtros o transformar imágenes, también facilitan el almacenamiento y la seguridad. En cambio,
utilizaremos la URL como dato de la imagen, la cual encriptaremos en nuestra base de datos.
- Cloudinary también permite utilizar APIs de securización de acceso a las imágenes (plan de pago).
- Las imágenes deberían estar únicamente visibles y accesibles al usuario correspondiente, evitando los accesos
públicos.

13. Datos
Documentos
Consejos para almacenamiento de documentos (office, pdf, etc):
- Eliminar metadatos o características del documento. Las cabeceras pueden contener nombres de usuario en la
empresa, el nombre de la empresa, correos electrónicos, etc.
- Utilizar servicios cloud de almacenamiento, los cuales gestionan el almacenamiento, la seguridad y el acceso a
los documentos. Éstos proporcionan URLs que almacenaremos encriptadas en la base de datos. También
proveen de APIs y métodos de acceso securizado.
- Los documentos deberían estar únicamente visibles y accesibles al usuario correspondiente, evitando los
accesos públicos.

14. Indice
• Base de datos
• Datos
• Contraseñas
• Sitios Web
• Autenticación y sesión
• Proxies y firewalls
• Anexo

15. Contraseñas
Constraseñas seguras
Tras 20 años de esfuerzo, hemos enseñado a todo el mundo a usar contraseñas que son difíciles de recordar para
los humanos, pero fáciles de adivinar para los ordenadores.

16. Contraseñas
Recomendaciones de contraseñas
- Cuanto más larga sea, más complicado será de adivinar
- El método de las cuatro palabras aleatorias es fácil de recordar y eficiente en seguridad
- Más recomendable: utilizar seis palabras aleatorias
- Contraseñas más fuertes:
- Letra/s mayúsculas
- Número/s
- Signo/s
- Utilizar contraseñas diferentes en diferentes servicios
Más info:
https://www.xataka.com/seguridad/trucos-para-crear-recordar-buena-contrasena
https://hackinglethani.com/es/contrasenas-seguras/

17. Contraseñas
Salt
Para fortalecer la encriptación de una contraseña, se agrega un salt aleatorio al algoritmo de encriptación. Esto
evita que si dos usuarios utilizan casualmente la misma contraseña, si un hacker consigue la contraseña de uno
de ellos pueda obtener del resto de contraseñas mediante el mismo método.
Gracias al uso de salt se complican los ataques de diccionario, incrementando el número de casuísticas para este
tipo de ataques.
Para una mayor seguridad, es recomendable guardar los salts fuera de la base de datos. Si un hacker roba la
base de datos, no podrá obtener las contraseñas.
Más info: https://es.wikipedia.org/wiki/Sal_%28criptograf%C3%ADa%29

18. Contraseñas
Encriptación unidireccional
Normalmente, los algoritmos de encriptación se realizan en dos direcciones:
- Se encripta mediante un dato y una clave de encriptación, obteniendo un hash.
- Se desencripta mediante un hash y la clave de encriptación, obteniendo la contraseña limpia.
La contraseña puede encriptarse en una única dirección (paso 1), comprobando si una determinada contraseña
se encuentra en un hash.
En NodeJS tenemos la librería bcrypt:
const hash = bcrypt.hashSync(password, bcryt.genSaltSync(8)); // retorna el hash
const isValid = bcrypt compareSync(password, hash); // Retorna true/false
En PHP se utiliza password_hash().
Más info:
https://www.npmjs.com/package/bcrypt
https://www.php.net/manual/es/function.password-hash.php

19. Indice
• Base de datos
• Datos
• Contraseñas
• Sitios web
• Autenticación y sesión
• Proxies y firewalls
• Anexo

20. Sitios Web
Fichero robots.txt
El archivo robots.txt puede dar mucha información a los buscadores para mejorar la indexación del sitio, pero
también ofrece mucha información a un posible hacker.
Entre estos contenidos se encuentran las urls a evitar indexar u ocultar. Aquí ya le está dando información a un
hacker. Un ejemplo habitual es la url a wp-admin o a phpMyAdmin de Wordpress. También se suele incluir el
acceso a la configuración, a urls de prueba (que pueden tener ejemplos de acceso), urls de archivos (entre los que
se pueden encontrar contraseñas) o imágenes, etc. También permite acceder a información de parámetros en la
url, como queries de administración, contraseñas, etc.
Más info: http://www.behindthefirewalls.com/2013/07/using-robotstxt-to-locate-your-targets.html

21. Sitios Web
Fichero security.txt
El archivo security.txt es un recurso que pasa desapercibido y que puede ser muy útil.
Al igual que robots.txt, es un archivo plano que se cuelga en el directorio raíz de un sitio web o,
recomendablemente, en la carpeta .well-known. Este archivo es un estándar que contiene información para el
reporte de vulnerabilidades en un sitio web. Los parámetros permitidos son:
Contact: <contact-email>
Encryption: https://<link-to-secure-key-to-talk>
Acknowlegments: https://<link-to-thanks-page>
Preferred-Languages: es[, en[,...]]
Canonical: https://<url-accesing-to-security.txt>
Policy: https://<url-to-policies-reporting-page>
Hiring: https://<url-to-security-Jobs-in-your-organization>
Nota: El parámetro Contact es el único que es obligatorio.
Más info: https://securitytxt.org/

22. Sitios Web
Acceso a recursos del site
Se debe evitar que se pueda acceder a recursos del site:
https://www.misitio.com/config/config.json
https://www.misitio.com?page=.../.../etc/passwd

23. Sitios Web
XSS Injection
La inyección XSS (ó Cross-site Scripting) es un tipo de ataque que permite ejecutar scripts maliciosos en páginas
web, normalmente desde un formulario en un navegador.
Hay dos tipos de inyección XSS:
- Reflejado o Almacenado. En el lado del servidor
- XSS basado en DOM. En el lado del front.
Es posible insertar tags en el DOM que ejecuten un script Javascript malicioso.
Es posible insertar tags de XML que permita ejecutar código en el servidor o acceder a recursos del sistema.
Más info:
https://cheatsheetseries.owasp.org/
https://cheatsheetseries.owasp.org/cheatsheets/DOM_based_XSS_Prevention_Cheat_Sheet.html
https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html

24. Indice
• Base de datos
• Datos
• Contraseñas
• Sitios web
• Autenticación y sesión
• Proxies y firewalls
• Anexo

25. Autenticación y sesión
Autenticación
A continuación se enumeran algunas recomendaciones a la hora de autenticarse:
- Usar siempre protocolos seguros (ejemplo: TLS)
- Siempre usar Case Sensitive tanto para el usuario como para la contraseña
- En caso de autenticación fallida, no aportar detalles de la causa del error
- No guardar las contraseñas en el front-end (ni en cookies ni en LocalStorage)
- Evitar que el navegador guarde contraseñas:
- Usar autocomplete = false
- Uso de campos tipo hidden en lugar de campos tipo password
- Utilizar un sistema de captcha junto al login.
- Utilizar una autenticación de dos factores. De forma aleatoria, tras el login solicitar un dato adicional, como un
código de validación enviado por SMS o email. Existen herramientas como Google Authenticator ó Latch.
- Si se produce un número seguido de intentos fallidos (por ejemplo, cinco), bloquear la cuenta

26. Autenticación y sesión
Sesión
Una vez autenticado el usuario, hay que gestionar adecuadamente la sesión:
- El back-end retornará un token de sesión tras el login
- El token debe tener una caducidad corta (por ejemplo, 24 horas)
- Las peticiones al servidor deberán estar autenticadas con el token
- Si un token caduca, debe renovar el token mediante algún servicio al cual se le pase el id del usuario y el token
antiguo para su validación.
- Se debe contemplar la posibilidad de varias sesiones para un mismo usuario (un por dispositivo o por
navegador). Para ello, en cada login se genera un app_instance, que asigna un id o hash único a esa sesión. La
renovación de token debe contemplar también el app_instance.
- En la parte back-end debe haber una función middleware que se ejecute antes que la función del servicio, y
dicha función debe validar el token provisto por el front-end. Si no es válido debe retornar un error al front-end.
Si es correcto, procederá a ejecutar la función correspondiente del servicio.
- Una recomendación adicional sería transformar el token para que solamente la aplicación sea capaz de
recuperar sus valores, ya que un hacker podría ver su contenido aunque no esté validado (ver https://jwt.io). Un
ejemplo sería invertir de todos los caracteres del token.
- Guardar valores de sesión no críticos en el token (no incluir contraseñas o códigos importantes)
Más info: https://jwt.io

27. Indice
• Base de datos
• Datos
• Contraseñas
• Sitios web
• Autenticación y sesión
• Proxies y firewalls
• Anexo

28. Proxies y firewalls
Introducción
Un firewall (o cortafuegos) permite restringir y autorizar determinadas comunicaciones de/hacia las máquinas de
nuestras aplicaciones. Normalmente se pueden definir protocolos, puertos y dirección de las comunicaciones
(ejemplo: IN TCP 8080, OUT UDP 2019)
Un proxy permite restringir las comunicaciones de una máquina hacia o desde determinadas ips o páginas uris.
También permite registrar el tráfico para su estudio. Por ejemplo, se puede restringir el acceso a una máquina a
determinadas ips, de forma que solamente esas ips (y solo esas ips) pueden acceder a esa máquina.

29. Proxies y firewalls
Aplicaciones
- Restringir el acceso a la máquina por determinado un único protocolo y puerto.
- Restringir el acceso a la máquina desde una determinada IP:
- Por ejemplo, el servicio de PostgreSQL para Azure, tiene restringido un único protocolo y puerto, y el acceso a
dicho servicio sólo se puede realizar desde las ips que se especifiquen (la de la máquina de la aplicación back-
end).
- Prohibir o limitar la descarga de determinados archivos.
- Conocer el uso de las comunicaciones. Permite registrar los intentos de acceso desde una ip concreta, con lo
que podemos detectar un ataque de intrusión y bloquear la ip.
- Un proxy permite ocultar al público la ip real del servidor destino.
- Un proxy puede penalizar el rendimiento, por lo que puede cachear recursos habituales, especialmente
imágenes y otros recursos pesados.

30. Proxies y firewalls
WAF (Web Application Firewall)
“Un firewall de aplicaciones web (WAF) es un tipo de firewall que supervisa, filtra o bloquea el tráfico HTTP hacia y
desde una aplicación web. Se diferencia de un firewall normal en que puede filtrar el contenido de aplicaciones
web específicas, mientras que un firewall de red protege el tráfico entre los servidores. Al inspeccionar el tráfico
HTTP un WAF protege a las aplicaciones web contra ataques como los de inyección SQL, XSS y falsificación de
sitios cruzados (CSRF)”
Fuente: Wikipedia: https://es.wikipedia.org/wiki/Web_application_firewall

31. Indice
• Base de datos
• Datos
• Contraseñas
• Sitios web
• Autenticación y sesión
• Proxies y firewalls
• Anexo

32. • Metadatos en imágenes: ElevenPaths FOCA, ExifTool
• Metadatos en documentos: ElevenPaths FOCA, ExifTool
• Validar SQL Injection: SQLMap y NoSQLMap
• Análisis de sitios con SSL: https://www.ssllabs.com/ssltest/
• Análisis de tecnologías en sitios web: Wappalyzer. Incluye extensión para navegador
• Análisis de IoT, puertos y hosting en sitios web: Shodan.io. Incluye extensión para navegador
• Subdominios abusivos: https://www.kitploit.com/2018/03/ctfr-get-subdomains-of-https-website.html
• Rastreo de puertos con Nmap: https://nmap.org/
• Recogida de información para intrusión (footprinting): https://www.spiderfoot.net/
• Escaneo de servidores y aplicaciones web: https://cirt.net/nikto2
• Escaneo de vulnerabilidades: https://es-la.tenable.com/products/nessus
• Escaneo de vulnerabilidades: http://www.openvas.org/
• Escaneo de vulnerabilidades de aplicaciones web: https://www.acunetix.com/
• IDS (Intrusion Detection System): https://www.ossec.net/ y https://www.zeek.org/
• IPS (Intrusion Prevention System): https://snort.org/ y https://suricata-ids.org/
• SIEM (Security Information and Event Management): https://cybersecurity.att.com/
Anexo
Herramientas

33. • Base de datos de exploits: https://www.exploit-db.com/
• Base de datos de vulnerabilidades: https://www.cvedetails.com/
• Fundación OWASP: https://www.owasp.org/index.php/Main_Page
• Recursos y consejos útiles de OWASP: https://cheatsheetseries.owasp.org/cheatsheets/
Anexo
Enlaces de interés

34. • Mantener siempre actualizados todos los componentes de nuestras aplicaciones
• Mantener siempre actualizados todos los componentes de nuestras infraestructuras
• Realizar backups frecuentes de todos los datos, mejor varias veces al día
• Realizar auditorías de seguridad cada año
• Si se almacenan tarjetas de crédito, utilizar el estándar PCI DSS: https://es.wikipedia.org/wiki/PCI_DSS
• Uso de Azure:
• Activar las alertas de seguridad
• Acceso aWeb Apps siempre mediante HTTPS
• Uso de Azure Front Door, que incluyeWAF y protección contra ataques DDoS (especialmente para redes virtuales
dedicadas)
• En los componentes de base de datos utilizar siempre conexión segura
• Algunos componentes de base de datos configurar proxy para restringir el acceso únicamente a la ip de la API
Anexo
Consejos finales

35. MUCHAS GRACIAS
2019 por Rafael Hernampérez