Frage:
Der Benutzer kann aufgrund von Berechtigungen nicht über die Benutzeroberfläche zur Webseite navigieren, kann jedoch durch Einfügen der URL zur Seite navigieren. Wie schütze ich mich davor?
Michael
2017-10-10 21:33:32 UTC
view on stackexchange narkive permalink

In meiner Anwendung haben Benutzer bestimmte Rollen mit Berechtigungen. Diese Berechtigungen bestimmen, welche UI-Elemente ihnen auf dem Startbildschirm zur Verfügung stehen. Viele der Elemente verweisen auf andere Seiten, die viele Benutzer nicht sehen können, da sie aufgrund ihrer Berechtigungen nicht auf diese Webseite zugreifen können.

Beispielsweise wird eine Schaltfläche mit dem Namen button1 verlinkt Zu einer zufälligen Seite in der Anwendung sagen wir http://www.example.com/example.jsp . Für den Benutzer John sind jedoch Berechtigungen festgelegt, mit denen er button1 nicht sehen kann. Daher kann John nicht zu http://www.example.com/example.jsp gehen.

Das Problem, das ich habe, ist, dass ich als John angemeldet bin und Wenn ich diese URL einfüge, werde ich zur Seite weitergeleitet.

Dies ist natürlich ein großes Sicherheitsrisiko, wenn ein Angreifer beispielsweise die URL zu einer Administratorseite erhält. Wie kann ich mich dagegen schützen? Muss ich den Benutzer für jede einzelne Seite überprüfen, Berechtigungen überprüfen und sicherstellen, dass sie dort sein dürfen?

Diese Anwendung enthält Hunderte von Seiten, die sehr redundant und nicht effizient zu sein scheinen Code auf jeder Seite, um dies zu tun. Gibt es einen einfacheren Weg als die gerade erwähnte Methode?

