Wie sicher ist das "Visible" an Objekten

[tommie-lie]

Zitat von bundy:

User drückt knopf und Server überprüft ob er auch die Berechtigungen besitzt...

Jein.
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 Ü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).

[bundy]

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.

[Tubos]

Zitat:

Sollte der User es schaffen den Knopf sichbar zu machen, besitzt er nicht das recht die Datenbankabrage durchzuführen.

Genau. So ist es sicher.

[mschaefer]

Zitat von tommie-lie:

tja, Pech gehabt Über derartige Probleme sollte man sich immer vorher Gedanken machen.

Theorie schlägt zu. Letzlich ist man bei Softwarentwicklung üblicherweise mit wachsenden Systemen am Arbeiten. Und da ist man Pleite, wenn alles vorher durchgeplant werden soll.

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

[Karstadt]

Zitat:

Nein.
Du möchtest dir EDA anschauen.

Wie kann ich den damit die nicht sichbare Objekte erkenne? Button1.visible False und nun?

[Elvis]

Zitat von mschaefer:

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...

Manche schießen auch gerne auf schnieke AppServer, weil sie fürchten, mit Browsern arbeiten zu müssen.
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.

[bundy]

Ich arbeite mit einem RO Server und einem Client.

[tommie-lie]

Zitat von bundy:

Ich habe alle SQL Scripts in die Middelware ausgelagert.

Sehr vorrausschauend!

Zitat von Bundy:

Und da liegt jetzt wohl der Hund begraben, weil ja machen sachen nicht wirklich Datenbankabhäng sind.

Und? Lass diese Sachen auch von der Middleware berechnen und genauso wie alle anderen Daten auch als Datenpaket an den Client schicken. Wie gesagt, der Client sollte mit der sicherheitsabhängigen Logik nichts zu tun haben. Der Client sagt der Middleware "Gib mir Report, now!!!11", die Middleware schaut nach, ob der das überhaupt darf, sagt dann "Nö, iss nich", und der Client gibt eine passende Fehlermeldung aus, daß die Privilegierungsstufe nicht ausreicht. Wenn deine Datenschnittstelle zwischen Client und Middleware richtig designed wurde, ist es für den Client unerheblich, ob die Daten von der Middleware irgendwie erfasst wurden, oder ob die Middleware die Daen aus der Datenbank gepult hat. Der Client kriegt Daten und zeigt sie an, oder er kriegt keine und teilt dem Benutzer mit, daß er das nicht darf.

Zitat von Bundy:

Sollte der User es schaffen den Knopf sichbar zu machen, besitzt er nicht das recht die Datenbankabrage durchzuführen.

Das wäre die Konsequenz davon, ja.


Aber, ähh... Wieso ist die Middleware zwar auf dem Server, die Firewall aber erst *hinter* der Middleware?

Zitat von mschaefer:

Letzlich ist man bei Softwarentwicklung üblicherweise mit wachsenden Systemen am Arbeiten. Und da ist man Pleite, wenn alles vorher durchgeplant werden soll.

Wenn ich weiß, daß ich eine Datenverwaltung für einen größeren Datenbestand machen soll, bei dem ich mehrere Benutzer habe, die unterschiedliche Privilegien haben und ich sichergehen muss, daß niemand an Daten herankommt, an die er nicht herankommen darf, programmiere ich nicht einfach munter drauf los, sondern überlege mir *vorher* wie ich das bewerkstelligen kann. Gegen wachsende Systeme habe ich überhaupt nichts gesagt, aber hier liegen die Anforderungen bereits vor.

Zitat von mschaefer:

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.

Das habe ich nicht übersehen und ich habe Webservice nicht auf ASP.NET beschränkt, sondern darauf hingewiesen, daß es auch andere Möglichkeiten gibt. XForms zum Beispiel. Oder das, was hier bereits halbfertig ist, ein schnöder Thin Client mit passendem Application Server dazu. Alles legitime Webservices, solange der eigentliche Service nicht beim Client liegt. Ich habe nicht den vorbesetzten Begriff für Webservice gemeint, als etwas, das mit einem Browser kommuniziert, weil das nur eine Möglichkeit von vielen ist. Browser muss nicht sein (und wäre hier der Usability wohl wenig dienlich).

Zitat von Karstadt:

Wie kann ich den damit die nicht sichbare Objekte erkenne? Button1.visible False und nun?

Mit EDA kannst du die von der VCL gar nicht erkennen, aber EDA zeigt, wie man's macht und somit bundy, daß ein solches Vorgehen nicht sicher sein kann. Schon mit EnumerateWindows() lassen sich nette Sachen machen, wenn man einfach nur abfragt, ob das Fenster sichtbar ist, oder nicht und plötzlich neugierig wird, wenn man auf ein unsichtbares Fenster stößt. Labels und alles andere ohne Handle sind das einzige, was vor einer solchen Attacke sicher ist, es sei denn man hat Lust irgendwelche Message-Handler von allerhand Fenstern zu überschreiben und zu reimplementieren. Dazu lohnt aber der Aufwand schlichtweg nicht, die Gründe dafür finden sich in diesem Fred.

[bundy]

ok dann bedanke ich mich mal für die ganze Info die ich bekommen habe, und versuche einiges davon in die Tat umzusetzten.