Miguel Ángel Arroyo Moreno                                                        Carlos García García                    ...
Algo sobre mi     Profesional desde 2001.     Experto en e-commerce: Verified By VISA,        SecureCode, etc.       OW...
Algo sobre OWASP    El proyecto abierto de seguridad en aplicaciones Web    (OWASP por sus siglas en inglés) es una comuni...
¿Para qué sirve el OWASP Top 10? La madre del cordero:    No se construyen web       seguras a menos que se       conozc...
OWASP Top 10 A1 Ataques de inyección (SQL inyection, etc) A2 Cross-Site Scripting (XSS) A3 Gestión de sesiones y ataques c...
¿Cómo se calcula el OWASP Top 10?          Threat       Attack      Weakness      Weakness                                ...
A1: Ataques de inyección  En qué consiste…  Mandar información a una aplicación y que ésta la interprete como parte de   u...
A1: Ataques de inyección                                                                                                  ...
A1: Ataques de inyección  Cómo evitarse 1. Evitar el uso de interpretes. Esto nomalmente no es posible. 2. Usar un interfa...
A2: Cross-Site Scripting (XSS)  En qué consiste…  Cuando se le devuelve a un usuario un script previamente introducido por...
A2: XSS1       Supongamos que existe un servicio de ‘buzón’ de administrador                                              ...
A2: XSS   Cómo evitarse 1. Evitar devolver los valores de entrada en la página de salida. Ni    incluir los valores recogi...
A3: Sesiones y autenticación  En qué consiste…  En obtener los datos de autenticación del usuario(LDAP) o bien su   identi...
A3: Sesiones y autenticación                                   1    Usuario envía credenciales                            ...
A3: Sesiones y autenticación correo o un                   El hacker envía un                                  1          ...
A3: Sesiones y autenticación  Cómo evitarse1. Verificar la arquitectura    • Debe ser simple, centralizada y estandarizada...
A4: Referencias inseguras a objetos  En qué consiste…  Hay que proteger el acceso a los datos. En una aplicación web esto ...
A4: Referencias inseguras a objetos                                            Como veo que unhttps://www.onlinebank.com/u...
A4: Referencias inseguras a objetos  Cómo evitarse1. Eliminar el método de acceso usando una referencia fija Se   pueden ...
A5: CSRF  En qué consiste…  Este tipo de ataque se produce cuando una web permite realizar operaciones    sensibles a usua...
A5: CSRF         El atacante almacena en ataque en una web o bien manda un     1       correo                             ...
A5: CSRF  Cómo evitarse  1. Enviar/Usar un token único que se debe enviar/recibir en     operaciones sensibles.  2. Realiz...
A6: Configuraciones de Seguridad  En qué consiste…  Si se usa una determinada API o plataforma de seguridad, es importante...
A6: Configuraciones de Seguridad                                           Knowledge Mgmt                                 ...
A6: Configuraciones de Seguridad  Cómo evitarse  1. Más formación y conocimiento en los sistemas de seguridad  2. Revision...
A7: Restricción de acceso a URLs  En qué consiste…  ¿Cómo se protege el acceso a determinadas URLs/páginas? Es importante ...
A7: Restricción de acceso a URLs                                              Me doy cuenta que parte dehttps://www.online...
A7: Restricción de acceso a URLs  Cómo evitarse  1. Verificar la arquitectura de seguridad  2. Verificar que cada URL está...
A8: Redirects and forwards inválidos  En qué consiste…  Es relativamente común la práctica de redireccionar a otra página ...
A8: Redirects and forwards inválidos               1   El atacante envía el ataque via email o link                     Fr...
A8: Redirects and forwards inválidos  Cómo evitarse  1. Evitar usar redirects y forwards  2. Si se usan, no usar parámetro...
A9: Almacenamiento criptográfico inseguro  En qué consiste…  Esto ocurre en las siguientes situaciones:  1. No se identifi...
A9: Almacenamiento criptográfico inseguro                   La víctima introduce              1    su PAN para comprar    ...
A9: Almacenamiento criptográfico inseguro  Como evitarlo  1. Verificar la Arquitectura:      a) Identificar qué se debe pr...
A10: Insuficiente protección de comunicaciones  En qué consiste…  Esto ocurre en las siguientes situaciones:  1. No se ide...
A10: Insuficiente protección de comunicaciones                                                          ClientesVictima   ...
A10: Insuficiente protección de comunicaciones  Como evitarlo  1. Verificar la Arquitectura:      a) Identificar qué se de...
Upcoming SlideShare
Loading in...5
×

