¿Se deben pasar datos confidenciales en la cadena de consulta?

Si la cadena de consulta es el objetivo de un enlace en el que se puede hacer clic por el usuario (a diferencia de una URL utilizada desde algún Javascript), aparecerá en la barra de URL del navegador cuando se cargue la página correspondiente. Tiene los siguientes problemas:

• Se mostrará la URL. Los surfistas de hombro pueden verlo y aprender cosas de eso (por ejemplo, una contraseña).
• El usuario puede marcarlo. Esto puede ser una característica; pero también significa que los datos se escriben en el disco.
• Del mismo modo, la URL irá al "historial" por lo que se escribirá en el disco de todos modos; y podría ser recuperado después. Por ejemplo, si el navegador es Chrome, entonces un atacante a la hora del almuerzo solo tiene que escribir Ctrl + H para abrir la "pestaña de historial" y obtener todas las cadenas de consulta.
• Si se imprime la página, se imprimirá la URL, incluida cualquier información confidencial.
• Las direcciones URL, incluidas las cadenas de consulta, también se registran con frecuencia en el servidor web, y es posible que esos registros no estén protegidos adecuadamente.
• Hay limitaciones de tamaño en la cadena de consulta, que dependen del navegador y del servidor (no hay nada realmente estándar aquí, pero espera problemas más allá de unos 4 kB).

Por lo tanto, si la cadena de consulta es un objetivo de enlace simple en una página HTML, los datos confidenciales deben transmitirse como parte de un formulario POST, no codificado en la propia URL. Con las descargas programáticas (a la manera AJAX), esto es un problema mucho menor.

Además de las otras respuestas aquí, la cadena de consulta también se almacena en los archivos de registro del servidor web, los Proxies HTTP, y puede verse incluso si se usa SSL junto con herramientas de monitoreo SSL como Bluecoat.

No , los datos confidenciales no deben enviarse a través de un "GET" de HTTP y siempre deben enviarse a través de "POST"

Editar:

Otra razón por la que debería usar un POST es que los GET son más susceptibles a CSRF attack

Los datos confidenciales deben pasarse:

1. Las cookies seguras solo de HTTP (seguro significa SSL solamente; y solo HTTP significa que javascript no puede acceder) (por ejemplo, un token aleatorio que identifica que ha iniciado sesión), o
2. variables POST (sobre SSL).

Tres razones:

1. Por lo general, su computadora registra la cadena de consulta (en el historial del navegador),
2. El servidor web en el otro extremo registra por defecto la cadena de consulta. Esto es malo si, por ejemplo, se están pasando las contraseñas, el servidor web solo almacena de manera inteligente los hashes criptográficos reforzados con clave con sales aleatorias (por ejemplo, bcrypt) para evitar que los atacantes obtengan las contraseñas inadvertidamente. Obviamente, no es difícil registrar las variables POST si es necesario, pero no se hace normalmente.
3. En general, los datos confidenciales solo se deben pasar cuando se realiza una acción de algún tipo basada en esos datos confidenciales; y en los casos en los que esté realizando algún tipo de acción (como iniciar sesión; pasar datos seguros para que se almacenen / actúen en una base de datos), debe utilizar POST frente a GET.

En general, las reglas que evitan las falsificaciones de solicitudes entre sitios (CSRF, también conocida como XSRF) solo se activan para solicitudes POST. GET es el método de solicitud HTTP previsto para recuperar datos de un servidor web que no tiene ningún otro efecto (además de elementos benignos como rellenar un archivo de registro que indica que se solicitó esta página); POST es el protocolo para que un usuario envíe datos para realizar alguna acción (por ejemplo, como ordenar algo desde un sitio web; transferir dinero desde su cuenta bancaria; cambiar su contraseña). Ese es un token CSRF aleatorio que generalmente requiere la mayoría de los marcos para las solicitudes GET, pero a menudo se requerirá para las solicitudes POST.

(Y mientras Thomas Pornin y makerofthings7 tocaron en 1 y 2, respectivamente, he mencionado a ambos anteriormente en una pregunta algo similar .)

Si se puede evitar, siempre lo evito. Es solo una superficie de ataque más que debe dejarse cerrada a menos que haya un necesario> legítimo para permitir que se pasen datos en la cadena de consulta.

También siempre existe la posibilidad de que usted o un futuro desarrollador no filtre / desinfecte adecuadamente los datos y abra la superficie de ataque aún más amplia. Incluso en una aplicación insegura, si accidentalmente permites una inyección, un atacante malintencionado e inyectas scripts XSS y XSRF en tu base de datos y usas tu aplicación no sensible para atacar a otros, así que es mejor jugar de forma segura.

La navegación por los hombros es otra preocupación legítima, dependiendo del entorno. Si su aplicación se va a utilizar en un lugar donde sea posible (una biblioteca, un cubículo que alguien pueda ver y una oficina con un escritorio orientado en la dirección equivocada, etc.) es una posible preocupación. Si todas las personas que usan su aplicación están en habitaciones en las que el escritorio está orientado para que la navegación por los hombros no sea un problema, no se preocupe. pero si no lo sabe con seguridad, y no sabe que será siempre de esa manera, es una preocupación.