Wo in den Call-Stack sollte Rollenüberprüfungen durchgeführt werden?

Question

In meinem typischen app, klickt der Benutzer auf eine Schaltfläche in einer aspx Seite, ein Objekt C # Geschäfts ruft, läuft dann eine gespeicherte Prozedur.

Sollten Rolle Kontrollen an der Spitze des Stapels durchgeführt werden, um die Unterseite des Stapels oder auf jeder Ebene? Es scheint, dass, wenn ein böswilliger Benutzer eine Methode aufrufen kann, er jeder berufen könne, so für eine effektive Sicherheit, die Sie auf jeder Methode einen Scheck benötigen würde (und das ist eine Menge zusätzlicher Code zu 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 auf die Daten so nah wie möglich stellen. Je näher Sie an die Daten, desto besser können Sie sicherstellen, dass es nicht möglich ist, etwas umständlicher Weg über Ihre Code-Basis zu nehmen eine Zugangsprüfung zu umgehen.

Das Argument für die Sicherheitskontrollen nennen würde in platziert wird entweder die Datenquelle selbst, wenn es unterstützt wird (wie Ihr Lieblings-RDBMS) oder die Datenzugriffsschicht.

Allerdings haben einige Sicherheitseinschränkungen einen starken Geruch von Geschäftslogik; z.B. „Wenn der Benutzer in dieser Rolle ist und versucht, Daten zu ändern, die diese Anforderungen erfüllen, sollte der Betrieb erlaubt sein, sonst nicht.“ Das klingt für mich wie eine Politik, und etwas, das entweder in der Business-Logik-Schicht eines separates Rules Engine von Art.

gehört

ich über etwas Ähnliches im Zusammenhang schrieb WCF vor einiger Zeit .

Answer 2

Von einer Umsetzung Sicht wäre es die beste Lösung, die Kontrollen so weit unten die Stapel wie möglich umzusetzen, da die niedrigste Anzahl von Funktionen ist, den Schutz benötigen, damit die niedrigste Zahl der Dinge in Unordnung zu bringen, und alle Benutzereingaben haben durch die geschützte Schicht passieren. Wenn Ihr Fundament geschützt ist, müssen Sie sich nicht um alles kümmern auf dieser Grundlage bauen.

Diese Lösung hat einen obviouse Nachteil - die Benutzeroberfläche weiß nichts über die Authentifizierung, Autorisierung, Datenüberprüfung, und all die anderen Sachen. So geht jeder Eingang den Stapel nach unten, kann einen Fehler verursachen, und wieder den Stapel nach oben geht, um den Benutzer zu informieren. Das wird eine unangenehme Benutzererfahrung führen, da Fehler, die leicht in der Benutzeroberfläche nur festgestellt werden konnten nach dem Passieren der Daten an den Backend-Systeme erfaßt werden. In der Folge finden Sie viele Kontrollen an den User-Interface hinzufügen, auch um eine bessere Benutzererfahrung zu geben.

Wenn Sie Schnittstelle basierte Programmierung verwenden, ist dies kein Problem, weil Sie den Bestätigungscode zwischen Anwendungsschichten teilen können. Dies ermöglicht es Ihnen weitere Bestätigungscode für alle Anwendungsschichten zu leicht hinzufügen und dies wird Ihnen Verteidigung in der Tiefe - ein Fehler in einer Anwendungsschicht kann durch eine andere Schicht gefangen werden. Natürlich, wenn der Bestätigungscode selbst fehlerhaft ist und Sie es Schichten accross Anwendung gemeinsam nutzen, um den Fehler und Fehler Hance wird wahrscheinlich durch alle Anwendungsschichten probagate.

Answer 3

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

die Rolle Prüfung auf Ihre Seite zu laden und Button-Klick Ereignisse Hinzufügen wäre Fremd, IMHO. Außerdem, wenn Sie die Seite schützen gehen, schützt die Seite mit den deklarativen Standort Richtlinien in Ihrem web.config mit ... z setzen alle Ihre „admin“ Seiten in einem separaten Ordner und schützen den gesamten Ordner, deklarativ.

Aber, sollen Sie immer die Kontrollen auf Ihren Business-Objekt-Methoden, als ein Minimum.

Answer 4

Sie müssen es auf der Methode Ebene setzen. Sie können nicht davon ausgehen, dass Sie diese Methode in einer bestimmten Art und Weise zu erreichen. Diese Methode kann durch die Button-Handler aufgerufen werden oder es kann in normalen Code als Ergebnis von jeder 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 ist es auf Page_Load setzen ist nicht genug. Sie sollten auch mit einem die Methode Dekoration überprüfen Principal . Das spart auf eine Menge von Code nach unten.

Answer 5

Dies ist nur ein anekdotischer Kommentar in, wie wichtig es Sicherheitsüberprüfung auf der Business-Seite zu tun sein kann. Es war nicht gut genug, um in unserem Fall über die niedrigen Erwartungen der Anfrage Hacking, optimistisch zu sein. Wir hatten keine Art von Prüfung in unserem Business-Objekten und wurde auf unerwartete Weise verbrannt. Ein Client baute ein Skript ihre Nutzung unserer Website zu automatisieren. Es endete folgende erwartete Links in ihrem Skript, das tatsächlich nicht erbracht wurde. Es endete die Beschädigung von Daten auf. Natürlich ist dies eher ein Systemstatus und Datenintegrität Problem ist für uns eher als eine Sicherheitsverletzung, aber ich nehme an beide wirklich gelten.

Answer 6

Handelsobjekte.

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

Edit:. Prägnante diese Art und Weise