Security-wise, è un'implementazione JavaScript nel browser fondamentalmente diversa da un'implementazione del linguaggio lato server (ad es. Python)?

Question

Security-wise, è un'implementazione JavaScript nel browser fondamentalmente diversa da un'implementazione del linguaggio lato server (ad es. Python)?

#1 da (1 voti)
#2 da (0 voti)

0

A quanto ho capito, le implementazioni JavaScript in esecuzione nei browser devono eseguire codice non affidabile e operare su dati non attendibili in modo sicuro. Le implementazioni linguistiche (ad es. Python) in esecuzione su un server, OTOH, eseguono codice attendibile e devono solo gestire in modo sicuro i dati non attendibili.

Questa differenza significa che le due implementazioni linguistiche devono risolvere problemi fondamentalmente diversi, per quanto riguarda la sicurezza?

Vi sono attacchi possibili tramite codice e dati non attendibili, ma non solo tramite dati non attendibili? Se è così, presumibilmente un'implementazione Python può permettersi di ignorare questi tipi di attacco, ma un'implementazione JS dovrebbe essere sicura contro di loro?

O tutti gli attacchi possibili tramite codice non affidabile dovrebbero essere considerati possibili anche attraverso dati non attendibili? In tal caso, le implementazioni Python dovrebbero impiegare tutte le funzionalità di sicurezza delle implementazioni JS?

In altre parole, è più semplice proteggere un'implementazione linguistica solo da dati dannosi, rispetto ai dati dannosi e al codice dannoso?

javascript python client-side server threat-modeling

posta user200783 28.05.2018 - 17:50

fonte

2 risposte

Leggi altre domande sui tag javascript python client-side server threat-modeling

Lunghezza della chiave superiore alla dimensione del blocco Quale libreria / librerie di crittografia lato client dovrei usare per rendere più semplice la sincronizzazione?

score 1 · Answer 1

Are there attacks which are possible via untrusted code and data, but not via untrusted data only?

Se puoi fidarti del codice, solitamente puoi usare questo codice fidato per convalidare i dati non fidati prima di elaborare ulteriormente i dati. Se il codice non è affidabile, questo non è possibile. Ecco perché il motore Javascript all'interno del browser (che sta eseguendo un codice non affidabile) funziona in un ambiente limitato (sandbox) in modo che il codice non affidabile non possa danneggiare il sistema sottostante. Ciò significa ad esempio che il file e l'accesso alla rete sono severamente limitati.

Ci sono casi in cui l'hacker riesce a iniettare il proprio codice in ambienti di esecuzione fidati. Se questo è il caso, il codice dell'attaccante ha lo stesso livello di attendibilità dell'altro codice attendibile e può quindi causare danni ingenti dato che l'assunto per l'ambiente è che il codice può essere considerato attendibile. Un tipico esempio di tale iniezione è di chiamare eval sui dati forniti dagli utenti malintenzionati, interpretando così questi dati come codice attendibile .

In other words, is it a simpler task to secure a language implementation against malicious data only, compared to both malicious data and malicious code?

Sì, se il codice può essere completamente affidabile non è necessario eseguire ulteriori restrizioni sull'ambiente di esecuzione poiché è possibile che il codice attendibile convalidi correttamente i dati non attendibili. Ovviamente le restrizioni sono comunque raccomandate come parte della difesa in quanto il codice più complesso ha dei bug.

Se invece il codice non può essere considerato attendibile, è essenziale limitare ciò che l'ambiente di esecuzione può fare. Ciò lo rende più complesso poiché questa protezione è necessaria in aggiunta alla lingua esistente. Inoltre, tutti i bug degli ultimi anni all'interno del Java Sandbox mostrano che la progettazione e implementare un ambiente di esecuzione così limitato non è facile.

score 0 · Answer 2

Are there attacks which are possible via untrusted code and data, but not via untrusted data only? If so, presumably a Python implementation can afford to ignore these types of attack, but a JS implementation would have to be secure against them?

Un esempio è la capacità di misurare il tempo con alta precisione (timer, cicli concomitanti). Tali timer sono necessari per sfruttare le vulnerabilità Spectre -like. Per mitigare la vulnerabilità alcuni browser riducono la risoluzione dei timer JavaScript. Un ambiente di esecuzione lato server non ha bisogno di tale restrizione.