¿GET o POST es más seguro que el otro?

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 rastreados 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 usar el código del lado del servidor para manejar la información confidencial?

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 de red real entre el cliente y el servidor. Si necesita pasar información sensible, su primera línea de defensa sería pasarla usando Secure HTTP.

Las publicaciones de cadenas de consulta o GET son realmente buenas para la información requerida para marcar un elemento en particular o para ayudar en la optimización del motor de búsqueda y la indexación de elementos.

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

La solicitud GET es marginalmente menos segura que la solicitud POST. Ninguno de los dos ofrece verdadera "seguridad" por sí mismo; El uso de solicitudes POST no hará que su sitio web sea mágicamente 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 debe utilizar las 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 usando el tipo de solicitud incorrecto.

Buscar arañas y aceleradores web

Esta es la verdadera razón por la que debe usar las solicitudes POST para cambiar los datos. Las arañas de búsqueda seguirán cada enlace en su sitio web, pero no enviarán 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 conectado . Por lo tanto, una aplicación que utiliza una solicitud GET para eliminar cosas, incluso si requiere un administrador, felizmente obedecerá las órdenes del acelerador web (¡no malicioso!) Y eliminará todo lo que vea .

Adjunto de ataque confuso

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

En los 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 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 (permitiendo que el atacante inyecte una solicitud GET arbitraria), pero evitan formas 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 adjunto 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 apenas es un ataque , incluso si el oficial está confundido.

Registros proxy

Es probable que los servidores proxy registren las URL GET en su totalidad, sin quitar 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. (ejemplo)

Este es un argumento muy débil a favor de POST. En primer lugar, el tráfico no cifrado 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 registros proxy, es poco probable que puedan atacar una URL GET o POST.

Hay una excepción para las solicitudes de inicio de sesión: 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 simple es inherentemente inseguro de todos modos.

Caché proxy

Los servidores proxy de almacenamiento en caché pueden retener las respuestas GET, pero no las respuestas POST. Dicho esto, las respuestas GET pueden hacerse no almacenables en caché con menos esfuerzo que convertir la URL en un controlador POST.

HTTP "Referer"

Si el usuario navegara a un sitio web de un tercero desde la página servida en respuesta a una solicitud GET, ese sitio web de terceros podrá 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 hacker necesitaría insertar un enlace a su propio sitio web en la respuesta del servidor.

Historial del navegador

Esto es muy similar al argumento "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 volverá a intentar una solicitud GET tan pronto como el usuario presione "actualizar". Podría hacer eso al restaurar pestañas después del apagado. 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 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?

• Use solo solicitudes POST para cambiar datos, principalmente por razones no relacionadas con la seguridad.
• Utilice solo solicitudes POST para formularios de inicio de sesión; hacer lo contrario introduce vectores de ataque.
• Si su sitio realiza operaciones delicadas, realmente necesita a alguien que sepa lo que está haciendo, porque esto no se puede cubrir en una sola respuesta. Debe usar HTTPS, HSTS, CSP, mitigar la inyección de SQL, la inyección de scripts (XSS) , CSRF y una gran cantidad de otras cosas que pueden ser específicas 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 de POST están codificados, pero ¿podrían ser rastreados los URL por un tercero?

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

¿Sería justo decir que la mejor práctica es evitar la posibilidad de colocar datos confidenciales en el POST o GET por completo y usar 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 devuelva. Si eso es importante, sí, mantenga los datos confidenciales en el servidor y no deje que se vayan.

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

HTTP / 1.1 nos proporciona varios métodos para enviar una solicitud :

• OPCIONES
• OBTENER
• CABEZA
• ENVIAR
• PONER
• ELIMINAR
• RASTRO
• CONECTAR

Supongamos que tiene el siguiente documento HTML usando 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? 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 imaginemos que cambiamos ese método de solicitud a 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
• Se puede evadir y estar sujeto a ataques MITM.
• Reproducido fácilmente por terceros y bots de script.

Muchos navegadores no admiten métodos HTTP que no sean 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 específico:

¿Es uno inherentemente más 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, porque 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 mire el historial de su navegador o algún otro ataque ingenuo de un niño de 10 años que cree que entiende h4x0r1ng , o scripts que verifican su tienda de historial. Si tiene un script que puede verificar su tienda de historial, podría fácilmente tener uno que verifique el tráfico de su red, por lo que toda esta seguridad a través de la oscuridad solo proporciona oscuridad a los niños de script y a las novias celosas.

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

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

PUBLICAR 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

OBTENER 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, algunos de ellos obviamente no deberían ser visualizables)

Toda la conversación HTTP está encriptada, 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 mayor seguridad sobre un método HTTP que sobre otro, los hackers y los novatos de todo el mundo saben exactamente cómo hacer lo que acabo de demostrar aquí. Si desea seguridad, use SSL. Los navegadores tienden a almacenar el historial, RFC2616 9.1.1 recomienda que NO use GET para realizar una acción, pero pensar que POST proporciona seguridad es totalmente erróneo.

¿Lo único para lo que POST es una medida de seguridad? Protección contra tus celosos ex hojeando el historial de tu 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 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 usa HTTPS y su sitio no contiene vulnerabilidades XSS . En resumen, este escenario de ataque supone que la víctima (el usuario de su sitio o servicio) ya ha iniciado sesión y tiene una cookie adecuada y luego se le 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 hay seguridad adicional.

Los datos de publicación no se muestran en el historial o en los archivos de registro, pero si los datos deben mantenerse seguros, necesita SSL.
De lo contrario, cualquiera que huela el cable puede leer sus datos de todos modos.

Incluso si POST no ofrece ningún beneficio de seguridad real en comparación GETcon los formularios de inicio de sesión o cualquier otro formulario con información relativamente confidencial, asegúrese de utilizarlo POSTcomo:

