Domanda:
Nuovo cheatsheet XSS?
naugtur
2010-11-12 14:14:52 UTC
view on stackexchange narkive permalink

C'è un ottimo elenco di vettori XSS disponibili qui: http://ha.ckers.org/xss.html, ma non è cambiato molto ultimamente (es. l'ultima versione FF menzionata è 2.0).

Esiste un altro elenco valido come questo, ma aggiornato?

Abbiamo bisogno di meno cheatsheets / strumenti e manuali di metodologia più approfonditi per problemi di risultati come XSS. Va inoltre notato che la revisione manuale del codice e l'analisi delle lacune basata sul controllo sono metodi più semplici per trovare ed eliminare i problemi XSS, specialmente su basi di codice estremamente grandi e su un gran numero di applicazioni.
@atdre, Sono d'accordo - in linea di principio. Tuttavia, un controllo mancante spesso non è sufficiente perché un'azienda decida di impegnare le risorse per rimediare alla mancanza. In effetti, la gestione del rischio richiederebbe di mostrare se il difetto è sfruttabile o solo best practice / difesa approfondita.
@AviD: Hahahahaha, XSS è sempre sfruttabile. Sono completamente in disaccordo con te. Dimostrare problemi di gestione del rischio tramite valutazioni del rischio è una totale perdita di tempo per la sicurezza delle applicazioni! Un'organizzazione ha bisogno di praticare l'arte di rubare i propri camion sotto la minaccia delle armi per dimostrare i problemi di gestione del rischio con i conducenti che attraversano quartieri difficili, di notte, con PR ovunque e il contenuto dei camion?
Ho appena notato che il mio commento qui è un argomento polemico. Per favore, non contrassegnarlo come offensivo
Heh, @atdre, Penso che sia un punto giusto, ma non quello che stavo cercando di fare. Non che la gestione del rischio debba essere effettuata tramite valutazioni del rischio, ma se hai eseguito valutazione del rischio / analisi pentest / controllo e hai riscontrato determinati problemi, come fai a sapere se si tratta di un rischio elevato o basso? Se è sfruttabile, ecco come. Molto semplicemente, se non è sfruttabile non influisce sul rischio. Inoltre, i cosiddetti "cheat sheet" POSSONO essere utilizzati come una forma di metodologia (leggera), poiché una delle parti principali sono i diversi vettori che dovrebbero essere testati - non è solo una questione di carico utile.
E, più specificamente, non che XSS sia sempre sfruttabile, ma la mancanza di prevenzione XSS o la mancanza di convalida / codifica nel codice, non significa automaticamente che sia XSS sfruttabile.
Sembra che mi sia perso molto durante il fine settimana :) Una parola da parte mia - Considero questi foglietti utili per `imparare a cosa dovrei prestare attenzione durante la programmazione`. E non devo essere un blackhat per provare a sfruttare un'app senza revisione del codice. (es. un'app scritta nella mia azienda, ma in una lingua che non conosco)
@ AviD: mancando un dato o una classificazione del rischio, potresti voler assegnare valutazioni del rischio. Ma i dati e le classificazioni di rischio non sono solitamente presenti? E se non lo sono, forse dovrebbero essere disponibili altri tipi di informazioni sulla gestione del rischio (un altro progetto di analisi delle lacune) come la cronologia degli incidenti o un'app forense adeguata?
@ AviD: definirei XSS sfruttabile come qualsiasi HTMLi, Script injection o persino CSSi - non importa se è livello HTTP o meno
@atdre,, il problema su cui stavo attirando la vostra attenzione è che un controllo di prevenzione XSS mancante NON significa necessariamente che ESISTE XSS. Stessa cosa con la revisione del codice, potresti trovare input non convalidati, ma questo NON significa che in realtà ci sia XSS. Perchè no? Poiché ci sono molti contesti diversi, in cui lo script iniettato potrebbe non essere eseguibile, o il suo errore tradotto, oo ... D'altra parte, un controllo ESISTENTE o la ricerca di metodi di convalida anti-XSS nel codice, ANCORA potrebbe non significare che ci sia NON xss. Perchè no? Di nuovo, ci sono molti modi per aggirare questo problema, a seconda del contesto.
@AviD: qualsiasi attributo dell'elemento HTML controllabile dall'utente è XSS, anche se è solo HTMLi o CSSi. Se il contenuto dell'input viene riflesso, hai bisogno di controlli anti-XSS - e almeno per me, il test della penna e la revisione del codice sono una perdita di tempo a seguito di questa scoperta - vai direttamente ai controlli appsec, non raccogliere $ 200
@atdre, e i dati controllabili dall'utente che NON sono un elemento HTML? che dire del meta tag, usando data: scheme? E i dati * parzialmente * controllabili (cioè c'è un filtro incompleto)? In breve ci sono molti casi limite in cui non è così chiaro.
@AviD: Bene, questo è esattamente il mio punto. Stai sostenendo la mia tesi per me. Grazie! Io vinco! Dove sono i miei punti score.ly?
Ogni app ha XSS. Whois ha XSS
No, @atdre, è il contrario. Che tu abbia il controllo o meno, non è il fattore decisivo se è sfruttabile o meno. Potresti ** non ** avere il controllo, e tuttavia * non * essere sfruttabile; oppure potresti ** avere ** il controllo, ma a causa dell '* implementazione *, ** è ** sfruttabile. Avere semplicemente un segno di spunta accanto a "Controllo XSS" in una lista di controllo non ti proteggerà.
Non ho mai detto che un controllo XSS avrebbe funzionato. Ho appena detto che è il posto migliore per iniziare. Ovviamente devi verificare che il controllo funzioni. Metti alla prova i tuoi controlli, giusto?
Bene, ovviamente è una buona idea raccogliere informazioni in anticipo. Ma il cheatsheet XSS viene utilizzato esattamente per questo - * per verificare che il controllo funzioni *. DING! Vinco, hai fatto il ** mio ** punto :)
E @atdre, NON tutte le app hanno XSS, solo la MAGGIOR PARTE di esse.
Quindi preoccupati di quei 30 anni da ora quando avrai sradicato XSS tramite i controlli di app. Puoi vincere la guerra, ma io vinco la battaglia. Oh aspetta, stiamo combattendo contro il RBN?
Inoltre: ogni app ha XSS che potrebbe essere visualizzato come HTML, XML o un futuro linguaggio di markup. Vuoi davvero avere quell'argomento?
Come voto per chiudere i commenti a questa domanda? ;)
In realtà, @naugtur, penso che i commenti qui siano estremamente utili, forse anche più delle risposte stesse, ma poi di nuovo, potrei essere di parte. Penso che il back'n'forth che ho avuto con @atdre fosse di attualità e di alto valore, ma probabilmente meritava la sua domanda / discussione. Ma di nuovo, probabilmente sono di parte :)
@AviD L'ho postato per scherzo. Sarebbe bello se qualcuno potesse riassumerlo in una forma utilizzabile;) La maggior parte delle persone salterà i commenti.
Cinque risposte:
#1
+25
Rory McCune
2010-11-12 14:52:28 UTC
view on stackexchange narkive permalink

