Una semplice domanda: come difendersi dai CROSS SITE REQUEST FORGERIES?
10x.
Una semplice domanda: come difendersi dai CROSS SITE REQUEST FORGERIES?
10x.
nello stesso modo in cui ci si difende dalle SQLInjections, si verifica sempre scrupolosamente il valore della stringa in entrata e si effettuano "le solite operazioni" di escape più idonee per questa problematica (htmlentities, htmlspecialchars, addslashes, strip_tags, etc etc)
Non necessariamente la pagina hackerata deve far parte del programma/sito attaccato: è sufficiente che l’utente, autenticato sul Sito_A (sito attaccato) visiti una pagina malevola sul Sito_B (sito controllato dall’hacker), la quale pagina rediriga al Sito_A con query string ad hoc.
Ecco: da questo come ci si difende?
Io (il Sito_A) posso fare tutti gli escaping possibili, ma se lo stesso browser dello stesso utente autenticato, che nel frattempo sta visitando un "sitaccio" mi chiama una pagina PHP con certi parametri (costruiti apposta) in GET, io... che posso fare??
Richiesta di "ok?" no, perchè bypassarla è un attimo...
fortunatamente il browser non conta niente per il server, quindi più che non salvare password in chiaro ed evitare iframes nell'area di admin non so che dirti ... se non effettua il parsing di tutti i dati in ingresso.Originariamente inviato da mark2x
Io (il Sito_A) posso fare tutti gli escaping possibili, ma se lo stesso browser dello stesso utente autenticato, che nel frattempo sta visitando un "sitaccio" mi chiama una pagina PHP con certi parametri (costruiti apposta) in GET, io... che posso fare??
Sito B può scrivere sul browser in sito_A quello che gli pare, il server, grazie a strip_tags, html_entities, specialchars, is_int, is_float, is_string, preg_match e tutto quello che vuoi non deve permettere a nessuno di infastidire il comportamento dell'area proposta.
Browser maligno ? ... chissenefrega, è il server che deve fare i controlli, mai l'utente (o il solo utente, tipo javascript).
chi usa javascript deve fare altrettanti controlli sul server, questo da sempre
Non intendevo proprio questo.... Ma:
- Io sono autenticato sul Sito_A e sto navigando. Sono amministratore, il mondo è mio, posso fare tutto.
- Nel mentre, navigo sul Sito_B che, nel tag <img> ha questo: "Sito_A/cancella_tutto.php?id=4"
- Risultato: solamente nel visualizzare la pagina con tale img sul Sito_B, cancello metà db sul Sito_A, e nemmeno me ne accorgo (vedo solo un'immagine che non si carica).
credo che questo si possa evitare a livello di struttura del software
ad esempio io ogni "eliminazione" la faccio passare da una pagia di conferma in cui c'è un form con un campo hidden contente la sessione dell'utente, e il metodo che elimina ovviamente esegue il controllo che la sessione sia corretta.
Ovviamente ciò non toglie al "sito_b" di farsi un form identico che fa il post (dopo essersi autenticato) sul mio portale, ma a sto punto la sessione dovrebbe essere differente, o sbaglio?
"durante i primi 5 miuti di pioggia nel bosco c'è ancora asciutto, poi quando smetterà di piovere nel bosco cadranno gocce per 5 minuti.....la natura ha un'ottima memoria..."
http://www.kumbe.it
ah beh ... se per area protetta intendi una pagina dove chiunqe possa scrivere quell'url e cancellarti il db allora abbiamo concetti differenti di aree protette ...Originariamente inviato da mark2x
- Nel mentre, navigo sul Sito_B che, nel tag <img> ha questo: "Sito_A/cancella_tutto.php?id=4"
un'area protetta sta su SSL, dove sito_B non può niente, oppure su sistemi affidabili di autenticazione dove ogni operazione, prima di essre fatta, deve controllare scrupolosamente che a richiamare tale operazione sia stato proprio l'utente Pippo da sito_A.
Il problema di cui parli è tipico delle aree admin in Flash fatte da utenti poco esperti che pensano che l'SWF non sia leggibile ... si trova il link, si distrugge il db .... niente di più facile
Lasciando perdere l'SSL, mi dici:
Un esempio?Originariamente inviato da andr3a
[...]sistemi affidabili di autenticazione dove ogni operazione, prima di essre fatta, deve controllare scrupolosamente che a richiamare tale operazione sia stato proprio l'utente Pippo da sito_A.
Nel senso che basta un controllo del tipo seguente e sto sicuro?
EDIT: il semplice canonico controllo della sessione non serve a nulla.ad esempio io ogni "eliminazione" la faccio passare da una pagina di conferma in cui c'è un form con un campo hidden contente la sessione dell'utente, e il metodo che elimina ovviamente esegue il controllo che la sessione sia corretta.
io autentico su db e salvo i dati hashati sulla sessione in db, ogni operazione di amministrazione, parte di metodi di una o più classi, è autorizzata ad essere eseguita solo se l'utente ha un riscontro reale degli hash memorizzati sulla sessione in database con la lista degli autorizzati, sempre in database, e solo se i privilegi sono sufficienti.Originariamente inviato da mark2x
Nel senso che basta un controllo del tipo seguente e sto sicuro?
sito_B può fare tutto quello che vuole ma non sarà riconosciuto come un utente autenticato mentre se l'utente in sito_B clicka un link che porta alla sua area di amministrazione mentre è loggato lui è un fagiano, io posso comunque tentare di verificare, oltre alla sessione, se il referer è quello predefinito e non quello di un altro sito.
Per avere un sito_B ad hoc per fare queste cose bisogna che tale sito sappia esattamente come agire nella "mia" area di amministrazione ed invogli in tutti i modi, nascondendo il link, l'utente a clickare li per fare danni sul sito_A senza avere un reale riscontro, essendo pagine differenti, dei danni causati o del risultato dei danni.
A quel punto un controllo in javascript tipo "sei sicuro che vuoi distruggere tutto ?" prima di effettuare l'operazione potrebbe salvare ulteriormente l'utente.
Un'insieme di "collisioni" rare, anche queste, per restare in tema con l'altro 3D
E fin qui non piove.Originariamente inviato da andr3a
ogni operazione di amministrazione è autorizzata ad essere eseguita solo se l'utente ha un riscontro reale degli hash memorizzati sulla sessione in database con la lista degli autorizzati, sempre in database, e solo se i privilegi sono sufficienti.
Epperchè? Il browser invia comunque il SID (diciamo immagazzinato in un cookie) al server del Sito_A e propaga la sessione. Non è il sito ad "essere un utente", ma il browser...sito_B può fare tutto quello che vuole ma non sarà riconosciuto come un utente autenticato
Se questa è la motivazione di cui sopra, allora ok.se il referer è quello predefinito e non quello di un altro sito.
EDIT: ma non era facilmente "spoofabile"?
Sì certo.Per avere un sito_B ad hoc per fare queste cose bisogna che tale sito sappia esattamente come agire nella "mia" area di amministrazione
Assolutamente no, l'hacker punterebbe direttamente alla pagina punatata dal JavaScript, non a quella prima...A quel punto un controllo in javascript tipo "sei sicuro che vuoi distruggere tutto ?" prima di effettuare l'operazione potrebbe salvare ulteriormente l'utente.
Un insieme di "collisioni" rare, anche queste, per restare in tema con l'altro 3D
Permessi di invio
Rispondi quotando