Ogni linguaggio lato client è più vulnerabile?

Questo è un problema su chi controlla il codice. Diamo per scontato che ci siano alcuni framework moderni come node per JavaScript sul lato server.

Le lingue stesse non sono necessariamente più vulnerabili. La maggior parte dei difetti non sono i risultati del linguaggio sottostante, ma dei vari controlli logici, sensibilizzazione di input, ecc.

Detto questo, non è possibile controllare il lato client del codice, il che significa che l'utente locale può modificarlo. Può anche essere modificato da un attacco man-in-the-middle sulla rete o da un attacco man-in-the-browser in cui l'utente malintenzionato ha compromesso il computer / browser locale.

Sul lato server, dovrebbero entrare nel tuo server per modificare il codice. Tuttavia, ciò non significa che il codice sia necessariamente più sicuro.

Sebbene sia possibile modificare localmente JavaScript tramite l'ispettore del codice, se hai fatto qualcosa di malevolo, lo faresti tu stesso. Solo perché si cambia il codice non significa che influenzerà altri utenti. Tuttavia, è possibile creare attacchi contro la richiesta di pagina che si invierà a qualcun altro, il che si tradurrà in XSS o CSRF. Ciò comporterebbe l'esecuzione di un attacco contro l'utente. Allo stesso tempo, è possibile modificare la richiesta in modo che richieste dannose o dati vengano inviati al server che provocano un overflow del buffer o un'iniezione di codice (ad es. SQL injection).

Una delle differenze è che puoi creare più facilmente un attacco se hai accesso al codice. Dato che puoi vedere la fonte dell'HTML e del JavaScript, potrebbe essere più facile creare un exploit, ma la stessa conoscenza potrebbe portare a creare un'iniezione SQL.

Ora, fino all'ultimo punto. Dovresti assicurarti che tutti i tuoi controlli di sicurezza siano eseguiti sul lato server, perché non puoi fidarti della convalida lato client dal momento che influisce solo su ciò che accade nel browser. Un utente malintenzionato localmente o MiTM può ancora modificare il traffico HTTP non elaborato, con il risultato che la convalida sul lato client viene ignorata in modo efficace. La convalida lato client è una comodità per gli utenti e consente di salvare alcuni cicli sul server.

Non sono le lingue stesse a essere fondamentalmente insicuri, è l'abuso di esse che può essere.

L'esecuzione della convalida dell'input solo con una lingua lato client è una cattiva idea, perché chiunque può semplicemente disabilitare JavaScript o inviare manualmente richieste al server che contengono valori arbitrari. Ad esempio, il tentativo di impedire XSS bloccando vari caratteri con JavaScript sul lato client non impedirà a qualcuno di inviare una richiesta al tuo server contenente vari caratteri oscuri e markup.

Tuttavia, la convalida di JavaScript è utile dal punto di vista dell'esperienza utente perché impedisce agli utenti legittimi di inviare accidentalmente il modulo con dati non validi, consentendo loro di correggerlo prima di continuare. La cosa importante da ricordare è che questo dovrebbe essere considerato solo una comodità, piuttosto che una misura di sicurezza.

JavaScript e altre lingue lato client possono anche essere utili in una prospettiva di sicurezza quando si usano concetti come prova a prova zero , o quando si crittografa il contenuto utente sensibile a cui gli operatori del server non dovrebbero avere accesso. Ciò può essere utile in scenari in cui il fornitore di applicazioni potrebbe essere costretto a divulgare i dati tramite warrant, poiché i dati crittografati sul lato client con una chiave nota solo all'utente sono inutili per la parte richiedente.

La differenza fondamentale da tenere presente è che chiunque può modificare il comportamento del proprio client, quindi qualsiasi cosa inviata dal client deve essere considerata non attendibile e potenzialmente dannosa. Fondamentalmente ti imbatti nello stesso problema del DRM - se dai un qualcosa a qualcuno, è fondamentalmente possibile per loro modificarlo e usarlo nel modo che preferiscono, che ti piaccia o no.