Ich versuche zu verstehen, wie ich eine API mit der ASP.NET-Web-API erstellen kann, die vor CSRF , während immer noch zugänglich von Nicht-Web-Umgebungen (zB native mobile Anwendungen).
Mein erster Gedanke wäre, dass eine Nicht-Web-Umgebung eine Anti-Fälschungs-Token-Validierung niemals erfolgreich bestehen kann, da sie kein Formular hat, das gepostet wird. Ist das wahr? Gibt es eine Möglichkeit, die Validierung zu ermöglichen?
Wenn es keinen Weg zur Validierung gibt, ist mein zweiter Gedanke, eine API anzubieten, die fälschungssichere Tokens für Web-Anrufe validiert, nicht jedoch für nicht-Web-Anrufe. Es scheint jedoch so, als ob ein Angreifer diese "Nicht-Web" -API für einen CRSF-Angriff genauso leicht nutzen könnte, oder?
Ist die Antwort, dass die Nicht-Web-API nur einen Nicht-Web-Authentifizierungsmechanismus (OAuth?) unterstützen muss, damit Anforderungen an sie nicht über einen Browser wiedergegeben werden können? Oder gibt es einen einfacheren Weg?
Wenn dies der einzige Weg ist, gibt es eine einfache Möglichkeit, alle unsicheren Authentifizierungsmechanismen auszuschalten? Sollte es in ASP.NET Web API nicht einen etwas einfachen / glücklichen Pfad geben, um diese Szenarien zu unterstützen?
CSRF wird nur dann zum Problem, wenn Sie einen persistenten Authentifizierungsmechanismus wie Cookies, Basic Auth, NTLM usw. verwenden. Mike Wasson hat ein Beispiel der Verwendung von CSRF gegen Webapi in Javascript - und ich habe Versionen in DelegatingHandlers gesehen ....
Da CSRF nur ein Problem in Webszenarien ist, können Sie argumentieren, dass es nicht wirklich notwendig ist, nach nicht webbasierten Anfragen zu suchen. Jede ajax Anfrage von einem Browser, ob über jquery, die nativen XmlHttpRequest Klassen oder was auch immer kommt mit einer Kopfzeile - X-Requested-With, die einen Wert von XMLHttpRequest haben wird. Sie können also Ihre CSRF-Prüfungen auf Anfragen mit dieser Kopfzeile beschränken, da alles, was nicht dazu gehört, von außerhalb eines Browsers stammen muss.
Nachdem Sie gesagt haben, dass Sie sich authentifizieren, würde ich eine Art Shared-Secret- oder OAuth-Mechanismus betrachten und eine DelegatingHandler-Serverseite zum Validieren haben, und in der Web-App einfach das Token so platzieren, wie es nur geht per Javascript aufgenommen und über einen X-Authentication-Header gesendet werden - da es nicht persistent ist und an jede Anfrage angehängt werden muss (genau wie das CSRF-Token) gibt es keine CSRF-Probleme. Dominick, wie immer dokumentiert so etwas gut.
Sehen Sie sich die SPA-Vorlagen im aktuellen MVC4-Update an. Sie haben eine Beispielimplementierung für Anti-CSRF für Web API.
Tags und Links asp.net-web-api antiforgerytoken