Link shortener che virtualizza il link per XSS riflesso?

I normali shorterner di URL sono comunemente usati per nascondere il payload e rendere i collegamenti meno sospetti. Tuttavia, non aiutano contro i filtri XSS del browser, dal momento che ciò che fa un normale URL shorterner è semplicemente l'invio di un reindirizzamento.

Suggerisci un approccio per costruire un URL shorterner che elimini i filtri XSS dei browser usando ciò che chiami virtualizzazione invece di reindirizzamenti.

Il modo di fare questa virtualizzazione sarebbe usare un iframe. L'unico problema è che il filtro XSS del browser (probabilmente) proteggerà l'iframe nello stesso modo in cui lo protegge quando inserisci un URL nella barra degli URL. Quindi non vinci nulla.

E l'uso di un iframe è l'unico modo in cui posso pensare di fare "virtualizzazione" senza entrare nel SOP. Quindi non penso che questo sia un concetto fattibile.

    

Innanzitutto il https://vulnerable.com/<scRIPt>alert("XSSed!");</scriPT> non è pericoloso per te, dal momento che stai chiedendo (chiedendo non significa parse ed eseguilo localmente) su una risorsa / percorso (qui è <scRIPt>alert("XSSed!");</scriPT> ).

In effetti questo è XSSing del server da parte del client. E penso davvero che abbiamo un server così malvagio che esegue realmente il percorso richiesto come script localmente (nel server). A meno che uno studente lo faccia per ricerca e materiale didattico (sì, assumiamo il percorso richiesto come script e lo eseguiamo localmente, sembra molto bello).

A volte il virtualizzatore che hai citato lo renderà pericoloso per te, considerando che c'è una pagina html che ha uno script e analizza il percorso dell'URL e inserisce il valore all'interno di qualche div, ad esempio come segue:
Il percorso (URI) sembra seguito

http(s)://noob_made.awesome/user={name_of_the_user}

E ora la parte di script all'interno della pagina

function a_student_did_this(){//on body load maybe!
 var user_name=...;//grab the user from url param user
 document.write('Hello '+user_name);//why?
 return true;//indeed
}

E ora se pensi di chiamare la pagina come segue

http(s)://noob_made.awesome/user=<scRIPt>alert("XSSed!");</scriPT>

il tuo browser (non testato) MIGHT assume l'utente come script e lo esegue veramente, in modo pericoloso.

Prima , non andare mai così quando pensi che sia possibile ottenere XSSed, specialmente quando non è sicuro (HTTP). Ma in effetti HTTPS e HTTP funzioneranno allo stesso modo per te nella virtualizzazione che hai menzionato.

Secondo , anche se non esiste alcun modo nel mondo e sei stanco di cercare un'alternativa, quindi almeno sistemarlo e farlo in un modo per renderlo non XSSable, ad esempio come segue

function a_jounior_student_did_this(){//but still in worst way
 var user_name=...;//grab the user from url param user
 user_name=encode_the_string(username);//encode it first
 user_name='<!CDATA['+user_name+']]>';//not it's not parsable
 document.write('Hello '+user_name);//could be safer now
 return true;//hmm
}

Dato che il codice seguente ora agisce proprio come CDATA (* dati carattere non-*), e browser (se lo stesso studente non ha codificato il browser), si suppone semplicemente di ottenere i dati all'interno del CDATA in una stringa semplice.

Le tue domande: , in effetti i siti di virtualizzazione che hai menzionato sono così intelligenti che non eseguiranno mai uno script (agiscono più come un proxy per te.), Logicamente script che dovrebbero essere eseguito dal nodo di destinazione
Ma ho visto i servizi (è emulatore IE penso che se hai una ricerca) che prendono la pagina che hai specificato, fai una foto del suo rendering e rispondi un'immagine a te. ma ovviamente non puoi ottenere alcuna informazione se è buono o cattivo con un'immagine renderizzata Anche se i servizi eseguono lo script, è quasi impossibile fare un grave esplicito danno al client di destinazione. Ma dovresti incolpare te stesso se lo script ti reindirizza per scaricare qualcosa, e peggio lo ottieni ed eseguilo, o una pagina ti chiede di pagare un conto (per una buona ragione?).
Il W3school che hai menzionato non fa quasi nulla per te, invece rende la codifica più facile per te, stessa cosa con jsfiddle, ecc.
Inoltre non esiste alcuna relazione diretta tra link shortener e XSS. Anche in questo caso è necessario caricare e richiamare gli script nel client di destinazione.
Un link shortener mantiene solo il collegamento associato a qualcosa, e per ogni chiamata per un collegamento in corto, l'utente viene reindirizzato .

Fatto 0 : se una pagina o un server è XSSable, quindi è il tuo errore (programmatore). Prenditi ancora un po 'di tempo per studiare e fare il lavoro giusto. proprio come l'SQL-injection old school (che vive ancora in alcuni siti!), potrebbe essere mantenuto anche il suo fratello XSS.

Fatto 1 : puoi ovviamente prevenire l'attacco XSS nel tuo server se lo fai correttamente. Dal momento che è quasi possibile anche per client (javascript), ma come ho detto, ancora XSS nel client non prenderà espliciti problemi pericolosi a meno che l'utente non agisca davvero male.