In che modo ValidateAntiForgeryToken si adatta alle API Web a cui è possibile accedere tramite l'app Web o nativa?

Question

Sto cercando di capire come sarà possibile creare un'API utilizzando l'API Web ASP.NET che verrà protetta da CSRF, pur rimanendo accessibile da ambienti non Web (ad esempio applicazioni mobili native).

Il mio primo pensiero sarebbe che un ambiente non Web non può mai passare con successo una convalida del token anti-contraffazione, dal momento che non ha un modulo che viene pubblicato. È vero? C'è un modo per far funzionare la validazione?

Se non c'è un modo per convalidare, il mio secondo pensiero è quello di offrire una API che convalida i token anti-contraffazione per le chiamate Web ma non per le chiamate non web. Tuttavia, sembra che un hacker possa altrettanto facilmente utilizzare questa API "non web" per un attacco CRSF, giusto?

È la risposta che l'API non Web deve supportare solo un meccanismo di autenticazione non Web (OAuth?), In modo che le richieste ad esso non possano essere riprodotte tramite un browser? O c'è un modo più semplice?

Se questo è l'unico modo, c'è un modo semplice per disattivare tutti i meccanismi di autenticazione non sicuri? Non dovrebbe esserci un percorso un po 'semplice/felice nell'API Web ASP.NET per supportare questi scenari?

Answer 1

CSRF diventa un problema solo quando si utilizza un meccanismo di autenticazione persistente come cookie, autenticazione di base, NTLM ecc. Mike Wasson ha an example di usare CSRF contro webapi in Javascript - e ho visto versioni in DelegatingHandlers ...

Poiché CSRF è solo un problema negli scenari Web, è possibile affermare che non è necessario verificare le richieste non web. Ogni richiesta Ajax da un browser, sia tramite jquery, le classi native XmlHttpRequest o qualsiasi altra cosa viene fornita con un'intestazione - X-Requested-With, che avrà un valore di XMLHttpRequest. Quindi potresti limitare i tuoi assegni CSRF alle sole richieste con quell'intestazione, poiché qualsiasi cosa senza di essa deve provenire da un browser esterno.

Detto questo, se si sta autenticando, guarderei una sorta di segreto condiviso o meccanismo OAuth, e ho un lato server DelegatingHandler da convalidare, e nell'app web basta mettere il token da qualche parte che può essere prelevato tramite javascript e inviato tramite un'intestazione X-Authentication - poiché non è persistente e deve essere allegato ad ogni richiesta (proprio come il token CSRF) non ci sono problemi CSRF. Dominick, come sempre, documents questo genere di cose bene.

Answer 2

Dai un'occhiata ai modelli SPA nell'ultimo aggiornamento di MVC4. Hanno un'implementazione di esempio per Anti-CSRF per l'API Web.

Answer 3

Dai un'occhiata all'implementazione CORS per WebAPI.

http://blogs.msdn.com/b/carlosfigueira/archive/2012/07/02/cors-support-in-asp-net-web-api-rc-version.aspx

allora si potrebbe consentire solo localhost come un URI valido sul server WebAPI. Ciò impedirebbe ad altri siti di caricare il codice di attacco nel browser.