Ich bin gespannt, ob dies das gleiche Problem ist wie "[Forced Browsing] (https://www.owasp.org/index.php/Forced_browsing)".Diese Seite beschreibt das Auffinden von Seiten, die niemals öffentlich sein sollten, anstatt Benutzerberechtigungsprüfungen zu umgehen.
@Michael Wenn für die Ausführung von Code auf jeder Seite tatsächlich jede Seite einzeln geändert werden muss, machen Sie wahrscheinlich auch andere Dinge falsch.Wenn Sie keine standortweiten Sicherheits- und Integritätsprüfungen vorgesehen haben, sollten Sie diese eher früher als später hinzufügen.Haben die Entwickler Sicherheitsschulungen?Hier gibt es überall rote Fahnen, und wenn Sie die Dinge reparieren, die Sie finden, bleiben die Dinge, die Sie nicht gefunden haben, unverändert.
Da es so aussieht, als ob Ihre Anwendung auf Servlets basiert, ist Spring Security einen Blick wert (Sie müssen Spring nicht verwenden, um sie zu verwenden, obwohl Spring fantastisch ist).
Ja, jede Seite und jede destruktive Aktion und jede Aktion, die private Daten verfügbar macht.Was Sie hier haben, wird als "Querschnittsthema" bezeichnet.
Berechtigungen sollten nicht nur durch Ausblenden von UI-Elementen erzwungen werden;), aber mit den Antworten denke ich, dass Sie das jetzt verstehen
Ich versuche immer, die URL nur zum Spaß zu ändern.Wenn es nur eine enable.php gibt, versuche ich zum Beispiel disable.php.
Wenn Sie derzeit Sicherheitsüberprüfungen auf Client-Ebene durchführen (dies ist hilfreich, um unnötige Abfragen an den Server zu vermeiden, aber in keiner Weise gesichert), können andere Sicherheitsprobleme auftreten, z. B. SQL-Injektionen.Stellen Sie sicher, dass Ihr Server alle Daten, die Ihr Client auf ihn wirft, ordnungsgemäß verarbeitet (und ja, wie bereits erwähnt, muss Ihr Server sicherstellen, dass der aktuell angemeldete Benutzer die aktuelle HTTP-Abfrage ausführen darf).
Ich habe die magischen Wörter in keiner Antwort gelesen.**Tun.Nicht.Vertrauen.Eingang.Je.**.
@usr-local-ΕΨΗΕΛΩΝ absolut, diese eine Regel gründlich angewendet bringt Sie einen langen Weg zu angemessener Sicherheit.
@danbru1211 Ich dachte, ich wäre versehentlich in eine Netzwerksache geraten, bis mir klar wurde, dass es sich nur um eine Demo des Produkts handelt, das das Unternehmen verkauft.Das Passwort "Sicherheit" war ein clientseitiger "md5" -Hash, und es ist völlig kaputt gegangen, wenn Sie etwas Ähnliches wie das beschriebene getan haben.Es ist jedoch eine großartige Möglichkeit, wirklich einfache Stifttests durchzuführen.
Ich habe ein GreaseMonkey-Skript, mit dem ich ** alle versteckten Elemente ** auf der Seite sehen kann, indem ich ** nur eine Taste ** drücke!Stellen Sie sich vor, was ich mit Ihrer Website machen kann, wenn ich mir tatsächlich die Mühe mache, den Quellcode zu lesen!
"* Das Problem, das ich habe, ist, dass wenn ich als John angemeldet bin *" - Warum können Sie sich überhaupt nach Belieben bei anderen Konten anmelden?
Die Implementierung der Schnittstelle "javax.servlet.Filter" ist genau das, was Sie wollen.Damit können Sie jede Anfrage bearbeiten.Übrigens ist jsp stark veraltet. Wenn es sich nicht um ein Universitätsprojekt handelt, sollten Sie Java EE strikt fallen lassen und mit moderneren Frameworks fortfahren, in denen all diese Grundbedürfnisse integriert sind.
Entschuldigung, aber Sie scheinen überhaupt kein Verständnis für die grundlegende Sicherheit von Webanwendungen zu haben.Sie sollten sich die [OWASP Top Ten] ansehen (https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project).
Es wundert mich, wie häufig diese Situation tatsächlich ist ...
Sieben antworten:
Trickycm
2017-10-10 21:43:34 UTC
view on stackexchange narkive permalink

Muss ich den Benutzer für jede einzelne Seite überprüfen?

Auf jeden Fall. Nicht nur jede Seite, sondern jede Anforderung an eine privilegierte Ressource, z. B. POST-Anforderung zum Aktualisieren, Löschen, Anzeigen usw. usw. Es geht nicht nur darum, die Seiten anzuzeigen, sondern zu steuern, wer was auf Ihrem System tun kann.

Es hört sich so an, als ob Ihr gesamtes Authentifizierungs- und Berechtigungssystem in seiner aktuellen Implementierung fehlerhaft ist. Die Schritte, um dies zu beheben, sind für diese eine Antwort zu weit gefasst. Es lohnt sich, dieses Forum und das gesamte Internet allgemein zu durchsuchen, um Lösungen zu finden, die für Ihr Framework geeignet sind (JSP, ASP.Net, PHP usw.). Die meisten Frameworks verfügen über sofort einsatzbereite Funktionen zur Lösung dieses Problems.

Ein guter Anfang wäre dieser hochrangige Leitfaden von OWASP: Betriebssicherheit: Administrative Schnittstellen.

