TORNA INDIETRO
Per quanto riguarda le librerie Javascript più diffuse, bisogna ammettere che nella loro storia di sviluppo (9, 6 e 5 anni per Angular, React e Vue, rispettivamente), sono successe molte cose buone in termini di sicurezza, soprattutto per quanto riguarda la vulnerabilità agli attacchi XSS. Tuttavia, questo articolo discuterà le piccole trappole e i principi che gli sviluppatori dovrebbero ancora conoscere.
Viviamo nell'era dei framework, non dei linguaggi. Questo implica che i programmatori dovrebbero essere in grado di preoccuparsi meno di molti aspetti dello sviluppo, compresa la sicurezza. La maggior parte degli attuali framework di backend implementa moduli di sicurezza, che vengono testati da aziende esterne specializzate e da grandi società. Pertanto, calo della consapevolezza della sicurezza potrebbe essere evidente, ad esempio tra i giovani programmatori, che si assumono maggiori responsabilità per i prodotti, soprattutto in termini di freelance.
Uno degli attacchi più comuni sul lato client dell'applicazione è l'XSS (Cross-Site Scripting). Viene eseguito iniettando script eseguibili sul lato client nelle applicazioni web [1] e utilizza metodi di rendering HTML implementati o Javascript codice valutatori che lo eseguono. L'XSS è relativamente redditizio, poiché può raccogliere molti dati diversi, tra cui cookie di sessione o dati dell'utente, e può installare un'applicazione di tracciamento come un keylogger, rendendolo pericoloso sia per gli utenti che per i proprietari di aziende. A volte vengono eseguite altre forme di attacco per consentire l'XSS sulla pagina, come ad esempio Iniezione SQL.
Il modulo di accesso alla pagina visualizza il parametro loginName inviato nella richiesta GET nell'input del nome di accesso. Il valore non viene elaborato né dal server né dal lato client dell'applicazione. Richiedendo: http://localhost:8080/login?name=<script>alert(document.cookies)</script>
Il codice viene eseguito e i dati sono esposti
Questo è un esempio di attacco XSS riflessoin cui gli script vengono iniettati attraverso un indirizzo URL appositamente preparato, inviato alla vittima e riflesso dalla risposta del server. Altre forme di attacco note sono le seguenti:
Per le attuali versioni React/Vue, sono stati individuati due problemi principali, non ancora ufficialmente risolti. La prima vulnerabilità ha la stessa natura per ogni framework ed è legata ai metodi che consentono il rendering di HTML grezzo all'interno dei template: v-html e pericolosamenteSetInnerHTML, rispettivamente, per Vue e React. Ogni documentazione [2] informa i lettori che un uso improprio può esporre gli utenti ad attacchi XSS. Se non ci sono altre opzioni per risolvere il problema, assicurarsi che i dati siano filtrata e sfuggito. Sebbene siano pericolosi, non ci si deve aspettare che questi metodi siano risolutivi. Utilizzateli a vostro rischio e pericolo.
Nel primo trimestre del 2018 è stato rilevato un bug di grandi dimensioni in React, che consentiva l'esecuzione diretta di codice impostando la proprietà dell'elemento tag. Il passaggio di codice di esempio all'interno di attributi, come ad esempio javascript:alert(1) e l'esecuzione di un collegamento renderizzato eseguirà il codice. Questo problema [4] è ancora aperto e non è stato preparato e unito alcun fix, quindi assicuratevi che il vostro codice sia sicuro. Gli esempi proposti nella discussione ufficiale suggeriscono alcuni modi per superare questo problema.
Se non è possibile aggiornare alle ultime versioni, assicuratevi che i vecchi problemi non vi causino problemi assicurandovi che il vostro codice non sia esposto:
Non dimenticate che oltre ai framework o alle librerie stesse, Javascript come linguaggio ha alcune funzioni pericolose, che devono essere evitate o utilizzate con cautela. In genere sono legate alla manipolazione del DOM o all'esecuzione di script. eval() rappresenta funzioni di punta di questo tipo ed è estremamente pericolosa perché esegue direttamente il codice stringato dato [9]. Inoltre, quando si trova una di queste funzioni, è bene dare un'occhiata al proprio codice:
In questo caso, l'uso di linters con regole appropriate può essere utile per trovare questi punti vulnerabili. Esistono anche molti analizzatori di codice aperti o commerciali che possono aiutare a rilevare le lacune di sicurezza nel codice sviluppato.
Indipendentemente dalla libreria/framework scelta, dobbiamo comunque ricordare i principi di base dello sviluppo front-end. Innanzitutto, bisogna sempre assicurarsi che il codice esterno iniettato provenga da una fonte affidabile. Audit le vostre dipendenze e sceglietele con saggezza. Alcune possono contenere gravi vulnerabilità, esponendo il codice anche se il codice stesso è a posto. Per saperne di più sulla sicurezza delle dipendenze, leggete qui:
https://thecodest.co/blog/security-in-javascript-packages/
Quindi... bisogna ancora preoccuparsi?
Sì, e invito tutti a non fidarsi mai delle librerie esterne o di se stessi in termini di sicurezza. Indipendentemente da quanto ci si aspetta che il proprio software sia sicuro, bisogna sempre fare uno sforzo per testarlo il più possibile in termini di forme di attacco comuni [10].
Per saperne di più:
5 errori da evitare durante la manutenzione di un progetto in PHP
Sviluppo PHP. Componente console di Symfony - Suggerimenti e trucchi
Perché abbiamo bisogno di Symfony Polyfill (... e perché non dovremmo)
Italian 
English 
German 
Swedish 
Danish 
Norwegian 
Finnish 
French 
Polish 
Arabic 
Japanese 
Korean 
Spanish 
Dutch 
Estonian 
Greek