html - method - post php

¿Es GET o POST más seguro que el otro? (25)

Al comparar un HTTP GET con un HTTP POST, ¿cuáles son las diferencias desde una perspectiva de seguridad? ¿Es una de las opciones inherentemente más segura que la otra? Si es así, ¿por qué?

Me doy cuenta de que POST no expone información en la URL, pero ¿hay algún valor real en eso o es solo seguridad a través de la oscuridad? ¿Hay alguna razón por la que prefiera POST cuando la seguridad es una preocupación?

Editar:
A través de HTTPS, los datos POST están codificados, pero ¿podrían las URL ser rastreadas por un tercero? Además, estoy tratando con JSP; al usar JSP o un marco similar, ¿sería justo decir que la mejor práctica es evitar colocar datos confidenciales en la POST o GET y utilizar el código del lado del servidor para manejar la información confidencial?

SEGURIDAD como seguridad de datos EN TRÁNSITO: no hay diferencia entre POST y GET.
SEGURIDAD como seguridad de los datos EN LA COMPUTADORA: POST es más seguro (sin historial de URL)

Como anteriormente algunas personas han dicho, HTTPS trae seguridad.

Sin embargo, POST es un poco más seguro que GET porque GET podría almacenarse en el historial.

Pero aún más, lamentablemente, a veces la elección de POST o GET no depende del desarrollador. Por ejemplo, siempre se envía un hipervínculo por GET (a menos que se transforme en un formulario de publicación utilizando javascript).

Considere esta situación: una API descuidada acepta solicitudes GET como:

http://www.example.com/api?apikey=abcdef123456&action=deleteCategory&id=1

En algunas configuraciones, cuando solicita esta URL y si hay un error / advertencia con respecto a la solicitud, toda esta línea se registra en el archivo de registro. Peor aún: si olvida deshabilitar los mensajes de error en el servidor de producción, ¡esta información solo se muestra en el navegador! Ahora que acaba de regalar su clave API a todos.

Desafortunadamente, hay API reales trabajando de esta manera.

No me gustaría la idea de tener alguna información confidencial en los registros o mostrarlos en el navegador. POST y GET no son lo mismo. Use cada uno donde sea apropiado.

En cuanto a la seguridad, son inherentemente iguales. Si bien es cierto que POST no expone información a través de la URL, expone tanta información como un GET en la comunicación real de la red entre el cliente y el servidor. Si necesita pasar información que sea confidencial, su primera línea de defensa sería pasarla usando HTTP seguro.

Los mensajes de GET o de cadena de consulta son realmente buenos para la información requerida para marcar un elemento en particular o para ayudar en la optimización de motores de búsqueda e indexar elementos.

POST es bueno para formularios estándar que se utilizan para enviar datos únicos. No usaría GET para publicar formularios reales, a menos que tal vez en un formulario de búsqueda en el que desee permitir que el usuario guarde la consulta en un marcador, o algo por el estilo.

Es más difícil alterar una solicitud POST (requiere más esfuerzo que editar la cadena de consulta). Edición: En otras palabras, solo es seguridad por oscuridad, y apenas eso.

Este es un post antiguo, pero me gustaría objetar algunas de las respuestas. Si está transfiriendo datos confidenciales, querrá estar usando SSL. Si usa SSL con un parámetro GET (por ejemplo,? Userid = 123), esos datos se enviarán en texto sin formato. Si envía mediante un POST, los valores se colocan en el cuerpo cifrado del mensaje y, por lo tanto, no son legibles para la mayoría de los ataques MITM.

La gran distinción es donde se pasan los datos. Solo tiene sentido que si los datos se colocan en una URL, NO PUEDEN cifrarse, de lo contrario, no podrá enrutar al servidor porque solo puede leer la URL. Así es como funciona un GET.

En resumen, puede transmitir datos de forma segura en un POST a través de SSL, pero no puede hacerlo con un GET, ya sea utilizando SSL o no.

Esto no está relacionado con la seguridad pero ... los navegadores no almacenan en caché las solicitudes POST .

GET es visible para cualquier persona (incluso el que está en su hombro ahora) y se guarda en la memoria caché, por lo que es menos seguro usar publicaciones, por cierto, sin cierta criptografía no está seguro, por un poco de seguridad tiene que usar SSL ( https)

Incluso POST acepta solicitudes GET. Supongamos que tiene un formulario con entradas como user.name y user.passwd, se supone que son compatibles con el nombre de usuario y la contraseña. Si simplemente agregamos un? Usuario.nombre = "mi usuario y usuario.passwd =" mi contraseña ", entonces la solicitud se aceptará" sin pasar por la página de inicio de sesión ".