Ich möchte nur wiederholen, weil Ihre Antwort in der OP-Phase keine Kleinigkeit ist: Ja, dies ist absolut die richtige und einzige Antwort.Jede einzelne Seite muss die Sicherheitsregeln ordnungsgemäß durchsetzen.Es hört sich so an, als ob derzeit nur clientseitige Sicherheit vorhanden ist, die eigentlich keine Sicherheit bietet.Es gibt Möglichkeiten, den Code so zu schreiben, dass Sie auf jeder Seite problemlos Sicherheit anwenden können. Es gibt jedoch keine Antwort, bei der nicht bei jeder einzelnen Anforderung die Sicherheit erzwungen werden muss.Ansonsten haben Sie keine Sicherheit.
Um ein bisschen genauer zu sein als Trickycm. Idealerweise müssen Sie eine einheitliche Lösung finden, um sowohl Navigationslinks / Schaltflächen / ... als auch direkte URL-Navigation zu handhaben.Da es einheitlich ist, haben Sie viel weniger Chancen, eine Sache zu vergessen.Wenn dies nicht der Fall ist, müssen Sie immer mindestens zwei verschiedene Deklarationen derselben Sicherheit behandeln (Hinweis: Ich habe diese derzeit und muss sie vereinheitlichen ,: 3).
Nur ein Hinweis: ** AJAX-Anfragen ** sind ebenfalls Anfragen und ** sollten überprüft werden **.Es spielt keine Rolle, dass diese bestimmte AJAX-Anforderung nur von einer Seite aus erfolgen sollte, die den Benutzer bereits überprüft hat.Ich weiß, dass dies in der Antwort unter "jede Anfrage" fällt.nur um sicherzustellen, dass OP das auch weiß.
Ein zusätzlicher Punkt: Diese Prüfung muss ** auf dem Server ** durchgeführt werden - nicht mit Javascript-Code, der auf dem Client ausgeführt wird (oder nicht).Ein böswilliger Benutzer kann das Ausführen des Javascript-Codes vermeiden.
Schließlich: Die Verwendung von Javascript zum Ausblenden von Links, auf die der Benutzer keinen Zugriff hat, ist in Ordnung - aber das ist eine Frage der Benutzeroberfläche, nicht der Sicherheit.
Es kann nützlich sein, den Begriff "Autorisierung" irgendwo in diesen Beitrag aufzunehmen, da dies auch ein gebräuchlicher Begriff für die Beschreibung der Berechtigungsprüfung / -verwaltung ist und daher bei der Suche hilfreich sein kann.
@MartinBonner Ich würde es vorziehen, die Links in PHP zu "verbergen" - könnte langsamer sein, aber wenn der HTML-Code für diese Links nie generiert wird, wäre der Client / Benutzer nicht klüger, selbst wenn er den Quellcode über einen Browser durchkämmtInspektor.
@psosuna Warum sollte es wichtig sein, wenn der Client / Benutzer die URLs finden könnte?Sie können nichts mit ihnen machen.Wenn sie versuchen, diese URLs zu verwenden, sagt der Server nur "Entschuldigung, Sie sind kein Administrator".
@immibis aus Gründen der Sauberkeit, wenn überhaupt.Es kann sein, dass es * die eine Seite * auf der Site gibt, die die Sicherheit nicht erzwingt (wie es sein sollte!) Und die Adresse dazu bei der Überprüfung der Quelle auf der Clientseite ermittelt werden kann.Um diese Möglichkeit abzuschwächen, ist es besser, sie nicht preiszugeben, oder?Besser sicher als leid, sage ich.
@psosuna: [Achselzucken] Es ist mir egal, wo Sie die Links verstecken.Der Punkt ist, dass es beim Verstecken der Links nicht wirklich um Sicherheit geht, sondern um eine gute UX.(Obwohl es ein Fall ist, in dem eine gute UX sicherlich nicht im Widerspruch zur Sicherheit steht.)
@MartinBonner stimmt Ihnen voll und ganz zu, aber im Allgemeinen geht es bei der Sicherheit um Ebenen.Und obwohl das Verstecken der Links natürlich keine Sicherheit ist, kann es helfen.Wenn irgendwo in der Sicherheitsüberprüfung ein Fehler auftritt, wird durch das Fehlen der Links immer noch etwas hinzugefügt. Daher ziehe ich es auch vor, die Daten überhaupt nicht an die Clients zu senden.(Ich sehe es als eine andere Schicht).
In jeder Hinsicht müssen alle Ressourcen / Anforderungen, die Ihr Server nicht direkt authentifiziert und autorisiert, als öffentlich betrachtet werden.Wenn Sie nicht überprüfen, ob die X-Anfrage von einem registrierten Benutzer mit den entsprechenden Berechtigungen stammt, ist die X-Anfrage öffentlich und kann von jedem aufgerufen werden, unabhängig davon, was Ihre Benutzeroberfläche bereitstellt.
Stilez
2017-10-11 22:42:57 UTC
view on stackexchange narkive permalink

