¿Cuáles son las vulnerabilidades de seguridad de un sitio web que me permite iniciar sesión mediante POSTing de los datos del formulario mediante programación?

Esto no suena como una vulnerabilidad en absoluto.

Si entiendo bien, ¿tienes que usar tu propio nombre de usuario y contraseña? Hacer una solicitud POST con eso es exactamente lo que hace su navegador una vez que presiona el botón de inicio de sesión. Que el servidor utilice otro programa para enviar la solicitud es imposible que el servidor lo sepa y no importa mucho. Cualquier cliente es tan bueno como cualquier otro. No hay "clientes autorizados", solo hay clientes.

Piénsalo así. Si escribo un programa que envía exactamente las mismas solicitudes HTTP que Firefox, ¿cómo podría su servidor diferenciarlas entre ellas? Todo lo que el servidor ve es la solicitud, no el propio cliente. Si descargo el código fuente de Firefox y lo modifico para mis propósitos, ¿cómo lo sabría su servidor? (Esto, por cierto, también es la razón por la que el servidor nunca puede confiar en el comportamiento del cliente para hacer cumplir la seguridad).

Además, si esto fuera considerado como una vulnerabilidad, ¿cómo podría un atacante explotarlo? Un atacante no sabría su contraseña, por lo que no podría POSTARLA, no importa si se hace "programáticamente" o desde un navegador.

Usted menciona que la cookie es "insegura". Si quiere decir que no tiene el indicador de seguridad establecido, es una mala práctica. Y podría ser una señal de que están sirviendo parte de su sitio a través de HTTP simple, lo cual tampoco es bueno.

Como han señalado otros, enviar sus credenciales de inicio de sesión (nombre de usuario + contraseña) es exactamente lo que hace cada cliente, ya sea Postman, un script que invoca a curl , un navegador web o cualquier otra cosa, lo hace. Sin embargo, hay algunos riesgos que pueden ocurrir con un sistema de inicio de sesión:

• ¿El sistema permite especificar una página a la que se le redirige después de iniciar sesión? Si es así, ¿permite especificar que el dominio del enlace sea algo que el propietario del sitio no posee también? Esa es una vulnerabilidad de Open Redirect , que se puede usar en combinación con otros ataques para evitar ciertos tipos de filtrado y / o hacer que sea más probable que las víctimas caigan en un ataque de phishing u otra forma de página web maliciosa. .
• En relación con lo anterior, ¿puede redireccionar al usuario a un esquema de URI diferente, como javascript: en lugar de http: o https: ? Si es así, un atacante puede potencialmente obtener un XSS en el usuario inmediatamente después de la autenticación, que podría usarse para realizar acciones como víctima y (si el navegador no navega realmente pero ejecuta el script) incluso puede robar las credenciales de inicio de sesión del usuario.
• En el caso de credenciales de inicio de sesión incorrectas, ¿la solicitud POST devuelve una página de error que es vulnerable a XSS? Por ejemplo, si envía un nombre de usuario que contiene < o " de caracteres y se reflejan en la respuesta por falla sin la codificación correcta, entonces un atacante podría "vincularlo a la página de inicio de sesión" desde otro sitio web, mientras que en realidad inyectando un script que robe sus credenciales si inicia sesión.
• Si no se requieren tokens adicionales, el sitio puede correr el riesgo de inicio de sesión CSRF , donde un atacante obliga a la víctima a iniciar sesión en un servicio con una cuenta que controla el atacante. Si bien esto no es un problema en la mayoría de los servicios, si me inicia sesión en su cuenta de StackOverflow, por ejemplo, eso significa que puedo usar StackOverflow bajo su nombre (lo que no le ayuda): algunos servicios que realmente no usa. desea utilizar mientras inicie sesión en la cuenta de otra persona. Por ejemplo, imagine un administrador de contraseñas que tenga una extensión de navegador y, cada vez que inicie sesión en un servicio, le preguntará si desea recordar su contraseña. Si puedo forzar la extensión del navegador de su administrador de contraseñas para que use una cuenta a la que tengo acceso, en lugar de su cuenta habitual, entonces si guarda una contraseña en ella, podré recuperarla más adelante. Sin embargo, la mayoría de las veces, el inicio de sesión CSRF no es una preocupación.
• Finalmente, mencionas brevemente el riesgo de que alguien intente forzar tu contraseña de forma bruta mediante el envío programado de un gran número de solicitudes de inicio de sesión. Esto es absolutamente un riesgo, y un sistema de inicio de sesión bien diseñado tendrá protecciones contra él. Si realiza una gran cantidad de solicitudes de inicio de sesión incorrectas (el umbral suele estar en algún lugar dentro del rango de 5 a 10 veces), debe suceder algo. Algunas buenas medidas incluyen exigirle que resuelva un CAPTCHA antes de que pueda volver a intentarlo (para interrumpir el cifrado) o deshabilitar el inicio de sesión en la cuenta pero enviar un correo electrónico a la dirección asociada, con un enlace que lo conectará. Tenga en cuenta que otros enfoques comunes (como simplemente bloquear la cuenta por unos minutos) no son una buena idea, ya que un atacante puede bloquear usuarios legítimos enviando deliberadamente malos intentos de inicio de sesión como esos usuarios.

Ahora, dicho esto, veamos algunos otros problemas que mencionaste. Si la cookie que almacena el token de autenticación no tiene el indicador Secure establecido, es una vulnerabilidad importante . Cualquier atacante en la misma red que podría secuestrar su sesión interceptando una página web que se sirve en texto sin formato y agregando una solicitud de texto sin formato (por ejemplo, una solicitud de script simple que no hace más que hacer que su navegador envíe una solicitud GET) al sitio vulnerable, luego robar la cookie cuando su navegador realiza esa solicitud a través de HTTP simple. Cualquier página web a la que le importe si el usuario ha iniciado sesión solo debería estar accesible a través de HTTPS; de lo contrario, un atacante puede realizar ataques aún más simples como Firesheep para secuestrar su sesión, y por lo tanto, no hay razón para tener tokens de autenticación en cookies no seguras. El indicador HttpOnly es mucho menos vital: hay ataques XSS que pueden ejecutarse independientemente de si el script puede leer sus cookies o no, pero en general también debería configurarse.

Volviendo a HTTPS, el sitio debería estar utilizando HTTP Strict Transport Security (HSTS), que protege contra ataques como SSLStrip ; cualquier sitio que requiera autenticación debe usar HSTS, ya que es solo un encabezado ( Strict-Transport-Security ) en la respuesta HTTP.