GET Security over HTTPS [duplicado]

El método HTTP GET nunca debe utilizarse para transmitir información confidencial, como credenciales.

No veo por qué el método HTTP GET es más fácil que usar el método HTTP POST, vea la diferencia en el código a continuación.

Sugiero crear una API que maneje la autenticación y la comunicación con el servidor de servicios de fondo.

Como mencionó que va a utilizar PHP, consulte este marco API: enlace

En teoría, los parámetros en la URL no se mostrarán en los archivos de registro ya que estás usando HTTPS. Sin embargo, hay, por ejemplo, proxies corporativos que realizan ataques de hombre en medio para inspeccionar todo el tráfico.

En estos casos, las credenciales se mostrarán en los registros de proxy y esto se considera una mala práctica.

Aquí hay algunos códigos PHP (que requieren saneamiento):

<?php

  $username = $_GET['username'];
  $password = $_GET['password'];

?>

Este ejemplo es incorrecto porque:

1. La información confidencial se transmite en la URL
2. No se ha realizado ninguna validación de entrada

Este ejemplo es un poco mejor, pero aún requiere que realices la validación de entrada:

<?php

  $username = $_POST['username'];
  $password = $_POST['password'];

?>

Ese es el uso diferente entre el método HTTP GET y HTTP POST usando PHP (y, por supuesto, su método de formulario debe establecerse en POST en lugar de GET también).     

  

Estoy pensando que esta información no se registrará en el historial del navegador del usuario, ya que es una declaración de inclusión

Si la contraseña se origina en el navegador como un parámetro GET, estará disponible en el historial del navegador. Si el PHP actúa como un proxy y agrega el nombre de usuario y la contraseña, entonces no estará en el historial del navegador. Sin embargo, ahora se otorga acceso sin contraseña a cualquier persona que pueda apuntar un navegador al sitio (en ausencia de restricciones de seguridad adicionales).

Si el "servidor de aplicaciones" está en un host separado del código PHP, entonces sí, puede pasar un href a la función de inclusión para presentar el contenido al navegador, sin embargo:

1) abre un gran agujero de seguridad en su sistema: si alguien puede engañar a su código para que lea el contenido de un sitio web y este contenga código PHP, se ejecutará

2) solo puede realizar operaciones GET y en un solo tipo de contenido: se perderán todos los encabezados del sistema backend.

Si estás feliz de agregar el nombre de usuario y la contraseña, una mejor solución sería hacerlo con Squid y un redirector de URL.

Le ayudaría saber qué está tratando de lograr, por qué no cambia el código en el "servidor de aplicaciones" para manejar la autenticación de una manera diferente (por ejemplo, usando SSO)