Die schnelle Antwort lautet "Ja", wie Sie erfahren haben. Aber es muss nicht der große Job sein, an den Sie denken. (Die ganze Sicherheitssache mag groß sein, aber das ist nur ein Teil davon). Sie haben weitaus schwerwiegendere Probleme.

Warum es wichtig ist

ALLES, was Sie erstellen, wird von Versuchen getroffen, es zu brechen. Jemand wird neugierig sein. Jemand wird etwas tun, was Sie nie erwartet haben und das Ihrem Denken widerspricht. Jemand wird neugierig oder bösartig oder neugierig sein.

Sie sollten auch davon ausgehen, dass Ihre Software / Web-App von automatisierten Tools hart getestet wird. Server mit einem Online-Portal (fast jeder Art) werden von Hackern innerhalb von zehn Minuten nach dem ersten Online-Start entdeckt und auf eine von Tausenden möglichen Sicherheitslücken oder Versehen untersucht. Dies bedeutet, dass sie prüfen, was genau "hinter den Kulissen" läuft und welche erkennbaren Fehler ausgenutzt werden können (Datenvalidierung, Cross-Scripting-Validierung, SQL- oder Binärinjektion, JavaScript-Hacking, das Back-End selbst, was Schwachstellen können entstehen, wenn etwas zum Scheitern gezwungen wird, welche Daten offengelegt werden können ...).

Ihre Webserver werden auf diese Weise ständig von Hunderten, wenn nicht Tausenden von automatisierten Tools auf mögliche Webcode- und Back-End-Fehler überprüft. Das ist so gut wie Menschen und Benutzer, nicht stattdessen.

Möchten Sie lieber, dass dies weit entfernt ist und von Kritikern, Medien und wütenden Benutzern mit Nachdruck auf Sie aufmerksam gemacht wird oder zu einer Haftung führt? Oder möchten Sie es lieber beheben?

Wie man es löst

In gewisser Hinsicht ist es keine große Aufgabe. Sie erstellen ein Sicherheitsframework und jede Seite importiert oder verwendet es. Die Konzepte dazu sind nicht schwer und gut dokumentiert. Die Anzahl der Seiten ist also keine große Sache.

Der schwierige Teil des Jobs ist, dass die Sicherheit schwer ist. Ihr eigentliches Problem ist, dass Sie aufgrund der Tatsache, dass diese Probleme vorhanden sind und Sie diese Fragen stellen, nicht genug wissen, um die Hoffnung zu haben, dies ohne Hilfe zu tun. Ernsthaft. Du. Machen. Nicht.

Ich weiß nicht, welche Teamgröße Sie haben oder welche Ressourcen Sie haben. Sie brauchen es - und Sie haben wahrscheinlich keine Hoffnung, es ohne fremde Hilfe zu tun.

Mein echtes Anliegen hier

Das heißt, mein echtes Anliegen ist nicht die Web-App . Es ist die Denkweise, die diese Frage nahe legt.

Stellen Sie sich vor, ich erwäge, Ihre App zu kaufen oder zu verwenden.

Es hilft oder beruhigt den Leser nicht, dass Sie Sicherheit anscheinend als eine betrachten Nachträglicher Gedanke, eine Unterbrechung Ihrer Arbeit oder Unannehmlichkeiten, die später behoben werden müssen (oder Sie verstehen es nicht genug, dass Sie es bisher so behandelt haben), und möglicherweise sind die Probleme Dinge, die wirklich grundlegend sind, wie das ordnungsgemäße Codieren einer Schaltflächen-URL .

