Re: [gente-cachirulista] Autorizando servicios rest

50 views
Skip to first unread message

Alberto Gimeno Brieba

unread,
May 3, 2013, 3:59:26 AM5/3/13
to Gente Cachirulista
Buenas,

Lo primero de todo comentar que hagas lo que hagas siempre se puede replicar automatizándolo. Mira este vídeo http://www.youtube.com/watch?feature=player_embedded&v=m_dvAI49Jn8 :D
En este caso siendo una web, se puede automatizar el acceso con selenium/phantomjs/casperjs/zombiejs,… Así que aunque tomes medidas haciendo cosas con javascript, simplemente se añade algo de complejidad, pero no afecta mucho a la dificultad para replicar un ataque.

La única forma de evitar un uso abusivo es implementando una política de "rate limiting" por usuario o por ip o por ambos, etc. Cada X peticiones en Y segundos se muestra una página de error o un captcha o fuerzas un delay en la respuesta para que el coste del ataque se haga exponencial con el paso del tiempo. Por si te sirve: un script para redis para implementar esto http://evalsha.com/scripts/71927ba3cf040801b6a3b3d7081191d403c8d110

Lo que comentas del MD5 es una buena idea, pero es la misma idea que una cookie firmada. Mira a ver si en tu framework hay algo para "signed cookies". Una cookie firmada no es más que lo que comentas: los datos de autorización del usuario, fecha, o todo lo que quieras guardar y luego un hash (mejor que sea HMAC-SHA1/256). Con el hash evitas el "cookie poisoning". La ventaja de la cookie es que probablemente te facilite más el desarrollo ya que es un "token", pero estándar.

Saludos!




2013/5/2 Raúl Truco <raul...@gmail.com>
Al hilo del post anterior sobre servicios Rest, que veo que hay mucho nivel, planteo otro tema interesante del que llevo tiempo mirando pero no doy con una solución convincente: Autorizar llamadas a rest.

En mi caso, tengo una api rest de mi base de datos (php + Slim framework) y una web que consume los datos con llamadas ajax (con framework backbonejs, muy recomendable, por cierto). La web tiene partes públicas y partes privadas, y tengo servicios públicos y privados.

Lo que me gustaría conseguir es lo siguiente:

1) Tener cierto control de quién hace las llamadas, y permitir las llamadas sólo desde el sitio web. 
Es muy fácil ver las llamadas ajax en la consola y crearte tu propia aplicación desde otro sitio web, o generar un bucle llamando a un servicio que consume muchos recursos.

2) Autorizar las llamadas a recursos privados, por ejemplo las del área privada del usuario.

Hablando con un colega me sugería un sistema de tokens, por el cual se genera un token en el servidor cada vez que se sirve una página y se inyecta en una variable javascript. El token sería un md5 del id de usuario (si está logeado), fecha/hora, un salt, etc, concatenando el id de usuario y la fecha/hora.
De esta forma en el token ya sabes el id de usuario y la fecha/hora, y te sirven para validar el token completo en cada llamada. 
El id de usuario puedes usarlo para autorizar la llamada (Resolvemos el nº 2) y con la fecha/hora caducas el token (Resolvemos el nº 1).
La verdad, me parece muy ingenioso, pero igual es rizar el rizo!!

¿Alguna idea o pensamiento?


Buf menudo rollo para mi primer post!!

Un saludo a todos,

--
Has recibido este mensaje porque estás suscrito al grupo "Gente Cachirulista" de Grupos de Google.
Para anular la suscripción a este grupo y dejar de recibir sus correos electrónicos, envía un correo electrónico a gente-cachiruli...@googlegroups.com.
Para obtener más opciones, visita https://groups.google.com/groups/opt_out.
 
 

Iván Loire

unread,
May 3, 2013, 4:56:25 AM5/3/13
to gente-cac...@googlegroups.com
No se qué pensáis vosotros pero tener un gimenete en esta lista con esta disposición para compartir conocimiento no tiene precio :D


2013/5/3 Alberto Gimeno Brieba <gime...@gmail.com>



--
ivan loire
web/software developer

Alberto Gimeno Brieba

unread,
May 3, 2013, 5:14:59 AM5/3/13
to Gente Cachirulista
Gracias Iván,

Añadiendo más información. La sugerencia de usar HMAC es para evitar un "length extension attack"




2013/5/3 Iván Loire <iv...@iloire.com>

Alberto Velaz

unread,
May 3, 2013, 6:16:48 AM5/3/13
to gente-cac...@googlegroups.com
Ya lo creo, una suerte inmensa, y no te digo si tienes a gimenete sentado en la misma mesa  ^_^

Alberto

Iván Loire

unread,
May 3, 2013, 7:25:19 AM5/3/13
to gente-cac...@googlegroups.com
i-nou-guo-iu-min-may :)


2013/5/3 Alberto Velaz <albert...@gmail.com>

Fernando Val

unread,
May 3, 2013, 8:02:27 AM5/3/13
to gente-cac...@googlegroups.com
Oztia Iván, no sabía que hablabas madarín... XD

Dani Latorre

unread,
May 3, 2013, 11:02:46 AM5/3/13
to gente-cac...@googlegroups.com
Cós! No secuestréis el hilo.

BTW http://www.youtube.com/watch?v=tsTGnneg3Gc (si es que me lo habéis puesto a huevo XD)
Daniel Latorre
My website: http://www.danilat.com/

Fernando Val

unread,
May 3, 2013, 11:25:54 AM5/3/13
to gente-cac...@googlegroups.com
Me uto collejo!... XD

Francho Joven

unread,
May 3, 2013, 1:23:04 PM5/3/13
to gente-cac...@googlegroups.com
Para los servicios privados yo hasta ahora siempre he montado un servicio de login que una vez autenticado devuelve un token asociado a una sesión del servidor y que se debe usar como semilla para "firmar" las peticiones de dichos servicios.

Las sesiones suelen tener controles de tiempo y número de peticiones, por lo que si se sobrepasan hay que volver a llamar al servicio de login y obtener otro token.

+1 a lo de la charla de REST del maestro gimenete ;)

En cuanto a lo de controlar que las peticiones solo vengan de tu web puedes implementar también controles a nivel de servidor que controlen el referer con mod-rewrite o algo similar (no es infalible, pero quita algunas moscas ;P ).
En una ocasión monté un servicio que devolvía la misma estructura de datos del servicio pero datos erroneos si el referer no era mio.

Saludos

PD: Saludicos Ivan (me autocaneo, pero no he podido resistirme ;)
FranCHo Joven    
web. http://francho.org    twitter. @francho_lab
Reply all
Reply to author
Forward
0 new messages