Il migliore nuovo che ho visto di recente è qui http://html5sec.org/ un buon elenco di vettori con supporto browser notato e ha alcuni di quelli più oscuri.

Il mese prossimo Mario Heiderich pubblicherà anche un libro che dovrebbe esplorare questo e gli argomenti correlati in modo più approfondito. Ecco un link al libro: http://isbn.nu/1597496049
Ho letto il libro. Sebbene alcune delle sue parti siano già obsolete, è sicuramente una lettura obbligata se qualcuno è in XSS, sebbene copra anche altre aree.
#2
+12
planetlevel
2010-11-21 10:24:50 UTC
view on stackexchange narkive permalink

Se vuoi davvero capire XSS, consiglio vivamente il Cheat Sheet di XSS Prevenzione di OWASP. Non si concentra sull'hacking, si concentra sull'aiutare gli sviluppatori a prevenire questi problemi in primo luogo. http://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet

#3
+9
Tate Hansen
2010-11-12 14:19:19 UTC
view on stackexchange narkive permalink

Sì, prendi fuzzdb da http://code.google.com/p/fuzzdb/:

fuzzdb aiuta a identificare difetti di sicurezza nelle applicazioni aggregando modelli di attacco noti, nomi di risorse prevedibili e messaggi di risposta del server per creare un set completo e ripetibile di casi di test di input non validi.

fuzzdb ha un ottimo elenco di payload di attacco .

#4
+3
AviD
2010-11-12 14:31:45 UTC
view on stackexchange narkive permalink

Il cheatsheat XSS di RSnake (a cui ti sei collegato) è ancora praticamente la risorsa definitiva, ed è anche menzionato nella guida alla codifica sicura di OWASP (che a sua volta è referenziata da PCI: DSS).
Vero, dato che RSnake sta facendo un passo indietro rispetto a queste cose, andando avanti questo potrebbe cambiare, ma per ora questo è il posto dove andare.


AGGIORNAMENTO : RSnake si è ufficialmente ritirato dal blog e ha dichiarato che non effettuerà alcun aggiornamento. Quindi, sebbene questo possa essere stato aggiornato fino al mese scorso, a quanto pare non lo è più.

Penso che fuzzdb possa sostituire il cheatsheet xss di rsnake dato che è una delle fonti primarie per fuzzdb oltre a molte altre fonti
#5
+1
Danish
2014-01-24 03:56:25 UTC
view on stackexchange narkive permalink

C'è stato un nuovo cheat sheet xss disponibile, contiene una quantità enorme di vettori che funzionano su tutti i browser moderni.

LINK: http://packetstormsecurity.com/files/download/124419/WAF_Bypassing_By_RAFAYBALOCH.pdf



Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 2.0 con cui è distribuito.
Loading...