Una solución para esto es implementar filtros (filtros java como una e) en el lado del servidor y detectar que no se pasan consultas de cadena como argumentos GET.

Incluso si POST no ofrece un beneficio de seguridad real en comparación con GET , para los formularios de inicio de sesión o cualquier otro formulario con información relativamente confidencial, asegúrese de utilizar POST como:

La información POST ed no se guardará en el historial del usuario.
La información confidencial (contraseña, etc.) enviada en el formulario no será visible más adelante en la barra de URL (al usar GET , estará visible en el historial y en la barra de URL).

Además, GET tiene un límite teórico de datos. POST no lo hace.

Para información realmente sensible, asegúrese de usar SSL ( HTTPS )

La diferencia entre GET y POST no debe verse en términos de seguridad, sino en sus intenciones hacia el servidor. GET nunca debe cambiar los datos en el servidor, al menos en los registros, pero POST puede crear nuevos recursos.

Los buenos proxies no almacenan en caché los datos de POST, pero pueden almacenar en caché los datos de GET de la URL, por lo que podría decir que se supone que POST es más seguro. Pero los datos de POST todavía estarían disponibles para los proxies que no funcionan bien.

Como se mencionó en muchas de las respuestas, la única apuesta segura es a través de SSL.

Pero ASEGÚRESE de que los métodos GET no confirmen ningún cambio, como eliminar filas de la base de datos, etc.

La diferencia es que GET envía datos abiertos y POST ocultos (en el encabezado http).

Así que obtener es mejor para datos no seguros, como cadenas de consulta en Google. Los datos de autenticación nunca se enviarán a través de GET; por lo tanto, utilice POST aquí. Por supuesto que todo el tema es un poco más complicado. Si quieres leer más, lee este artículo (en alemán).

La noción de seguridad no tiene sentido a menos que defina contra qué quiere estar seguro.

Si desea estar seguro contra el historial del navegador almacenado, algunos tipos de registro y las personas que miran sus URL, POST es más seguro.

Si desea estar seguro contra alguien que esté olfateando la actividad de su red, entonces no hay diferencia.

La solicitud GET es ligeramente menos segura que la solicitud POST. Tampoco ofrece la verdadera "seguridad" por sí misma; el uso de solicitudes POST no hará mágicamente que su sitio web sea seguro contra ataques maliciosos por una cantidad notable. Sin embargo, el uso de solicitudes GET puede hacer que una aplicación segura sea insegura.

El mantra de que "no debes usar solicitudes GET para realizar cambios" sigue siendo muy válido, pero esto tiene poco que ver con el comportamiento malicioso . Los formularios de inicio de sesión son los más sensibles a ser enviados utilizando el tipo de solicitud incorrecto.

Búsqueda de arañas y aceleradores web.

Esta es la verdadera razón por la que debe usar solicitudes POST para cambiar datos. Las arañas de búsqueda seguirán todos los enlaces de su sitio web, pero no enviarán los formularios aleatorios que encuentren.

Los aceleradores web son peores que las arañas de búsqueda, porque se ejecutan en la máquina del cliente y "hacen clic" en todos los enlaces en el contexto del usuario que inició sesión . Por lo tanto, una aplicación que utiliza una solicitud GET para eliminar cosas, incluso si requiere un administrador, obedecerá con gusto las órdenes del acelerador web (¡no es malicioso!) Y eliminará todo lo que vea .

Ataque de diputado confuso

Un ataque de agente confuso (donde el agente es el navegador) es posible independientemente de si utiliza un GET o una solicitud POST .

En sitios web controlados por atacantes, GET y POST son igualmente fáciles de enviar sin interacción del usuario .

El único escenario en el que la POST es ligeramente menos susceptible es que muchos sitios web que no están bajo el control del atacante (por ejemplo, un foro de terceros) permiten incrustar imágenes arbitrarias (lo que permite al atacante inyectar una solicitud GET arbitraria), pero previene todo Maneras de inyectar una solicitud POST arbitraria, ya sea automática o manual.

Se podría argumentar que los aceleradores web son un ejemplo de ataque de agente confuso, pero eso es solo una cuestión de definición. En todo caso, un atacante malintencionado no tiene control sobre esto, por lo que no es un ataque , incluso si el oficial está confundido.

Registros de proxy

