Quali sono le vulnerabilità della sicurezza per un sito Web che mi consente di effettuare l'accesso POSTing dei dati dei moduli in modo programmatico?

Questa non sembra affatto una vulnerabilità.

Se ti capisco bene, devi usare il tuo nome utente e la tua password? Fare una richiesta POST con quelli è esattamente ciò che fa il browser una volta che si preme il pulsante di accesso. Che tu usi un altro programma per inviare la richiesta è impossibile da conoscere per il server, e non importa molto comunque. Ogni cliente è buono come qualsiasi altro. Non ci sono "clienti autorizzati", ci sono solo clienti.

Pensa in questo modo. Se scrivo un programma che invia esattamente le stesse richieste HTTP di Firefox, come potrebbe distinguere il server tra loro? Tutto il server vede è la richiesta, non il client stesso. Se scarico il codice sorgente per Firefox e lo modifico per i miei scopi, come lo saprebbe il tuo server? (Questo, a proposito, è anche il motivo per cui il server non può mai fare affidamento sul comportamento del client per rafforzare la sicurezza.)

Inoltre, se questa dovesse essere considerata una vulnerabilità, come potrebbe un hacker sfruttarla? Un utente malintenzionato non conoscerà la tua password, quindi non potrebbe POSTarlo, non importa se è fatto "programmaticamente" o da un browser.

Hai detto che il cookie è "insicuro". Se vuoi dire che non ha il flag sicuro, allora è una cattiva pratica. E potrebbe essere un segno che stanno scontando parte del loro sito su un semplice HTTP, il che non va bene neanche.

Come altri hanno notato, l'invio delle credenziali di accesso (username + password) è esattamente ciò che fa ogni client - che sia Postman, uno script che richiama curl , un browser Web o qualsiasi altra cosa. Ci sono alcuni rischi che possono verificarsi con un sistema di accesso, però:

• Il sistema consente di specificare una pagina a cui viene reindirizzato dopo l'accesso? In tal caso, consente di specificare che il dominio del link è qualcosa che il proprietario del sito non possiede? Questa è una vulnerabilità Open Redirect , che può essere utilizzata in combinazione con altri attacchi per aggirare certi tipi di filtri e / o renderla più probabile che le vittime cadano per un attacco di phishing o altra forma di pagina Web dannosa .
• In relazione a quanto sopra, puoi reindirizzare l'utente a un diverso schema URI, ad esempio javascript: anziché http: o https: ? In tal caso, un utente malintenzionato può potenzialmente ottenere un XSS all'utente subito dopo l'autenticazione, che potrebbe essere utilizzato per intraprendere azioni come vittima e (se il browser non naviga ma esegue lo script) ruba anche le credenziali di accesso dell'utente.
• In caso di credenziali di accesso errate, la richiesta POST restituisce una pagina di errore vulnerabile a XSS? Ad esempio, se invii un nome utente che contiene < o " caratteri e si riflettono nella risposta per errore senza codifica corretta, un utente malintenzionato potrebbe "collegarti alla pagina di accesso" da un altro sito web, mentre in realtà iniettare uno script che ruba le tue credenziali se effettui il login.
• Se non sono richiesti token aggiuntivi, il sito potrebbe essere esposto a login CSRF , in cui un utente malintenzionato costringe una vittima ad accedere a un servizio utilizzando un account controllato dall'hacker. Anche se questo non è un problema nella maggior parte dei servizi - se mi accedi al tuo account StackOverflow, ad esempio, questo significa che posso usare StackOverflow sotto il tuo nome (che non ti aiuta) - alcuni servizi che davvero non voglio usare mentre sei loggato nell'account di qualcun altro. Ad esempio, immagina un gestore di password che abbia un'estensione per il browser e, ogni volta che accedi a un servizio, ti chiede se vuoi che ricordi la tua password. Se riesco a forzare l'estensione del browser del gestore di password a utilizzare un account a cui ho accesso, invece del tuo account abituale, quindi se salvi le password, sarò in grado di recuperarle in un secondo momento. Il più delle volte, però, accedere a CSRF non è un problema.
• Infine, si cita brevemente il rischio che qualcuno provi a forzare la password tramite l'invio a livello di codice di un numero elevato di richieste di accesso. Questo è assolutamente un rischio, e un sistema di login ben progettato avrà protezioni contro di esso. Se si effettua un numero elevato (la soglia è in genere da qualche parte nell'intervallo 5-10x) di richieste di accesso errate, qualcosa dovrebbe accadere. Alcune buone misure includono la richiesta di risolvere un CAPTCHA prima di poter riprovare (per interrompere la forzatura bruta basata su script) o disattivare la registrazione nell'account ma inviare una e-mail all'indirizzo associato, con un collegamento che effettuerà l'accesso. Nota che alcuni altri approcci comuni (come il blocco dell'account per pochi minuti) non sono una buona idea, in quanto un utente malintenzionato può bloccare gli utenti legittimi inviando intenzionalmente tentativi di accesso non validi come tali utenti.

Ora, con ciò detto, diamo un'occhiata ad altri problemi che hai menzionato. Se il cookie che memorizza il token di autenticazione non ha il flag Secure impostato, questa è una vulnerabilità maggiore . Qualsiasi utente malintenzionato sulla stessa rete in cui è possibile dirottare la sessione intercettando una pagina Web che viene pubblicata in testo semplice e aggiungendo una richiesta di testo normale (ad esempio, una semplice richiesta di script che non fa altro che far inviare al browser una richiesta GET) al sito vulnerabile, quindi rubare il cookie quando il browser effettua tale richiesta su un semplice HTTP. Qualsiasi pagina web a cui interessa se l'utente ha effettuato l'accesso deve essere sempre accessibile solo tramite HTTPS; in caso contrario, un utente malintenzionato può eseguire anche attacchi più semplici come Firesheep per dirottare la sessione - e quindi non c'è motivo di avere mai token di autenticazione in cookie non sicuri. Il flag HttpOnly è molto meno vitale: esistono degli attacchi XSS che possono essere eseguiti indipendentemente dal fatto che lo script possa o meno leggere i cookie, ma in generale dovrebbe essere impostato anche.

Tornando a HTTPS, il sito dovrebbe davvero utilizzare HTTP Strict Transport Security (HSTS), che protegge da attacchi come SSLStrip ; qualsiasi sito che richiede l'autenticazione dovrebbe utilizzare HSTS, poiché è solo un'intestazione ( Strict-Transport-Security ) nella risposta HTTP.