¿Es una mala práctica usar el método GET como nombre de usuario / contraseña de inicio de sesión para los administradores?

45

Trabajo en aplicaciones web y, como saben, tener un panel de administradores es una necesidad en la mayoría de los casos. Podemos ver que muchas aplicaciones web tienen una página de inicio de sesión específica para administradores en la que hay un formulario (generalmente el método POST ) que los administradores pueden usar para iniciar sesión en su panel.

Pero como los nombres de los campos son conocidos, un pirata informático puede intentar descifrar las contraseñas incluso si se implementan algunos métodos de seguridad.

Entonces, ¿cuál es el problema con una simple clave GET (como nombre de usuario) y su valor (como contraseña)? ¿Por qué no se usa mucho o, al menos, no se sugiere en muchos artículos?

¡Para los administradores, las páginas de inicio de sesión fáciles de usar no son realmente necesarias! Los datos se registrarán en ambos casos ( GET / POST ) si hay un atacante MiTM.

Pero usando este método, los campos serán desconocidos, y los administradores los esperan.  Aquí hay un ejemplo de código PHP:

"category.php": (Un nombre de página sin significado)

<?php
if (isset($_GET['meaningless_user']) && $_GET['meaningless_word'] == "something"){
    session_start();
    $_SESSION["user"] = "test";
    header('Location: category.php');   // Redirect to same or other page so GET parameters will disappear from the url     
} else {
    die(); // So it'll be like a blank page
}
?>
    
pregunta Amirreza Nasiri 04.01.2017 - 03:44
fuente

9 respuestas

58

Se me ocurren varias razones por las que esto no sería lo ideal:

  • En el fragmento de código que publicaste, ahora estás codificando una clave secreta en el código fuente de tu programa. Esto es malo porque ahora, si desea publicar o compartir su código fuente con otra persona, tendrá que acordarse de redactar esa clave. La seguridad de un sistema no debe depender de que su código fuente permanezca oculto.
  • Esto no escala bien. Si solo tiene una clave secreta que todos los administradores deben compartir, es mucho más fácil filtrarla accidentalmente. Si se filtra, no tendría forma de saber quién fue el responsable de filtrarlo. Podría proporcionar una clave diferente a cada administrador, pero esto se vuelve desordenado muy rápidamente.
  • No puedes cambiar la clave fácilmente. En general, es probable que necesite que los administradores del sitio sean no y también operadores de servidores. Pero con esta configuración, no puede otorgar a nadie la capacidad de cambiar la clave sin otorgar también acceso al código fuente y al servidor, que pueden o no saber cómo usar el identificador. Ajustar el código fuente que se ejecuta en un sistema de producción de forma voluntaria es propenso a errores y probablemente dará lugar a un tiempo de inactividad.
  • Debido a que utiliza GET, es muy fácil que la clave se filtre a través de los historiales del navegador, o el intercambio accidental de enlaces.
  • No es muy fácil de usar. Usar esto requiere saber cómo manipular manualmente un parámetro GET específico. Usted dice que la facilidad de uso para los administradores no es necesaria, pero esto definitivamente no es cierto en general. Todo el sitio debe ser lo más fácil de usar posible, incluido el panel de administradores.

En resumen, puedo ver este tipo de sistema en uso como una medida temporal en un sitio pequeño, donde hay un administrador del sitio que también escribió el código fuente del sitio y administra el servidor. Pero cualquier cosa más grande que eso, querrá tener un panel de inicio de sesión de administrador real, con credenciales hash y salted almacenadas en la base de datos como cualquier otro usuario.

    
respondido por el tlng05 04.01.2017 - 04:51
fuente
132

Esto almacenaría el enlace de inicio de sesión con contraseña y nombre de usuario en el historial de los navegadores. También podría ser capturado accidentalmente por cosas como los registros de firewall, que no capturarían las variables de publicación.

    
respondido por el jdow 04.01.2017 - 04:29
fuente
25

¿Qué tan cómodo está con el almacenamiento de contraseñas de administrador en texto sin cifrar en los registros de acceso de su servidor web?

El problema que veo aquí es que una solicitud GET debe poner todos los nombres y valores de los campos en el URI de la solicitud. Los URI de solicitud se registran por todo tipo de procesos y probablemente se almacenarán, en su totalidad, en el registro de acceso del servidor web.

Eso significa que su registro de acceso al servidor web aumenta el riesgo de seguridad porque ahora contiene los nombres de usuario y las contraseñas de las páginas de inicio de sesión basadas en GET. Si bien, por lo general, puede considerar que los registros del servidor contienen información privilegiada (por ejemplo, las direcciones IP de sus clientes), no suelen ser tan confidenciales como para contener suficiente información para comprometer la interfaz administrativa de un cliente.

POST es superior para esto, porque los nombres de campo y los valores no se almacenan en el registro.

    
respondido por el Andy Holland 04.01.2017 - 12:40
fuente
25

No estrictamente desde una postura de seguridad, pero Protocolo de transferencia de hipertexto - HTTP / 1.1 RFC 2616 lo deja bastante claro:

  

