Wie sicher ist das "Visible" an Objekten
Hallo Leute ich mal wieder.
Ich würde mal eure meinung dazu höhren. Ich progge gerade ein grossen Kundenverwaltungssystem für einen Kabelnetzprovider. Benutzer können sich mit Benutznamen und Passwort anmelden. Je nach Berechtigungsstufe (Werte aus DB) blende ich Knöpfe aus oder schränke Suchcriterien ein. Meine Frage: Ist das Sicherheitstechnisch vertretbar die Visible Option zu nutzen? oder sollte ich die Objekte freigeben (button1.free). lg Bundy |
Re: Wie sicher ist das "Visible" an Objekten
Ziemlich unsicher, die kann man ganz einfach wieder sichtbar machen, genauso das aktivieren. Aber ich würde die Sicherheit nicht von der GUI abhängig machen, sondern eine Schicht tiefer gehen und zu mindest die Berechtigungen noch abfragen, bevor irgend etwas ausgeführt wird, am besten sogar auf DB Ebene.
|
Re: Wie sicher ist das "Visible" an Objekten
Zitat:
Du möchtest dir EDA anschauen. |
Re: Wie sicher ist das "Visible" an Objekten
Eine ungeschützte Exe kann in ihren Objekteigenschaften manipuliert werden. Das ist damit nicht sicher.
Du könntest eine Buttonklasse ableiten, die im Create seinen Status abfragt und das Create abbrichtt. Oder ein Programm zur Verschlüsselung der Exe-Datei nehmen (ICE-Lock). Das spart letzlich mit neuen Objekten zu arbeiten. Grüße // Martin |
Re: Wie sicher ist das "Visible" an Objekten
Zitat:
Außerdem sagtest du schon, daß eine Echse nicht sicher ist, den Konstruktor eines Buttons könnte ich auch patchen, wenn ich ihn erstmal gefunden habe, das macht es mir als Hacker also nur schwieriger, ist aber eigentlich immer noch ein Witz. Sicher kriegt man das nur, wenn man selbst der einzige ist, der die Kontrolle über Funktionalität hat. Das schreit also schon fast nach einem Webservice, muss ja nicht mit HTML-Frontend (ASP(.NET)), andere Mütter haben ja auch nette Thin Clients. Dann ist es zumindet *ziemlich* sicher. Kommt nur drauf an, wie sicher es sein muss, damit es den Aufwand rechtfertigt, um die gewünschte Sicherheit zu erreichen. Da das Ganze anscheinend eh über's Netz läuft, sollte man auf jeden Fall ein Acknowledgment für jedes Kommando machen. Entweder, der Server bestätigt, dann ist alles in Ordnung, oder er lehnt ab, idealerweise mit Fehlercode, dann hatte man nicht genügend Rechte und der Client meldet sich beim Benutzer zu Wort, zum Beispiel mit wüsten Beschimpfungen. Bei Sicherheitssystemen ist es immer unklug, Sicherheitsprüfungen in Komponenten zu verlagern, über die du keine Kontrolle hast. Delikate Dinge im Client sind also tabu, denn der Server ist das einzige, über das du Kontrolle hast. |
Re: Wie sicher ist das "Visible" an Objekten
Wie könnte ich das bewerkstelligen ?
User drückt knopf und Server überprüft ob er auch die Berechtigungen besitzt... hab ich das so richtig verstanden ? oder bin ich komplett auf dem Holzweg. |
Re: Wie sicher ist das "Visible" an Objekten
Zitat:
|
Re: Wie sicher ist das "Visible" an Objekten
Und die if-Abfrage kan ich ich umgehen. Meiner Meinung nach, müsste das alles schon auf dem Server passieren. Dort müssen für den Datenbankzugriff unterschiedliche Benutzer mit entsprechenden Rechten eingerichtet sein.
|
Re: Wie sicher ist das "Visible" an Objekten
Ich hab einen Table der Sicherheitsstufe heisst.
Jeder Benutzer hat eine zugeteilte Sicherheitsstufe. Beim Loggin ruft er zum Benutzer die dazugehörige Sicherheitsstufe auf. Im Table Sicherheitsstufe, hab ich z.B ID Object Enabled Visible .... ------------------------------------------ 1 Button1 true true 2 Button2 false true 3 Button3 .... .. ...... ___________________________________________ Nachdem der Userer erfolgreich eingeloggt ist setzt er die Werte von der DB auf die Objekte. |
Re: Wie sicher ist das "Visible" an Objekten
Warum verwendest du nicht das eingebaute Sicherheitssystem des DBMS?
In dieser Variante hast du ja schon wieder Buttons, die clientseitig aktiviert/deaktiviert werden. |
Re: Wie sicher ist das "Visible" an Objekten
Zitat:
Der Client setzt die Anfrage zusammen, die der Server auswerten soll. Die schickt er einfach ab und der Server antwortet. Der Server ist also derjenige, der die eigentliche Aktion ausführt. Es wird nicht überprüft, ob der Benutzer den Knopf drücken darf, sondern ob er diese Aktion durchführen kann. Das Durchführen der Aktion findet ausschließlich auf dem Server statt, niemals im Client. Was du aus reinem Komfort dennoch tun kannst, ist beim Einloggen die Benutzerrechte abzufragen und entsprechend alle Grafikcontrols unsichtbar zu machen, für die er eh keine Rechte hat. Mehr Energie sollte man nicht in den Client stecken (z.B. die Controls tatsächlich freigeben). Sollte ein Anwender den Client unter seine Kontrolle bringen und die versteckten Elemente anzeigen, bringt ihm das auch nichts, der Server verhindert ja immer noch das Ausführen der Aktion. Das Verstecken der Buttons ist also nichts anderes als Usability, damit de Anwender nichts sieht, was ihn eh nicht interessiert. Dieses Prinzip funktioniert hier wunderbar, da ja wohl alle Einstellungen sich irgendwie in der zentralen Datenbank auf dem Server niederschlagen, also muss der Client nichts können, er muss nichtmal wissen, was er da überhaupt macht, er schickt einfach nur Befehle an den Server. Der Nachteil an der Sache ist halt, daß der Server entsprechend leistungsfähig sein muss, um auf bei mehreren konkurrierenden Zugriffen nicht zusammenzubrechen. Je nachdem, was gemacht werden muss und wieviele Leute gleichzeitig zugreifen werden, kann das gegenüber einem reinen Datenbankserver schon ein deutliches Problem werden. Allerdings lässt sich mit entsprechender Netzwerkstruktur auch das in den Griff kriegen, zum Beispiel durch einen Cluster oder einem getrennten Application-Server, der auf einen von außen nicht zugänglichen Datenbankserver zugreift. Derartige Systeme sollten durch einfaches reinschieben eines zusätzlichen Servers relativ gut skalieren, ein ebenso skalierendes DBMS vorausgesetzt (sonst wird die Datenbank zum Flaschenhals, dann bringen auch riesige Farmen von Application Servern nix, wenn die ihre Daten zwar blitzschnell verarbeiten können, aber nicht schnell genug in die Datenbank gespeichert kriegen). Edit: Solltest du jetzt bereits einen Fat Client fast fertig haben, tja, Pech gehabt :mrgreen: Über derartige Probleme sollte man sich immer vorher Gedanken machen. Aber den Code solltest du mit wenigen Veränderungen für den Server wederverwenden können, es sei denn du kannst auf dem Server kein Delphi einsetzen (z.B. weil dieser unter Linux läuft). |
Re: Wie sicher ist das "Visible" an Objekten
Ich Arbeite mit RemObject & DataAbstract
Aufbau: ***********************| Serverseite....................................... ..| Client-----------------Middelware--------|Firewall|-------------PostgreSQL DB Ich habe alle SQL Scripts in die Middelware ausgelagert. Ich übertrage nur mehr die Parameter für die SQL Scripts. Ich möchte ein Programm, das sich anhand des eingeloggten user anpasst. z.b Report oder gewisse Funktionen dürfen nur User mit dem SIcherheitsstatus 1 machen. usw..... Und da liegt jetzt wohl der Hund begraben, weil ja machen sachen nicht wirklich Datenbankabhäng sind. oder meint Ihr Sollte der User es schaffen den Knopf sichbar zu machen, besitzt er nicht das recht die Datenbankabrage durchzuführen. |
Re: Wie sicher ist das "Visible" an Objekten
Zitat:
|
Re: Wie sicher ist das "Visible" an Objekten
Zitat:
Es wird immer gern gleich mit Webservices geschossen, aber das die VCL wesentlich komfotablere Programme zuläßt als eine rein browserorientierte Anwendung, dies wied oft übersehen. Die Nutzer wissen aber schon sehr wohl warum sie keine Browser zur Textverarbeitung nehmen... Das Grundproblem liegt wie schon angesprochen daran, dass der User mit niedriger Priorität eine Exe mit (wenn auch abgeschalteten) Funktionen höherer Prioritätsstufe versorgt wird. Wenn sowas in der Firma eingesetzt wird, dann kann man durch Installationsschutz auch das für eine gewisse Zeit vertretbar einsetzen. Später könnte man ein Einlogmenü bauen und je nach Nutzerstatus aus der Datenbank der Nutzerstufe entsprechende Programmodule auf den Nutzerrechnern speichern und starten. Beim Ausloggen würden diese Module wieder gelöscht. Das Einloggmodul würde nur starten, wenn diese Nutzermodule zunächst nicht vorhanden sind. Grüße // Martin |
Re: Wie sicher ist das "Visible" an Objekten
Zitat:
|
Re: Wie sicher ist das "Visible" an Objekten
Zitat:
tommies WebService ist in bundies Fall ein DataAbstract Service und sein Client ist eine piepnormale Echse, die dank dem DA Service einfach ohne jegliche Kenntnis von der genauen Datenquelle auskommt. Deshalb findet die Sicherheitsprüfung da statt wo man noch die Kontrolle hat: auf einem Server. @bundy Mit DA hast du zwangsläufig auch ein komplettes RO SDK laufen, vllt wäre es für dich einfacher noch einen RO Service zwischen DA und deinem Client zu klemmen. Wenn du den auch noch auf WSDL/SOAP statt ROSDL umstellst würdest du dich für künftige Wendungen auf der sicheren (standardisierten) Seite befinden. Das viele Gerede über RO/DA hat mich jetzt aber ganz schön hibbelig gemacht. Ich werde es wohl am WE mal wieder rauskramen. :) |
Re: Wie sicher ist das "Visible" an Objekten
Ich arbeite mit einem RO Server und einem Client.
|
Re: Wie sicher ist das "Visible" an Objekten
Zitat:
Zitat:
Zitat:
Aber, ähh... Wieso ist die Middleware zwar auf dem Server, die Firewall aber erst *hinter* der Middleware? Zitat:
Zitat:
Zitat:
|
Re: Wie sicher ist das "Visible" an Objekten
ok dann bedanke ich mich mal für die ganze Info die ich bekommen habe, und versuche einiges davon in die Tat umzusetzten. :thumb: :thumb:
|
Alle Zeitangaben in WEZ +1. Es ist jetzt 01:31 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz