#########################################################
#AUTHOR: _KING-V_
#SITE:
#DATE: sabato 9 gennaio 2010 21:41
#
#
#
#########################################################
[DISCLAIMER: QUESTO PAPER E' A SCOPO PURAMENTE INFORMATIVO. NON MI ASSUMO LA BENCHE' MINIMA RESPONSABILITA' SULL'UTILIZZO CHE NE FARETE. QUINDI NON VENITE A LAMENTARVI CON ME SE AVETE LA DIGOS TRA I PIEDI O SE IL VOSTRO SITO PERSONALE E' PIENO DI IMMAGINI PORNO.]
Il paper è ancora in fase di lavorazione, se credete che manchi qualcosa scrivetelo!
salve gente, premetto che questo è il mio primo tutorial(ne ho sempre fatti in versione video) quindi si accettano commenti e critiche.
Molta gente, girando sul web, si chiede come possa riuscire ad ottenere la password di un account qualsiasi, di quello della propria ragazza,
o come ottenere accesso ad aree private di un sito, ma non sa da dove iniziare.
Bé, da me non otterrete una risposta, dato che una risposta di tal genere non esiste; o almeno essa non esiste nell'ambito dell'hacking. Altresì, non esiste un metodo definitivo per appropriarsi (più o meno illecitamente) di dati personali altrui o per accedere ad aree protette, nemmeno se si tocca un argomento più scottante e restrittivo come quello del "cracking".
Comunque, per chi non conosca la differenza fra hacking e cracking sarà bene fare una ricerca più approfondita e tornare alla lettura di questo paper quando si avranno le conoscenze necessarie.
Per quanto riguarda il campo di quello che spesse volte viene definito "gioco intellettuale" dai praticanti, l'hacking, l'argomento che oggi vorrei sottoporre alla vostra attenzione è il Cross Site Scripting, una tecnica a cui sono vulnerabili molti siti web con scarso controllo delle variabili utilizzate da pagine dinamiche (come i siti che fanno uso di tecnologie con preprocessore di ipertesto, tipo PHP). Vediamo le possibilità che una tale situazione ci mette di fronte.
l'xss consente di inserire codice a livello browser al fine di modificare il codice sorgente della pagina web visitata dall'utente, in questo modo
un hacker (black hat) può tentare di recuperare dati sensibili come i cookies.
dunque, vediamo com'è strutturato un sito affetto da xss:
[ SCRIPT PRESO DAL LIBRO SCRITTO DA MURD3R CODE]
stringa che verrà poi stampata nella pagina che vedremo una volta arrivati alla funzione
document.write() .
Prendiamo dunque l'esempio di un motore di ricerca. Per sfruttare questa vulnerabilità c'è bisogno di inserire nel campo di input del motore di ricerca interno di un sito
o nella variabile affetta da bug, poichè i dati inseriti nel campo del motore di ricerca passano attraverso essa, del codice "maligno".
supponiamo di essere su
bene, cambiamo codice:
fin qui è una cosa innocua, ma se al posto di quei codici mettessimo:
infatti se inserissimo quel codice e faremo eseguire il link generatosi, ad una vittima, essa verrebbe trasportata su quel sito ed automaticamente
le verrebbero sottratti i cookies.
apriamo una piccola parentesi su i cookies:
quando ci si registra ad un sito, esso ci invia dei file di testo chiamati cookies,i quali contengono username e password, in modo tale che al prossimo
accesso al sito non sia necessario inserire i dati di accesso, quindi saremo già autentificati.
le variabili con scarso controllo possono essere di tipo GET o POST, ossia in quella di tipo GET i dati inseriti(<script>alert....)
sono visibili all'utente nell'url, mentre nel tipo POST no.
ma che vuol dire?!
in pratica se noi facessimo un xss in una variabile get il link che si genererà nell'url,
conterrà il codice inserito(
e quindi è possibile farlo eseguire
alla vittima semplicemente facendoglielo visitare.
mentre quella di tipo POST, nell'url non risulterà il codice inserito, quindi dovremo cercare la variabile buggata nel sorgente della pagina, dopodichè basta incollarla sull'url
ed inserire il codice che si vuole.
queste di cui ho parlato, sono xss "volatili" ossia, vengono solo visualizzate se l'utente visita il link con il codice dell'xss.
Esistono però le xss permanent, ossia sono quelle xss il cui codice viene iniettato in un campo input di una pagina e, se la pagina è strutturata in un certo modo (come vedremo) ci permetterà di iniettare il codice e di farlo permanere
nella stessa pagina. in pratica questo tipo di xss si verifica ogni volta che viene visitata quella determinata pagina, senza far visitare il link che contienè il codice maligno. Vi faccio capire meglio:
supponiamo di avere una pagina strutturata in questo modo:
questo form non fa altro che prendere i dati immessi, memorizzarli e mostrarli in una pagina successiva chiamata 03_inse.php
che conterrà il codice
quindi se un utente inserisse come nome "mario", come email "mario@provider.com" e come password "pincopallino",
nella pagina 03_inse.php verranno stampati i dati immessi. Però come possiamo notare non c'è nessun controllo su quel form, quindi un utente potrebbe inserire anche i tag html e di conseguenza fare un xss,
quindi se al posto dei campi user, mail e pass inserissimo il codice dell'xss, nella pagina 03_inse.php visualizzeremo l'alert.
Di conseguenza, tutti gli utenti e sottolineo tutti, che visiteranno la pagina 03_inse.php vedranno comparire l'alert.
la divverenza tra i 2 tipi di xss consiste nel fatto che in quelle voltatili, per far visualizzare l'xss alla vittima bisogna dare il link contenente il codice, nelle permnenti, il codice è già stmpato nella pagina.
per fixare questo tipo di vulnerabilità bisogna modificare lo script dicendogli di negare l'azione se viene inserito il codice <script>.
Il codice in questione è:
pensate davvero che non si possa effettuare nessun tipo di attacco?!
se avete notato, la funzione "str_replace" impedisce solo l'uso degli script (<script>) permettendoci invece di fare uso di codice html.
Possiamo sfruttare l'html in quanto esso è possibile utilizzare gli eventi "onload" ed "on error".
parlando dell'evento "on error" , proviamo ad iniettare il seguente codice:
cosa fa questa stringa di codice?! semplice, se l'immagine non esiste comparirà un alert.
La stessa cosa può essere fatta con l'evento "on load" ovvero iniettando il seguente codice:
Qui invece, comparirà l'alert se l'immagine esiste.
un altro fix inutile è questo:
questa funzione toglie tutto quello che c'è tra la funzione script, ovvero se si provasse ad inserire
nella pagina verrà stampato solamente
possiamo naturalmente bypassarlo inserendo un src:
Se ben ricordate, all'inizio della guida abbiamo parlato della "pagina che ruba i dati", bene , vediamo come sfruttare l'xss con un cookie grabber.
esaminiamo e salviamo la seguete pagina in cookie.php
esaminiamo la seguente stringa di codice che abbiamo visto all'inizio:
con href specifichiamo il sito
cookie.php e il file precedente che ruba i cookie
c è la variabile dalla quale verrà inserito il comando per catturare i cookie
document.cookie è appunto il comando che serve per catturarli.
ora veniamo alla parte dell'attacco:
non vi resta che aprire il vostro file.txt e gustarvi i golosi biscotti della vittima
per scrivere questo paper ho studiato diverse guide e diversi esempi.
spero che abbiate capito, ma ricordate di usare il "codice maligno" solo per vendetta o per ownare un lamer (XD),
non è defacciare siti e rubare password che fa di voi un hacker!
_KING-V_
#AUTHOR: _KING-V_
#SITE:
Perfavore,
Entra
oppure
Registrati
per vedere i Link!
#DATE: sabato 9 gennaio 2010 21:41
#
#
#
#########################################################
[DISCLAIMER: QUESTO PAPER E' A SCOPO PURAMENTE INFORMATIVO. NON MI ASSUMO LA BENCHE' MINIMA RESPONSABILITA' SULL'UTILIZZO CHE NE FARETE. QUINDI NON VENITE A LAMENTARVI CON ME SE AVETE LA DIGOS TRA I PIEDI O SE IL VOSTRO SITO PERSONALE E' PIENO DI IMMAGINI PORNO.]
Il paper è ancora in fase di lavorazione, se credete che manchi qualcosa scrivetelo!
salve gente, premetto che questo è il mio primo tutorial(ne ho sempre fatti in versione video) quindi si accettano commenti e critiche.
Molta gente, girando sul web, si chiede come possa riuscire ad ottenere la password di un account qualsiasi, di quello della propria ragazza,
o come ottenere accesso ad aree private di un sito, ma non sa da dove iniziare.
Bé, da me non otterrete una risposta, dato che una risposta di tal genere non esiste; o almeno essa non esiste nell'ambito dell'hacking. Altresì, non esiste un metodo definitivo per appropriarsi (più o meno illecitamente) di dati personali altrui o per accedere ad aree protette, nemmeno se si tocca un argomento più scottante e restrittivo come quello del "cracking".
Comunque, per chi non conosca la differenza fra hacking e cracking sarà bene fare una ricerca più approfondita e tornare alla lettura di questo paper quando si avranno le conoscenze necessarie.
Per quanto riguarda il campo di quello che spesse volte viene definito "gioco intellettuale" dai praticanti, l'hacking, l'argomento che oggi vorrei sottoporre alla vostra attenzione è il Cross Site Scripting, una tecnica a cui sono vulnerabili molti siti web con scarso controllo delle variabili utilizzate da pagine dinamiche (come i siti che fanno uso di tecnologie con preprocessore di ipertesto, tipo PHP). Vediamo le possibilità che una tale situazione ci mette di fronte.
l'xss consente di inserire codice a livello browser al fine di modificare il codice sorgente della pagina web visitata dall'utente, in questo modo
un hacker (black hat) può tentare di recuperare dati sensibili come i cookies.
dunque, vediamo com'è strutturato un sito affetto da xss:
[ SCRIPT PRESO DAL LIBRO SCRITTO DA MURD3R CODE]
Cosa fa questa pagina ? tramite la funzione prompt() , ci fa inserire una qualsiasi
stringa che verrà poi stampata nella pagina che vedremo una volta arrivati alla funzione
document.write() .
Prendiamo dunque l'esempio di un motore di ricerca. Per sfruttare questa vulnerabilità c'è bisogno di inserire nel campo di input del motore di ricerca interno di un sito
o nella variabile affetta da bug, poichè i dati inseriti nel campo del motore di ricerca passano attraverso essa, del codice "maligno".
supponiamo di essere su
Perfavore,
Entra
oppure
Registrati
per vedere i Link!
e di voler fare un xss, allora dovremmo andare nel motore di ricerca e scrivere:appena la ricerca verrà eseguita, nella pagina ci comparirà una finestra con scritto "xss".
bene, cambiamo codice:
appena la ricerca verrà eseguita nella pagina, ci comparirà l'immagine che abbiamo dichiarato.
fin qui è una cosa innocua, ma se al posto di quei codici mettessimo:
allora la cosa si farebbe seria.
infatti se inserissimo quel codice e faremo eseguire il link generatosi, ad una vittima, essa verrebbe trasportata su quel sito ed automaticamente
le verrebbero sottratti i cookies.
apriamo una piccola parentesi su i cookies:
quando ci si registra ad un sito, esso ci invia dei file di testo chiamati cookies,i quali contengono username e password, in modo tale che al prossimo
accesso al sito non sia necessario inserire i dati di accesso, quindi saremo già autentificati.
le variabili con scarso controllo possono essere di tipo GET o POST, ossia in quella di tipo GET i dati inseriti(<script>alert....)
sono visibili all'utente nell'url, mentre nel tipo POST no.
ma che vuol dire?!
in pratica se noi facessimo un xss in una variabile get il link che si genererà nell'url,
conterrà il codice inserito(
)
e quindi è possibile farlo eseguire
alla vittima semplicemente facendoglielo visitare.
mentre quella di tipo POST, nell'url non risulterà il codice inserito, quindi dovremo cercare la variabile buggata nel sorgente della pagina, dopodichè basta incollarla sull'url
ed inserire il codice che si vuole.
queste di cui ho parlato, sono xss "volatili" ossia, vengono solo visualizzate se l'utente visita il link con il codice dell'xss.
Esistono però le xss permanent, ossia sono quelle xss il cui codice viene iniettato in un campo input di una pagina e, se la pagina è strutturata in un certo modo (come vedremo) ci permetterà di iniettare il codice e di farlo permanere
nella stessa pagina. in pratica questo tipo di xss si verifica ogni volta che viene visitata quella determinata pagina, senza far visitare il link che contienè il codice maligno. Vi faccio capire meglio:
supponiamo di avere una pagina strutturata in questo modo:
questo form non fa altro che prendere i dati immessi, memorizzarli e mostrarli in una pagina successiva chiamata 03_inse.php
che conterrà il codice
Come si può notare, c'è la funzione "print" che stampa tutto quello che è stato scritto nella pagina precedente.
quindi se un utente inserisse come nome "mario", come email "mario@provider.com" e come password "pincopallino",
nella pagina 03_inse.php verranno stampati i dati immessi. Però come possiamo notare non c'è nessun controllo su quel form, quindi un utente potrebbe inserire anche i tag html e di conseguenza fare un xss,
quindi se al posto dei campi user, mail e pass inserissimo il codice dell'xss, nella pagina 03_inse.php visualizzeremo l'alert.
Di conseguenza, tutti gli utenti e sottolineo tutti, che visiteranno la pagina 03_inse.php vedranno comparire l'alert.
la divverenza tra i 2 tipi di xss consiste nel fatto che in quelle voltatili, per far visualizzare l'xss alla vittima bisogna dare il link contenente il codice, nelle permnenti, il codice è già stmpato nella pagina.
per fixare questo tipo di vulnerabilità bisogna modificare lo script dicendogli di negare l'azione se viene inserito il codice <script>.
Il codice in questione è:
questo codice sostituisce la funzione <script> in "script" , in questo modo la sintassi non sarebbe valida e quindi non si potrebbe effettuare nessun tipo di attacco.
pensate davvero che non si possa effettuare nessun tipo di attacco?!
se avete notato, la funzione "str_replace" impedisce solo l'uso degli script (<script>) permettendoci invece di fare uso di codice html.
Possiamo sfruttare l'html in quanto esso è possibile utilizzare gli eventi "onload" ed "on error".
parlando dell'evento "on error" , proviamo ad iniettare il seguente codice:
cosa fa questa stringa di codice?! semplice, se l'immagine non esiste comparirà un alert.
La stessa cosa può essere fatta con l'evento "on load" ovvero iniettando il seguente codice:
Qui invece, comparirà l'alert se l'immagine esiste.
un altro fix inutile è questo:
questa funzione toglie tutto quello che c'è tra la funzione script, ovvero se si provasse ad inserire
nella pagina verrà stampato solamente
possiamo naturalmente bypassarlo inserendo un src:
ovviamente il file script.js conterrà il codice interessato.
Se ben ricordate, all'inizio della guida abbiamo parlato della "pagina che ruba i dati", bene , vediamo come sfruttare l'xss con un cookie grabber.
esaminiamo e salviamo la seguete pagina in cookie.php
esaminiamo la seguente stringa di codice che abbiamo visto all'inizio:
document.location è il comando che serve per eseguire un redirect ad un altro sito
con href specifichiamo il sito
cookie.php e il file precedente che ruba i cookie
c è la variabile dalla quale verrà inserito il comando per catturare i cookie
document.cookie è appunto il comando che serve per catturarli.
ora veniamo alla parte dell'attacco:
la vittima eseguirà il codice ignara di tutto e verrà redirectata su youtube,
non vi resta che aprire il vostro file.txt e gustarvi i golosi biscotti della vittima
per scrivere questo paper ho studiato diverse guide e diversi esempi.
spero che abbiate capito, ma ricordate di usare il "codice maligno" solo per vendetta o per ownare un lamer (XD),
non è defacciare siti e rubare password che fa di voi un hacker!
_KING-V_