Es probable que los servidores proxy registren las URL de GET en su totalidad, sin eliminar la cadena de consulta. Los parámetros de solicitud POST normalmente no se registran. Es poco probable que las cookies se registren en cualquier caso. (example)

Este es un argumento muy débil a favor de POST. En primer lugar, el tráfico sin cifrar se puede registrar en su totalidad; un proxy malicioso ya tiene todo lo que necesita. En segundo lugar, los parámetros de solicitud son de uso limitado para un atacante: lo que realmente necesitan son las cookies, por lo que si lo único que tienen son los registros de proxy, es poco probable que puedan atacar una URL GET o POST.

Hay una excepción para las solicitudes de inicio de sesión: estas tienden a contener la contraseña del usuario. Guardar esto en el registro de proxy abre un vector de ataque que está ausente en el caso de POST. Sin embargo, el inicio de sesión a través de HTTP es inherentemente inseguro de todos modos.

Caché de proxy

Los proxies de almacenamiento en caché pueden retener respuestas GET, pero no respuestas POST. Dicho esto, las respuestas GET se pueden hacer sin almacenamiento en caché con menos esfuerzo que convertir la URL en un controlador POST.

HTTP "Referer"

Si el usuario navegaba a un sitio web de un tercero desde la página servida en respuesta a una solicitud GET, ese sitio web de un tercero puede ver todos los parámetros de la solicitud GET.

Pertenece a la categoría de "revela parámetros de solicitud a un tercero", cuya gravedad depende de lo que está presente en esos parámetros. Las solicitudes POST son naturalmente inmunes a esto, sin embargo, para explotar la solicitud GET, un pirata informático necesitaría insertar un enlace a su propio sitio web en la respuesta del servidor.

Historial del navegador

Esto es muy similar al argumento de "registros de proxy": las solicitudes GET se almacenan en el historial del navegador junto con sus parámetros. El atacante puede obtenerlos fácilmente si tiene acceso físico a la máquina.

Acción de actualización del navegador

El navegador reintentará una solicitud GET tan pronto como el usuario haga clic en "actualizar". Podría hacerlo cuando se restauran pestañas después del cierre. Cualquier acción (por ejemplo, un pago) se repetirá sin previo aviso.

El navegador no volverá a intentar una solicitud POST sin una advertencia.

Esta es una buena razón para usar solo las solicitudes POST para cambiar datos, pero no tiene nada que ver con el comportamiento malicioso y, por lo tanto, con la seguridad.

¿Entonces qué debo hacer?

Utilice solo solicitudes POST para cambiar los datos, principalmente por motivos no relacionados con la seguridad.
Utilice únicamente solicitudes POST para formularios de inicio de sesión; Hacer lo contrario introduce vectores de ataque.
Si su sitio realiza operaciones confidenciales, realmente necesita a alguien que sepa lo que está haciendo, porque esto no se puede cubrir con una sola respuesta. Debe usar HTTPS, HSTS, CSP, mitigar la inyección de SQL, la inyección de scripts (XSS) , CSRF y muchos otros elementos que pueden ser específicos para su plataforma (como la vulnerabilidad de asignación masiva en varios marcos: ASP.NET MVC , Ruby on Rails , etc.). No hay una sola cosa que haga la diferencia entre "seguro" (no explotable) y "no seguro".

A través de HTTPS, los datos POST están codificados, pero ¿podrían las URL ser rastreadas por un tercero?

No, no pueden ser olidos. Pero las URL se almacenarán en el historial del navegador.

¿Sería justo decir que la mejor práctica es evitar la posible colocación de datos confidenciales en la POST o GET y utilizar el código del lado del servidor para manejar la información confidencial?

Depende de qué tan sensible sea, o más específicamente, de qué manera. Obviamente el cliente lo verá. Cualquier persona con acceso físico a la computadora del cliente lo verá. El cliente puede falsificarlo cuando se lo envíe de vuelta. Si eso importa, sí, mantenga los datos confidenciales en el servidor y no deje que se vayan.

Mi metodología habitual para elegir es algo como:

GET para los elementos que serán recuperados más tarde por la URL
- Por ejemplo, la búsqueda debería ser GET para que puedas hacer search.php? S = XXX más adelante
POST para artículos que serán enviados
- Esto es relativamente invisible en comparación con GET y más difícil de enviar, pero los datos aún pueden enviarse a través de cURL.