Sicherheit ist Ihre Arbeit, denn so technisch wunderbar das Produkt / die Dienstleistung auch ist und wer auch immer seine Benutzer sind, Ihr echtes Produkt ist Vertrauen und Sicherheit dafür Sie werden auf meine Bedürfnisse eingehen und mir keine größere Katastrophe verursachen.

Ich soll Ihrer App meine Daten anvertrauen? Im Moment, und es tut mir leid, das zu sagen, denke ich, ich könnte es genauso gut selbst auf Google+ veröffentlichen. Ja, es ist eine "so schlimme" Situation und ein Eindruck, und nein, dies übertreibt die Wirkung nicht.

Es tut mir leid.

Nun, Wenn Ihre App gut ist, binden Sie eine andere Person ein.

Der letzte Teil davon scheint darauf hinzudeuten, dass sich Kunden auf der Grundlage der Sicherheit für Produkte entscheiden.Außer in einigen sehr, sehr spezifischen Nischen ist dies einfach nicht wahr und aus Sicht eines Unternehmens-PoV ist es eine schreckliche Idee, nicht mehr als den bloßen Betrag für nicht funktionale Anforderungen wie Sicherheit als Startup auszugeben.Ja, jeder hier hasst diese Einstellung, aber die einfache Tatsache bleibt, dass Benutzer sich nicht um Sicherheit kümmern und selbst wenn sie dies tun, nicht beurteilen können, was sicher ist und was nicht (glauben Sie das nicht?Benutzernummern von TextSecure / Signal mit WhatsApp)
Du denkst an vorne.Nicht anfangs, nein.Aber sobald ein großes Problem bekannt wird - ja.Sobald es Bewertungen trifft - ja.Sobald in den sozialen Medien Kommentare wie "Was ist passiert und wie könnte es passieren?" Von mehr als einer oder zwei Personen eingehen - ja.Die Leute suchen nicht aktiv nach Sicherheit, aber sie schauen sich Bewertungen und öffentliches Wissen an, wenn es da draußen ist, und es wird nach einer Weile sein.(Ich bin damit einverstanden, dass es schöner wäre, wenn sie zuerst nachsehen würden, aber wenn es ein großes Problem ist, wie das OP anzeigt, wird es ziemlich schnell sichtbar - genau dann, wenn etwas schief geht und jemand wütend darüber schreibt)
Silencer310
2017-10-11 02:46:02 UTC
view on stackexchange narkive permalink

Sie müssen die Benutzerberechtigungsstufe für jede Anforderung (GET, POST, PUT, DELETE) überprüfen. Das Durchsuchen einer Seite, wie in Ihrem Fall, ist eine GET-Anfrage. Ein Benutzer sollte nicht in der Lage sein, eine Anfrage auch ohne Erlaubnis zu stellen.

Ob Sie nun den Code auf jeder Seite Ihrer Anwendung hinzufügen müssen, hängt von Ihrem Anwendungsframework ab. In einigen Frameworks (Laravel, Express.JS) können Sie beispielsweise Routen gruppieren und auf jede Anforderung für diese Route einen Filter anwenden. Hier setzen Sie die Überprüfungen ein. Für Anwendungen in einfachem PHP müssten Sie den Code auf jeder Seite haben. Sie können die Anweisung "include" verwenden, um die Wiederholung des gesamten Blocks Ihres Codes zu minimieren.

HEAD oder andere [seltsame HTTP-Methoden] (https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods) ebenfalls (es sei denn, Sie blockieren diese natürlich * immer *).
psosuna
2017-10-11 04:11:22 UTC
view on stackexchange narkive permalink

