Wir schreiben eine mobile iOS-App in Objective-C, die Beiträge zu unserer ASP.NET MVC-Server-App erstellt. Auf dem iPhone scheint der HTTP-Stack (und Cookies usw.) für Safari freigegeben zu sein. Dies lässt uns für XSRF-Angriffe offen. Wenn ich mich nicht irre, müssen wir die POSTs mit fälschungssicheren Token schützen und unsere Controller-Methoden mit schützenValidateAntiForgeryTokenAttribute.

Ich werde diese Frage einschränken, indem ich sage, dass ich den Mechanismus, mit dem die Fälschungsschutz-Token erzeugt und verifiziert werden, nicht richtig verstehe. Insbesondere der in diesem Zusammenhang verwendete Begriff „Nonce“ ist etwas mystisch.

Da wir dem Client kein HTML liefern, können wir den Standard nicht verwenden@Html.AntiForgeryToken(), also stattdessen müssen wir verwendenAntiForgery.GetTokens die Token zu erwerben und an unsere Kunden zu verteilen. Dies hat einen mysteriösen ersten Parameter:oldCookieToken. Im Moment habe ich es einfach so eingestelltnull und alles scheint gut zu funktionieren. Kann mir jemand sagen, was es bringt, den alten Token dem Algorithmus zur Token-Generierung zuzuführen? Wenn nur ein einziger Token an unsere iOS-App ausgegeben und für mehrere Posts wiederverwendet wird, ist dies problematisch?