L'iniezione di codice è una vulnerabilità critica che consente a terze parti di eseguire il codice sul software lato server. L'iniezione del linguaggio di espressione è un tipo di esecuzione remota del codice che divulga i dati sensibili dal server. Il codice remoto esegue e visualizza variabili, password, funzioni o codice. Nel peggiore dei casi, può dare a un utente malintenzionato il controllo remoto del server.
Che cos'è l'iniezione del linguaggio di espressione?
L'iniezione del linguaggio di espressione è una vulnerabilità che colpisce JavaServer Pages (JSP), Active Server Pages (ASP) e altri linguaggi di espressione ospitati su un server web. Questi linguaggi sono linguaggi interpretati, pertanto qualsiasi codice inviato al server viene compilato durante il runtime dell'applicazione, a differenza dei linguaggi compilati standard con file eseguibili binari. In un linguaggio interpretato, il codice viene compilato sul server quando un utente effettua una richiesta per una pagina.
Quando un'applicazione di linguaggio di espressione (EL) è vulnerabile all'iniezione del linguaggio di espressione, un utente malintenzionato invia il codice creato all'applicazione come input, nella stringa di query o in un oggetto di forma. Il codice viene compilato in runtime e può quindi visualizzare variabili, password e altre informazioni sensibili. Le vulnerabilità EL sono comuni nelle versioni obsolete dei linguaggi interpretati, pertanto le applicazioni legacy devono essere sottoposte a test di penetrazione prima di essere distribuite in produzione. Dopo un evento critico, le organizzazioni hanno bisogno di piani di disaster recovery per correggere la divulgazione e gli exploit dei dati.
Come funziona Expression Language Injection
Tutte le applicazioni che eseguono un linguaggio interpretato devono eliminare codice e caratteri speciali dall'input. Senza l'input di scrubbing, l'applicazione accetta il codice ed esegue il codice sul server. La maggior parte delle vulnerabilità delle iniezioni EL coinvolge JSP, quindi utilizzeremo il codice JSP nell'esempio seguente. Lo snippet riportato di seguito è un esempio di una singola riga di codice vulnerabile all'iniezione EL:
<spring:message code="${param['message']}" text=""/>
In questo esempio, l'attributo di codice assume un parametro contenente una stringa. Se un utente malintenzionato inserisce il codice nel parametro, verrà compilato ed eseguito sul server. Gli utenti non vedono questo codice nella pagina web locale, quindi gli autori degli attacchi utilizzano script comuni per individuare le vulnerabilità dell'iniezione EL.
Vulnerabilità comuni che portano all'iniezione del linguaggio di espressione
Analogamente a qualsiasi vulnerabilità all'iniezione, la vulnerabilità all'iniezione EL deriva da nessuna convalida dell'input sull'applicazione server. Utilizzando lo stesso esempio di cui sopra, la stringa di messaggi potrebbe essere una stringa di caratteri innocente, ma potrebbe anche essere un codice. Invece di inviare una stringa innocente, supponiamo che l'utente abbia inviato quanto segue:
${"aaaa".toString().concat(T(java.lang.Runtime).getRuntime().exec('ls -l'))}
L'input di cui sopra tenta di eseguire il comando di sistema "ls -l" sul server. Questo comando elenca i file e le directory nella directory corrente. Con un elenco di file, un utente malintenzionato potrebbe quindi tentare di inviare un altro comando per aprire e visualizzare il contenuto di un file nella propria finestra. Un file potrebbe contenere dati sensibili come le password. Da lì, l'autore dell'attacco potrebbe accedere al server ed eseguire ulteriori azioni dannose.
Rilevamento dell'iniezione del linguaggio di espressione
I test di penetrazione, sia di tipo white box che di tipo black box, rilevano le vulnerabilità dovute all'iniezione di EL. Il white box test è un metodo in cui i professionisti della sicurezza esaminano il codice per rilevare eventuali vulnerabilità. Le aziende forniscono il codice ai revisori della sicurezza e i revisori identificano tutte le vulnerabilità del codice in un report. Si tratta di un approccio proattivo comune alla data protection.
I test di penetrazione Black Box utilizzano la stessa forma di scansioni e rilevamento delle vulnerabilità di un utente malintenzionato. I professionisti della sicurezza attaccano l'applicazione senza conoscerne il codice, quindi è possibile testare qualsiasi convalida o difesa. I test con caselle grigie sono un mix di test con caselle nere e con caselle bianche ed è spesso un metodo scelto per le applicazioni web di test di penetrazione.
Prevenzione dell'iniezione del linguaggio di espressione
Il modo migliore per rilevare gli attacchi di iniezione EL è convalidare il codice e rimuovere l'input con caratteri specifici. Ad esempio, l'immissione di un campo nome non deve contenere <” or “>caratteri "". Gli sviluppatori devono utilizzare librerie create per rilevare questi caratteri, rimuoverli o rilasciare l'input e visualizzare un errore per l'utente.
Anche altri caratteri possono essere dannosi. In una pagina JSP, i frammenti di codice iniziano con i <%” characters and end with the “%>caratteri "". Questi caratteri insieme devono essere rimossi dall'input. Gli autori degli attacchi eseguiranno numerose combinazioni di codice dannoso per bypassare il rilevamento, quindi il modo migliore per rilevarlo è utilizzare una libreria creata per la convalida degli input. Le applicazioni SIEM possono anche rilevare gli exploit e fornire analytics se la tua applicazione è una destinazione.
Conclusione
Le vulnerabilità dell'iniezione EL devono essere considerate come problemi di sicurezza critici. Fai sempre testare le tue applicazioni linguistiche interpretate per rilevare eventuali vulnerabilità dovute all'iniezione e altre vulnerabilità che potrebbero divulgare dati sensibili. Gli sviluppatori devono utilizzare strumenti di convalida per rilevare e arrestare l'iniezione EL e le applicazioni legacy che utilizzano JSP e ASP devono essere attentamente monitorate per rilevare eventuali attacchi.
Pure Storage dispone dell'infrastruttura di sicurezza e del monitoraggio delle minacce necessari per proteggere le applicazioni dagli attacchi alla sicurezza.
