seguridad en aplicaciones web y comercio electrónico
TRANSCRIPT
René OlivoSanto Domingo
28 Mayo 2015
En las Aplicaciones Weby el Comercio Electrónico
Seguridad
● Definiciones.● Mitos de seguridad.● Como documentarse.● Como analizar tu website.● NodeGoat.● Recomendaciones.
Temas
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.
Mito
Seguridad por oscuridad.
Mito
Seguridad por oscuridad.
Debil contra ataques como Brute-Force, Dictionary y Crawling.
Mito
Las claves necesitan números, símbolos y mayúsculas para ser seguras.
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
Mito
Mi sitio es seguro porque usa HTTPS.
Mito
Usar un framework (o un lenguaje) hace que mi aplicación sea segura.
Mito
Usar un framework (o un lenguaje) hace que mi aplicación sea segura.
Ing. Lead Programador Senior
Data Breach Investigation Report (DBIR)
http://www.verizonenterprise.com/DBIR/
Cómo documentarse?
PCI Compliance Guide
https://www.pcicomplianceguide.org/
Cómo documentarse?
Open Web Application Security Project(OWASP)
http://owasp.org
Cómo documentarse?
OWASP Top 101. 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.
OWASP Top 101. 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.
Validación!Validación
! Validación!
1. Inyección
1. Inyección
3. XSS
No intentes sanear la data
No intentes sanear la data
No intentes sanear la data
No intentes sanear la data
8. CSRF
8. CSRF
8. CSRF
Crea un token por cada request y validalo
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)
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)
9. componentes vulnerables
Guardando información Confidencial
Disclaimer!PCI Compliance
OperadorChrome
Servidor Público
Servidor Privado
USB
Certificados
Cliente
Servidor Administrativo
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/
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
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
4. El Operador accesa el Servidor Administrativo.
OperadorServidor
Administrativo
DATA: { usuario: ******
clave: ********}
5. El Servidor Administrativo genera un token aleatorio y lo encripta usando el Certificado Público.
Servidor Administrativo
6. El Servidor Administrativo envía el token encriptado al operador.
OperadorServidor
Administrativo
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
OperadorChrome
USB
Certificados
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
9. El Operador envía el token desencriptado al Servidor Administrativo.
OperadorServidor
Administrativo
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:}
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:}
12. Chrome desencripta la información privada usando el Certificado Privado.
Chrome
13. El Operador recive la Información Privada desencriptada y realiza la transacción deseada.
OperadorChrome
Analizando vulnerabilidades
Estudiando el protocolo HTTP.
Analizando vulnerabilidades
Herramientas de prueba de vulnerabilidades.
OWASP ZAP (Open Source)
ACUNETIX(Comercial)
PhantomJS(Open Source, Manual)
Recomendaciones
● Documentarse bien sobre el tema.● Minimizar el uso de componentes externos
de poca confianza.● Usar solo los servicios necesarios.● Implementar Unit Testings.
