seguridad b á sica para gadgets
DESCRIPTION
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. - PowerPoint PPT PresentationTRANSCRIPT
Seguridad Básica para Gadgets.
Eduardo Vela Nava
hi5 Hackathon - 2008
About me..
Estudio Ingeniería en Tecnologías Computacionales, ITESM-CEMTrabajo en seguridad en hi5.Hobbies: Hago investigación de seguridad web.
Me gusta mas javascript que Jessica Alba.
Principales tipos de vulnerabilidades
CSRF – Cross Site Request Forgery
XSS – Cross Site Scripting
(SQLi, LDAP injection, RFI, RCE, etc..)
CSRF
Cross Site Request Forgery
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.
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.
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×tamp=NONCE
Mitos Checar el “referrer” te protege de CSRF. Recibir info por POST te protege.
XSS
Cross Site Scripting
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).
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..
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)+";";
});
};
Vulnerabilidades de diseño
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.
0 confianza
No confies en lo que lees.
No confies en lo que vas a escribir.
No confies en lo que quieres modificar.
¿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.
¿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)+";";
});
};
¿Que modificar?
1. Verificar que la acción la hizo el usuario voluntariamente.
2. Verificar que es una acción válida.
3. Verificar si el usuario tiene permiso de ejecutar esa acción.
Uso de backends
Filtrar los datos que recibes desde tu aplicación en javascript.
No poner datos en cookies.
Monitorear abuso.
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)
FAQ
FAQ
1. ¿Puedo asumir que los datos que van de servidor al cliente estan limpios?
NO, esto se puede atacar con ataques como cache-poisoning.
FAQ
2. ¿Puedo asumir que un formulario para subir un archivo no fue enviado por CSRF?
NO, se puede enviar un archivo por medio de CSRF.
FAQ
3. ¿Puedo asumir que un dato en un campo de cookies esta limpio?
NO, se pueden poner cookies por medio de ataques de CSRF.
¿Preguntas?
Hack me
Gracias