Muchas personas adoptan una convención (aludida por Ross) de que las solicitudes GET solo recuperan datos, y no modifican ningún dato en el servidor, y las solicitudes POST se utilizan para todas las modificaciones de datos. Si bien uno no es más seguro que el otro, si sigue esta convención, puede aplicar una lógica de seguridad transversal (por ejemplo, solo las personas con cuentas pueden modificar los datos, por lo que se rechazan los POST no autenticados).

Ninguno de GET y POST es inherentemente "más seguro" que el otro, al igual que ninguno de fax y teléfono es "más seguro" que el otro. Se proporcionan los diversos métodos HTTP para que pueda elegir el que sea más adecuado para el problema que está tratando de resolver. GET es más apropiado para consultas idempotent mientras que POST es más apropiado para consultas de "acción", pero puede dispararse al pie con cualquiera de ellas con la misma facilidad si no comprende la arquitectura de seguridad para la aplicación que está manteniendo.

Probablemente sea mejor si lee el Capítulo 9: Definiciones de métodos del RFC HTTP / 1.1 para tener una idea general de lo que GET y POST originalmente se imaginaron que significaban.

Ninguno de los dos confiere mágicamente la seguridad en una solicitud, sin embargo, GET implica algunos efectos secundarios que generalmente evitan que sea segura.

Las URL de GET se muestran en el historial del navegador y en los registros del servidor web. Por esta razón, nunca deben usarse para cosas como formularios de inicio de sesión y números de tarjetas de crédito.

Sin embargo, simplemente publicar esos datos tampoco lo hace seguro. Para eso quieres SSL. Tanto GET como POST envían datos en texto sin formato a través del cable cuando se usan a través de HTTP.

También hay otras buenas razones para POST datos, como la capacidad de enviar cantidades ilimitadas de datos u ocultar parámetros de usuarios ocasionales.

El inconveniente es que los usuarios no pueden marcar los resultados de una consulta enviada a través de POST. Para eso, necesitas GET.

No tiene mayor seguridad porque las variables se envían a través de HTTP POST que las variables enviadas a través de HTTP GET.

HTTP / 1.1 nos proporciona un montón de métodos para enviar una solicitud :

OPCIONES
OBTENER
CABEZA
ENVIAR
PONER
BORRAR
RASTRO
CONECTAR

Supongamos que tiene el siguiente documento HTML utilizando GET:

<html> <body> <form action="http://example.com" method="get"> User: <input type="text" name="username" /><br/> Password: <input type="password" name="password" /><br/> <input type="hidden" name="extra" value="lolcatz" /> <input type="submit"/> </form> </body> </html>

¿Qué pregunta tu navegador? Se pregunta esto:

GET /?username=swordfish&password=hunter2&extra=lolcatz HTTP/1.1 Host: example.com Connection: keep-alive Accept: application/xml,application/xhtml+xml,text/html;q=0.9,text/ [...truncated] User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US) [...truncated] Accept-Encoding: gzip,deflate,sdch Accept-Language: en-US,en;q=0.8 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3

Ahora simulemos que cambiamos ese método de solicitud a un POST:

POST / HTTP/1.1 Host: example.com Connection: keep-alive Content-Length: 49 Cache-Control: max-age=0 Origin: null Content-Type: application/x-www-form-urlencoded Accept: application/xml,application/xhtml+xml,text/ [...truncated] User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; [...truncated] Accept-Encoding: gzip,deflate,sdch Accept-Language: en-US,en;q=0.8 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3 username=swordfish&password=hunter2&extra=lolcatz

AMBAS de estas solicitudes HTTP son:

No encriptado
Incluido en ambos ejemplos
Puede ser ejecutado y sujeto a ataques MITM.
Reproducido fácilmente por terceros, y los robots de script.

Muchos navegadores no admiten métodos HTTP distintos de POST / GET.

Muchos comportamientos de los navegadores almacenan la dirección de la página, pero esto no significa que pueda ignorar cualquiera de estos otros problemas.

Para ser más específicos:

¿Es uno más intrínsecamente seguro que otro? Me doy cuenta de que POST no expone información en la URL, pero ¿hay algún valor real en eso o es solo seguridad a través de la oscuridad? ¿Cuál es la mejor práctica aquí?

Esto es correcto, ya que el software que está utilizando para hablar HTTP tiende a almacenar las variables de solicitud con un método, pero no con otro, solo evita que alguien vea el historial de su navegador u otro ataque ingenuo de un niño de 10 años que piensa que entiende. H4x0r1ng , o scripts que comprueban tu historial de almacenamiento. Si tiene un script que puede consultar su almacén de historial, podría tener uno que compruebe el tráfico de su red, por lo que toda esta seguridad a través de la oscuridad solo está proporcionando oscuridad a los chiquillos y novias celosas.

