Quanto è facile hackerare JavaScript (in un browser)?

La mia domanda ha a che fare con la sicurezza JavaScript.

Immagina un sistema di autenticazione in cui stai utilizzando un framework JavaScript come Backbone o AngularJS e hai bisogno di endpoint sicuri. Questo non è un problema, poiché il server ha sempre l'ultima parola e controllerà se sei autorizzato a fare quello che vuoi.

E se fosse necessario un po 'di sicurezza senza coinvolgere il server? È possibile?

Ad esempio, supponiamo che tu abbia un sistema di routing sul lato client e desideri che un percorso concreto sia protetto per gli utenti che hanno effettuato l'accesso. Quindi esegui il ping del server chiedendoti se ti è permesso visitare percorsi protetti e vai avanti. Il problema è che quando esegui il ping del server, memorizzi la risposta in una variabile, quindi la prossima volta che vai su una route privata, controllerà che se hai già effettuato l'accesso (nessun ping al server) e a seconda sulla risposta andrà o no.

Quanto è facile per un utente modificare quella variabile e ottenere l'accesso?

La mia conoscenza della sicurezza (e JavaScript) non è eccezionale. Ma se una variabile non è nell'ambito globale ed è nella parte privata di un modello di modulo che ha solo getter ma non setter, anche in quel caso, puoi hackerare la cosa?

Si prega di leggere la risposta di Joachim prima di leggere questo. Copre le ragioni generali alla base della vulnerabilità sul lato client. Ora, per un suggerimento su come aggirare questo problema ...

Uno schema sicuro per la comunicazione client-server senza dover eseguire l'autenticazione con il server manualmente su ogni richiesta:

Stai ancora lasciando che il server abbia l'ultima parola, e il server deve ancora convalidare tutto ciò che dice il client, ma succede in modo trasparente.

Supponiamo che il protocollo HTTPS prevenga gli attacchi man-in-the-middle (MITMA).

• Il client stringe la mano al server per la prima volta e il server genera una chiave pubblica per il client e ne mantiene una privata utilizzando uno schema di crittografia asimmetrica. Il client memorizza la chiave "pubblica" del server nella memoria locale, crittografata con una password sicura che non si salva da nessuna parte.

• Il client è ora offline. Il cliente desidera eseguire azioni attendibili. Il client immette la sua password e prende la chiave pubblica del server.

• Il client ora esegue azioni in base alla sua conoscenza di tali dati e crittografa tutte le azioni che esegue con la chiave pubblica del server per quel client .

• Quando il client è online, il client invia l'ID client e tutte le azioni eseguite dal client vengono inviate al server crittografate con la chiave pubblica del server.

• Il server decodifica le azioni e, se sono nel formato corretto, si fida del fatto che hanno avuto origine nel client.

Nota:

• Non è possibile memorizzare la password del client da nessuna parte, altrimenti un utente malintenzionato sarebbe in grado di recuperare la chiave e firmare le azioni come proprie. La sicurezza di questo schema si basa esclusivamente sull'integrità della chiave generata dal server per il client. Il client dovrebbe comunque essere autenticato con il server quando richiede quella chiave.

• In realtà stai ancora facendo affidamento sul server per la sicurezza e non sul client. Ogni azione eseguita dal client deve essere convalidata sul server.

• È possibile eseguire script esterni nei web worker . Tieni presente che ogni richiesta JSONP che hai ora è un problema di sicurezza molto più grande. È necessario proteggere la chiave a tutti i costi. Una volta perso, un utente malintenzionato può impersonare l'utente.

• Ciò soddisfa la tua richiesta che non venga eseguito "nessun ping al server". Un utente malintenzionato non può semplicemente imitare una richiesta HTTP con dati falsi se non conosce la chiave.

• La risposta di Joachim è ancora corretta . In effetti, stai ancora eseguendo tutta l'autenticazione sul server . L'unica cosa che hai salvato qui è la necessità di convalidare la password con il server ogni volta. Ora è necessario coinvolgere il server solo quando si desidera eseguire il commit o estrarre i dati aggiornati. Tutto ciò che abbiamo fatto qui è salvare una chiave attendibile sul lato client e far riconvalidare il client.

• Questo è uno schema abbastanza comune per le applicazioni a pagina singola (ad esempio, con AngularJS).

• Chiamo la chiave pubblica del server "pubblica" a causa di ciò che significa in schemi come RSA , ma in realtà sono informazioni sensibili nello schema e dovrebbero essere salvaguardate.

• Non conserverei la password in nessun punto della memoria. Farei in modo che l'utente invii la sua password "offline" ogni volta che inizia a eseguire il codice offline.

• Non eseguire il rollup della tua crittografia : utilizza una libreria nota come quella di Stanford per l'autenticazione.

