Come prevenire gli attacchi contro le convalide del lato client?

Naviga le tue risposte
4

Ho un modulo di accesso in cui accetto il numero di cellulare dell'utente per il login.

Quando viene inviato un numero di cellulare, sto chiamando un JavaScript per convalidare il numero di cellulare. Le convalide del mio lato cliente consistono in verifiche come il numero di cellulare inizia con 9, 8 o 7, la lunghezza del numero di cellulare è uguale a 10 ecc.

Una volta che questo tipo di convalida è stato eseguito, sto controllando sul lato server se sono state immesse le corrispondenze di numero di cellulare e password (autenticazione).

Dato che ho alcuni controlli in JavaScript, uno può vedere la fonte e sapere che questo tipo di controlli ci sono. E si può modificare questo codice e lasciarlo riflettere per tutti gli utenti. Ad esempio, si può cambiare il codice che controlla se il numero di cellulare inizia con 9, 8 o 7 e sostituisce 9 con 1 (per esempio). Quindi, se uno immette il numero che inizia con 9, fallirà.

  1. Come prevenire questo tipo di attacchi? Il modo ovvio è di mettere questi controlli sul lato server, ma ho almeno 10 diversi controlli e non voglio sovraccaricare i controlli lato server.

  2. In che modo l'attaccante può modificare questi valori nel mio JavaScript e lasciare che rifletta per tutti gli utenti?

EDIT : il mio codice JavaScript lato client è simile a 

var checkMobileNumber = form.mobileNumber.value;
if (checkMobileNumber.charAt(0) != 9 && checkMobileNumber.charAt(0) != 8 && checkMobileNumber.charAt(0) != 7) {
  //Throw some error
}
    
posta Vikas V 21.02.2013 - 06:18
fonte

4 risposte

10

Effettuare 10 controlli sul lato server non mette probabilmente sotto stress il tuo server. A meno che non siate al punto di migliaia di richieste al secondo, starete bene. A quel punto, probabilmente implementeresti il clustering, ecc. La sicurezza vale sempre i cicli extra. La validazione lato client non è mai sufficiente. Quando pensi alla convalida, dovresti pensare a filtrare RAW HTTP senza tener conto del fatto che il "browser" potrebbe aver generato il contenuto.

Anche se c'è una convalida sul lato client, ci sono ancora attacchi Man-in-the-middle , dove possono modificare il contenuto della richiesta HTTP non elaborata dopo la verifica. La convalida lato client è davvero utile per l'utente finale, quindi non invia, quindi riceve un messaggio di errore e deve inviare nuovamente. Non considererei la convalida lato client in un'applicazione basata su browser per fornire alcuna sicurezza per l'elaborazione in corso sul server.

Per quanto riguarda il modo in cui un attacco può modificare la convalida, dipenderà da molte cose. Ad esempio, quali sono i valori dinamici sulla pagina: si prendono i parametri dalle stringhe di query (parametri GET) senza filtrare? Questo potrebbe portare ad attacchi XSS o CSRF perché possono modificare quei valori e la tua applicazione li elaborerà. Ovviamente puoi proteggerti da ciò con la corretta fuga e altre tecniche. L'attacco potrebbe anche aver caricato qualche tipo di script o proxy utente che può inserire codice nella pagina.

Dato che stai usando "riflesso", potresti voler leggere più specificamente su un "XSS riflesso", che è solo un tipo di vettore di attacco. Da OWASP :

Reflected attacks are those where the injected code is reflected off the web server, such as in an error message, search result, or any other response that includes some or all of the input sent to the server as part of the request. Reflected attacks are delivered to victims via another route, such as in an e-mail message, or on some other web server. When a user is tricked into clicking on a malicious link or submitting a specially crafted form, the injected code travels to the vulnerable web server, which reflects the attack back to the user’s browser. The browser then executes the code because it came from a "trusted" server.

    
risposta data 21.02.2013 - 06:26
fonte
2

sai già cosa fare , il problema è che hai più cose da convalidare. La risposta semplice è se vuoi delle cose sicure, fai tutte le convalide sul lato server. Che cosa mai hai fatto per le cose lato client, gli hacker possono vederli e possono cambiare.

(non dimenticare gli attacchi mitm, la validazione lato client non aiuterà)

    
risposta data 21.02.2013 - 06:33
fonte
2

Hai un controllo ZERO su ciò che un utente invia al server. Un concetto di sicurezza fondamentale non si fida mai dell'utente, e questo vale in casi come questi. Utilizzare le protezioni del lato client per evitare richieste accidentali non formulate (errori di scrittura della persona) e per motivi di praticità. Cercare di rafforzare questi controlli per diventare "sicuri" è fondamentalmente errato.

Assicurati che tutte le convalide di sicurezza siano fatte lato server, indipendentemente da quanto carico metti a sua volta sul tuo server, sfortunatamente non hai altra scelta.

    
risposta data 21.02.2013 - 09:13
fonte
0

Bene, se non vuoi caricare il carico sul server, la tua "sicurezza" è rotta. Puoi mettere la sicurezza che desideri sul lato client, un client esperto sarà sempre in grado di inviare ciò che gli piace sul tuo server. Il tuo server non deve fidarsi dell'input del client. Non devi supporre che la roba che il tuo server riceve provenga dal software che hai messo dal lato client. Questo potrebbe essere il caso nominale e l'unico caso che hai immaginato, ma un utente esperto può inviare qualsiasi contenuto desideri al tuo server. Lui / lei può modificare il tuo software lato client, lui / lui può aggirarlo ...

Il carico del server non è un problema, altrimenti è necessario acquistare un hardware migliore. E il carico del server può essere ridotto al minimo.

Nice framework per app Web - come Vaadin - consentono di sviluppare la convalida una volta e di eseguirla in entrambe le posizioni, sul client e sul server. Quindi hai questi vantaggi:

  • La convalida sul lato server è la convalida sicura.
  • La convalida sul lato client è la convalida reattiva, l'utente non deve attendere un round trip del server per ottenere il feedback della convalida.
  • La maggior parte delle volte, il server riceve input utente validi, poiché la maggior parte degli utenti ha prima superato la convalida sul lato client. Nessun round trip client / server per i soliti errori dell'utente. Quindi il carico del server è ridotto al minimo, il carico di rete è ridotto al minimo, questo è un bene per il risparmio energetico, questo è positivo per la bolletta elettrica, questo è buono per il pianeta .

E puoi risparmiare di più facendo meno. Tutte le tue limitazioni sul numero di telefono sono davvero buone idee? Che cosa succederà se un utente ha un numero di telefono di un paese che non ha pensato? Sai che le persone possono portare il proprio telefono cellulare oltre i confini? Cosa succederà se un utente scrive il suo numero di telefono con spazi? Questi casi daranno una cattiva esperienza utente. Ci sono davvero dei buoni motivi per proibire questi casi? O i tuoi vincoli saranno solo fastidi che faranno più male che bene?

    
risposta data 23.02.2013 - 12:10
fonte

Leggi altre domande sui tag

Garantire che un servizio Web elabori solo le richieste da computer specifici Backprack Footprints