thecodest, Author at The Codest

XSS

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.

Esempio

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:

XSS memorizzato eseguiti con dati iniettati memorizzati sul lato server, di solito da moduli disponibili nell'applicazione. L'applicazione client esegue il rendering del codice memorizzato, ad esempio, in un database.
DOM XSS esegue un attacco XSS senza utilizzare il lato server. Nel prosieguo dell'articolo, ci concentreremo su questa forma di attacco.

Attuali vulnerabilità nelle librerie React e Vue

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:

bambino nodo iniezione - React, utilizzo di React.createElement [5]
Rendering lato server - React/Vue [6]
Iniezione di CSS [8]

Si tratta ancora di Javascript. Si tratta ancora di front-end

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:

documento.scrivere
document.writeln
(elemento).innerHTML
(elemento).outerHTML
(elemento).insertAdjacentHTML

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)