Perché è importante non usare mai "eval" insieme a AJAX?

2

Da OWASP Cheat Sheet AJAX Security :

Eval is evil, never use it. Needing to use eval usually indicates a problem in your design.

Comprendo che eval di codice JS non attendibile può portare a un intero mondo di dolore, tuttavia non riesco a capire la categoricità della proibizione di OWASP.

Per come ho capito, è perfettamente possibile utilizzare eval in modo sicuro, vale a dire quando il codice eval 'd è attendibile.

Sto sviluppando una app web per hobby (gioco) nel mio tempo libero (non ancora pubblicata). In questa app uso eval . Anche se questa è una singola pagina, a volte mi sembra più semplice fare in modo che il server invii blocchi di codice HTML al browser invece di fare in modo che il browser costruisca la pagina da zero. Quindi questo è quello che sto facendo:

  1. Avere il browser avvia una XMLHttpRequest sul server per un frammento di pagina;
  2. Carica il codice HTML ricevuto (questo implica innerHTML , che incidentalmente è un'altra cosa che avverte OWASP agains )
  3. Poiché innerHTML non esegue il codice JS presente nel frammento assegnato, cerca il codice HTML caricato per script tag e eval .

In questo modo viola chiaramente le linee guida di OWASP. Tuttavia non riesco a vedere come questo sia meno sicuro del normale caricamento di una pagina HTML / CSS / JS dal server senza AJAX, semplicemente digitando l'indirizzo della pagina nella barra degli indirizzi del browser. In entrambi i casi (caricando la pagina dalla barra degli indirizzi rispetto a innerHTML 'ing e - gasp! - eval ing la risposta da una chiamata AJAX al server) c'è un'assunzione implicita di fiducia in questa pagina web. Se il server è compromesso e inizia a emettere un codice HTML / JS violento, tutti sono ugualmente fottuti anche se non viene utilizzato alcun% maligno% co_de. Altrimenti, tutti sono ugualmente al sicuro.

Tuttavia so che non essendo un esperto probabilmente ho una comprensione molto limitata e se OWASP vieta categoricamente qualcosa, probabilmente hanno buone ragioni per questo. Lascia che ti chieda allora, quali sono i rischi di fare ciò che ho descritto?

    
posta gaazkam 03.12.2018 - 20:31
fonte

2 risposte

2

tl/dr: For a game you are working on for fun with no one else's information at risk then sure - do whatever makes your life easiest. You're welcome to balance security and usability however you want as long as you aren't risking other people's information. What you are doing certainly isn't uncommon. However, this decision does in fact prevent you from following some best security practices, and so overall I think that advice from OWASP is perfectly applicable.

È vero che ciò che stai facendo non è particolarmente pazzo, non è necessariamente raro e non è sostanzialmente diverso da un caso d'uso più tipico. È anche vero che affermazioni come "X is evil do not ever do it" sono un po 'esagerate e raramente del tutto vere. Tuttavia, penso che ci siano un numero di punti che ancora ti mancano (anche dopo che McMatty ha menzionato un dettaglio importante nella sua risposta), quindi penso che valga la pena discutere di più. Tuttavia c'è un avvertimento importante che vale la pena menzionare per primo:

La sicurezza non è mai "Tutto o niente"

La sicurezza è sempre un atto di bilanciamento. La questione fondamentale della sicurezza è fondamentalmente "è abbastanza sicuro per i miei scopi?" A differenza del sito di lancio di missili nucleari, un sito di votazione di immagini anonime non ha praticamente alcun bisogno di sicurezza. Se capisci le implicazioni delle decisioni che prendi e sei soddisfatto del bilanciamento tra la tua applicazione tra "questo è facile per me scrivere / mantenere" e "questo è abbastanza sicuro per i miei scopi", allora non importa cosa sia OWASP dice (presumendo, ovviamente, che in realtà stai prendendo una decisione informata e non stai semplicemente dicendo "Non mi interessa se le carte di credito dei miei clienti vengono rubate"). Se stai solo facendo un gioco per divertimento, allora non importa. Naturalmente se in seguito ha successo e inizi a integrare un portale di pagamento per gli acquisti in-app, potresti ritrovarti a dover tornare indietro e rinnovare l'intero sistema per una maggiore sicurezza.

