Difesa contro gli stessi attacchi di origine?

4

La domanda:

Come faccio, in quanto vittima, a proteggere il mio sito dall'essere manipolato a fare qualcosa che non dovrebbe, su un host condiviso? La politica della stessa origine guarda dall'altra parte. La cosa più comoda sarebbe probabilmente se potessi in qualche modo dire qualcosa come "il mio url = origine sempre unica" .

Sfondo:

Sono appena entrato nel mondo di Javascript ed ecco la mia comprensione della politica Same-Origin : SOP entra in gioco ogni volta che due siti su origini diverse interagiscono, sia tramite XMLHttpRequest , <script> caricando, accesso DOM tramite window.open() 's Window riferimento o attraverso iframe ..

Ora va tutto bene e bene in caso di "un sito per dominio" o "sul sito per sottodominio" , ma per quanto riguarda l'hosting condiviso o i domini condivisi ?

Scenario:

Lascia che il sito del bravo ragazzo risieda

http://shared-hosting.tld/~target/administration/

e l'autore dell'attacco in

http://shared-hosting.tld/~attacker/

I cookie a parte, la vittima ha una sessione autenticata in qualche modo in corso a /administration/ (cookie, archiviazione locale, qualsiasi cosa). Dopodiché, l'utente malintenzionato inganna la vittima visitando il sito su /~attacker/ e utilizzando window.open() o iframe sul sito dell'aggressore, sposta il browser della vittima su /administration/ . Poiché l'autore dell'attacco ha un riferimento all'oggetto Window e entrambi i siti hanno la stessa origine, l'utente malintenzionato ha accesso completo al contenuto di quel sito tramite la manipolazione DOM (autenticato e tutto), poiché SOP non interferisce.

E ti preghiamo di non intrappolare in che modo il sito /administration/ della vittima autentica (e mantiene) lo stato autenticato dagli utenti. A meno che non ci sia un modo per risolvere questo problema in questo modo.

anche:

Capisco che sto solo indicando l'oggetto Window e l'accesso al DOM attraverso di esso, perché non vedo (so) altri modi in cui un sito potrebbe interagire maliziosamente con altri siti su un host condiviso in questo caso , ma sentiti libero di evidenziare altre cattive intenzioni rilevanti per questo.

Alcuni pensieri: il controllo di Javascript per il caricamento lego della pagina? Non sembra che sarebbe di aiuto. Il sito "reale" della vittima di Iframing all'interno di un sito di "benvenuto" con attributo sandbox? Disabilita anche l'accesso genitore- e gt; .. Tutto sembra tornare sempre al "genitore" potendo accedere al "bambino" senza alcuna restrizione.

    
posta Gima 24.03.2013 - 17:19
fonte

2 risposte

5

Prima di tutto è necessario leggere la Parte 2 del Manuale di sicurezza del browser, in particolare la stessa politica di origine per Accesso DOM e XMLHttpRequest .

La stessa politica di origine è limitata dal nome del dominio, non dal percorso e questa regola fondamentale probabilmente non cambierà mai. Se due applicazioni web condividono lo stesso dominio, saranno in grado di leggere gli altri dati utilizzando una richiesta XMLHttpRequest. Questo può essere usato per sconfiggere i token CSRF , in un attacco simile a worm Smile di MySpace . L'ID di sessione può anche essere accessibile se il flag cookie http_only non è impostato.

Quindi, come hai due applicazioni correttamente sandbox? Devono essere su domini diversi . I sottodomini sono gratuiti , quindi per utilizzare SOP in sandbox queste applicazioni devi utilizzare target.shared-hosting.tld e attacker.shared-hosting.tld .

Se leggi la politica della stessa origine per i cookie vedrai che se un cookie ha come ambito shared-hosting.tld , quindi *.shared-hosting.tld sarà in grado di accedere a questo valore del cookie. Ma questo è anche facile da evitare, ma assicurati che tutti i cookie abbiano come ambito il sottodominio, quindi www.shared-hosting.tld sarebbe un dominio sicuro.

E questo uso delle applicazioni SOP su sandbox funzionerà perfettamente, purché l'applicazione di destinazione non sia vulnerabile a XSS.

    
risposta data 24.03.2013 - 17:46
fonte
1

La risposta breve è mettere la tua applicazione sul proprio dominio. Non condividere il dominio con nessuno di cui ti fidi.

Ad esempio, invece di ospitare i tuoi contenuti in http://shared-hosting.tld/~gima/ , ospitali su http://gima.shared-hosting.tld/ o http://gima.org/ . Qualsiasi buona compagnia di hosting dovrebbe supportare questo. (Se non lo fanno, scegli una società di hosting diversa!) Se usi i cookie, http://gima.org è più sicuro di http://gima.shared-hosting.tld/ , perché impedirà l'inserimento di cookie da parte di altri utenti utilizzando lo stesso servizio di hosting condiviso.

Se lo fai, la politica della stessa origine ti proteggerà.

    
risposta data 25.03.2013 - 03:19
fonte