Recentemente ho scoperto che se usi l'elemento inspect per vedere il codice sorgente dell'Html, puoi cambiare questo <input type="password"/> in <input type="text"/> , quindi puoi vedere la password rivelata, quindi, come posso evitarlo angularJS? o puro Javascript?
Ogni oscurità nella luce sarà apprezzata.
Sembra un brutto caso di Security Theatre
Security theater is the practice of investing in countermeasures intended to provide the feeling of improved security while doing little or nothing to actually achieve it.
Dico questo perché in tutta la realtà ...
Given enough time, effort, and computing power security is nothing more than a delay.
Certo, va peggio di così. Javascript è un linguaggio basato su computer, il che significa che deve essere eseguito da una macchina. Quella macchina può dire di ignorare il tuo Javascript.
Ciò significa in realtà che stai chiedendo la domanda sbagliata . Cosa stai veramente chiedendo:
How do you keep your forms safe from someone using saved passwords to fill out the form, and then changing the type of the form to read it?
E a questa risposta è piuttosto semplice:
Mantieni il tuo terminale sicuro e protetto. L'unico modo per prevenire questo tipo di attacco è quello di non permettere a un utente malintenzionato su un sistema con una password salvata in primo luogo.
Perché? Perché hai uno "spettro". Chiamiamolo lo spettro di sicurezza in questo esempio semplificato:
Alla base della sicurezza semplice hai il seguente:
Sicurezza > ----------------------------------------- ----- < Facilità d'uso
Nella maggior parte dei casi questo è ciò che accade:
La sicurezza che hai, la less facilità d'uso che hai.
La più facilità d'uso che hai, meno sicurezza che hai.
Usando un modulo che contiene una password e lasciandolo lì, sei crescente tuo Facilità d'uso e decrescente tuo < em> Sicurezza
Non c'è modo di impedire a un utente malintenzionato di farlo se sta già accedendo agli strumenti di sviluppo: possono semplicemente mettere in pausa il javascript e continuare quello che stanno facendo. Il meglio che potresti essere in grado di fare è cancellare la casella della password dopo una piccola quantità di inattività.
La linea di fondo è che non puoi, ma non è tanto un problema come si potrebbe pensare .
La cosa da tenere a mente è che quando cambi la sorgente nel debugger di un browser (che è ciò che stai descrivendo), non viene salvato da nessuna parte . Ciò significa che la modifica riguarda solo la macchina su cui è in esecuzione il debugger. Non posso cambiare il campo della password in "testo" sulla macchina di tutti , solo mia. Significa anche che la modifica ha effetto solo fino alla prossima volta che la pagina viene caricata, quindi anche se l'ho impostato una volta, non posso trasformare una macchina in un robot che raccoglie password facendo questo.
Un'altra cosa da tenere a mente è che gli script non devono modificare il tipo di campo della password per ottenere il valore . Possono farlo attraverso semplici script vecchi, e ci sono dei veri vantaggi nel farlo in quel modo. Il più grande è che dal momento che non si modifica il tipo di campo, l'utente non vede nulla di insolito, quindi gli utenti non vengono informati che qualcosa potrebbe essere sbagliato.
Ora, tutto questo ha detto, tu fai devi essere cauto degli attacchi cross-site scripting , che possono fare il genere di cose che hai menzionato (anche se sono ancora non è necessario modificare il tipo di campo per ottenere il suo valore). Esistono già numerose best practice per evitare attacchi XSS e i comuni metodi di evasione del filtro XSS sono ben noti, quindi puoi anche testarli. Nessuno di questi fermerà il trucco del debugger, ma come descritto sopra, il trucco del debugger non ha bisogno di essere fermato: XSS sì.
La linea di fondo è che non è necessario allarmarsi per il debugger del browser. Ci sono attacchi correlati di cui dovresti essere preoccupati, ma sono ben studiati e nessuno di essi riguarda il debugger del browser.
Non puoi farlo perché tutto sta accadendo dal lato del client e ha quasi pieno accesso al tuo codice (html, css, javascript) usando strumenti di sviluppo. Quindi, può mettere in pausa o interrompere javascript.
Se sei davvero preoccupato di questo, puoi eliminare completamente le password nella tua applicazione. Chiedi all'utente di inserire il nome utente o l'e-mail e di inviare loro un'email con un link di accesso temporaneo.
Non puoi. Il modulo deve essere in grado di inviare la password al server per la convalida. Anche se sviluppi una sorta di tecnica di offuscamento (non consigliato), allora, come ha detto William Dunne, puoi semplicemente mettere in pausa / interrompere Javascript.
Stai cercando di raggiungere la sicurezza attraverso l'oscurità e non funzionerà.
Potresti essere in grado di usare div e altri elementi per creare il tuo campo di testo, un po 'come i campi di testo sui moduli di Google. Se lo hai fatto, puoi configurarlo in modo che, quando l'utente digita, modifichi semplicemente il contenuto di una variabile JavaScript crittografata e in realtà non digiti nel campo di testo.
In Javascript, per le password già salvate, un modo potrebbe essere:
Qualcuno può comunque leggere la password dalla variabile tramite javascript
ad esempio:
console.log( passwordVAR );
Leggi altre domande sui tag javascript angularjs