Tutto ciò che viene detto, che cosa significa il consiglio di OWASP per il tuo caso d'uso? Ecco alcuni dettagli che ritengo possano mancare

  1. In realtà non devi usare eval qui. Se hai un tag script invece di eval i suoi contenuti puoi semplicemente creare un tag script e scriverlo sul corpo ( vedere questa domanda ). Ovviamente, c'è poca differenza pratica tra l'uso di eval e la scrittura di un tag script sul corpo, quindi questo è in qualche modo inutile ...

  2. Con javacript definito direttamente sulla pagina non è possibile utilizzare un CSP rigoroso per bloccare gli attacchi XSS. Con un CSP sufficientemente rigido puoi dire al browser di non consentire qualsiasi in linea javascript da eseguire sulla pagina. Questo è molto efficace per fermare un attacco XSS se qualcuno riesce a trovarne uno nel tuo sistema. Tuttavia, non puoi farlo se hai il tuo javascript in linea.

  3. I file javascript esterni possono avere un hash allegato che impedirà al browser di utilizzare il file se non corrisponde (ovvero se il file esterno è stato manomesso). Questo non importa come molto nel tuo caso perché stai caricando le tue risorse interne e, se le tue risorse interne sono manomesse, hai un problema molto più grande che un hash non si fermerà. Tuttavia, la difesa approfondita suggerisce che tali passi possono comunque essere preziosi. Ad esempio, un'app più grande può avere script forniti da diversi "servizi" nel proprio sistema e un utente malintenzionato può accedere a una sola area del proprio sistema. Includendo controlli dell'integrità delle risorse secondarie anche su sistemi interni, è possibile fornire facilmente una barriera che potrebbe impedire a un utente malintenzionato di compromettere ulteriori parti del sistema. Questo è impossibile con gli script inline.

  4. La necessità di utilizzare eval di solito indica un problema nel tuo design. Sto evidenziando questa affermazione di OWASP, perché penso che sia applicabile e tu la stia ignorando. Hai detto che lo stai facendo perché a volte trovi più facile avere il server che manda giù blocchi di HTML invece di fare in modo che la pagina venga creata da javascript. Apparentemente quando ciò accade a volte il server invia anche più javascript stesso. Tutto questo per dire: sì, penso che ci sia un problema con il tuo design. Non fraintendermi, questo non significa che devi andare a revisionare tutto. Comunque tu hai alcune pagine in cui javascript costruisce la pagina, alcuni punti in cui il server costruisce le pagine e alcune pagine in cui il server costruisce la pagina e invia anche più javascript per controllare la nuova pagina. Questo potrebbe essere molto più facile per te in questo momento, ma da una prospettiva esterna penso che sia facile dire che hai davvero un certo "odore" di design. Questo non deve essere un grosso problema, e non intendo che sia negativo, perché dobbiamo prendere tutte le decisioni di progettazione che hanno più senso per noi. Tuttavia, che tu te ne renda conto o no, penso che tu stia in molti modi provando la verità su ciò che stanno dicendo.

risposta data 04.12.2018 - 14:46
fonte
1

Il rischio è che tu abbia abilitato l'esecuzione del codice dal tag eval se un utente malintenzionato può ottenere contenuti in esso. Ti fidi del contenuto in modo che non sia un problema, ma come menzione è un difetto di progettazione e pigrizia. La pigrizia porta a bug e problemi di sicurezza.

La politica di sicurezza del contenuto è molto specifica per interrompere ciò che stai tentando qui e le loro sono buone maniere per ottenere ciò che stai facendo. Solo perché trovi il modo di far funzionare qualcosa e la sua facilità non è quella giusta.

    
risposta data 03.12.2018 - 21:16
fonte

Leggi altre domande sui tag