Este documento discute varios temas relacionados con la seguridad en aplicaciones web y comercio electrónico. Explica mitos comunes sobre la seguridad, cómo documentarse sobre seguridad, y cómo analizar vulnerabilidades en un sitio web. También recomienda implementar pruebas unitarias y minimizar el uso de componentes externos de baja confianza para mejorar la seguridad.

1. René Olivo
Santo Domingo
28 Mayo 2015
En las Aplicaciones Web
y el Comercio Electrónico
Seguridad

2. ● Definiciones.
● Mitos de seguridad.
● Como documentarse.
● Como analizar tu website.
● NodeGoat.
● Recomendaciones.
Temas

3. Seguridad
- Es relativa. Será tan efectiva como el valor
de lo que se quiere proteger.
- Incluye a todos los componentes que
integran el sistema (hardware, software,
personas, etc.).
- Es un estado temporal. Debe reevaluarse
periodicamente.
Source: The Protection of Information in Computer Systems. – Jeromoe Saltzer & Michael Schroeder.

4. Mito
Seguridad por oscuridad.

5. Mito
Seguridad por oscuridad.
Debil contra ataques como Brute-Force, Dictionary y
Crawling.

6. Mito
Las claves necesitan números, símbolos y
mayúsculas para ser seguras.

7. Mito
Las claves necesitan números, símbolos y
mayúsculas para ser seguras.
"durante 20 años de esfuerzo, hemos entrenado a todo el mundo a usar claves
que son difíciles de recordar para los humanos y fáciles de adivinar para las
computadoras"
- XKCD

8. Mito
Mi sitio es seguro porque usa HTTPS.

9. Mito
Usar un framework (o un lenguaje) hace que mi
aplicación sea segura.

10. Mito
Usar un framework (o un lenguaje) hace que mi
aplicación sea segura.
Ing. Lead Programador Senior

11. Data Breach
Investigation Report
(DBIR)
http://www.verizonenterprise.com/DBIR/
Cómo documentarse?

12. PCI Compliance
Guide
https://www.pcicomplianceguide.org/
Cómo documentarse?

13. Open Web Application
Security Project
(OWASP)
http://owasp.org
Cómo documentarse?

14. OWASP Top 10
1. Ataques de Inyección.
2. Problemas de autenticación y manejo de sesiones.
3. Cross-Site Scripting (XSS).
4. Accesos a recursos no autorizados.
5. Mala configuración de servicios.
6. Data sensible expuesta.
7. Uso no autorizado de funcionalidades.
8. Cross-Site Request Forgery.
9. Uso de componentes con vulnerabilidades conocidas.
10. Redireccionamientos no validados.

15. OWASP Top 10
1. Ataques de Inyección.
2. Problemas de autenticación y manejo de sesiones.
3. Cross-Site Scripting (XSS).
4. Accesos a recursos no autorizados.
5. Mala configuración de servicios.
6. Data sensible expuesta.
7. Uso no autorizado de funcionalidades.
8. Cross-Site Request Forgery.
9. Uso de componentes con vulnerabilidades conocidas.
10. Redireccionamientos no validados.

16. Validación!
Validación
!
Validación!

17. 1. Inyección

18. 1. Inyección

19. 3. XSS

20. Demo Time!
http://localhost:4000

21. No intentes sanear la data

22. No intentes sanear la data

23. No intentes sanear la data

24. No intentes sanear la data

25. 8. CSRF

26. 8. CSRF

27. Demo Time!
http://localhost:3000

28. 8. CSRF
Crea un token por cada request y validalo

29. 2. Mal manejo de la autenticación
● Arregla problemas de XSS, Inyección,
validación, etc.
● Usa HTTPS.
● Usa HTTP-Only y expira las cookies en un
tiempo prudente.
● Cuando el usuario haga login, dale un
session ID nuevo. (Session Fixation)

30. OWASP Top 10 en R.D.
5. Mala configuración de servicios.
6. Data sensible expuesta.
9. Uso de componentes con vulnerabilidades conocidas.
0. Mal manejo de subida de archivos (defacement)

31. 9. componentes vulnerables

32. Guardando información
Confidencial

33. Disclaimer!
PCI Compliance

34. Operador
Chrome
Servidor
Público
Servidor
Privado
USB
Certificados
Cliente
Servidor
Administrativo

35. Servidor
Público
Cliente
1. El cliente envía el dato confidencial por HTTPS
Más información: https://www.pcicomplianceguide.org/pci-dss-v3-1-and-ssl-what-you-should-do-now/

36. 2. El servidor público encripta la información de la
tarjeta usando el certificado público.
Servidor
Público
Más información: https://github.com/quartzjer/ursa

37. 3. El servidor público envía los datos del usuario y la
información encriptada al servidor privado.
DATA: {
idUsuario:
tarjeta:
}
Servidor
Público
Servidor
Privado
Nota: El servidor público solo tiene acceso de escritura al servidor privado
Más información: http://www.noelherrick.com/blog/creating-users-granting-permissions-in-mysql

38. 4. El Operador accesa el Servidor Administrativo.
Operador
Servidor
Administrativo
DATA: {
usuario: ******
clave: ********
}

39. 5. El Servidor Administrativo genera un token aleatorio
y lo encripta usando el Certificado Público.
Servidor
Administrativo

40. 6. El Servidor Administrativo envía el token encriptado
al operador.
Operador
Servidor
Administrativo

41. 7. El Operador espera a Chrome que Chrome busque
los certificados en un dispositivo externo.
Más información: https://developer.chrome.com/apps/app_usb
Operador
Chrome
USB
Certificados

42. 8. Chrome usa el Certificado Privado para desencriptar
el token.
Más información: https://www.chromium.org/administrators/certificate-management-extension-api-on-chrome-
os
Chrome

43. 9. El Operador envía el token desencriptado al Servidor
Administrativo.
Operador
Servidor
Administrativo

44. 10. El Servidor Administrativo compara los tokens y
pide la información privada de un usuario específico al
servidor privado.
Servidor
Administrativo Servidor
Privado
DATA: {
idUsuario:
}

45. 11. El Servidor Privado responde con la información
necesaria y el Servidor Administrativo la pasa al
Operador.
Servidor
Administrativo
Servidor
Privado
Operador
DATA: {
idUsuario:
tarjeta:
}

46. 12. Chrome desencripta la información privada usando
el Certificado Privado.
Chrome

47. 13. El Operador recive la Información Privada
desencriptada y realiza la transacción deseada.
Operador
Chrome

48. Analizando vulnerabilidades
Estudiando el protocolo HTTP.

49. Analizando vulnerabilidades
Herramientas de prueba de vulnerabilidades.
OWASP ZAP
(Open Source)
ACUNETIX
(Comercial)
PhantomJS
(Open Source, Manual)

52. Recomendaciones
● Documentarse bien sobre el tema.
● Minimizar el uso de componentes externos
de poca confianza.
● Usar solo los servicios necesarios.
● Implementar Unit Testings.