Bindung von Aktionsparametern an Anfrage-Cookies in ASP.NET MVC - was ist passiert?

Question

In einigen frühen Vorschauen von ASP.NET MVC wurden Argumente für Controller-Methoden aufgelöst, indem zunächst der Query-String, dann das Formular und anschließend die Sammlungen von Cookies und Servervariablen untersucht wurden, wie in dieser Beitrag von Stephen Walther .

Dieser Code hat zum Beispiel funktioniert:

public class MyController : Controller {

    // This should bind to Request.Cookies["userId"].Value
    public ActionResult Welcome(int userId) {

        WebUser wu = WebUser.Load(userId);
        ViewData["greeting"] = "Welcome, " + wu.Name;
        return(View());
    }
}

aber jetzt gegen den Release Candidate läuft, wirft es eine Ausnahme, weil es keinen Wert für userId finden kann, obwohl userId definitiv in den Anfrage-Cookies erscheint.

Wurde diese Änderung irgendwo in den Versionshinweisen erwähnt? Wenn es sich um eine Änderung des Frameworks handelt, gibt es dann eine empfohlene Alternative zur Bindung von Cookies und Servervariablen auf diese Weise?

EDIT: Vielen Dank an alle, die bisher geantwortet haben. Ich habe vielleicht ein schlechtes Beispiel gewählt, um dies zu demonstrieren; unser Code verwendet Cookies für verschiedene Formen der "bequemen", aber nicht essentiellen Persistenz (Speicherung der Reihenfolge von Suchergebnissen und so weiter), es ist also keineswegs nur ein Authentifizierungsproblem. Die Auswirkungen auf die Sicherheit, wenn man sich auf Benutzer-Cookies verlässt, sind gut dokumentiert; ich bin eher an aktuellen Empfehlungen für flexible, leicht testbare Techniken zum Abrufen von Cookie-Werten interessiert. (Wie Sie sich sicher denken können, hat das obige Beispiel zwar Sicherheitsimplikationen, ist aber sehr, sehr einfach zu testen).

Answer 1

Ich glaube nicht, dass die Cookies noch überprüft werden, und ich bin mir nicht sicher, ob das beabsichtigt ist oder nicht.

In einer Anwendung gegen den RC, die ich kürzlich geschrieben habe, habe ich die CookieContainer-Code aus diesem Beitrag und ein benutzerdefiniertes authorize-Attribut für Klassen wie diese:

public class LoginRequiredAttribute : AuthorizeAttribute
{
    protected override bool AuthorizeCore(HttpContextBase httpContext)
    {
        IAppCookies a = new AppCookies(new CookieContainer());
        return a.UserId != null; /* Better checks here */
    }
}

Meine AppCookies.cs hat nur eine Methode für UserId wie diese (Auto löst zu int/null für Sie):

public int? UserId
{
    get { return _cookieContainer.GetValue<int?>("UserId"); }
    set { _cookieContainer.SetValue("UserId", value, DateTime.Now.AddDays(10)); }
}

Stellen Sie dann sicher, dass Ihre web.config so eingerichtet ist, dass sie auf Ihre Anmeldeseite verweist:

<authentication mode="Forms">
<forms loginUrl="~/Login"/>
</authentication>

Das bedeutet, dass ich in meinem Controller, um eine UserId zu erhalten, etwas wie folgt tun muss, um mein Cookie abzurufen:

[LoginRequiredAttribute]
public class RandomController : Controller
{
    BaseDataContext dbContext = new BaseDataContext();
    private readonly IAppCookies _cookies = new AppCookies(new CookieContainer());

    public ActionResult Index()
    {
        return View(new RandomViewData(dbContext, _cookies.UserId));
    }
}

Answer 2

Ich glaube, es waren die Sicherheitsaspekte, die sie dazu bewogen haben, sie herauszunehmen:

Die Kommentare im Beitrag von Stephen Walther ASP.NET MVC Tipp 15 und führte zu Phil Haacks Beitrag Benutzereingaben im Schafspelz insbesondere sein Kommentar aquí :

@Troy - Schritt eins besteht darin, die Entwickler von vornherein von dieser Denkweise abzubringen ;) Der erste Schritt besteht darin, dass wir (parallel dazu) die Möglichkeit dieser Denkweise in diesem Fall ausschließen.

Der größere Punkt steht immer noch, wir können diese Änderung vornehmen (nachdem wir darüber diskutiert haben, werden wir das wahrscheinlich tun), aber das bedeutet nicht, dass es plötzlich sicher ist, Parametern von Aktionsmethoden zu vertrauen.

Hinzu kommen die Komplikationen beim Aufruf dieser Methoden aus den verschiedenen Action-Builder-Klassen.

Ich kann außer Stephens Beitrag keine explizite Dokumentation über dieses Verhalten der Controller finden, also wurde es wohl "stillschweigend fallengelassen".

Answer 3

Neben den offensichtlichen Auswirkungen auf die Sicherheit Warum sollten Sie den Cookie in der Route überhaupt durchreichen?

Sicherlich wäre es besser, ein Authorize-Attribut für die Aktion zu haben, das angibt, dass der Benutzer authentifiziert werden sollte, bevor die Aktion ausgeführt wird.

Letzten Endes denke (hoffe) ich, dass Microsoft dieses Problem geschlossen hat, da es sich um ein ziemlich großes Sicherheitsproblem handelt. Wenn dies der Fall ist, sollten Sie in Erwägung ziehen, Ihre Anwendung so umzuschreiben, dass sie diese Anforderungen erfüllt.