¿Son los servicios web JSON vulnerables a los ataques CSRF?

Estoy construyendo un servicio web que utiliza exclusivamente JSON para su contenido de solicitud y respuesta (es decir, sin cargas útiles codificadas en forma).

¿Es un servicio web vulnerable al ataque CSRF si se cumple lo siguiente?

1. Cualquier POSTsolicitud sin un objeto JSON de nivel superior, por ejemplo, {"foo":"bar"}será rechazada con un 400. Por ejemplo, una POSTsolicitud con el contenido 42sería rechazada.

2. Cualquier POSTsolicitud con un tipo de contenido diferente a application/jsonse rechazará con un 400. Por ejemplo, una POSTsolicitud con un tipo de contenido application/x-www-form-urlencodedse rechazará.

3. Todas las solicitudes GET serán seguras y, por lo tanto, no modificarán ningún dato del lado del servidor.

4. Los clientes se autentican a través de una cookie de sesión, que el servicio web les proporciona después de proporcionar un par de nombre de usuario / contraseña correcto a través de un POST con datos JSON, por ejemplo {"username":"[email protected]", "password":"my password"}.

Pregunta auxiliar: ¿Son PUTy las DELETEsolicitudes alguna vez vulnerables al CSRF? Lo pregunto porque parece que la mayoría (¿todos?) Los navegadores no permiten estos métodos en formularios HTML.

EDITAR: elemento agregado # 4.

EDITAR: Muchos buenos comentarios y respuestas hasta ahora, pero nadie ha ofrecido un ataque CSRF específico al que este servicio web sea vulnerable.

Forjar solicitudes CSRF arbitrarios con los tipos de medios arbitrarios es efectiva sólo es posible con XHR, porque un método de formulario se limita a GET y POST y un cuerpo del mensaje POST del formulario también está limitada a los tres formatos application/x-www-form-urlencoded, multipart/form-dataytext/plain . Sin embargo, con la codificación de datos del formulario text/plain, todavía es posible falsificar solicitudes que contengan datos JSON válidos .

Entonces, la única amenaza proviene de los ataques CSRF basados ​​en XHR. Y esos solo tendrán éxito si son del mismo origen, por lo que básicamente de su propio sitio de alguna manera (por ejemplo, XSS). Tenga cuidado de no confundir la desactivación de CORS (es decir, no configurar Access-Control-Allow-Origin: *) como protección. CORS simplemente evita que los clientes lean la respuesta. El servidor aún envía y procesa toda la solicitud.

Sí, es posible. Puede configurar un servidor atacante que devolverá una redirección 307 al servidor de destino a la máquina víctima. Necesita usar flash para enviar el POST en lugar de usar Form.

Referencia: https://bugzilla.mozilla.org/show_bug.cgi?id=1436241

También funciona en Chrome.

Es posible hacer CSRF en servicios Restful basados ​​en JSON usando Ajax. Probé esto en una aplicación (usando Chrome y Firefox). Debe cambiar contentType a text / plain y dataType a JSON para poder realizar una solicitud de verificación previa. Luego puede enviar la solicitud, pero para enviar datos de sesión, debe configurar el indicador withCredentials en su solicitud ajax. Discuto esto con más detalle aquí (se incluyen referencias):

http://wsecblog.blogspot.be/2016/03/csrf-with-json-post-via-ajax.html

Tengo algunas dudas sobre el punto 3. Aunque se puede considerar seguro, ya que no altera los datos del lado del servidor, los datos aún se pueden leer y el riesgo es que puedan ser robados.

http://haacked.com/archive/2008/11/20/anatomy-of-a-subtle-json-vulnerability.aspx/

¿Es un servicio web vulnerable al ataque CSRF si se cumple lo siguiente?

Si. Sigue siendo HTTP.

¿Son las solicitudes PUT y DELETE vulnerables a CSRF?

si

parece que la mayoría de los navegadores (¿todos?) no permiten estos métodos en formularios HTML

¿Crees que un navegador es la única forma de realizar una solicitud HTTP?