¿Debo evitar el envío de solicitudes GET para las URL que normalmente se utilizan con la solicitud POST?

Si la transacción tiene efectos secundarios, sí, debe configurar su servidor web para que no procese esas solicitudes GET. No debe permitir que ninguna solicitud GET cause efectos secundarios en su servidor.

No puedo señalar ningún ataque en particular que necesariamente le cause problemas, pero existen vulnerabilidades sutiles si permite que el procesamiento de una solicitud GET cause efectos secundarios, por lo tanto, si permite que las solicitudes GET tengan efectos secundarios, estamos empezando a bordear el territorio de "hay dragones". Por ejemplo, conozco un ataque sutil en sitios que usan el encabezado del Referer para defenderse de los ataques CSRF y que permiten que las solicitudes GET tengan efectos secundarios. Los navegadores no han implementado soluciones para detener ese ataque porque la reacción es "duh, no se supone que las solicitudes GET tengan efectos secundarios, por lo que es culpa del sitio web". Así que en lugar de ingresar a un territorio potencialmente peligroso, le sugiero que configure su servidor web para que solo procese esas solicitudes a través de POST, no a través de GET.

Hay varias razones para usar POST:

1. El navegador advierte sobre la reenvío.
2. El tamaño del contenido no está restringido
3. La carga de archivos solo funciona mediante POST
4. Algunos programas aceleran el tiempo de respuesta mediante la búsqueda previa de páginas vinculadas, por lo que desencadena una solicitud falsa.
5. La URL no se puede marcar como favorito, lo que evita el envío accidental (aunque el token CSRF puede tener un límite de tiempo de todos modos).
6. Los datos del formulario (que podrían incluir tokens CSRF) no se muestran en la barra de direcciones, marcadores, historial del navegador o registros del servidor.

POST no proporciona ninguna protección notable contra CRSF. Solo los tokens inconfesables pueden hacer eso, como dijiste. Si solo está utilizando "POST" en sus formularios, ninguno de los problemas enumerados se aplica a usted porque los usuarios normales usarán la variante POST.

Por supuesto, existe la noción de deshabilitar cosas que no se utilizan para reducir las superficies atacables.

El motivo por el que no debe usar el método GET para datos confidenciales ya se encuentra en la lista anterior, por lo que no volveré a escribirlos. Y como entiendo por defecto, su aplicación generaría una solicitud de Post para los recursos en cuestión. Algunas razones por las que aún debe bloquear el método GET por configuración o mediante programación

1. Pocos usuarios tienden a marcar páginas con los Parámetros en URL (incluso solicitudes de inicio de sesión). Entonces, si su solicitud no procesa la solicitud GET, el marcador no funcionará y, por lo tanto, no utilizará realmente los marcadores. Por lo tanto, evitando la exposición de datos confidenciales en URL
2. Cuando tiene una aplicación empresarial, el mismo controlador de solicitudes puede ser invocado desde diferentes componentes de la aplicación, por lo que un desarrollador puede usar Publicar para invocar esto, pero otro desarrollador en el futuro puede usar GET para invocarlo. Por lo tanto, al modificar el método GET, se asegurará de que él / ella no pase la prueba de la unidad.

Línea inferior, si sus aplicaciones fluyen siempre a través de POST, rechazar GET agregaría una cantidad mínima de protección.

Lo vería todo el tiempo en WAF, enviar una solicitud con un verbo inesperado es el 99% del tiempo que un bot o un script es un niño. En todo caso, actúa como una advertencia si ves muchos verbos inesperados

¿Por qué no restringir el uso de variables individuales a las fuentes previstas?

  

Esta solicitud será aprobada por el servidor y se llevará a cabo la acción

Esto suena como si no estuvieras evaluando correctamente tus variables. No mencionó el idioma del servidor que está utilizando, pero la mayoría puede distinguir entre GET y POST. Por ejemplo, si está esperando una variable llamada 'foo' a través de POST, en PHP usando $ _POST ['foo'] en lugar de $ _REQUEST ['foo'] se eliminará la ambigüedad.

También admitiría no procesar el verbo inesperado.

Si su aplicación está diseñada para esperar un tipo de comportamiento en el uso normal (por ejemplo, un POST) pero luego recibe algo inesperado (por ejemplo, un GET en este caso), también tiene un buen escenario para detectar usuarios potencialmente maliciosos.

enlace

Eche un vistazo al proyecto AppSensor de OWASP si le interesa esta idea.

-Michael

Otro punto es evitar el raspado del sitio. Si su sitio proporciona información de alto valor, es posible que las personas deseen rastrear estos datos. Es mucho más fácil hacerlo con GET que con POST.

No es 100% de seguridad, pero aún así ...