Stai assumendo che il controllo sia stato aggirato di proposito. Potrebbe essere il caso che qualcuno stia usando un browser che non riesce a gestire lo script correttamente o con gli script disabilitati, forse anche senza saperlo.

Sembra che tu abbia un motivo per cui le persone usano password complesse. Se lo fai, perché accettare che le persone possano aggirarlo?

La convalida lato client può essere utile dal punto di vista dell'usabilità, ma se decidi che è richiesta una sicurezza minima della password, dovresti applicarla implementando lato server.

La regola quando si scrive un'applicazione server è semplicemente non fidarsi mai di ciò che viene dal client . I controlli effettuati lato client sono ottimi in quanto consentono una piacevole esperienza utente con bei popup e visualizzazione immediata. Ma poiché tutto può succedere, da un browser javascript disabilitato a un utente che utilizza un linguaggio di scripting per simulare un browser, tutti i controlli devono essere eseguiti (di nuovo) lato server.

Se si consigliano solo password complesse, fare cosa vuoi, se sono un requisito, devi implementare un controllo lato server.

BTW: tu come sviluppatore puoi proporre soluzioni, ma il cliente esprime i requisiti. Se non sei d'accordo con loro puoi chiedere chiarimenti e proporre altre modalità, ma alla fine deciderà il cliente.

Se l'utente DEVE impostare una password complessa, il controllo della sicurezza della password solo dal lato client rappresenta una vulnerabilità.

Esempio

Se lavori in una grande azienda e hai per cambiare la tua password ogni 2 o 3 mesi alcune persone inizieranno a bypassare il controllo lato client della forza della password per usare una password più corta o migliore per memorizzare le password.Se queste password vengono utilizzate per derivare chiavi crittografiche, ad esempio per la crittografia multiutente dei file, diventa orribile ...

Soluzione

Controlla sempre la sicurezza della password sul server e facoltativamente controlla la forza della password sul client per diminuire le richieste a il server.

Libreria consigliata: ZXCVBN

• Utilizza la corrispondenza dei modelli e controlla le password più utilizzate per stimare la robustezza della password.
• È disponibile in più linguaggi di programmazione

Basandosi sulla risposta di Teun Vink, ci sono alcuni scenari del mondo reale in cui un utente può accidentalmente aggirare il controllo di sicurezza.

Supponiamo che un utente scarichi un blocco degli annunci come Adblock Plus o uBlock Origin . Quindi, a causa dell'errata configurazione degli script, uno di questi adblock blocca accidentalmente lo script che stavi utilizzando per verificare la sicurezza della password. Ora l'utente può inserire 1234 come password senza alcun controllo lato server per impedirlo.

O in alternativa, forse la memorizzazione nella cache locale ha dato il utilizza una versione precedente del tuo script. Forse hanno salvato la tua pagina web come file HTML statico sul desktop. Forse il PC dell'utente ha un virus che ha alterato il contenuto del tuo script. Come dice il detto comune ...

Non fidarti mai dell'utente.

Modifica: Vedi anche " Impossibile salvare il profilo quando maps.googleapis.com è bloccato" per un ottimo esempio del motivo per cui non dovresti mai fidarti dell'utente.

Dici che sia il controllo & che l'abilitazione del pulsante di invio sono uno script, quindi è sicuro anche se alcuni script vengono caricati e altri no. Quanto sei sicuro che queste due funzioni saranno sempre nello stesso script?

Suppongo che quello che sto dicendo è che suona come, allo stato attuale delle cose, significherebbe che qualcuno intenzionalmente fa qualcosa che sa essere una cattiva idea per ottenere una cattiva password, e tu sei d'accordo con quello; stai cercando di prevenire gli incidenti, non la stupidità intenzionale.

La cosa che mi preoccupa è che se questo script viene riformattato, & si divide, o la stupidità intenzionale diventa il tuo problema, o qualche utente malintenzionato scrive un lato client script apparentemente per aiutare le persone, ... allora sei nei guai.

Un possibile problema è che basta un solo saggio (che potrebbe essere abbastanza informato da usare quella tecnica per usare una password che non supera il controllo ed è comunque sicura!) per trovare un modo per hackerarlo - e distribuire l'hack a poche altre persone (che probabilmente ritiene abbastanza responsabili) che alla fine lo daranno a persone contro la cui mancanza di competenza in materia di sicurezza avrebbe dovuto difendere la soluzione.

Applica le regole sul server

Qualunque sia la regola che imposti, devono essere applicate a livello di server in ogni caso. Questo è vero per l'impostazione della password e per i campi obbligatori nei moduli, ad esempio (ad esempio, se un numero di telefono è richiesto al momento della registrazione, dovrebbe essere controllato nel server).

Aiuta il tuo utente sul client

Qualunque siano le regole che imponi sul server, dovresti aiutare il tuo utente il più possibile fornendo aiuto al client.

Può essere solo una spiegazione, stelle accanto ai campi obbligatori, che mostrano errori prima di inviare moduli, ...

Ma applica le regole sul server

Ma in ogni caso, non puoi fare affidamento sul client. Alcune persone bloccheranno JS. Alcune persone bloccheranno il flash. Ad un certo punto potresti aprire la tua API a terze parti, che potrebbero o meno far rispettare le tue regole per te.

Io, per esempio, a volte ho riattivato i pulsanti bloccati da JS perché ho trovato quel client - le regole applicate erano ridicole (es. la tua password deve contenere esattamente 8 caratteri, inclusi esattamente 1 lettera maiuscola, 1 numero e 1 carattere speciale solo in (! @ # $% & *?)), sperando che il server non li applicasse regole (cosa che spesso non accadeva).

Se le tue specifiche devono avere un insieme preciso di regole sulla password dei tuoi utenti, avere il lato client di convalida non soddisfa le specifiche.

Mi aspetto che l'azienda di pen test stia applicando un principio generale qui "fai tutta la convalida lato server" senza considerare il caso specifico in modo molto dettagliato.

Nel tuo scenario, in cui JavaScript non può essere disabilitato, io non vedere alcun rischio pratico per la sicurezza. Potrebbe esserci un rischio non tecnico se sono necessarie password complesse per un requisito normativo (ad esempio PCI-DSS).