1 / 25

Seguridad B á sica para Gadgets.

Seguridad B á sica para Gadgets. Eduardo Vela Nava hi5 Hackathon - 2008. About me. Estudio Ingenier í a en Tecnolog í as Computacionales, ITESM-CEM Trabajo en seguridad en hi5. Hobbies: Hago investigaci ó n de seguridad web. Me gusta mas javascript que Jessica Alba.

chenoa
Télécharger la présentation

Seguridad B á sica para Gadgets.

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Seguridad Básica para Gadgets. Eduardo Vela Nava hi5 Hackathon - 2008

  2. About me.. • Estudio Ingeniería en Tecnologías Computacionales, ITESM-CEM • Trabajo en seguridad en hi5. • Hobbies: • Hago investigación de seguridad web. • Me gusta mas javascript que Jessica Alba.

  3. Principales tipos de vulnerabilidades • CSRF – Cross Site Request Forgery • XSS – Cross Site Scripting • (SQLi, LDAP injection, RFI, RCE, etc..)

  4. CSRF Cross Site Request Forgery

  5. CSRF • Definición Sencilla: • Hacer que una aplicación ejecute una acción creyendo que la hizo un usuario. • Peligrosidad: • Control de una sesión de forma remota.

  6. CSRF • Vectores de ataque comunes: • <img src=http://www.ilike.com/backend?addSong=998822> • Esto agregaría a tu listado de canciones la canción con el id 998822, al momento de ver la imagen. • <img src=http://foro.com/borrar.php?foro=1> • Esto borraría el foro 1, si un administrador ve una página con ese código.

  7. Protección CSRF • Nonces • “clave” aleatoria, que solo es válida una vez. • Se debe enviar en cada petición hecha. • Se debe invalidar despues de usarse. • Ejemplo: http://hi5.com/friend/mail/deleteMail.do?msgId=1&senderId=2&offset=0&timestamp=NONCE • Mitos • Checar el “referrer” te protege de CSRF. • Recibir info por POST te protege.

  8. XSS Cross Site Scripting

  9. XSS • Definición sencilla: • Capacidad de insertar codigo de “scripting” en un sitio (javascript, vbscript, ascript). • Peligrosidad: • Robo de identidad, Acceso no autorizado a información privada, XSS Worms, Request Forgery (protegido por nonces).

  10. XSS • Vectores de ataque comunes: • <<script/src=//x.se/xm8# • <img src=javascript:alert(/xss/[-1]);> • <link rel=stylesheet href=//ha.ckers.org/xss.css> • <style>@import'//ha.ckers.org/xss.css'; • body{-moz-binding:url(url);x:expression(js)} • +ADw-script+AD4-alert(‘xss');+ADw-/script+AD4- • etc..

  11. Protección XSS • Filtrar los datos. • PHP: htmlentities($input,ENT_QUOTES); • JavaScript: function limpia(x){ return x.replace(/[\W]/,function(y){ return "&#"+y.charCodeAt(0)+";"; }); };

  12. Vulnerabilidades de diseño

  13. Vulnerabilidades de diseño • Vulnerabilidades creadas por un mal diseño de un programa, que podrían permitir el acceso a información privada. • Ejemplo • creer que lo que se encuentra en la cookie “Email” siempre será el mail de usuario.

  14. 0 confianza • No confies en lo que lees. • No confies en lo que vas a escribir. • No confies en lo que quieres modificar.

  15. ¿Qué leer? • Problema:Toda información leida desde la API de JavaScript no es de confianza, un atacante puede modificar y falsificar absolutamente todo. • Soluciones:Si necesitas guardar datos, autenticar usuarios, etc., usa un backend.

  16. ¿Qué escribir? • No escribir información privada proveniente del backend sin validar. • No escribir datos sin filtrar. function limpia(x){ return x.replace(/[\W]/,function(y){ return "&#"+y.charCodeAt(0)+";"; }); };

  17. ¿Que modificar? • Verificar que la acción la hizo el usuario voluntariamente. • Verificar que es una acción válida. • Verificar si el usuario tiene permiso de ejecutar esa acción.

  18. Uso de backends • Filtrar los datos que recibes desde tu aplicación en javascript. • No poner datos en cookies. • Monitorear abuso.

  19. Protecciones • No confiar en nada generado en el cliente. • Usar el cliente para trabajo de CPU, y usar al servidor para operaciones de CRUD y validación. • (CRUD=Crear, Leer, Actualizar y Borrar datos)

  20. FAQ

  21. FAQ • ¿Puedo asumir que los datos que van de servidor al cliente estan limpios? • NO, esto se puede atacar con ataques como cache-poisoning.

  22. FAQ • ¿Puedo asumir que un formulario para subir un archivo no fue enviado por CSRF? • NO, se puede enviar un archivo por medio de CSRF.

  23. FAQ • ¿Puedo asumir que un dato en un campo de cookies esta limpio? • NO, se pueden poner cookies por medio de ataques de CSRF.

  24. ¿Preguntas? Hack me

  25. Gracias

More Related