Vulnerabilità XSS in risposta

-1

Sto verificando la presenza di XSS riflessivo in un sito Web e ho notato che il sito Web utilizza il concetto di escape dell'HTML, quindi praticamente tutti i caratteri speciali / non validi sono sfuggiti. Quindi iniettare non è così facile.

Esempio: ' viene convertito in ' e > viene convertito in >

Ho avuto due domande:

1) È possibile aggirare questo tipo di filtro?

2) Inoltre ho notato che quando si intercetta la risposta dopo che il filtro è sfuggito al carico utile utilizzato, il sito Web consente di manomettere la risposta. (Fondamentalmente consente all'utente di sostituire la versione di escape del payload visto nella risposta al payload originale, quindi eseguire il pop-up per ottenere nome host, cookie, dominio ecc.) Anche se suppongo che questo non sia esattamente il modo in cui funziona XSS, Sono ancora in grado di ottenere alcune informazioni sul sito web.

    
posta sectest 02.01.2018 - 11:44
fonte

2 risposte

2

Per quanto riguarda l'acquisizione di XSS in questa configurazione, in cui la risposta finisce nel contenuto HTML, come dice @snappie, nella maggior parte dei casi è necessario trovare una vulnerabilità nella codifica per aggirare questo problema.

Tuttavia esiste un'altra opzione, ovvero il vettore potrebbe atterrare all'interno del contenuto JavaScript o JSON (ad esempio, non nelle pagine HTML), nel qual caso la codifica HTML potrebbe non essere una difesa efficace.

Suggerirei di inserire una stringa tracciabile come vettore, quindi esaminare tutte le posizioni in cui il vettore appare, nelle risposte dal sito.

Quindi, ad esempio, se si inserisce la stringa "LoremIpsum" in vari parametri inviati al sito, è possibile utilizzare uno strumento proxy per cercare tra le risposte e vedere dove tali stringhe riemergono (cioè appaiono solo in HTML o appaiono in altri tipi di risposta)

Quello che tendo a fare è iniziare con una stringa vanilla senza caratteri speciali, poiché a volte le applicazioni rimuovono l'input contenente caratteri speciali interamente. Questo dà un'immagine di partenza e da lì puoi farti un'idea di dove il tuo input dovrebbe apparire nelle risposte una volta che inizi a usare il fuzz alla ricerca di problemi XSS.

Per quanto riguarda il secondo punto, se intendi inserire risposte e codice JavaScript di iniezione a quel punto, è ciò che viene comunemente chiamato "Self-XSS" e di solito non è considerato una vulnerabilità nel sito stesso. Le tue modifiche avvengono dopo che i dati sono stati trasmessi dal sito e solitamente questo viene mitigato utilizzando connessioni crittografate SSL.

    
risposta data 02.01.2018 - 13:22
fonte
1

1) È possibile ignorare questo tipo di filtro?

Solo se trovi difetti nell'implementazione del filtro, ma probabilmente no. Questa è la difesa predefinita contro XSS. Ad esempio, noterai che Google utilizza la stessa tattica.

2) Inoltre ho notato che quando si intercetta la risposta dopo che il filtro è sfuggito al payload utilizzato, il sito Web consente di manomettere la risposta.

Se puoi intercettare e modificare la risposta, puoi fare un Man In The Middle Attack . Questo tuttavia non ha nulla a che fare con XSS. XSS si verifica solo quando il sito Web rimanda i tag HTML incorporati nei dati forniti dall'utente. Se modifichi la risposta dopo che il sito Web l'ha inviata, non è il sito web che "consente" di modificare la risposta, è qualcun altro che fa finta che il sito Web invii qualcosa che non ha.

    
risposta data 02.01.2018 - 13:17
fonte

Leggi altre domande sui tag