Wo in der Aufrufliste sollten Rollenprüfungen durchgeführt werden?

Question

In meiner typischen App klickt der Benutzer auf eine Schaltfläche in einer aspx-Seite, ruft ein C# -Geschäftsobjekt auf und führt dann eine gespeicherte Prozedur aus.

Sollten Rollenprüfungen oben im Stapel, im unteren Bereich des Stapels oder auf jeder Ebene durchgeführt werden? Es scheint, dass wenn ein böswilliger Benutzer eine Methode aufrufen kann, er alle aufrufen kann, so dass für eine effektive Sicherheit eine Überprüfung für jede Methode erforderlich ist (und das ist viel zusätzlicher Code zum Schreiben).

Hier ist ein typischer Call-Stack meine Frage zu erläutern:

Page_Load() 
{ 
    if(p.IsInRole("Managers")) //or equivalent attribute 
    { 
    AddAccount.Visible =true; 
    } 
} 

AddAccount_OnClick() 
{ 
    if(p.IsInRole("Managers")) //or equivalent attribute 
    { 
    //Add the account 
    Account.Add(...); //and maybe another role check... 
    } 
} 

-- TSQL doesn't understand .NET authorization, this call is in a 'trusted' subsystem 
create proc Add_Account @user, @account_name 
If @user in (Select user from role_table where role='manager') 
-- Add the account 

Answer 1

Meiner Meinung nach sollten Sie es so nah wie möglich an die Daten bringen. Je näher Sie an den Daten sind, desto besser können Sie sicherstellen, dass es nicht möglich ist, einen umständlichen Weg durch Ihre Codebasis zu gehen, um eine Zugriffsprüfung zu umgehen.

Dieses Argument würde Sicherheitsüberprüfungen erfordern, die entweder in der Datenquelle selbst, wenn sie dies unterstützt (wie Ihr bevorzugtes RDBMS) oder in der Datenzugriffsschicht platziert werden.

Allerdings haben einige Sicherheitsbeschränkungen einen starken Geruch von Geschäftslogik; z.B. "Wenn der Benutzer in dieser Rolle ist und versucht, Daten zu ändern, die diese Spezifikationen erfüllen, sollte der Vorgang erlaubt sein; andernfalls nicht". Das klingt für mich nach einer Richtlinie und nach etwas, das entweder in der Business-Logik-Ebene einer separaten Regel-Engine liegt.

I wrote about something similar in the context of WCF some time ago.

Answer 2

Ich würde die Rolle Zugriffsüberprüfungen in den Business-Objekten platzieren tatsächlich das potenziell gefährliche/sensible Material durchgeführt wird.

Hinzufügen der Rolle überprüfen, um Ihre Seite laden und Button klicken Ereignisse würde außerhalb sein, IMHO. Wenn Sie die Seite schützen möchten, schützen Sie die Seite außerdem mit den Anweisungen für den deklarativen Speicherort in Ihrer Datei web.config ... z. Legen Sie alle Ihre "Admin" -Seiten in einen separaten Ordner und schützen Sie den gesamten Ordner deklarativ.

Aber Sie sollten mindestens die Prüfungen Ihrer Geschäftsobjektmethoden mindestens haben.

Answer 3

Sie müssen es auf der Methodenebene setzen. Sie können nicht davon ausgehen, dass Sie diese Methode auf eine bestimmte Weise erreichen. Diese Methode kann vom Button-Handler aufgerufen werden oder sie kann im normalen Code als Ergebnis einer beliebigen Art von Logik aufgerufen werden. Wie oft haben Sie so etwas wie dies gesehen eine Schaltfläche Handler Aufruf ...

private void MyBypassingCall() 
{ 
    if(myLogic) 
    { 
    AddAccount_OnClick(); 
    } 
} 

So legt es auf Page_Load ist nicht genug. Sie sollten auch die Methode mit einer PrincipalPermissionAttribute dekorieren. Das reduziert eine Menge Code.

Answer 4

Business-Objekte.

Aber zur Bauzeit. Lassen Sie jede Instanz eine ganz bestimmte Rolle erfassen.

Edit: Auf diese Weise prägnanter.

Answer 5

Dies ist nur eine anekdotische Bemerkung, wie wichtig es sein kann, die Sicherheitsvalidierung auf der Geschäftsseite durchzuführen. Es war in unserem Fall nicht gut genug, um die niedrigen Erwartungen bezüglich des Request Hacking zu optimisieren. Wir hatten keine Validierung in unseren Geschäftsobjekten und wurden auf eine unerwartete Art und Weise gebrannt. Ein Client hat ein Skript erstellt, um die Nutzung unserer Website zu automatisieren. Es folgte den erwarteten Links in ihrem Skript, die nicht tatsächlich gerendert wurden. Es endete damit, Daten zu korrumpieren. Natürlich ist dies für uns eher ein Systemzustands- und Datenintegritätsproblem als eine Sicherheitsverletzung, aber ich nehme an, dass beide wirklich zutreffen.

Answer 6

Aus einer Implementierungsperspektive wäre es die beste Lösung, die Prüfungen so weit wie möglich auf dem Stapel zu implementieren, da es die geringste Anzahl von Funktionen gibt, die geschützt werden müssen, daher die geringste Anzahl von Fehlern und alle Benutzer Eingänge müssen die geschützte Schicht passieren. Wenn Ihre Stiftung geschützt ist, müssen Sie sich nicht um alles kümmern, was auf dieser Grundlage aufgebaut ist.

Diese Lösung hat einen offensichtlichen Nachteil - die Benutzeroberfläche weiß nichts über Authentifizierung, Autorisierung, Datenverifizierung und all die anderen Dinge. So geht jede Eingabe den Stapel hinunter, könnte einen Fehler verursachen und geht den Stapel wieder hoch, um den Benutzer zu informieren. Dies führt zu einer unangenehmen Benutzererfahrung, da Fehler, die auf der Benutzeroberfläche leicht erkannt werden können, erst nach der Übergabe der Daten an die Backend-Systeme erkannt werden.In der Folge werden Sie dem Benutzerinterface auch viele Checks hinzufügen, um eine bessere Benutzererfahrung zu ermöglichen.

Wenn Sie interface-basierte Programmierung verwenden, ist dies überhaupt kein Problem, da Sie den Verifikationscode zwischen den Anwendungsschichten teilen können. Auf diese Weise können Sie allen Anwendungs-Layern noch einfacher Verifikationscode hinzufügen. So erhalten Sie eine umfassende Verteidigung - ein Fehler in einer Anwendungsebene kann von einer anderen Schicht abgefangen werden. Wenn der Verifikationscode selbst fehlerhaft ist und Sie ihn über Anwendungsschichten gemeinsam nutzen, wird der Fehler und der Fehler wahrscheinlich auf allen Anwendungsschichten auftreten.