• Prendi questo consiglio così com'è . Prima di eseguire questo tipo di autenticazione in un'applicazione business-critical del mondo reale, consultare un esperto di sicurezza . Questo è un problema serio che è sia doloroso che facile da sbagliare.

È fondamentale che nessun altro script abbia accesso alla pagina. Ciò significa che permetti solo script esterni con i web worker. Non puoi fidarti di nessun altro script esterno che potrebbe intercettare la tua password quando l'utente la inserisce.

Utilizzare una prompte non un campo password in linea se non sei del tutto sicuro e non indugiare la sua esecuzione (che è, non dovrebbe vivere a un punto in cui gli eventi hanno accesso ad esso, ma solo nel codice di sincronizzazione). E in realtà non archiviare la password in una variabile - di nuovo, funziona solo se ritieni che il computer dell'utente non sia compromesso (anche se questo è vero anche per la convalida su un server).

Vorrei aggiungere ancora che non ci fidiamo ancora del cliente . Non puoi fidarti del cliente da solo, e penso che la risposta di Joachim lo inchioda. Abbiamo solo ottenuto la comodità di non dover eseguire il ping del server prima di iniziare a lavorare.

Materiale correlato:

• Certificati vs nome utente + password .
• Perché non possiamo garantire la sicurezza tramite il lato client?
• Non lanciare la tua criptovaluta.
• Discussione correlata su come rendere sicuro JS per le operazioni di crittografia

È semplice: qualsiasi meccanismo di sicurezza che si basa sul client per fare solo ciò che gli dici di fare può essere compromesso quando un utente malintenzionato ha il controllo sul client.

È possibile avere controlli di sicurezza sul client, ma solo per agire efficacemente come una "cache" (per evitare di fare un costoso di andata e ritorno al server se il client sa già che la risposta sarà "no").

Se si desidera mantenere le informazioni da un gruppo di utenti, assicurarsi che il client di tali utenti non ottenga mai tali informazioni. Se invii quei "dati segreti" insieme alle istruzioni "ma per favore non visualizzarli", diventerà banale disabilitare il codice che controlla quella richiesta.

Come vedi, questa risposta in realtà non menziona specifiche di JavaScript / Browser. Questo perché questo concetto è lo stesso, indipendentemente dal tuo cliente. Non importa che si tratti di un client fat (app client / server tradizionale), un'applicazione web di vecchia scuola o un'app a pagina singola con JavaScript esteso sul lato client.

Una volta che i tuoi dati lasciano il server, devi presumere che un utente malintenzionato abbia pieno accesso ad esso.

C'è un detto nella comunità di gioco: " Il cliente è nelle mani del nemico". Qualsiasi codice in esecuzione al di fuori di un'area protetta come il server è vulnerabile. Nello scenario più semplice, vulnerabile a non essere eseguito in primo luogo. È la decisione del cliente di eseguire effettivamente il" codice di sicurezza "e l'utente può semplicemente "opt out". Mentre con il codice nativo hai almeno un offuscamento automatico nell'assemblaggio e un ulteriore livello di protezione dal fatto che un utente malintenzionato deve essere un buon programmatore per manipolarlo, JS viene normalmente non confuso e come testo semplice. Tutto ciò di cui hai bisogno per mettere in scena un attacco sono strumenti primitivi come un server proxy e un editor di testo. L'attaccante avrà comunque bisogno di un certo livello di istruzione riguardo alla programmazione, ma è molto più semplice modificare uno script usando qualsiasi texteditor che iniettare codice in un eseguibile.

Questa non è una questione di hacking di JavaScript. Se volessi attaccare la tua app, utilizzerei un proxy privato che mi consentirebbe di acquisire, modificare e riprodurre il traffico. Il tuo schema di sicurezza proposto non sembra avere alcuna protezione in atto contro questo.

Parlando specificamente di Angular:

La protezione di una route client non esiste. Anche se 'nascondi' un pulsante per quel percorso in cui l'utente può sempre immetterlo, Angular si lamenterà, ma il client può codificarlo.

A un certo punto il controller dovrà richiedere al server i dati necessari per eseguire il rendering della vista, se l'utente non è autorizzato ad accedere a tali dati, non li riceveranno poiché sono stati protetti questi dati sul lato server e la tua app Angular dovrebbe gestire il 401 in modo appropriato.

Se stai cercando di proteggere i dati non elaborati, non puoi lato client, se desideri che un determinato utente sia in grado di visualizzare solo i dati comuni in un determinato modo, crea le "visualizzazioni" dei dati sul server anziché inviare dati grezzi per il client e averli riorganizzati (dovresti già farlo per motivi di prestazioni).

Nota a margine: non dovrebbero mai esserci elementi sensibili integrati nei modelli di vista richiesti da Angular, ma non farlo. Se per qualche motivo folle esiste, è necessario proteggere quei modelli di vista sul lato server, proprio come se si stesse eseguendo il rendering sul lato server.