how could they escape the string and run code server-side
L'unico modo in cui un utente malintenzionato può causare l'esecuzione di una stringa sul lato server, è se il server interpreta il codice stringa . Se il server esegue solo l'eco della stringa sul client, il codice non può essere eseguito sul lato server. (ma, come rimani, può essere ancora un vettore di attacco XSS)
Le seguenti situazioni sono i casi più comuni in cui una stringa fornita dall'utente potrebbe essere interpretata accidentalmente come codice e quindi eseguita sul server.
Le vulnerabilità -
SQL Injection rappresentano l'evento più comune. In molti casi, Java produce una stringa SQL, che, se combinata con input non salvati o con scarsa escaping, potrebbe consentire all'utente malintenzionato di eseguire comandi SQL arbitrari . Nella maggior parte dei casi questo è limitato all'accesso, all'aggiornamento o all'eliminazione dei dati a cui l'utente SQL ha accesso, ma in alcune situazioni potrebbe essere utilizzato un attacco SQLi per ottenere un accesso più elevato al sistema.
-
Un meccanismo di caricamento dei file mal progettato potrebbe utilizzare Traversamento del percorso per posizionare un file eseguibile sul server, sia per l'esecuzione automatica tramite cron, o nel docroot per l'esecuzione tramite richiesta HTTP. (una funzione di download di file potrebbe anche essere vulnerabile al path traversal)
-
Le vulnerabilità del buffer overflow sono un'occorrenza comune nei linguaggi di programmazione di basso livello come C o C ++.
Coloro che sviluppano in un linguaggio di alto livello come Java hanno il lusso dell'assegnazione automatica del buffer e non saranno in grado di creare una di queste vulnerabilità nella maggior parte delle situazioni.
Tuttavia, a volte un linguaggio di alto livello si collegherà a un modulo vulnerabile. Ad esempio, un livello di crittografia HTTPS o di elaborazione delle immagini può essere scritto in un linguaggio di basso livello per velocizzarne l'esecuzione.
Come sempre, controlla i tuoi pacchetti per gli aggiornamenti di sicurezza che potrebbero dover essere installati.
Since java just compiles down to bytecode, is it possible to inject bytecode directly in a scenario like this?
Ciò richiederebbe una vulnerabilità (elemento 3 sopra) all'interno del runtime Java, ma l'effetto desiderato potrebbe essere ottenuto con l'elemento 2.