Verhinderung von Url-Manipulationsangriffen mit MVC?

Question

Gibt es gute Strategien, Codeschnipsel usw., um URL-Manipulationen zu verhindern?

Ich habe zum Beispiel diese Url, http://localhost/profile/edit/5 die Kennung könnte leicht in irgendetwas geändert werden, so dass Personen Profile bearbeiten könnten, die sie nicht bearbeiten sollten.

Hier sind einige Ideen, an die ich gedacht habe, aber sie haben alle ihre Nachteile:

1. Ändern Sie mein System, um GUID-Primärschlüssel zu verwenden - das macht es fast unmöglich, die Schlüssel zu erraten - aber die Leute können immer noch die GUID von einem Teil der Anwendung nehmen und sie später in einer anderen URL verwenden.

2. Verwenden Sie TempData, um die Schlüssel zu speichern - so wird verhindert, dass Urls herumgeschickt werden \used später.

3. Prüfungen im Controller vor der Anzeige der Seite durchführen - bedeutet, dass Sie müssen Sie überall 'adminy' Code machen um Vorgänge zu prüfen.

Was ist das Beste, was man tun kann? Eine von diesen oder etwas anderes?

Answer 1

Nummer 3 ist die richtige Vorgehensweise. Die serverseitige Sicherheitsvalidierung ist immer das, was Sie brauchen, denn dies ist der Mechanismus, den Sie vollständig kontrollieren und auf den Sie sich verlassen können.

Nummer 1 ist "Security by Obscurity", und wenn jemand versehentlich seine URL irgendwo veröffentlicht (wie es Leute oft mit Session-IDs tun, wenn sie Links kopieren/einfügen), ist Ihre "Sicherheit" gebrochen.

Nummer 2 scheint eine schwache Sicherheitsmaßnahme zu sein - wenn man sich schon die Mühe macht, sollte man besser eine angemessene Sicherheit einführen. So können die Leute auch ein Lesezeichen für die Seite setzen.

Answer 2

Ich verwende benutzerdefinierte Autorisierungsfilter, um rollen- und eigentümerbasierte Zugriffskontrolle zu implementieren. Mit dem standardmäßigen AuthorizationFilter können Sie benannte Rollen oder Benutzer angeben, die Zugriff auf eine Aktion haben können. Ich habe dies so erweitert, dass Sie angeben können, dass der aktuelle Benutzer Zugriff haben kann, wenn er der "Eigentümer" der Daten ist. Ich habe zwei zusätzliche Filter, RoleOrOwnerAuthorizationFilter und RoleOrOwnerAssociatedAuthorizationFilter. Der erste prüft, ob ein konfigurierbarer Parameter (normalerweise id ), die in RouteData übergeben wird, ist die ID des aktuellen Benutzers in meiner Benutzertabelle oder wenn der aktuelle Benutzer einer der aufgeführten Rollen angehört. Wenn dies der Fall ist, ist die Prüfung erfolgreich, wenn nicht, wird ein Berechtigungsfehler angezeigt.

Mit der zweiten kann ich eine Verknüpfungstabelle und die zu verwendenden Parameter angeben, um einen Parameter in den RouteData mit einer Spalte in einer Verknüpfungstabelle und den aktuellen Benutzer mit einer anderen Spalte in der Verknüpfungstabelle zu verknüpfen. Wenn es einen Eintrag gibt, der sowohl mit dem Parameterwert als auch mit dem Benutzer übereinstimmt, schließe ich daraus, dass der Benutzer mit den Daten verbunden ist und Zugriff hat. Der Zugriff ist auch möglich, wenn Sie eine bestimmte Rolle innehaben. Mit den drei verschiedenen Attributen habe ich fast alle meine Anforderungen an die Zugriffskontrolle erfüllt, d. h. ich wende die Sicherheit einfach an, indem ich ein entsprechend konfiguriertes Attribut einsetze.

Answer 3

Sie sollten Ihre URLs nicht "manipulationssicher" machen, um die zugrunde liegende Funktionalität zu schützen. Außerdem: Die meisten Websites machen URLs lesbarer wie http://stackoverflow.com/questions/741653/preventing-url-manipulation-attacks-with-mvc zum Beispiel - wäre eine Verschleierung ein Rückschritt.

Überprüfen Sie stattdessen die Berechtigungen in Ihren Controllern und lösen Sie eine Ausnahme aus, wenn der Benutzer nicht berechtigt ist, Profil 6 zu bearbeiten. Wenn Sie die "Prüfungen" nicht überall haben wollen, könnten Sie sie vielleicht in eine ActionFilter , oder erstellen Sie eine Hilfsmethode wie CurrentUser.FindProfileToEditById(profileId) (die eine Ausnahme auslöst, wenn die Aktion nicht erlaubt ist) anstelle von Profile.FindById(id) .

Wenn Sie einen allgemeinen Dienst wollen, bei dem es keinen "aktuellen Benutzer" gibt, können Sie die GUID verwenden (so macht es z. B. Doodle) - allerdings wird dies immer ein Sicherheitsrisiko in verschiedener Hinsicht darstellen (Facebook hatte dieses Problem mit seinen Fotoalben).

Answer 4

Die URL, die für den Zugriff auf Ihre Website verwendet wird, sind Daten des Kunden, und wenn es um Sicherheit geht, sollten Sie die vom Kunden bereitgestellten Daten immer als feindlich betrachten.

Leider gibt es keine Patentrezepte für dieses Problem. Sie müssen in der gesamten Anwendung Zugriffsbeschränkungen einführen.