Ich kann den vom MVC3-Framework generierten Verifikationstoken-Schlüssel tatsächlich im Klartext sehen, wenn ich eine Anfrage an den Server ohne SSL stelle.

Dieser Schlüssel wird in einem Cookie mit dem Namen: _RequestVerificationToken_Lw__ gespeichert.

In einer gemischten Sicherheitsumgebung ist es tatsächlich möglich, dieses Token in Klartext anzuzeigen, der bei der ersten Anforderung an die Site ohne SSL an den Server gesendet wurde. Dieses Token ist auch für die Dauer der Benutzersitzung statisch. Was nützt es dann, dieses Token zu haben, wenn es leicht von einem Angreifer gestohlen werden kann, weil das Cookie im Klartext herumgeworfen wird.

Sollte dieses Cookie nicht als sicher markiert und niemals im Klartext übermittelt werden? Oder zumindest bei jeder Anfrage neu generiert werden, damit die gesicherten Informationen nicht aus dem SSL-Kanal austreten?

Ich spreche von diesem Block in MVC 3AntiForgeryWorker Klasse

private string GetAntiForgeryTokenAndSetCookie(HttpContextBase httpContext, string salt, string domain, string path)
{
  string forgeryTokenName = AntiForgeryData.GetAntiForgeryTokenName(httpContext.Request.ApplicationPath);
  AntiForgeryData token = (AntiForgeryData) null;
  HttpCookie httpCookie = httpContext.Request.Cookies[forgeryTokenName];
  if (httpCookie != null)
  {
    try
    {
      token = this.Serializer.Deserialize(httpCookie.Value);
    }
    catch (HttpAntiForgeryException ex)
    {
    }
  }
  if (token == null)
  {
    token = AntiForgeryData.NewToken();
    string str = this.Serializer.Serialize(token);
    HttpCookie cookie = new HttpCookie(forgeryTokenName, str)
    {
      HttpOnly = true,
      Domain = domain
    };
    if (!string.IsNullOrEmpty(path))
      cookie.Path = path;
    httpContext.Response.Cookies.Set(cookie); //Ma, Why isn't this marked as "SECURE"
  }
  return this.Serializer.Serialize(new AntiForgeryData(token)
  {
    Salt = salt,
    Username = AntiForgeryData.GetUsername(httpContext.User)
  });
}