Es wurde bereits gesagt, aber ja, Sie sollten Ihre Benutzeranmeldeinformationen auf jeder Seite überprüfen. Wenn Ihre Site beispielsweise PHP verwendet, ist es am einfachsten, den angemeldeten Benutzer und seine Berechtigungsstufe in Sitzungsvariablen zu speichern und diese Sitzungsvariablen zu Beginn des Codes zu überprüfen. Diese werden beim Abmelden (wenn Sie eine Abmeldelogik zum Löschen dieser Variablen erstellt haben) oder beim Sitzungszeitlimit (die Zeit für das Timeout kann definiert werden, aber ich denke, der Standardwert beträgt 5 Minuten Inaktivität) gelöscht, sodass ein nicht autorisierter Benutzer nicht darauf zugreifen kann eine Seite. Andere Technologien werden eine ähnliche Handhabung haben.

Ich möchte wirklich nicht herablassend klingen, wenn ich das sage, also hoffe ich, dass Sie es nicht in diesem Licht sehen, aber dies ist eine Art Brot-und-Butter-Information . Wenn Sie dies in Ihrem Selbststudium irgendwie nicht gelernt haben oder nicht darauf gestoßen sind, empfehle ich Ihnen dringend, dies zur Kenntnis zu nehmen und etwas ausführlicher über dieses spezielle Thema zu lesen, da es sehr wichtig ist. Sie werden dies immer wieder für eine ähnliche Anwendung dieser Art tun.

Beachten Sie, dass es verschiedene Möglichkeiten gibt, dies auf einfache und effiziente Weise zu tun. Ein persönlicher Vorschlag von mir an Sie wäre, das Codieren in Ihrer eigenen Logik zu üben, damit Sie vollständig verstehen, wie es funktioniert funktioniert, bevor Sie versuchen, ein Framework zu verwenden. Testen Sie es anhand verschiedener Zugriffsmethoden. Wenn Sie zufrieden sind, können Sie untersuchen, wie die verschiedenen Frameworks die Behandlung von Benutzersitzungen durchführen.

BEARBEITEN : Ich habe dies unten in einem Kommentar angegeben, aber dies ist auch eine gute Ressource für OP: https://www.w3schools.com/ php / php_sessions.asp

