Ci sono due modi in cui XSS e SQLi possono interagire. Il commento che hai citato è da questa domanda ed è chiaramente riguardo al primo punto.

SQLi tramite XSS

Se sai che un'applicazione è vulnerabile all'iniezione SQL, ma non hai le autorizzazioni necessarie per accedere al componente vulnerabile, potresti essere in grado di sfruttare una vulnerabilità XSS esistente e ottenere così un utente più privilegiato per eseguire l'SQL iniezione per te.

Come hai sottolineato, la ricerca di vulnerabilità nei componenti a cui non hai accesso potrebbe non essere così facile. Ci sono ancora almeno due casi in cui questo può facilmente accadere però:

• Software open source
• Accesso temporaneo al codice sorgente (magari tramite un revisore esterno, tramite perdite di posta elettronica, tramite un ex dipendente scontento, tramite vulnerabilità nel controllo del codice sorgente, ...)

Per iniezioni molto semplici, un utente malintenzionato può anche solo ipotizzare un attacco (forse un utente malintenzionato sa che l'applicazione non difende affatto da SQLi, ma tutte le iniezioni nei componenti a cui hanno accesso utilizzano un utente del database con autorizzazioni limitate in questo caso potrebbero essere in grado di indovinare i nomi di script e parametri di altri componenti e sfruttarli tramite XSS).

In teoria, si potrebbe anche immaginare un'installazione in cui più utenti privilegiati utilizzano sempre una connessione di database con un utente di database più privilegiato, quindi anche un'iniezione in componenti pubblici può essere più potente se sfruttata tramite un utente più privilegiato tramite XSS.

Gli ultimi esempi sono un po 'inventati, ma certamente possibili. Ci sono probabilmente anche altri esempi.

XSS via SQLi

In questo caso, hai un'iniezione SQL, ma in realtà non puoi ottenere nulla di interessante con esso. L'iniezione può avvenire con un utente di database molto limitato, che ad esempio può solo leggere dati già disponibili pubblicamente (ma non può leggere altri dati, scrivere dati, scrivere o leggere i file di sistema, eseguire comandi, ecc, non ci sono anche vulnerabilità nel dbms puoi sfruttare)

In questo caso, potresti essere in grado di eseguire un attacco XSS riflesso o memorizzato tramite SQLi.

Un esempio:

• forum in cui tutti possono pubblicare commenti
I commenti
• vengono disinfettati prima di essere inseriti nel database, ad esempio, qualsiasi tentativo di includere lo script verrà rilevato
• SQLi consente l'accesso diretto al DB e quindi rende possibile aggiungere un commento che non è disinfettato o modificare in questo modo il commento esistente - e in questo modo aggiungere script nel commento
Il sistema del forum
• assume i commenti sterilizzati nel DB e mostrerà solo il commento come memorizzato nel DB, incluso lo script - > XSS memorizzato