Hacklab cordoba owasp-top10

1,018

Published on

Presentación realizada en el HackLab Cordoba 2011. No pude hacerla entera....

Published in: Education
1 Comment
3 Likes
Statistics
Notes
No Downloads
Views
Total Views
1,018
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
0
Comments
1
Likes
3
Embeds 0
No embeds

No notes for slide
  • javascript:void prompt("Introduce la cookie:",document.cookie).replace(/[^;]+/g,function(_){document.cookie=_;});
  • Transcript of "Hacklab cordoba owasp-top10"

    1. 1. Miguel Ángel Arroyo Moreno Carlos García García Juan José Rider JiménezI Hacklab en Córdoba · www.hacklabcordoba.com
    2. 2. Algo sobre mi  Profesional desde 2001.  Experto en e-commerce: Verified By VISA, SecureCode, etc.  OWASP member desde 2010. Miembro del Spain Chapter.  Fundador empresa www.wul4.es  Twitter: @jjriderWul4  Email: jjrider@wul4.es / juan.rider@owasp.org2
    3. 3. Algo sobre OWASP El proyecto abierto de seguridad en aplicaciones Web (OWASP por sus siglas en inglés) es una comunidad abierta y libre de nivel mundial enfocada en mejorar la seguridad en las aplicaciones de software. Nuestra misión es hacer la seguridad en aplicaciones "visible", de manera que las organizaciones pueden tomar decisiones sobre los riesgos en la seguridad de aplicaciones. Todo el mundo es libre de participar en OWASP y todos los materiales están disponibles bajo una licencia de software libre y abierto. http://www.owasp.org3
    4. 4. ¿Para qué sirve el OWASP Top 10? La madre del cordero:  No se construyen web seguras a menos que se conozca cómo atacarlas El Problema:  Para el 99% de los desarrolladores los tests de seguridad son un arte oscuro La solución?  Formación básica y conocimiento de posibles ataques
    5. 5. OWASP Top 10 A1 Ataques de inyección (SQL inyection, etc) A2 Cross-Site Scripting (XSS) A3 Gestión de sesiones y ataques contra la autenticaciónA4 Exposición de referencias a objetos de forma directa = A5 Cross-Site Request Forgery (CSRF) =A6 Errores de configuración de la seguridad NEW A7 Errores al restringir accesos a URLsA8 Redirects y Forwards no validados NEWA9 Almacenamiento criptográfico inseguroA10 Comunicaciones inseguras
    6. 6. ¿Cómo se calcula el OWASP Top 10? Threat Attack Weakness Weakness Technical Impact Business Impact Agent Vector Prevalence Detectability 1 Easy Widespread Easy Severe ? 2 Average Common Average Moderate ? 3 Difficult Uncommon Difficult Minor 1 2 2 1 A1-Inyección 1.66 * 16 1.66 weighted risk rating
    7. 7. A1: Ataques de inyección En qué consiste… Mandar información a una aplicación y que ésta la interprete como parte de un comando, ya sea SQL, de sistema, LDAP, etc. Campos de acción Casi cualquiera que imaginemos… SQL, LDAP, XPath, ORM(Hibernate, etc), OS, etc. Impacto Severo. En el caso de PCI tenemos que tener especial cuidado en el acceso a los datos y en el control de acceso a las aplicaciones que muestran datos de tarjeta.
    8. 8. A1: Ataques de inyección "SELECT * FROM Account Summary accounts WHERE Account: Knowledge Mgmt Communication Administration Bus. Functions Legacy Systems Human ResrcsApplication Layer E-Commerce Transactions Web Services acct=‘’ OR 1=1-- SKU:: Directories Accounts Acct:5424-6066-2134-4334 Databases Finance HTTP Billing HTTP SQL DB Table Acct:4128-7574-3921-0192 response  ’" request query Acct:5424-9383-2039-4029  APPLICATION   Acct:4128-0004-1234-0293  ATTACK  Custom Code 1. Se presenta un formulario al atacante 2. Se envía el ataque enviando datos ‘no-esperados’ App Server 3. La aplicación reenvia esos Web Server datos embedidos en una SQL Hardened OSNetwork Layer 4. La BD ejecuta la query y devuelve todos los datos a la aplicación Firewall Firewall 5. La aplicación toma los datos y se los devuelve al atacante
    9. 9. A1: Ataques de inyección Cómo evitarse 1. Evitar el uso de interpretes. Esto nomalmente no es posible. 2. Usar un interfaz para acceder a estos interpretes que permita el ‘binding’ de estos valores. Ej: PreparedStatements o Stored Procedures. 3. Codificar/Validar todas las entradas antes de pasarlas al intérprete. • Uso de ‘listas blancas’ • Limitar privilegios de acceso a los datos(Usuario de BD) • ESAPI.Encoder Solución: Uso de filtros HTTP de validación en base a Patrones y PreparedStatements. Más info: http://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet
    10. 10. A2: Cross-Site Scripting (XSS) En qué consiste… Cuando se le devuelve a un usuario un script previamente introducido por un atacante. El usuario ‘confia’ en el portal. Campos de acción En aplicaciones donde lo que uno escribe/envía, otro lo recibe, etc. Varios tipos: 1. Directo(El script puede encontrarse en BD) 2. Indirecto o reflejado (La web usa un parámetro de entrada en la respuesta) 3. XST(Cross Site Tracing) que usa el método TRACE de HTTP para obtener las credenciales de usuario ‘Basic-Auth’ Impacto Severo. Desde obtener el identificador de sesión y reenviarlo de forma silenciosa a un atacante como instalar un proxy en el navegador para observar todo el tráfico.
    11. 11. A2: XSS1 Supongamos que existe un servicio de ‘buzón’ de administrador Aplicación con vulnerabilidad XSS El atacante envia el script en el mensaje que se almacena en BD Communication Administration Bus. Functions E-Commerce Transactions Knowledge Accounts 2 El administrador visualiza el mensaje Finance Mgmt Custom Code El script se interpreta con los privilegios y permisos del administrador 3 El Script envía la cookie de sesión al atacante
    12. 12. A2: XSS Cómo evitarse 1. Evitar devolver los valores de entrada en la página de salida. Ni incluir los valores recogidos.(esto es imposible en muchos casos) 2. Escaneos periódicos 3. Para defendernos, codificar/validar todas las entradas de usuario usando listas blancas, ESAPI, y en el caso de tener que incluir grandes cantidades de HTML, usar AntiSamy. http://www.owasp.org/index.php/ESAPI http://www.owasp.org/index.php/AntiSamy Solución: Uso de validaciones en base a Patrones. Uso de librerias de OWASP ESAPI y AntiSamy String safe = ESAPI.encoder().encodeForJavaScript( request.getParameter( "input" ) ); Más info: http://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_S heet
    13. 13. A3: Sesiones y autenticación En qué consiste… En obtener los datos de autenticación del usuario(LDAP) o bien su identificador de sesión(JSESSIONID) Cómo se obtienen 1. HTTP es un protocolo sin-estado. Las credenciales viajan en TODA petición.  Se debe usar protocolo seguro siempre que se envíen. 2. Accediendo a logs que contienen el identificador de sesión.  El identificador de sesión NO debe almacenarse en logs, ni usar reescritura de URLs… 3. Ataques de ‘session fixation’  Si un ID de sesión no es válido, no darle validez 4. Mediante sistemas de autologin, remember-me, recordatorios de password con email, etc. 5. Obtener las sesiones persistentes  Destruir la sesión y tiempos de vida cortos(15minutos) Impacto Severo. Apropiación indebida de los privilegios de usuario.
    14. 14. A3: Sesiones y autenticación 1 Usuario envía credenciales Administration Communicatio Bus. Functions www.boi.com?JSESSIONID=9FA1DB9EA... Transactions E-Commerce Knowledge Accounts Finance Mgmt n Aplicación usa reescritura de 2 URLs Custom Code 3 El usuario cierra el browser y deja su PC5 El hacker usa el id de 4 El hacker accede al PC y busca sesión y toma el control en el historico de navegación de la sesión
    15. 15. A3: Sesiones y autenticación correo o un El hacker envía un 1 link a un usuario registrado con un id de session generado por élwww.boi.com?JSESSIONID=9FA1DB9EA... El usuario accede a la aplicación y se autentica 2 Knowledge Mgmt Communication Administration Bus. Functions Transactions E-Commerce Accounts Finance La aplicación admite el id de sesión porque cumple sus patrones 3 Custom Code Aplicación usa reescritura d URLs 4 El hacker usa el id de sesión y toma el control de la sesión
    16. 16. A3: Sesiones y autenticación Cómo evitarse1. Verificar la arquitectura • Debe ser simple, centralizada y estandarizada (Ej. LDAP) • Asegurarse que tanto el id de sesión como las credenciales siempre viajan seguras2. Verificar la implementación • Examinar todas las funciones de creación/destrucción de sesiones y comprobación de usuario. • Verificar que el logout destruye la sesión3. Escaneos periódicosSolución: Muchas opciones.
    17. 17. A4: Referencias inseguras a objetos En qué consiste… Hay que proteger el acceso a los datos. En una aplicación web esto implica acceso a opciones de menú, URLs, etc. Esto está en consonancia con el 6.5.7. The ‘schoolboy mistake’ • Ocultar las referencias en campos hidden. • Sólo mostrar los objetos a los que tiene acceso el usuario(menús, botones, etc) • Realizar comprobaciones en el cliente …. Y luego no hacerlo en el servidor • Usar un valor de un parámetro (lista de valores) para acceder a una funcionalidad. Aplicaciones vulnerables Aquellas que reciben como parámetro el procedimiento remoto a ejecutar…. Impacto Implica ciertos conocimientos de la aplicación a atacar. Acceso no autorizado a datos/operaciones.
    18. 18. A4: Referencias inseguras a objetos Como veo que unhttps://www.onlinebank.com/user?acct=6065 campo es el ‘acct’ con valor 6065… pruebo el 6066 Y bingo! Ya tengo acceso a otra cuenta.
    19. 19. A4: Referencias inseguras a objetos Cómo evitarse1. Eliminar el método de acceso usando una referencia fija Se pueden usar referencias ‘temporales’(ESAPI proporciona esa funcionalidad)2. Validar la referencia al objeto • Validar el formato de la referencia • comprobar que el usuario realmente tiene privilegios(filtros, Spring Security, etc)3. Cuidado con sistemas REST
    20. 20. A5: CSRF En qué consiste… Este tipo de ataque se produce cuando una web permite realizar operaciones sensibles a usuarios sin un rigor adecuado. A diferencia del XSS aquí quien confía es la web en el usuario y no el usuario en la web. La base del problema • Los navegadores incluyen las credenciales en cada petición. ¿Qué ocurre si en una web maligna se hace referencia a un contenido u operación de una aplicación que admite CSRF? • Así, TODAS las aplicaciones que dejan la autenticación/autorización únicamente en el sistema de credenciales del contenedor(Cookies de sesión, Basic-Auth, IP, Certificado X.509 de cliente, usuario de Dominio…) son VULNERABLES. Impacto Aunque en general todas las aplicaciones son vulnerables, es dificil explotar dicha vulnerabilidad porque implica un conocimiento profundo de la aplicación atacada.
    21. 21. A5: CSRF El atacante almacena en ataque en una web o bien manda un 1 correo Aplicación vulnerable Un tag ‘<img ..>’ a CSRF contiene el ataque Administration Communicatio Bus. Functions Transactions E-Commerce n nowledge Accounts Finance Mgmt Mientras ve el portal del atacante, la victima 2 K se loguea sin saberlo en la aplicación Custom Code 3 La aplicación cree que El tag ‘<img’ cargado es una solicitud de un por el browser de la usuario legítimo y victima le lleva a la realiza la operación aplicación y usa sus credenciales precargadas
    22. 22. A5: CSRF Cómo evitarse 1. Enviar/Usar un token único que se debe enviar/recibir en operaciones sensibles. 2. Realizar una segunda autenticación para determinadas operaciones. 3. Sistemas CAPTCHA Qué NO VALE 1. Sólo admitir peticiones por POST 2. Reescritura de URLs Más info www.owasp.org/index.php/CSRF_Prevention_Cheat_Sheet
    23. 23. A6: Configuraciones de Seguridad En qué consiste… Si se usa una determinada API o plataforma de seguridad, es importante que se configure adecuadamente. Ejemplos de frameworks de seguridad: Spring Security, HDIV, ESAPI, JASS, Jguard, etc. Incluso las propias. También se engloban aquí las APIs criptográficas: BouncyCastle, JSSE, XML Signature, etc…. La base del problema • El código fuente no es un secreto. • La configuración de la seguridad es distinta dependiendo del entorno. • Desarrollo de ‘puertas traseras’ para pruebas que pasan a REAL • Falta de actualización/control de las librerias de seguridad • Presencia de cuentas por defecto, etc Impacto El atacante debe ser un poco friki(pero los hay). El atacante puede, al tener acceso, incorporar scripts XSS, obtener datos de usuarios, cuentas, etc.
    24. 24. A6: Configuraciones de Seguridad Knowledge Mgmt Communication Administration Bus. Functions E-Commerce Transactions Accounts Finance Database Custom Code App Configuration Development Framework App Server QA Servers Web Server Hardened OS Atacante Test Servers Source Control
    25. 25. A6: Configuraciones de Seguridad Cómo evitarse 1. Más formación y conocimiento en los sistemas de seguridad 2. Revisiones de código: también la configuración de la seguridad 3. Verificar periódicamente que no la API está libre de bugs de seguridad 4. Tener una arquitectura de seguridad debidamente documentada Qué NO VALEperiódicos de AppScan 5. Escaneos 1. Dar por hecho que el framework lo hace todo 2. Dar por hecho que la configuración es adecuada Más info Ver cada API/Librería
    26. 26. A7: Restricción de acceso a URLs En qué consiste… ¿Cómo se protege el acceso a determinadas URLs/páginas? Es importante entender que aquí no se trata de proteger la aplicación como un todo, sino que usuarios con un determinado nivel de acceso no accedan a páginas administrativas . The ‘schoolboy mistake’ • Mostrar sólo los menús o links a los que tiene acceso el usuario en cuestión Impacto Es relativamente fácil el realizar estos ataques. El atacante puede visualizar información de otros usuarios o realizar acciones para las que no deberia tener permiso.
    27. 27. A7: Restricción de acceso a URLs Me doy cuenta que parte dehttps://www.onlinebank.com/user/getAccounts la URL es el rol /user/getAccounts Modifico la URL para ver si funciona /admin/getAccounts, or /manager/getAccounts Si funciona…soy administrador
    28. 28. A7: Restricción de acceso a URLs Cómo evitarse 1. Verificar la arquitectura de seguridad 2. Verificar que cada URL está protegida por un filtro (ya sea en el web.xml o producto /API) o bien introducir chequeos en el propio código(comprobación de roles y permisos) mediante sistemas como Spring Security, ESAPI, etc. 3. Usar sistemas/frameworks que controlen esta funcionalidad 4. Hacer hacking ético (WebScarab por ejemplo) para forzar/testar este tipo de intrusiones. 5. Escaneos periódicos 6. Toda aplicación debe cumplir: a) Restringir acceso sólo a usuarios autenticados b) Chequear el acceso en base al rol del usuario c) Deshabilitar acceso a ficheros protegidos o de configuración
    29. 29. A8: Redirects and forwards inválidos En qué consiste… Es relativamente común la práctica de redireccionar a otra página e incluso incorporar parámetros en la URL. Si no se chequean esos parámetros, el atacante podria reenviar al usuario a una página o portal malicioso. El caso de los forwards es similar. Consisten en enviar la misma petición a otra página(habitualmente de la misma aplicación). Si la página a realizarse el forward es un parámetro o similar, se podría saltar el control de autenticación o autorización. The ‘schoolboy mistake’ • No validar los parámetros que pueden usarse al abrir una ventana o realizar un forward. Importante…. NO VALE CON COMPROBAR EN EL CLIENTE. • IMPORTANTE: ESTO NO ES PISHING Impacto Es complicado el llevar a cabo estos ataques porque no todas las aplicaciones usan estos métodos.
    30. 30. A8: Redirects and forwards inválidos 1 El atacante envía el ataque via email o link From: Tu Banco(o tu mujer) Subject: Te ha tocado un premio Enhorabuena, pincha aqui, 3 La aplicación redirige inconsciente de la vida! a la víctima al portal fraudulento Knowledge Mgmt Communication Administration Bus. Functions Transactions E-Commerce Accounts Finance La victima pincha en el ink que le lleva a la 2 página del banco…(con un regalo) Custom Code LA petición viaja a la aplicación vulnerable, que usa el parámetro mal formado para reenviar al usuario a la url incorrecta Evil Site 4 El atacante instala softwarehttp://www.irs.gov/taxrefund/claim.jsp?year= en el PC del usuario o le 2006&… &dest=www.evilsite.com solicita información
    31. 31. A8: Redirects and forwards inválidos Cómo evitarse 1. Evitar usar redirects y forwards 2. Si se usan, no usar parámetros como parte de la URL 3. Si se deben usar, validar que cada parámetro es válido y está autorizado para el usuario o bien ‘mapear’ la petición en el servidor con la URL en cuestión. 4. Hacer hacking ético (WebScarab por ejemplo) para forzar/testar este tipo de intrusiones. 5. Escaneos periódicos 6. ESAPI proporciona métodos seguros de redirects y forwards. Ver: SecurityWrapperResponse.sendRedirect( URL ) http://owasp-esapi-java.googlecode.com/svn/trunk_doc/org/owasp/esapi/filters/ SecurityWrapperResponse.html#sendRedirect(java.lang.String)
    32. 32. A9: Almacenamiento criptográfico inseguro En qué consiste… Esto ocurre en las siguientes situaciones: 1. No se identifica adecuadamente qué información se debe proteger. 2. No se conoce adecuadamente donde se almacena dicha información(BD, ficheros, backups, etc) 3. No se encripta la información de forma adecuada(criptografía insegura, claves criptográficas comprometidas, etc) 4. No se tiene una política de destrucción de los datos cifrados ni renovación de las claves de cifrado The ‘schoolboy mistake’ • Usar algoritmos de criptografía ‘debiles’. Ej: DES • Almacenar las claves de cifrado de forma insegura o directamente en claro. Impacto Es dificil que se produzca esta situación. Pérdida de credibilidad de toda la compañia.
    33. 33. A9: Almacenamiento criptográfico inseguro La víctima introduce 1 su PAN para comprar Bus. Functions Administration Communicatio Transactions E-Commerce Knowledge Accounts Finance Mgmt n Custom Code El atacante recopila Log files 4 los logs y roba 4 La aplicación guarda en 2 millones de los logs el PAN pq lo tarjetas necesita luego Las trazas están 3 accesibles a todos los operadores, uno de ellos, becario, pasando una mala racha
    34. 34. A9: Almacenamiento criptográfico inseguro Como evitarlo 1. Verificar la Arquitectura: a) Identificar qué se debe proteger. b) Identificar dónde se almacena(BD, ficheros, backups, etc) c) No se encripta la información de forma adecuada(criptografía insegura, claves criptográficas comprometidas, etc) d) No se tiene una política de destrucción de los datos cifrados ni renovación de las claves de cifrado 2. Usar mecanismos de encriptación adecuados. Posibilidades: a) Ficheros completos b) Base de Datos c) Elemento en cuestión 3. Usar los mecanismos correctamente: a) Strong cryptography (Preferiblemente, un HSM) b) Proteger las claves(generación, uso y destrucción)  HSM c) Tener planificado un posible cambio de claves(incluso en caso de urgencia) 4. Verificar la implementación(código, librerias, etc)
    35. 35. A10: Insuficiente protección de comunicaciones En qué consiste… Esto ocurre en las siguientes situaciones: 1. No se identifica adecuadamente qué información a enviar/recibir se debe proteger(identificadores de clientes, tarjetas, etc) 2. No se conoce adecuadamente donde se envía dicha información(BD, clientes, servicios web o procesos remotos internos) 3. No se utilizan métodos adecuados para proteger las comunicaciones 4. A veces, el problema es el cliente (proxy) The ‘schoolboy mistake’ • Se encriptan con HTTPS la navegación, pero es posible también hacerlo por HTTP o bien se envían las credenciales de usuario por email ordinario Impacto Es ciertamente dificil que se produzca este ataque(Man in the middle) Pérdida de credibilidad de toda la compañia.
    36. 36. A10: Insuficiente protección de comunicaciones ClientesVictima Custom Code Backend Systems Empleados 1 2 Se capturan Se capturan credenciales y credenciales y datos datos que viajanDesde el por la redexterior.. Desde el interna interior…
    37. 37. A10: Insuficiente protección de comunicaciones Como evitarlo 1. Verificar la Arquitectura: a) Identificar qué se debe proteger. b) Identificar dónde se almacena(BD, ficheros, backups, etc) c) No se encripta la información de forma adecuada(criptografía insegura, claves criptográficas comprometidas, etc) d) No se tiene una política de destrucción de los datos cifrados ni renovación de las claves de cifrado 2. Usar mecanismos de encriptación adecuados. Posibilidades: a) Ficheros completos b) Base de Datos c) Elemento en cuestión 3. Usar los mecanismos correctamente: a) Strong cryptography (Preferiblemente, un HSM) b) Proteger las claves(generación, uso y destrucción)  HSM c) Tener planificado un posible cambio de claves(incluso en caso de urgencia) 4. Verificar la implementación(código, librerias, etc)

    ×