En https, los datos de POST están codificados, pero ¿podrían las direcciones URL ser rastreadas por un tercero?

Así es como funciona SSL. ¿Recuerdas esas dos peticiones que envié arriba? Así es como se ven en SSL: (cambié la página a https://encrypted.google.com/ porque example.com no responde en SSL).

POST sobre SSL

q5XQP%RWCd2u#o/T9oiOyR2_YO?yo/3#tR_G7 2_RO8w?FoaObi) oXpB_y?oO4q?`2o?O4G5D12Aovo?C@?/P/oOEQC5v?vai /%0Odo QVw#6eoGXBF_o?/u0_F!_1a0A?Q b%TFyS@Or1SR/O/o/_@5o&_o 9q1/?q$7yOAXOD5sc$H`BECo1w/`4?)f!%geOOF/!/#Of_f&AEI# yvv/wu_b5?/o d9O?VOVOFHwRO/pO/OSv_/8/9o6b0FGOH61O?ti /i7b?!_o8u%RS/Doai%/Be/d4$0sv_%YD2_/EOAO/C?vv/%X!T?R _o_2yoBP)orw7H_yQsXOhoVUo49itare#cA?/c)I7R?YCsg ??c'' (_!(0u)o4eIis/S8Oo8_BDueC?1uUO%ooOI_o8WaoO/ x?B?oO@& Pw?os9Od!c?/$3bWWeIrd_?( `P_C?7_g5O(ob(go?&/ooRxR''u/ T/yO3dS&??hIOB/?/OI?$oH2_?c_?OsD//0/_s%r

GET sobre SSL

rV/O8ow1pc`?058/8OS_Qy/$7oSsU''qoo#vCbOO`vt?yFo_?EYif) 43`I/WOP_8oH0%3OqP_h/cBO&24?''?o_4`scooPSOVWYSV?H?pV!i ?78cU!_b5h''/b2coWD?/43Tu?153pI/9?R8!_Od"(//O_a#t8x?__ bb3D?05Dh/PrS6_/&5p@V f $)/xvxfgO''q@y&e&S0rB3D/Y_/fO? _''woRbOV?_!yxSOdwo1G1?8d_p?4fo81VS3sAOvO/Db/br)f4fOxt _Qs3EO/?2O/TOo_8p82FOt/hO?X_P3o"OVQO_?Ww_dr"''DxHwo//P oEfGtt/_o)5RgoGqui&AXEq/oXv&//?%/6_?/x_OTgOEE%v (u(?/ t7DX1O8oD?fVObiooi''8)so?o??`o"FyVOByY_ Supo? /''i?Oi"4 tr''9/o_7too7q?c2Pv

(nota: convertí el HEX a ASCII, algo de esto obviamente no debería poder mostrarse)

La conversación HTTP completa está cifrada, la única parte visible de la comunicación está en la capa TCP / IP (es decir, la dirección IP y la información del puerto de conexión).

Así que déjame hacer una gran declaración audaz aquí. Su sitio web no cuenta con una mayor seguridad en un método HTTP que en otro, los piratas informáticos y los usuarios de todo el mundo saben exactamente cómo hacer lo que acabo de demostrar. Si quieres seguridad, usa SSL. Los navegadores tienden a almacenar el historial, se recomienda en RFC2616 9.1.1 NO usar GET para realizar una acción, pero pensar que POST proporciona seguridad es completamente erróneo.

¿Lo único que POST es una medida de seguridad hacia? Protección contra su ex celoso hojeando el historial de su navegador. Eso es. El resto del mundo está conectado a su cuenta riéndose de usted.

Para demostrar aún más por qué POST no es seguro, Facebook utiliza las solicitudes POST en todo el lugar, entonces, ¿cómo puede existir un software como FireSheep ?

Tenga en cuenta que puede ser atacado con CSRF incluso si utiliza HTTPS y su sitio no contiene vulnerabilidades de XSS . En resumen, este escenario de ataque asume que la víctima (el usuario de su sitio o servicio) ya ha iniciado sesión y tiene una cookie adecuada y luego se solicita al navegador de la víctima que haga algo con su sitio (supuestamente seguro). Si no tiene protección contra CSRF, el atacante aún puede ejecutar acciones con las credenciales de las víctimas. El atacante no puede ver la respuesta del servidor porque se transferirá al navegador de la víctima, pero el daño generalmente ya está hecho en ese punto.

