2013-10-24 3 views
6

A partire da 2 diverse applicazioni, sono stato in grado di inviare le richieste cross-orgin. Sebbene il browser restituisca un errore di Cross-Origin, ma il mio server sta ancora ricevendo ed eseguendo la richiesta. Ad esempio, da un sito remoto, posso richiamare richiesta tra domini utilizzando,Come impedire ad altri siti Web di inviare richieste ajax su più domini?

$.ajax({ 
     xhrFields: { 
      withCredentials: true 
     }, 
     data:{ my: 'a' }, 
     url: 'http://MyApp/Page', 
     type: 'POST' 
}) 

So che il browser non restituisce la risposta alla sceneggiatura, ma la mia pagina del server ancora eseguire.

Diciamo che un utente innocente viene registrato in un sito, http://abc.com. Questa applicazione accetterà richiesta post per inserire un record. Quando innocenti visite degli utenti a innocenti http://HackerSite.com, il http://HackerSite.com saranno in grado di inviare una richiesta POST per http://abc.com tramite Ajax. Come evitare questo?

+2

Nizza domanda. Se hai una risposta per questo, apprezzerò molto se pubblichi se. –

+0

Per un servizio WCF, è possibile impostare ** ** crossdomainscriptaccessenabled su false nella configurazione punto finale. – Saranya

+2

Avrai lo stesso problema con un modulo di invio, nessun javascript coinvolto. Le specifiche CORS non sono state create pensando alla sicurezza aggiuntiva. Invece, ti permette essenzialmente di eseguire le stesse azioni che potresti già eseguire (cross-origin) con ajax. Le specifiche CORS va un po 'più in là, in quanto assicurano il server non ha nemmeno ricevere la richiesta di fondo, se il server non correttamente opt-in per le specifiche e la stessa richiesta non poteva essere inviato cross-origine sans ajax (diciamo, tramite un modulo di invio). Quest'ultimo concetto è chiamato preflight. –

risposta

2

La vulnerabilità di cui si sta parlando è CSRF ma può essere sorvegliata.

È possibile evitare che il POST venga inviato al di fuori di una richiesta AJAX (ad esempio mediante un modulo HTML) inviando e controllando l'intestazione X-Requested-With: XMLHttpRequest. Anche questo non può essere inviato tra domini tramite AJAX poiché questa intestazione non è nella lista sicura (senza CORS).

Tuttavia in passato ci sono stati alcuni exploit attraverso i plugin come Flash, dove potrebbero essere impostate le intestazioni che non erano possibili tramite un browser (ad esempio Referer) in modo da evitare il rischio di questo si consiglia di utilizzare la synchroniser token pattern che prevede la fissazione di un token in un campo nascosto che verrà convalidato così come i cookie per tutte le richieste distruttive. Per distruttivo intendo le richieste che cambiano, inoltrano o cancellano le cose (ad esempio, quali dovrebbero essere i POST).

Per maggiori informazioni vedi qui: http://www.html5rocks.com/en/tutorials/cors/

+0

Nel mio asp.caso web-form netto, sta inviando il cookie, Ecco le regole del preflight, 'Il browser può saltare la richiesta preflight se si verificano le seguenti condizioni: Il metodo di richiesta è GET, HEAD o POST e L'applicazione fa non impostare alcuna intestazione di richiesta diversa da Accetta, Accetta lingua, Content-Language, Content-Type o Last-Event-ID e L'intestazione Content-Type (se impostata) è una delle seguenti: application/x- www-form-urlencoded multipart/form-data text/plain ' – user960567

+0

Ma controllerò di nuovo e tu lo sai. Grazie – user960567

+0

Penso che tu abbia ragione - I'll edit. – SilverlightFox

0

Access-Control-Allow-Origin intestazione deve essere impostato in modo appropriato per non consentire i domini diversi da quelli richiesti. tuttavia questo funziona solo per i browser moderni. riferiscono http://encosia.com/using-cors-to-access-asp-net-services-across-domains/ http://code.google.com/p/html5security/wiki/CrossOriginRequestSecurity

+0

Questo non è il posto giusto per implementare la sicurezza. Il browser/client non può essere considerato affidabile. –

1

On facile soluzione, ma questo non è del tutto a prova di proiettile è ciò che chiamiamo un "token di convalida". Ogni post proveniente dal tuo sito web dovrebbe avere un token CSRF da convalidare sul lato server per assicurarti che la richiesta provenga realmente dal tuo sito web. Controllare questo per ulteriori informazioni: http://shiflett.org/articles/cross-site-request-forgeries