1. La información POSTed no se guardará en el historial del usuario.
2. 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, será visible en el historial y la barra de URL).

También, GET tiene un límite teórico de datos. POSTno lo hace

Para obtener información confidencial real, asegúrese de usar SSL( HTTPS)

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

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

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 que no sea en los registros, pero POST puede crear nuevos recursos.

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

Como se menciona 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.

Mi metodología habitual para elegir es algo como:

• OBTENGA los elementos que se recuperarán más tarde por URL
  • Por ejemplo, la búsqueda debe ser GET para que pueda hacer search.php? S = XXX más adelante
• POST para artículos que se enviarán
  • Esto es relativamente invisible comparado con GET y más difícil de enviar, pero los datos aún se pueden enviar a través de cURL.

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

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

Las URL 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 los hace seguros. Para eso quieres SSL. GET y POST envían datos en texto plano a través del cable cuando se usan a través de HTTP.

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

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

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 simplemente se muestra en el navegador! Ahora acaba de entregar su clave API a todos.

Desafortunadamente, hay API reales que funcionan de esta manera.

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

1. SEGURIDAD como seguridad de los datos EN TRÁNSITO: no hay diferencia entre POST y GET.

2. SEGURIDAD como seguridad de los datos EN LA COMPUTADORA: POST es más seguro (sin historial de URL)

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

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

Si desea estar seguro contra alguien que detecte su actividad de red, entonces no hay diferencia.

Muchas personas adoptan una convención (aludida por Ross) en la 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. Mientras que uno no es inherentemente más seguro que el otro, si lo hace seguir esta convención, se puede aplicar la lógica de seguridad intersectorial (por ejemplo, sólo las personas con cuentas pueden modificar los datos, por lo que no autenticados POST son rechazadas).

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

No estoy dispuesto a repetir todas las otras respuestas, pero hay un aspecto que aún no he visto mencionado: es 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 todas las noches perdía todos sus datos y nadie sabía por qué. La inspección de los registros reveló más tarde que el sitio fue encontrado por Google u otra araña arbitraria, que felizmente OBTENER (lea: GOT) todos los enlaces que encontró en el sitio, incluyendo "eliminar esta entrada" y "¿estás seguro?" Enlaces.

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

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

RFC7231:

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

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 existentes, servidores proxy y agentes de usuario registran o muestran el objetivo de la solicitud en lugares donde pueda ser visible para terceros. Dichos servicios deberían utilizar el envío de formularios basado en POST en su lugar ".

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 que haré porque nadie se adhiere a estas especificaciones)

Como anteriormente han dicho algunas personas, HTTPS brinda 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, GET siempre envía un hipervínculo (a menos que se transforme en un formulario de publicación mediante javascript).

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

Una razón por la que 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 contrario , casi no está registrado universalmente , 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 1KB, ayudaría a las personas a identificar a los atacantes que trabajan en un punto de entrada débil hasta que explote, luego POST lo hace un doble servicio, al permitir que cualquier puerta trasera basada en HTTP pase silenciosamente cantidades ilimitadas de datos.

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

Entonces obtener es mejor para datos no seguros, como las cadenas de consulta en Google. Los datos de autenticación nunca se enviarán a través de GET, así que use POST aquí. Por supuesto, todo el tema es un poco más complicado. Si desea leer más, lea este artículo (en alemán).

Recientemente se publicó un ataque que permite al hombre en el medio revelar el cuerpo de la 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 utilizada). En estos escenarios, el ataque es más fácil de prevenir (los proveedores de navegadores ya proporcionaron soluciones). La compresión de nivel HTTP es una característica más fundamental, es poco probable que los proveedores la desactiven.

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 por este motivo de ataque. El ataque es bastante sofisticado y requiere prerrequisitos 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 sería dañino.

Descargo de responsabilidad: los siguientes puntos solo se aplican a las llamadas a la API y no a las URL del sitio web.

Seguridad en la red : debe usar HTTPS. GET y POST son igualmente seguros en este caso.

Historial del navegador : para aplicaciones de front-end como, Angular JS, React JS, etc. Las llamadas API son llamadas AJAX realizadas por front-end. Estos no se convierten en parte del historial del navegador. Por lo tanto, POST y GET son igualmente seguros.

Registros del lado del servidor : con el uso del conjunto de escritura de enmascaramiento de datos y el formato de registros de acceso, es posible ocultar todos o solo los datos confidenciales de la URL de solicitud.

Visibilidad de datos en la consola del navegador: para alguien con intenciones maliciosas, es casi el mismo esfuerzo ver los datos POST tanto como GET.

Por lo tanto, con las prácticas de registro correctas, GET API es tan segura como POST API. Siguiendo POST en todas partes, obliga a definiciones API pobres y debe evitarse.

La publicación es la más segura junto con SSL instalado porque se transmite en el cuerpo del mensaje.

Pero todos estos métodos son inseguros porque el protocolo de 7 bits que usa debajo es pirateable con escape. Incluso a través de un firewall de aplicaciones web de nivel 4.

Los enchufes tampoco son garantía ... Aunque es más seguro en ciertos aspectos.

Esta es una publicación antigua, pero me gustaría objetar algunas de las respuestas. Si está transfiriendo datos confidenciales, querrá usar SSL. Si utiliza SSL con un parámetro GET (por ejemplo,? Userid = 123), ¡esos datos se enviarán en texto sin formato! Si envía utilizando una 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ía enrutar al servidor porque solo usted podría 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, utilizando SSL o no.

Incluso POST acepta solicitudes GET. Suponga que tiene un formulario que tiene 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? User.name = "my user & user.passwd =" mi contraseña ", la solicitud será aceptada" pasando por alto 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.