... se ha establecido la convención de que los métodos GET y HEAD NO DEBEN tener la importancia de realizar una acción que no sea la recuperación . Estos métodos deben considerarse "seguros". Esto permite que los agentes de usuario representen otros métodos, como POST, PUT y DELETE, de una manera especial, para que el usuario tenga conocimiento del hecho de que se está solicitando una acción insegura.

GET debe usarse solo para recuperación. En su caso, está enviando datos al servidor, el servidor está realizando estas acciones específicas (como mínimo):

  • Autentificando a un usuario
  • Crear una sesión para rastrear el estado del usuario (PHP crea datos de sesión en archivos sin formato o en una base de datos)
  • Configuración de una cookie de sesión para rastrear la sesión

POST sobre HTTPS sería el método preferido para transmitir datos confidenciales; nombre de usuario, contraseña en este caso.

    
respondido por el AbraCadaver 04.01.2017 - 15:42
fuente
4

Un usuario malicioso obtiene credenciales de administrador. Usando una etiqueta de imagen

<img src="https://example.com/login?username=admin&amp;password=topsecret"style="display:none"> 

engañan a su navegador para iniciar sesión (las imágenes no están sujetas a restricciones de dominio de forma predeterminada). Luego, pueden usar una serie de llamadas de "imagen" para obtener o cambiar datos (muchas de las llamadas AJAX también usan GET de manera incorrecta). Hay formas de evitar esto , pero la mayoría de las personas no las habilitan. Si estás usando POST, este vector de ataque no funciona.

    
respondido por el Machavity 04.01.2017 - 19:04
fuente
3

El problema de usar el método de obtención es que los datos estarán visibles en la pantalla y en los registros del servidor web de forma predeterminada.

Mi regla de oro es el uso de entradas para contraseñas y gran información como editores de artículos de blogs y uso para obtener todo lo demás. Por supuesto, hay algunas excepciones en las que los datos son demasiado sensibles para aparecer incluso en los registros. Pero esos son raros incluso en el sector corporativo.

Por ejemplo, tengo una funcionalidad tipo asistente con 5 pasos en los que genero una ID de proceso en el primer paso y en cada paso verá ?proc_id=123 . PHP soporta la cadena de consulta incluso en métodos posteriores. Incluso en un paso en el que los datos del formulario son demasiado grandes y me veo obligado a usar el método de publicación, la identificación del proceso aún se hace visible en la URL como ?proc_id=123 .

Esto hace que sea más fácil marcar las cosas, más fácil de entender los registros de acceso, y también más educativo para terceros que quieran integrarse con mis aplicaciones.

Se deben tomar algunas precauciones en ese escenario para evitar problemas con el botón de retroceso, como borrar las URL de historial que no se deben volver a enviar. La mayoría de las acciones de guardar son así.

Por supuesto, el POST no lo protegerá de un ataque MiTM. Solo evitará que la información confidencial, como las contraseñas, se escriba en los registros de su sitio y en el historial local del navegador.

    
respondido por el Lucas 04.01.2017 - 13:11
fuente
3

También considere que las solicitudes GET están destinadas a no cambiar nada en el lado del servidor. Un cambio de estado como "desconectado" - > El "inicio de sesión" siempre debe hacerse con una solicitud POST.

Tener un parámetro GET como

https://example.com/loginpage.php?password=topsecret 

es semánticamente exactamente igual que

https://example.com/loginpage/password/topsecret 

Así que no hay autenticación en absoluto. Es solo una URL "secreta" que debes conocer para "iniciar sesión".

Para que sea más claro. Si usa Apache, por ejemplo, puede obtener el mismo resultado con una redirección como esta:

RedirectTemp password/topsecret veryobfuscateddirectoryname/loggedin

y luego, en la página de inicio de sesión, coloca tu session_start()

    
respondido por el Andre Geddert 04.01.2017 - 17:04
fuente
1

Sí, es una mala práctica. Cualquier ventaja de seguridad disponible al tener un nombre de campo secreto también se puede obtener al insertar ese secreto en la contraseña.

En lugar de GET con

elephant=rthg4e5sdc

sería mejor usar POST con

password=elephantrthg4e5sdc

Y, por supuesto, puede aumentar la seguridad de nuevo cambiando eso a algo más como

password=ehu3dva7rthg4e5sdc
    
respondido por el bdsl 07.01.2017 - 00:44
fuente
1

Incluso si el usuario y la contraseña no fueron almacenados en el historial del navegador (como lo son, como parámetros de URL), esto hace que sea extremadamente fácil para cualquier pirata informático robar su información. Aparecerá en los registros del servidor, hace que sea incluso más fácil realizar un ataque de hombre en el medio. También permite muchas malas prácticas, como personas que marcan la URL de inicio de sesión, se olvidan y dejan que otros humanos utilicen su navegador web.

TL; DR: esta es una idea horrible.

    
respondido por el Leo Wilson 07.01.2017 - 16:55
fuente

Lea otras preguntas en las etiquetas