Welche Sicherheitsgarantien bietet PHP für diese Sitzungsvariablen?Sind sie auf dem Client-Computer gespeichert?Wenn nicht, wie identifiziert ein Client seine Sitzung?Sind die clientseitigen Daten verschlüsselt?Gibt es Schutzmaßnahmen gegen die Weitergabe der clientseitigen Daten?
Hier ist eine schnelle und einfache Erklärung der PHP-Sitzungen: https://www.w3schools.com/php/php_sessions.asp.Informationen und Sitzungsvariablen werden nicht clientseitig, sondern nur serverseitig gespeichert.Der Server stellt dem Client einen Schlüssel zur Verfügung.Der Schlüssel wird verwendet, um die Sitzung zu identifizieren, in der sich der Benutzer gerade befindet.
@jpmc26 eine zusätzliche Seite: PHP = Hypertext * Pre- * Prozessor.Dies bedeutet, dass PHP-Code serverseitig ausgeführt wird.Es wird vor dem HTML-Code ausgeführt, sodass viele Dinge nicht an den Computer des Benutzers übertragen werden müssen.Aus diesem Grund ist PHP eine gute Option für die Authentifizierung, da die Eingabedaten überprüft werden können, bevor eine Antwort an den Client zurückgesendet wird.
Oh, ich bin ziemlich vertraut damit, dass PHP eine serverseitige Technologie ist.(Ich arbeite beruflich an Web-Apps, nur nicht an PHP .;)) Aber ich weiß, dass * etwas * clientseitig gespeichert werden muss, damit die Benutzersitzung identifiziert werden kann.Daher meine Fragen, ob diese Daten verschlüsselt sind und was Sie haben (um Sitzungsentführungen zu verhindern oder den Schlüssel absichtlich an einen anderen Benutzer weiterzugeben).Siehe zum Beispiel [diese Kritik] (https://security.stackexchange.com/a/18898/46979).Ich weiß nicht, ob sich etwas davon in den letzten 5 Jahren geändert hat.
@jpmc26 Ich denke, dass Kritik schlecht ausgerichtet ist: Es geht darum, dass gemeinsam genutzte Server schlecht konfiguriert sind, damit Benutzer auf die Daten des anderen zugreifen können.Anstelle der Verschlüsselung besteht die Antwort darin, die Sitzungen in einem Verzeichnis abzulegen, auf das andere Benutzer nicht zugreifen können.Wenn es kein solches Verzeichnis gibt, können sie trotzdem auf Ihren Entschlüsselungsschlüssel zugreifen.Es hat auch nichts mit Sitzungsentführung zu tun, die im Allgemeinen einen Angreifer beschreibt, der die Sitzungskennung * auf der Clientseite * stiehlt.Verschlüsselung würde auch dort nicht helfen.
@jpmc26 Aus Angst, zu weit vom Thema abzukommen, schützen Sie Sitzungen mit CSRF-Token.Jede Aktion, die Sie ausführen, aktualisiert das Token (daher fordere ich etwas mit meinem Token an => Server sendet ein neues Token zurück, das für die nächste Sache verwendet werden soll).
Majid Khan
2017-10-10 22:11:12 UTC
view on stackexchange narkive permalink

Der Benutzer darf nicht zur Seite navigieren können, unabhängig davon, ob er die Adresse eingibt oder auf den Link klickt.

Eine generische Lösung für Ihr Problem ist die Verwendung einer rollenbasierten Zugriffssteuerung ( RBAC) Ansatz. Erstellen Sie verschiedene Gruppen und weisen Sie der entsprechenden Gruppe Benutzer mit gleichen Berechtigungen zu. Gruppieren Sie Webseiten und andere Ressourcen in verschiedenen Ordnern. jeweils im Besitz einer bestimmten Gruppe. Ich hatte chgrp (Änderungsgruppe) verwendet, um dies auf einem System zu erreichen, auf dem Embedded Linux mit einem leichten Webserver ausgeführt wird. Dasselbe kann im Apache-Webserver erreicht werden, indem eine .htaccess-Datei abgelegt und der Zugriff verweigert wird, wie unter Stapelüberlauf angegeben.

Für die UI-Elemente müssen Sie verschiedene Seiten erstellen (oder Elemente durch Gruppenprüfung ausblenden). Sie müssen den Benutzer identifizieren (ihn anmelden und die entsprechende Gruppe bestimmen) und dann Webseiten gemäß den Berechtigungen des Benutzers anzeigen.

Jester
2017-10-11 02:25:04 UTC
view on stackexchange narkive permalink

Nur ein kurzer Vorschlag zur Implementierung, da Sie Bedenken hinsichtlich von Hunderten von Seiten hatten. In ASP.NET MVC können Sie beispielsweise einen globalen Filter oder eine "Basisseite" erstellen, von der alle anderen erben können.

Anschließend kann der zentral angeordnete Code den Benutzerkontext / die Benutzersitzung überprüfen und vergleichen Sie es mit einer Liste von Rechten / Berechtigungen / oder Gruppenmitgliedschaften für die aktuelle Seite (möglicherweise eine Datenstruktur auf jeder Seite oder eine Datenbanksuche basierend auf dem Seitennamen usw.).

Readin
2017-10-14 07:44:13 UTC
view on stackexchange narkive permalink

Andere Antworten waren sehr allgemein, daher füge ich dies hinzu, da JSP -Seiten erwähnt wurden. Ich kann also davon ausgehen, dass Sie in Java arbeiten.

Als solche können Sie höchstwahrscheinlich Filter verwenden, um Code jedes Mal ausführen zu lassen, wenn eine Anforderung an die Anwendung gestellt wird. Wenn Sie ein Sicherheitsframework wie Spring verwenden, können Sie URLs konfigurieren, auf die zugegriffen werden kann und von wem.



ⓘ
Diese Fragen und Antworten wurden automatisch aus der englischen Sprache übersetzt.Der ursprüngliche Inhalt ist auf stackexchange verfügbar. Wir danken ihm für die cc by-sa 3.0-Lizenz, unter der er vertrieben wird.
Loading...