¿Es posible CSRF con métodos PUT o DELETE?

Question

¿Es posible CSRF con métodos PUT o DELETE? ¿O el uso de Put/Delete previene CSRF?

Answer 1

No. Confiar en un verbo HTTP no es una forma de prevenir un ataque CSRF. Todo está en la forma en que se crea su sitio. Puede usar PUT como POST y DELETE como GET, en realidad no importa.

Para evitar CSRF, tomar algunos de los pasos que se indican here:

sitios web tienen varias contramedidas CSRF disponibles:

• que requieren un secreto, símbolo específico del usuario en todos los envíos de formularios y lateral las URL de efecto previenen el CSRF; sitio del atacante no puede poner el
  correcto token en sus comunicaciones 1
• que requiere el cliente para proporcionar los datos de autenticación en la misma petición HTTP utilizado para realizar cualquier operación con seguridad implicaciones (de transferencia de dinero, etc.)
• La limitación de la tiempo de vida de las cookies de sesión Verificación de la cabecera HTTP Referer o (e)
• Comprobación de la cabecera HTTP de origen [16]
• Asegurarse de que no hay ningún archivo clientaccesspolicy.xml conceder el acceso no deseado a los controles de Silverlight [17]
• Ensuri ng que no hay ningún archivo crossdomain.xml que otorgue acceso no intencionado a las películas Flash [18]
• Verificando que el encabezado de la solicitud contenga X-Requerido-Con. Utilizado por Ruby on Rails (antes de v2.0) y Django (antes de v1.2.5). Esta protección se ha demostrado insegura [19] bajo una combinación de complementos de navegador y redireccionamientos que pueden permitir a un atacante proporcionar encabezados HTTP personalizados en una solicitud a cualquier sitio web, de ahí que permitan una solicitud falsificada.

Answer 2

En teoría no debería ser posible, ya que no hay manera de iniciar un PUT entre dominios o DELETE petición (a excepción de CORS, pero que necesita una solicitud de verificación previa y por lo tanto la cooperación del sitio de destino). En la práctica, no confiaría en eso: muchos sistemas han sido mordidos por, p. asumiendo que un ataque de carga de archivo CSRF no era posible (no debería ser así, pero ciertos errores del navegador lo hicieron posible).

Answer 3

¡Gran pregunta!

En un mundo perfecto, no puedo pensar en una forma de realizar un ataque de CSRF.

• No puede realizar solicitudes PUT o DELETE utilizando formularios HTML.
• Imágenes, etiquetas de secuencias de comandos, enlaces CSS, etc. todas envían solicitudes GET al servidor.
• Los complementos XmlHttpRequest y del navegador como Flash/Silverlight/Applets bloquearán las solicitudes entre dominios.

Por lo tanto, en general, no debería ser posible realizar un ataque CSRF a un recurso que admita los verbos PUT/DELETE.

Dicho esto, el mundo no es perfecto.Puede haber varias formas en las que este tipo de ataque puede ser posible:

1. marcos de red tales como rieles tienen soporte para "método seudo". Si coloca un campo oculto llamado _method, establece su valor en PUT o DELETE, y luego envía una solicitud GET o POST, anulará el verbo HTTP. Esta es una forma de admitir PUT o DELETE desde los formularios del navegador. Si está utilizando dicho marco, deberá protegerse de CSRF utilizando las técnicas estándar

2. Puede configurar accidentalmente encabezados de respuesta laxa para CORS en su servidor. Esto permitiría que sitios web arbitrarios realicen solicitudes PUT y DELETE.

3. En algún momento, HTML5 había planeado incluir soporte para PUT y DELETE en formularios HTML. Pero más tarde, eliminaron ese apoyo. No hay garantía de que no se agregará más tarde. Algunos navegadores pueden realmente tienen soporte para estos verbos, y eso puede funcionar en su contra.

4. Es posible que exista un error en algún complemento del navegador que podría permitir al atacante realizar solicitudes PUT/DELETE.

En resumen, recomendaría proteger sus recursos incluso si solo son compatibles con los métodos PUT y DELETE.

Answer 4

CSRF es de hecho posible con PUT y DELETE dependiendo de la configuración de su servidor.

La manera más fácil de pensar en CSRF es pensar en tener dos pestañas abiertas en su navegador, una abierta a su aplicación con su usuario autenticado y la otra pestaña abierta a un sitio web malicioso.

Si el sitio web malicioso realiza una solicitud de JavaScript a su aplicación, el navegador enviará las cookies estándar con la solicitud, permitiendo así que el sitio web malicioso 'falsifique' la solicitud utilizando la sesión ya autenticada. Ese sitio web puede hacer cualquier tipo de solicitud que desee, incluyendo GET, PUT, POST, DELETE, etc.

La forma estándar de defenderse contra el CSFR es enviar algo junto con la solicitud que el sitio web malicioso no puede conocer. Esto puede ser tan simple como el contenido de una de las cookies. Si bien la solicitud del sitio malicioso tendrá las cookies enviadas, en realidad no puede acceder a las cookies porque está siendo servida por un dominio diferente y la seguridad del navegador le impide acceder a las cookies de otro dominio.

Llamar el contenido de la cookie un 'token'. Puede enviar el token junto con las solicitudes, y en el servidor, asegúrese de que el 'token' se haya proporcionado correctamente antes de continuar con la solicitud.

La siguiente pregunta es cómo se envía ese valor con todas las diferentes solicitudes, con ELIMINAR específicamente difícil, ya que no está diseñado para tener ningún tipo de carga útil. En mi opinión, la forma más limpia es especificar un encabezado de solicitud con el token. Algo así como x-security-token = token. De esta forma, puede ver los encabezados de las solicitudes entrantes y rechazar las que faltan el token.

En el pasado, la seguridad estándar de ajax restringía lo que se podía hacer a través de ajax en el servidor malicioso, sin embargo, ahora la vulnerabilidad depende de cómo se configura el servidor en lo que respecta a las configuraciones de control de acceso. Algunas personas abren su servidor para hacer más fácil realizar llamadas de dominio cruzado o para que los usuarios creen sus propios clientes RESTful o similares, pero eso también facilita que un sitio malicioso lo aproveche a menos que los métodos de prevención de CSRF como los anteriores sean poner en su lugar.

Answer 5

Sí, CSRF es posible con los métodos PUT y DELETE, pero solo con CORS habilitado con una política no restrictiva.

no estoy de acuerdo con Sripathi Krishnan's answer:

XMLHTTPRequest navegador y plugins como Flash/Silverlight/applets bloquearán entre dominios solicita

Nada detiene el navegador de hacer una solicitud de varios dominios . El Same Origen Policy hace not evitar que se haga a request; todo lo que hace es evitar que el navegador lea la solicitud.

Si el servidor no está optando por CORS, esto hará que se realice una solicitud de verificación previa. Este es el mecanismo que evitará que se use un PUT o DELETE, porque no es una solicitud simple (el método debe ser HEAD, GET o POST). Asumiendo una política CORS correctamente bloqueada por supuesto (o ninguna en absoluto que es segura por defecto).