parámetros de Php (nombre de usuario, contraseña) en el enlace

  

Creo que ahora sé qué parámetros ($ nombre de usuario y $ contraseña) almacenan en código php.

No, no lo tienes en cuenta:

$asserted_user=$_GET['username'];

E incluso sabiendo esto, los datos son efímeros. Además, si alguien puede llegar a un lugar donde pueda leer el valor del argumento, también puede leer el código y posiblemente hacer muchas otras cosas.

Habiendo dicho eso, hace alusión a mucha ingenuidad por parte del desarrollador del sitio.

YourCommonSense ya mencionó que las contraseñas se expondrán en texto sin cifrar en los registros del servidor y del proxy. Pero también serán expuestos en el historial del navegador. Esto generalmente se considera un método muy malo. Y todo lo que se necesita para corregir es un cambio de GET a POST en el html.

  

¿Esto puede llevar a una inyección de SQL?

No.

FlorenceUguet dice que existe un riesgo de MITM. No hay nada en su pregunta que tenga alguna relación con MITM. Si utiliza GET o POST no tiene ningún impacto en MITM. No nos dijiste si el sitio estaba usando HTTP o HTTPS. Los ataques MITM se evitan mediante el uso de TLS (HTTPS). Si el sitio no utiliza HTTPS, este sería un error importante por parte del proveedor. Incluso si la inscripción es gratuita y el valor del activo es trivial, un proveedor tiene un deber de atención a su clientela; Y eso incluye proteger sus contraseñas. Mucha gente todavía reutiliza la misma contraseña para diferentes sitios.

No hay una amenaza directa al enviar las credenciales en la cadena de consulta. Técnicamente , para el servidor no importa si los datos del formulario se envían en el cuerpo de la solicitud o en la cadena de consulta.

Esto significa que tus suposiciones iniciales son todas erróneas:

  

Creo que ahora sé qué parámetros almacenan en código php.

Primero, tal conocimiento no le dará ninguna ventaja.
En segundo lugar, puede ver en la consola del navegador TODOS los parámetros enviados al servidor, independientemente del método que se utilice, los parámetros del cuerpo de la solicitud también se muestran en la consola

  

¿Esto puede llevar a una inyección de SQL?

Por supuesto que no. La inyección de SQL está relacionada con SQL, no con HTTP, de lo que está hablando.

La única amenaza aquí es la posibilidad de exponer la contraseña a un tercero. En primer lugar, se almacenará en el registro de acceso del servidor. O puede almacenarse en algún servidor proxy en el camino (sin embargo, en caso de que el sitio use HTTPS, no sucederá).

Entonces, al final, es probable que no obtengas ninguna ventaja en este caso, pero es mejor usar el método POST de todos modos.