2. Eduardo Castellanos 3 años de experiencia en desarrollo 3 años de experiencia en seguridad Analista de seguridadpara Verizon Business Security Solutions A través de SISAP Asociado de (ISC)² orientado a CISSP Miembro del capítulo de OWASP Guatemala
3. Su “perímetro” de seguridadtienegrandesagujeros en la capa de aplicaciones |3 Código de AplicaciónElaborado a la Medida Capa de Aplicaciones Bases de datis Legacy Systems Servicios Web Directorios RRHH Cobros ATAQUE A LA APLICACIÓN Servidor de App Servidor Web SO Endurecido Capa de Red Firewall Firewall No se puedenutilizarmecanismos de protección de red paradetener o detetctarattaques de la capa de aplicación
6. Ejemplo: ataque de inyección SQL Select user_informationfrom user_tablewhere username='input username'and password='input password' Select user_informationfrom user_tablewhere username= '' or 1=1 -- ' and password='abc'
7. ¿Comodo? Marzo 2011 Un hacker usó inyección SQL para entrar a un sistema de un afiliado de Comodo. Comodo es un CA. Ellos firman certificados SSL para garantizar la seguridad de las comunicaciones. Resultado El hacker obtuvo las credenciales paraentrar a los sistemas para generar certificados. Generó certificados para mail.google.com, www.google.com, login.yahoo.com, login.skype.com, addons.mozilla.org y login.live.com
8. A1 – Evitando la Inyección Recomendaciones Evitarusar un interprete, o Usarunainterfazquepermitaatar (bind) variables (e.g., prepared statements, o stored procedures) Codificartodaslasentradas del usuario antes de pasarlas al interprete. Referencias SQLi Prevention Cheat Sheet http://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet
10. XSS = Cross-site Scripting Vulnerabilidad de las aplicaciones web Permite la inyección de código en páginas que serán vistas por otros usuarios XSS = el nuevo buffer overflow Javascript = el nuevo Shell Code
11. Samy Worm 11 Primer Worm de XSS EscritoporSamyKamkar Afectó a MySpace.com En menos de 20 horasafectó a más de 1 millón de usuarios
17. A3 – Evitando la Pérdida de Autenticación y Gestión de Sesiones Verificar la arquitectura La autenticacióndebe ser simple, centralizada y estandarizada. Use el identificador de sesiónproporcionadopor el contenedor Aseguresequelascredenciales y el identificador de sesiónestanprotegidos con SSL todo el tiempo. Verificar la implementación Verificarque el cierre de sesión la destruya. Verificarlasfunciones de autenticación Authentication Cheat Sheet http://www.owasp.org/index.php/Authentication_Cheat_Sheet
19. Ejemplo:ReferenciaDirectaInsegura a Objetos El atacante se dacuentaque el identificador de sucuentaes 6534 ?acct=6534 Lo cambia a un numero similar… ?acct=6535 El atacantepuedever la información de la víctima https://www.onlinebank.com/user?acct=6534
25. Ejemplo: CSRF El atacantearmaunatrampa en algun website en Internet Aplicación con vulnerabilidad CSRF Unaetiqueta <img> contiene el ataque contra el sitio vulnerable Mientrasesta en unasesión en el sitio vulnerable, la víctimavisita el sitiomalo El sitio vulnerable miraunapetición vulnerable de la víctima y ejecuta la acciónsolicitada <imgsrc=http://bank.com/transferir?cuenta=2323&cantidad=10000&dest=4444 />
26.
27.
28. Defectos en la Configuración de Seguridad BD Finance Transactions Accounts Administration Communication Knowledge Mgmt E-Commerce Bus. Functions Custom Code App Configuration Development Framework App Server QA Servers Web Server Hardened OS Atacante Test Servers Source Control
39. Ejemplo de Falla de Restricción de Acceso a URL El atacante se dacuentaque el URL define surol /user/getAccounts Lo cambia a otrodirectorio (rol) /admin/getAccounts, o /manager/getAccounts El atacantemiralascuentas de otrosusuarios
42. A9 – EvitandoProtecciónInsuficiente en la Capa de Transporte Proteger con mecanismosadecuados Usar TLS en todaslasconexiones con información sensible Cifrarmensajesprevio a sutransmisión Usar los mecanismosadecuadamente No usarcifrados SSL obsoletos Atributo Secure de las cookies Gestionarlasllaves/certificadosadecuadamente Usarmecanismoscomprobados Cheat Sheet: http://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet
45. A10 – EvitandoRedirecciones y Reenvíos No Validados Variasopciones Evitarusarlos No usarparámetrosparadeterminar el URL Si ‘debe’ tenerparametros Validarquecadaparámetro sea válido. (preferido) – Usar un mapeo del lado del servidor ESAPI Ver: SecurityWrapperResponse.sendRedirect( URL ) http://owasp-esapi-java.googlecode.com/svn/trunk_doc/org/owasp/esapi/filters/SecurityWrapperResponse.html#sendRedirect(java.lang.String)
46. Resumen: ¿Cómoatacarestosproblemas? Desarrollarcódigoseguro Seguirlasmejoresprácticasdefinidas en OWASP’s Guide to Building Secure Web Applications http://www.owasp.org/index.php/Guide Usar OWASP’s Application Security Verification Standard http://www.owasp.org/index.php/ASVS Usarcomponentes de seguridad Usar OWASP’s ESAPI como la base paraSUScomponentes http://www.owasp.org/index.php/ESAPI Revisarlasaplicaciones Que un equipo de expertos revise susaplicaciones Revise susaplicacionesporsimismousandoguías OWASP OWASP Code Review Guide: http://www.owasp.org/index.php/Code_Review_Guide OWASP Testing Guide: http://www.owasp.org/index.php/Testing_Guide
