¿Cómo proteger a un consumidor de OpenID contra el abuso?

Question

Considero OpenID como un método de inicio de sesión para mi aplicación PHP, pero hay una cosa que me impide continuar: ¿cómo puedo proteger a un consumidor de OpenID contra el abuso?

An example of abusing OpenID by using a consumer as proxy

abuso incluye inundar otros servidores de solicitudes, utilizando mi aplicación como un proxy, pasando una descarga grande como URL o innecesariamente ralentizar el servidor haciendo un montón solicitudes.

Supongo que debería implementar la limitación de velocidad en las solicitudes, pero ¿cómo se supone que voy a hacer eso? Los posibles atacantes podrían usar otros proxies o TOR para eludir las comprobaciones de IP. Limitar los proveedores que están permitidos estaría en contra de los principios de OpenID ¿verdad?

No espero que mis usuarios sean malvados, pero me gustaría saber qué cosas debo tener en cuenta antes de agregar otro posible vector de ataque.

En caso de que importe, estoy a punto de usar lightopenid como back-end para la aplicación PHP.

Answer 1

Necesita separar los ataques en dos grupos. 1) Ataques contra su propio sitio, y 2) Ataques contra alguien que lo use como proxy. Ninguno de estos problemas es nuevo o exclusivo de OpenID. Por ejemplo, los correos electrónicos clásicos "cuéntele a un amigo" se pueden automatizar para enviar correos electrónicos no deseados desde la dirección IP y el correo electrónico del tercero, protegiendo a la parte no solicitada de las consecuencias y proporcionándole un IP/correo electrónico (potencialmente) limpio que no sea ya marcado por la protección contra correo no deseado. Esto se trató principalmente con el "CAPTCHA" para evitar el uso automatizado del formulario.

Para ataques contra su propio sitio, esto ha sido cubierto innumerables veces antes. Intente aquí: protect your self against DOS attacks

Para los ataques contra el sitio de otra persona, muchos de los mismos principios se aplican como se menciona en esa otra pregunta. Acelere las solicitudes de autenticación, rechace solicitudes irrazonables o malformadas, verifique el encabezado Content-Length contra el contenido en POST y, por supuesto, siempre puede agregar el clásico "CAPTCHA" para ayudar a prevenir ataques automatizados con su consumidor OpenID.

También contrariamente a otras sugerencias aquí, no aceleraría en función del TLD de OpenID, sino más bien de la dirección IP de la parte solicitante. Sí, las personas pueden alquilar direcciones IP proxy, pero no se puede acelerar de forma justa en función del TLD, ya que la base de usuarios de cada proveedor de OpenID variará mucho.También puede comprar una base de datos de direcciones IP proxy conocidas de una empresa como MaxMind. Si el usuario proviene de una IP proxy, aumente la agresividad de su aceleración.

Answer 2

Desacelera las solicitudes proporcionalmente a la cantidad de veces que se ha solicitado un determinado dominio.

Por ejemplo, supongamos que alguien trata de usar para el servidor DOS example.com solicitando muchas URL como http://example.com/foo, http://example.com/bar, http://example.com/foobar120382. Considere todas estas solicitudes como solicitudes para example.com y ejecute la primera solicitud sin demora. Demora 2 segundos antes de realizar la siguiente solicitud, demora 4 segundos antes de realizar la tercera solicitud, demora 8 segundos antes de realizar la cuarta solicitud, 16 antes de la quinta, y así sucesivamente.

Estos pequeños retrasos son prácticamente desconocidos por los usuarios humanos, pero reducirán en gran medida la capacidad de su servidor para actuar como un proxy DOSsing. Solo piense que la solicitud número 12 será bloqueada por más de una hora (si usa potencias de dos).

Obviamente, también debe crear algún tipo de lista blanca o gris para los proveedores grandes de OpenID como Google o myOpenID. Esos dominios probablemente se soliciten con mucha frecuencia.

Answer 3

Haría algo más simple. Limite los puntos finales OpenID a un conjunto limitado de confiables: Google, WordPress, myopenid, yahoo. Probablemente cubrirá a la mayoría de los usuarios y no permitirá que los bots hagan que su sitio genere tráfico a sitios aleatorios.