No voy a repetir todas las demás respuestas, pero hay un aspecto que aún no he visto mencionado: la historia de la desaparición de datos. No sé dónde encontrarlo, pero ...

Básicamente se trata de una aplicación web que, misteriosamente, cada noche perdía todos sus datos y nadie sabía por qué. La inspección de los registros más tarde reveló que el sitio fue encontrado por google u otra araña arbitraria, que felizmente OBTUVO (leído: GOT) todos los enlaces que encontró en el sitio, incluyendo "eliminar esta entrada" y "¿estás seguro?" campo de golf.

En realidad - parte de esto ha sido mencionado. Esta es la historia detrás de "no cambiar datos en GET sino solo en POST". Los rastreadores seguirán felizmente a GET, nunca POST. Incluso robots.txt no ayuda contra el mal comportamiento de los rastreadores.

RFC7231:

"Los URI están diseñados para ser compartidos, no seguros, incluso cuando identifican recursos seguros. Los URI a menudo se muestran en las pantallas, se agregan a las plantillas cuando se imprime una página y se almacenan en una variedad de listas de marcadores no protegidos. Por lo tanto, no es aconsejable incluir información dentro de un URI que sea sensible, identificable personalmente o un riesgo de divulgación.

Los autores de los servicios deben evitar los formularios basados en GET para el envío de datos confidenciales porque esos datos se colocarán en el objetivo de la solicitud. Muchos servidores, servidores proxy y agentes de usuario existentes registran o muestran el objetivo de la solicitud en lugares donde podría ser visible para terceros. Dichos servicios deberían utilizar en su lugar el envío de formularios basados en POST "

Este RFC establece claramente que los datos confidenciales no deben enviarse utilizando GET. Debido a esta observación, algunos implementadores podrían no manejar los datos obtenidos de la parte de consulta de una solicitud GET con el mismo cuidado. Estoy trabajando en un protocolo que garantiza la integridad de los datos. De acuerdo con esta especificación, no debería tener que garantizar la integridad de los datos GET (lo cual haré porque nadie se adhiere a estas especificaciones)

Recientemente se publicó un ataque , que permite al hombre en medio revelar el cuerpo de solicitud de solicitudes HTTPS comprimidas. Debido a que los encabezados de solicitud y la URL no están comprimidos por HTTP, las solicitudes GET están mejor protegidas contra este ataque en particular.

Hay modos en los que las solicitudes GET también son vulnerables, SPDY comprime los encabezados de solicitud, TLS también proporciona una compresión opcional (rara vez se utiliza). En estos escenarios, el ataque es más fácil de prevenir (los proveedores de navegadores ya proporcionaron correcciones). La compresión de nivel HTTP es una característica más fundamental, es poco probable que los proveedores la deshabiliten.

Es solo un ejemplo que muestra un escenario en el que GET es más seguro que POST, pero no creo que sea una buena idea elegir GET sobre POST de esta razón de ataque. El ataque es bastante sofisticado y requiere requisitos previos no triviales (el atacante debe poder controlar parte del contenido de la solicitud). Es mejor deshabilitar la compresión HTTP en escenarios donde el ataque podría ser dañino.

También debe tener en cuenta que si sus sitios contienen enlaces a otros sitios externos que no controla mediante GET, los datos se colocarán en el encabezado de refeerer de los sitios externos cuando presionen los enlaces de su sitio. Por lo tanto, transferir datos de inicio de sesión a través de métodos GET es SIEMPRE un problema importante Ya que eso podría exponer las credenciales de inicio de sesión para un fácil acceso con solo revisar los registros o buscar en Google Analytics (o similar).

Una razón por la que la POST es peor para la seguridad es que GET se registra de forma predeterminada, los parámetros y todos los datos se registran casi universalmente por su servidor web.

POST es lo opuesto , casi no está registrado , lo que lleva a una actividad de atacante muy difícil de detectar.

No compro el argumento "es demasiado grande", esa no es razón para no registrar nada , al menos 1 KB, ayudaría mucho a las personas a identificar a los atacantes que trabajan en un punto de entrada débil hasta que aparezca, entonces POST sí lo hace. un doble dis-servicio, al permitir que cualquier puerta trasera basada en HTTP pase silenciosamente cantidades ilimitadas de datos.

No hay seguridad añadida.

La publicación de datos no se muestra en el historial y / o los archivos de registro, pero si los datos deben mantenerse seguros, necesita SSL.
De lo contrario, cualquier persona que huela el cable puede leer sus datos de todos modos.