Problemas de seguridad relacionados con HTTP GET en el desarrollo web

• A través de conexiones TLS (https), los datos POST y GET están encriptados, por lo que no hay diferencia al respecto.
• Para evitar problemas de inyección de SQL (u otros), debe validar y sanear todas las entradas de usuarios entrantes, independientemente de si se usó POST o GET.
• Inherentemente, el uso de solicitudes POST no es más seguro , pero es una buena práctica usar solicitudes POST cuando se envían datos que cambiarán (por ejemplo) algo en la base de datos.

• Si usa GET, existe un mayor riesgo de que las herramientas de registro del servidor también registren información confidencial de manera predeterminada (el registro de solicitudes HTTP contendrá todos los datos). Puede minimizar este riesgo enviando datos con POST.

• Además, en algunos escenarios (dependiendo de su uso y necesidades específicas), tener información confidencial en la URL como parámetros de consulta (por ejemplo, /data/something?secret_key=123321 ) también se almacenará en el historial del navegador, y esto podría ser un riesgo si las computadoras compartidas son comunes para sus usuarios.

Parece que estás confundiendo varios problemas diferentes en términos de seguridad. Hay algunos problemas con el uso de los parámetros GET, aunque estos no están específicamente relacionados con la inyección de SQL, y la inyección de SQL no se puede evitar mediante el uso de solicitudes POST.

La mayoría de las inquietudes con respecto a las solicitudes GET provienen del acceso indirecto a los datos: por ejemplo, los parámetros GET se pueden ver en el historial del navegador y se almacenan en los archivos de registro del lado del servidor sin ningún procesamiento adicional. Las solicitudes POST, por otro lado, generalmente se muestran en el historial del navegador sin ningún valor de parámetros, y los registros del servidor generalmente no incluyen el cuerpo de las solicitudes.

SQLi, por otro lado, resulta del uso de datos no confiables en el contexto de una consulta SQL. No importa de dónde provengan los datos: solicitud GET, solicitud POST, otro sistema backend, cookies, la base de datos en sí.

En general, es una buena práctica imponer estrictamente métodos de solicitud específicos, pero se trata más de evitar otros tipos de fallas (las versiones anteriores de PHP combinarían las variables GET y POST, por ejemplo, dando como resultado problemas en los que los valores deseados podrían ser sobrescritos por suministrando un parámetro insertado cliente del otro tipo). Un paradigma para esto es seguir los métodos REST ( enlace ) donde cada método HTTP se asigna a un tipo de acción, por lo que solo las solicitudes GET recuperar datos, las solicitudes POST crean datos, las solicitudes PUT actualizan datos y las solicitudes DELETE borran datos, pero esto no siempre tiene sentido para todas las aplicaciones (por ejemplo, no es posible realizar solicitudes PUT / DELETE). >     

Para agregar a las respuestas excesivas sin demasiada superposición, la preocupación por las URL no es infundada y existen recomendaciones para esto: "En las solicitudes GET, los datos confidenciales deben transferirse en un encabezado HTTP"

Como se señaló en mi comentario sobre otra respuesta, todo lo que se haga con GET debe ser idempotent y safe .

GET y POST (largos con PUT, DELETE y PATCH) tienen funciones funcionales muy específicas , que redefinen la semántica de estos no es algo que deba tomarse sin una consideración muy cuidadosa.

Incluso cuando usa POST, si está siguiendo las convenciones de REST, hay información transaccional significativa dentro de la URL.

Si está ejecutando cualquier tipo de contenido transaccional, o contenido que requiera autenticación, entonces debe usar HTTPS. Esto (en su mayoría) aborda la confidencialidad de los datos en tránsito. Sus problemas restantes están en los puntos finales. Presumiblemente el servidor no es una preocupación. En el cliente, los datos persistirán en el historial en el dispositivo, pero solo para las URL a las que el usuario navegó: XMLHttpRequests no completan el historial a menos que usted explícitamente ponga los datos allí .

Los navegadores son relativamente buenos en la partición de los datos que pertenecen a sitios separados, pero hay varios canales que pueden filtrar información a un atacante determinado, pero estos son todos (AFAIK) en el dominio de datos estáticos: nombres de host, certificados, estado de HSTS, almacenamiento en caché de contenido ... el historial del navegador no es uno de estos.

Así, aparte del modelo de amenaza de que alguien se apodere del dispositivo de un usuario y extraiga los datos del sistema de archivos, no hay diferencia entre un GET y un POST desde una perspectiva de seguridad.

Serverside, su práctica común para registrar la URL completa, por lo que debe pagar protecciones similares a sus datos de registro como lo hace con los datos transaccionales.