¿Las solicitudes GET y POST son vulnerables al ataque CSRF?

Sí, tanto GET como POST son vulnerables a CSRF.

Sin embargo, RFC 7231 declara

  

los métodos GET y HEAD NO DEBEN tener el significado de tomar   una acción distinta de la recuperación. Estos métodos deben ser considerados   "seguro".

Por lo tanto, si un sitio web cumple con el estándar y solo implementa acciones "inseguras" como POST, aquí solo las solicitudes POST son vulnerables. Sin embargo, muchos sitios web no hacen esto por todas sus acciones "inseguras"; por ejemplo, la funcionalidad de cierre de sesión a menudo se pasa por alto.

Aunque PUT es seguro sin CORS , no es el método correcto para usar aquí. Si está implementando la protección CSRF, un buen método para proteger las solicitudes XHR es agregar un encabezado como X-Requested-With para sus solicitudes y luego validar este lado del servidor de cabecera. Podría combinar esto con un valor aleatorio que esté marcado en el lado del servidor para agregar mayor protección en el caso de complementos del navegador como Flash que contiene vulnerabilidades que accidentalmente permiten el encabezado. Consulte esta respuesta y esta. .

GET y POST pueden ser vulnerables a CSRF a menos que el servidor ponga un fuerte mecanismo Anti-CSRF en su lugar, el servidor no puede confiar en el navegador para evitar las solicitudes de dominios cruzados. En cuanto a las solicitudes PUT, hay una pequeña diferencia, en teoría también es vulnerable, sin embargo, requiere que las circunstancias sean más favorables . Aquí es por qué:

Si bien las solicitudes GET y POST se pueden realizar fácilmente a través de formularios HTML, imágenes, etiquetas de script, etc., hacer una solicitud PUT es un poco más complicado, no puedes hacer una solicitud PUT sin el navegador interferir con la solicitud.

Si utiliza la API XmlHttpRequest para configurar el método de solicitud como PUT, el navegador envía primero una solicitud de 'pre-vuelo' CORS (Intercambio de origen cruzado) al servidor de destino, básicamente, solicita permiso para haga la solicitud, lo que sucede es que se hace una solicitud de OPCIONES al servidor de destino con un encabezado establecido en el Origen de la solicitud, por ejemplo: enlace (donde está alojado su script) y Método de solicitud de control de acceso y Solicitud de control de acceso -Cabezales . Si el servidor responde con Access-Control-Allow-Origin: enlace , entonces el navegador envía su solicitud hacia adelante. Por lo tanto, necesita que el servidor devuelva el valor para el encabezado de Origen como su servidor, si el Encabezado de origen se establece en '*' , las credenciales no pueden enviarse con la solicitud . No se permite realizar una solicitud PUT con credenciales (cookies) a un servidor que permite Origen: * . De enlace :

Solicitudes previamente verificadas

  

A diferencia de las solicitudes simples (explicadas anteriormente), las solicitudes "pre-iluminadas" envían primero una solicitud HTTP por el método OPTIONS al recurso en el otro dominio, para determinar si la solicitud real es segura para enviar. Las solicitudes de sitios cruzados están marcadas previamente de esta manera, ya que pueden tener implicaciones para los datos del usuario. En particular, una solicitud se marca previamente si:

     

Utiliza métodos distintos a GET, HEAD o POST. Además, si se usa POST para enviar datos de solicitud con un tipo de contenido distinto de application / x-www-form-urlencoded, multipart / form-data o text / plain, por ejemplo. Si la solicitud POST envía una carga XML al servidor utilizando application / xml o text / xml, entonces la solicitud se verifica previamente.   Establece encabezados personalizados en la solicitud (por ejemplo, la solicitud utiliza un encabezado como X-PINGOTHER)

Por lo tanto, realizar un ataque CSRF contra una página que usa PUT es un poco más difícil , ya que requiere la cooperación del servidor de destino . Sin embargo, no se debe confiar en este como un mecanismo anti-CSRF viable, ya que las peculiaridades del navegador pueden inutilizar este mecanismo de protección.

Además, en cuanto a las circunstancias que pueden hacer que la dependencia del método PUT como protección se haya resumido bien en esta respuesta: enlace

Espero que haya ayudado.

El método; es decir, poner, publicar, eliminar, solicitar, obtener, etc., el envío de datos es irrelevante. Un ataque CSRF (falsificación de solicitudes en sitios cruzados) permite que el servidor web inyecte y procese contenido no confiable.