Laden...

GUID als Parameter ausreichend sicher?

Erstellt von Quallo vor 16 Jahren Letzter Beitrag vor 16 Jahren 7.057 Views
Q
Quallo Themenstarter:in
992 Beiträge seit 2005
vor 16 Jahren
GUID als Parameter ausreichend sicher?

Hallo Jungs und Mädels!

Ich habe in einer Datenbank GUIDs als Primärschlüssel und benutze sie auch als Identität für meine Business Objekte.
Folgendes Szenario: Ein User X hat Datensätze und ein User Y hat Datensätze, alle Datensätze in einer Tabelle. User X darf nicht mit den Datensätzen von User Y in Berührung kommen, User Y nicht mit den Datensätzen von User X.

Nehmen wir an ich hätte jetzt sequentielle IDs statt GUIDs.
Folgende Methode, die einen Datensatz anzeigt und als link im geschützen Bereich von User X ist: http://www.mydom/myapp/viewdata.aspx?id=123 .
Nun könnte jeder "Hacker" auf die Idee kommen, wenn er statt einer 123 eine 124 eingibt, einen anderen Datensatz zu sehen. Deswegen muss ich applikationsseitig prüfen, ob der Datensatz 124 auch zu User X gehört. Dass dies viel Arbeit und Implementierungsaufwand ist, ist wohl klar, von der Performance mal zu schweigen...

Wie sieht es jetzt bei meiner Applikation aus, die ja GUIDs als Schlüssel benutzt.
Reicht es da aus zu sagen, dass die GUIDs zufällig gewählt und nicht vorhersehbar sind, um ein ausreichendes Maß an Sicherheit zu erhalten? Es sind ja 2128 Möglichkeiten, die vorhanden sind, also selbst bei ca. 1.000.000 Datensätzen noch ca. 2108 Versuche um eine GUID zu erraten. Es wäre auf jeden Fall stets weniger Aufwand, per Brute Force das Passwort eines Users herauszufinden.

Gibt es vieleicht bzgl. History im Browser oder temporärer Internetdateien noch etwas zu bedenken?

Falls ich doch etwas implementieren muss, da ein Benutzer zwar einen Datensatz sehen, ihn aber nicht löschen darf, was ist die einfachste Art so einen Mechanismus zu implementieren?

Gibt es was generisches(Best Practices, Patterns) oder muss man das je nach Business Case prüfen?

Grüße, Christoph

1.457 Beiträge seit 2004
vor 16 Jahren

Meiner Meinung nach könntest du entweder über Sessions arbeiten. Ich selber bevorzuge ein Sicherheitsmodell wechles solche Überprüfungen vornimmt.

A
138 Beiträge seit 2007
vor 16 Jahren

Hallo,
GUID wäre nur 'Security through obscurity' und eigentlich nur Suboptimal, ist ähnlich wie eine JS Passwortabfrage, die den User dann an seite_eingegebenesPasswort.html weiterleitet.

Weise den Usern doch eine User-ID zu (UID), sofern noch nicht vorhanden, und bei jedem Datensatz speicherst du noch die UID ab, also die vom Besitzer.
So viel aufwendiger ist dies auch nicht, die SQL Abfrage würe in etwa so aussehen:
SELECT * FROM table WHERE id = id_aus_url AND uid = uid_des_users;

Wenn alles in Ordnung ist, bekommst du 1 Datensatz zurück, oder eben keinen.

Wenn der User sich einlogt, legst du eine Session an, und speicherst darin die UID ab.

Falls ich doch etwas implementieren muss, da ein Benutzer zwar einen Datensatz sehen, ihn aber nicht löschen darf, was ist die einfachste Art so einen Mechanismus zu implementieren?

Hmm dies hängt stark davon ab, was du brauchst. Soll dieses für einzelne User gelten, oder doch für Gruppen (alle User der Gruppe A dürfen Datensätze der Gruppe B lesen?)

Sonst dieses über eine weitere Tabelle lösen, in der dann drin steht, was User A mit den den Datensätzen von User B anfangen darf, kann ca. so aussehen:
id, uidSource, uidDestination, rechte

Mit JOINs kannst du dann in einer Abfrage klären, ob nun User A wirklich den Datensatz 124 sehen darf.

PS: Mir ist zu uidSource & uidDestination nix besseres eingefallen.
Rechte kann dann aus Bit-Flags bestehen, so dass du Lesen, Schreiben, Löschen etc. in einer Zahl "abspeichern" kannst.

Q
Quallo Themenstarter:in
992 Beiträge seit 2005
vor 16 Jahren

Vielen Dank für eure Meinungen!

@burning_snow: Wie sollen mir Sessions in dem konkreten Fall helfen? Dass ich Sessions benutze steht wohl außer Frage.

@Andavos: Ich sehe das nicht als Security by Obscurity an um ehrlich zu sein.
Wenn wirklich nur der User diese GUID zu Gesicht bekommt, kann man sich die GUID wie ein Passwort pro Datensatz vorstellen. Die GUID ist wesentlich länger als ein normales Passwort und durch die Zufälligkeit auch schwerer zu erraten. Wie gesagt, bevor ich versuche die GUID eines Users per Brute Force zu attackieren, kann ich eher sein Passwort per Bruce Force knacken.

Wie gesagt, dass gilt alles nur, wenn lediglich der User, der das Recht auf einen Datensatz hat, die GUID auch sieht, sonst ist es hinfällig.

Natürlich sind die Rechte ein wenig komplizierter gelagert. Das Ganze geht eher über 15-20 Tabellen, teilweise relational bzw. ineinander hierarchisch verknüpft.
Da verlangt es schon ein wenig Power Datenbankseitig um zu jedem Datensatz über mehrere Tabellen zu prüfen, ob der Nutzer auf genau diesen Datensatz zugreifen darf.

Eine Extra Tabelle ist zwar eine nette Idee, aber das würde die Datenbank doch sehr aufblähen und ich müsste bei jedem eingefügten Datensatz einen weiteren Datensatz schreiben bzw. beim Löschen einen weiteren löschen.
Falls jemand mal so ein Modell implementieren muss, sollte er das bedenken. Und natürlich sollte man "rechte" dann nicht als Flag in der Datenbank speichern(es soll ja alles atomar sein), sondern als verschiedene Felder.

Gibt es nicht irgendwie einen anderen Ansatz?

Grüße, Christoph

1.457 Beiträge seit 2004
vor 16 Jahren

Der Unterschied zwischen Session und QueryStrings sind, dass Session Variablen nicht in der URL sichtbar sind.

Wie ich schon erwähnt habe wäre beides für mich keine Alternative. Ein entsprechendes Sicherheitsmodell sollte dir da auf jedenfall weiterhelfen.

Q
Quallo Themenstarter:in
992 Beiträge seit 2005
vor 16 Jahren

Also sollte ich jede GUID in der Session speichern und in die URL eine andere ID übergeben, beim Aufruf der URL dann Mappen?
Auch ein ganz schöner Aufwand, besonders bei Quersprüngen...

Problematisch wird es dann allerdings, wenn ich die zu Grunde liegenden Komponenten auch für Webserviceaufrufe nehmen will, die teilweise von Smart Clients mit Stammdaten stammen, die GUIDs wurden vorher in der Session also nicht übermittelt.

1.457 Beiträge seit 2004
vor 16 Jahren

Ich weiß nicht ob du verstanden hast was Sessions sind.

Woher stammen die GUIDs? Werden die nicht von einer Liste ausgewählt und der Benutzer wird dann zu einer "Detailsseite" weitergeleitet?

Dieses Video sollte dir bzgl. Sicherheit auch weiterhelfen (http://www.asp.net/learn/videos/view.aspx?tabid=63&id=45).

Q
Quallo Themenstarter:in
992 Beiträge seit 2005
vor 16 Jahren

Ich denke schon, dass ich weiß was Sessions sind.

Es geht darum, dass jedes Objekt in der Datenbank eine GUID hat. Wenn jetzt ein Benutzer der Webanwendung innerhalb seiner Session irgendeine Aktion macht, bezieht sich diese Aktion meist auf eben solche Objekte.
Beispiel: Er hat einen Buchungsdatensatz angelegt und will ihn wieder löschen.
Er muss irgendwie sagen, welchen(!) Buchungsdatendatz er löschen will. Dies geschieht dadurch, dass er eine Auswahlliste hat. Die Auswahlliste besteht aus sehr vielen Links, jeder steht für einen Datensatz und jeder Link hat als Parameter die GUID des Datensatzes.
Übertragen auf den Webservice, ruft der Webservice eine Funktion auf, die die GUID als Parameter hat.
Die GUID innerhalb des Links ist natürlich durch den Benutzer manipulierbar (so wie alle Daten die auf dem Client landen grundsätzlich manipulierbar sind).

Bei einer GUID ist die Manipulierbarkeit m. E. kein großes Problem, da er sie ruhig ändern kann. Die Anfrage trifft dann stumpf ins Leere, da er nicht die GUID eines anderen Datensatzes erraten kann. Dies ist bei sequentiellen IDs natürlich anders.
Meine Frage war, ob dies zutrifft.

Problematisch wird es erst, wenn er eine GUID eines Datensatzes kennt (weil er beispielsweise ein View darauf hat), diesen Datensatz aber nicht löschen darf. Er darf allerdings andere Datensätze löschen. Dann könnte er die GUID (als Parameter eines Links) eines Datensatzes den er löschen darf durch die GUID des Datensatzes ersetzen, den er nicht löschen darf. Dies muss ich sicherlich applikationsseitig abfangen.

Grob gesagt, geht es um die Manipulierbarkeit von Parameterdaten auf dem Client und ob es best practices gibt um das zu verhindern oder zu umgehen.

Grüße, Christoph

1.373 Beiträge seit 2004
vor 16 Jahren

Hallo,

Ich sehe das wie burning snow. Das Sicherheitsmodell gehört meines Erachtens in die Anwendung integriert und sollte nicht von der Erratbarkeit von URL abhängen. So wild ist das doch gar nicht. Ein Benutzer gehört einer oder mehrerer Rollen an. Je nach Rolle darf der Benutzer Daten sehen und/oder bearbeiten. Neben einer einfachen Zuordnung an Rollen kannst du bestimmte Aktionen auch detaillierte gestalten, etwa nach dem Motto: wenn der Benutzer zu Abteilung A gehört, darf er mit den Daten von Abteilung B dies und das anstellen.

Solche Regeln gehören zu den Business Rules und sollten als solche auch Teil der Programmierung sein. Wenn die Regeln kompliziert sind, dann sind sie das eben. Trotzdem darf man sich nicht scheuen, sie umzusetzen und anzuwenden. Alles andere ist über Kurz oder lang nur eine unbefriedigende Behelfslösung.

Grüße,
Andre

Q
Quallo Themenstarter:in
992 Beiträge seit 2005
vor 16 Jahren

@VizOne: Ich weiß nicht, ob Burning Snow das ebenso sieht.
Im Prinzip hast du natürlich völlig Recht! Ich weiß zwar nicht, ob ich diese Rules alle im Business Layer unterbingen kann, aber wenn man Rechteverwaltung teilweise auch mit in der Datenbank festmacht, sollte es keine grobe Verletzung der Schichtenarchitektur darstellen. Es muss nur klar sein, dass diese Rechteverwaltung bei Austausch des Datenbanklayers auch implementiert werden muss.
Ich bin noch am evaluieren, ob ich das alles im Business Layer unterbringen kann. Die Grundlegende Rechteverwaltung auf jeden Fall, auf Datensatzebene mal schauen.

Ich bitte jetzt noch einmal folgendes zu diskutieren:
Ich denke trotzdem, dass man gewisse Dinge nicht auf Datensatzebene absichern muss, beispielsweise wenn es um Daten geht, die nur angesehen werden können, bzw. bei denen jeder Benutzer seine eigenen Daten ändern darf.

Noch mal ein Beispiel: Es gab bei der Telekom (ohne Garantie auf Richtigkeit, habe es selbst nur im Web gelesen) mal einen Fall, in dem man Daten von anderen Kunden einsehen konnte.
Man musste nur eine ID in einem Link ändern (Beispiel: ViewVertragsdaten.aspx?Kundenid=175 in ...?Kundenid=176 ändern) und hatte dann die Daten von jemand anders.

Wenn ich in diesem Fall eine Guid einsetzte, ist es allerdings nicht möglich, die GUID eines anderen Kunden zu erraten. Die GUID ist 128 bit lang, also müsste ich selbst bei Millionen von Datensätzen 2x, wobei x größer als 100 ist, also beispielsweise 81129638414606681695789005144064 für 2106 Versuche starten, um eine GUID zu erraten. Selbst wenn es durch irgendein statistisches Phänomen (Geburtstagsparadoxon etc.) noch mal eine Million mal weniger wären, wäre es immer noch praktisch völlig unmöglich. Das wären bei 10 Versuchen pro Sekunde über 257.260.395.784.521.441.196.692 Jahre. Vorher geht das Universum noch zig mal unter. Da ist es doch einfacher das Passwort eines Benutzers zu knacken.

1.457 Beiträge seit 2004
vor 16 Jahren

Ich sehe es genauso 😉

So wie du es vorhast würde ich nicht machen. Was ist wenn derjenige aus Zufall doch "errät"?

In diesem Zusammenhang hättest du, wenn du es nicht als Business Rule abfängst ein großes Sicherheitsproblem. Egal ob man die Daten "nur" lesen kann oder auch ändern kann.

Ich würde auf jedenfall deine Business Rules im Business Layer unterbringen und nicht auf Datenbankebene. An zwei Stellen Regeln zu definieren führt nur zum Chaos.

Du musst immer vom schlimmsten ausgehen.

Q
Quallo Themenstarter:in
992 Beiträge seit 2005
vor 16 Jahren

Die Chance, dass jemand ein Passwort errät ist allerdings höher. Also ist das ein wesentlich besseres Angriffsziel...
Es geht ja um bewusste Manipulation. Und ich glaube nicht, dass sich da wer ran traut eine GUID zu erraten, wäre auch ziemlich blöd...

1.457 Beiträge seit 2004
vor 16 Jahren

Was möchtest du denn eigentlich nun bezwecken?

Ein User soll keine Daten von einem anderen User sehen? Richtig?

Wenn ja, kannst du ja soetwas wirklich super über die Authentifizierung lösen oder sehe ich irgendetwas falsch?

1.373 Beiträge seit 2004
vor 16 Jahren

Hallo,

Mit deinem Vorschlag versuchst du lediglich, die Wahrscheinlichkeit bestimmter Symptome (Datenzugang für unbefugte Nutzer) klein zu halten, statt dich um die Ursache zu kümmern (unsichere Anwendung). Was du vorhast ist keine Lösung, sondern ein Hack, der wahrscheinlich funktioniert.
*Was ist, wenn eine MS SQL Server Datenbank verwendet wird, bei der statt NEWID() NEWSEQUENTIALID() verwendet wird? *Was ist, wenn man statt Guid.NewGuid() Combs verwendet? *Was ist, wenn die IDs unter WinNT generiert werden, wo GUIDs nicht zufällig, sondern mit hoher Wahrscheinlichkeit sequentiell sind? *Was ist mit Browser-History? Die GUIDs stehen dort im Klartext drin. Mal eben nachsehen, was der Kollege macht... *Was ist mit Szenarien, die du und ich nicht kennen?

Ups. Vielen Dank. Bei sensiblen Daten möchte ich mich auf so ein "System" nicht verlassen. Obige Punkte enthalten übrigens einige Punkte, bei denen die Sicherheit deiner Anwendung tatsächlich von der Datenhaltungsschicht abhängen. Bei einer Prüfung innerhalb der Businessschicht ist das eben nicht der Fall. Dort wird ganz klar geguckt: wer will was machen? Was darf er?

Im Sinne deiner Kunden kann ich dich nur bitten, das Thema Sicherheit etwas tiefergehend zu betrachten als "Wird schon nichts passieren."

Grüße,
Andre

Q
Quallo Themenstarter:in
992 Beiträge seit 2005
vor 16 Jahren

Original von VizOne
Hallo,

Mit deinem Vorschlag versuchst du lediglich, die Wahrscheinlichkeit bestimmter Symptome (Datenzugang für unbefugte Nutzer) klein zu halten, statt dich um die Ursache zu kümmern (unsichere Anwendung). Was du vorhast ist keine Lösung, sondern ein Hack, der wahrscheinlich funktioniert.

siehe unten...

Was ist, wenn eine MS SQL Server Datenbank verwendet wird, bei der statt NEWID() NEWSEQUENTIALID() verwendet wird?

Was ist, wenn man statt Guid.NewGuid() Combs verwendet?

Was ist, wenn die IDs unter WinNT generiert werden, wo GUIDs nicht zufällig, sondern mit hoher Wahrscheinlichkeit sequentiell sind?Die GUIDs werden allesamt mit GUID.NewGuid() erzeugt. Dass das ganze von der sicheren Zufälligkeit der GUIDs abhängt ist mir klar, das sollte auch aus den Ursprungsposts herausgekommen sein...

Was ist mit Browser-History? Die GUIDs stehen dort im Klartext drin. Mal eben nachsehen, was der Kollege macht...Das ist übrigens der einzige Punkte, den ich auch, die Zufälligkeit der GUIDs vorausgesetzt, als Angriffspunkt sehe. Sonst ist es praktisch unmöglich so eine GUID zu erraten. Ich denke, dass wir da übereinstimmen, oder?
Werden die Daten, die innerhalb von SSL-Verbindungen zustande gekommen sind überhaupt in der Browser-History gespeichert?
Btw.: Bei Cookies ist es übrigens ebenso. Sobald man etwas auf dem Client speichert, in welcher Form auch immer, ist es unischer.

Was ist mit Szenarien, die du und ich nicht kennen?Wenn dann sollte es by Design "ausreichend" sicher sein, "ausreichend" per üblicher Definition (im Prinzip kann man mit genügend Zeit alles knacken, auch PPK).
[/list]

Ups. Vielen Dank. Bei sensiblen Daten möchte ich mich auf so ein "System" nicht verlassen. Obige Punkte enthalten übrigens einige Punkte, bei denen die Sicherheit deiner Anwendung tatsächlich von der Datenhaltungsschicht abhängen. Bei einer Prüfung innerhalb der Businessschicht ist das eben nicht der Fall. Dort wird ganz klar geguckt: wer will was machen? Was darf er?

Innerhalb der Datenschicht ist dies auch der Fall, nur technisch anders realisiert.
Das das im Idealfall besser in der Businessschicht aufgehoben ist, ist mir wohl klar.
Das sollte aber nicht Zentrum dieser Diskussion sein!

Im Sinne deiner Kunden kann ich dich nur bitten, das Thema Sicherheit etwas tiefergehend zu betrachten als "Wird schon nichts passieren."

Ähem, das finde ich dann doch ein wenig flapsig! Was meinst du, warum ich solche Ideen in einem Forum zur Diskussion stelle! Wahrscheinlich nicht, weil ich sie schon implementiert habe, sondern, weil sie eine Idee sind.

Grüße,
Andre

Bitte nicht gleich persönlich werden (zumindest habe ich es so aufgefasst), wenn man technische Ideen diskutiert.

Ebenso Grüße.

Q
Quallo Themenstarter:in
992 Beiträge seit 2005
vor 16 Jahren

Original von burning snow
Was möchtest du denn eigentlich nun bezwecken?

Ein User soll keine Daten von einem anderen User sehen? Richtig?

Wenn ja, kannst du ja soetwas wirklich super über die Authentifizierung lösen oder sehe ich irgendetwas falsch?

Die Frage ist nur, ob man an bestimmten Stellen das Berechtigungssystem auf Datensatzebene herunterziehen will, oder ob man davon ausgehen kann, dass es durch die Nichtkenntnis einer Identität(als GUID), die vom Server nur an authorisierte Benutzer herausgegeben wird, hineichend sicher ist.

Grüße, Christoph

1.373 Beiträge seit 2004
vor 16 Jahren

Hallo,

Natürlich ist das, was ich sage, persönlich gemeint. Sonst hätte ich dich nicht mit "Du" angesprochen, sondern über "jemanden, der so ein System implementieren will" 😉

Aber es war keinesfalls verletzend gemeint, falls du das meintest und so aufgefasst hast. Ich finde es gut und interessant, darüber zu diskutieren. Das ändert allerdings nichts an der Tatsache, dass ich denke, dass du die Sicherheit deiner Anwendung zu sehr auf die leichte Schulter nimmst, bzw. versuchst, die Unsicherheit deiner Anwendung an der falschen Stelle abzudichten.

Natürlich ist die Sicherheit einer Anwendung immer auch zu einem Teil eine Frage der Wahrscheinlichkeit (wie wahrscheinlich ist es, dass das Passwort eines Benutzers missbraucht wird usw.). Aber ich halte es in diesem Fall für völlig unnötig, einen zusätzlichen Unsicherheitsfaktor einzubringen und die Sicherheit möglicherweise vertraulicher Daten auf diese Weise aufs Spiel zu setzen.

Noch ein schönes Szenario: innerhalb eines Büros wird die Anwendung eingesetzt. Herr S. amüsiert sich gerade über die lustigen Fotos der Person, dessen Datensatz er gerade liest. Er schickt den Link an seine Kollegen, damit sie sich ebenso totlachen können. Im Besitz des Links können sich die Kollegen die vertraulichen Daten auf der Seite anschauen. Schon Interessant, was Herr Meyer (zufällig Nachbar einer der Mitarbeiter) wieder an Krediten aufgenommen hat...

Ich kann einfach nicht verstehen, dass du dich dagegen sträubst, die Sicherheit der Anwendung "ordentlich" als Teil der Anwendungslogik zu implementieren und dich stattdessen auf die Zufälligkeit eines Keys verlässt.

Grüße,
Andre

P.S.:

Die Frage ist nur, ob man an bestimmten Stellen das Berechtigungssystem auf Datensatzebene herunterziehen will

Das klingt so, als wenn das a) was außergewöhnliches und b) besonders schwer zu implementieren wäre. Beides ist nicht der Fall.

Q
Quallo Themenstarter:in
992 Beiträge seit 2005
vor 16 Jahren

Mit dem persönlich meinte ich persönlich verletzend, ist aber zurückgenommen, da es so von dir nicht gemeint war.

Ich sehe Sicherheit als sehr wichtig an, dass kannst du mir sehr wohl glauben! Sonst würde ich keine Diskussionen darüber führen und nicht (als normalerweise Nicht-Webprogrammierer) über Dinge wie Parameterfälschung nachdenken. Ich kenne übrigens einige Firmen bzw. Anwendungen, die dies gar nicht tun. Dass ich hier nicht herauspuste wer das sind, ist wohl klar (wir sind es nicht(!!!)).

Ich habe mich übrigens nicht dagegen gesträubt, zumindest nicht mehr als ihr diesen Vorschlag anzuerkennen. Es wäre doch sicherlich schön, für soetwas wie parameterfälschung / -veränderung eine generische, sichere Lösung zu haben, das war mein Gedankengang.

Ich habe übrigens im Bereich der Webservices, wo ja auch alles fälschbar ist, bereits Lösungen implementiert, wo ich die Sicherheit auf die Satzebene gebracht habe. Ist nur sehr viel Aufwand, eine generische Lödung wäre da schön!

Hoffe, dass du diesen versöhnlichen Worten zustimmen kannst.

Grüße, Christoph

1.373 Beiträge seit 2004
vor 16 Jahren

Ich glaube dir natürlich, dass dir die Sicherheit wichtig ist, sonst würdest du dir sicher nicht so viele Gedanken machen. Mit "auf die leichte Schulter nehmen" meinte ich eher, dass du auf der Suche nach einer leichten Lösung vielleicht nicht ganz bis zu Ende gedacht hast.

Mir ging es auch weniger darum, die Möglichkeit der Parameterfälschung zu beurteilen, sondern vielmehr darum, ein Bewusstsein zu schaffen, Sicherheit zu einem First-Class-Member der Programmlogik zu machen. Eben wirklich Sicherheit by Design und nicht "by Zufall der Datenkeys" 😉

Zudem ließe sich eine flexible, wiederverwendbare Lösung sicherlich programmieren. Wenn man Businessrules im Code forciert und Sicherheit zu einer Businessrule erhebt, lässt sie sich relativ problemlos in die Anwendung integrieren. Man kann das aber auch trennen und dann eine recht einfaches API à la bool MayPerform(User user, Action action) verwenden, welches intern die Rollen des Nutzers und z.B. den Zustand der Anwendung überprüft und daraus Rückschlüsse über die Zulässigkeit bestimmter Aktionen zieht.

Viel Erfolg auf jeden Fall weiterhin!

Viele Grüße,
Andre

1.457 Beiträge seit 2004
vor 16 Jahren

Ich für meinen Teil bin für Sicherheit und nicht für generische Lösungen. Es wird bei einer Sicherheitsschicht nie eine generische Lösung wie du das haben möchtest geben.

Und unter anderem sollte das Argument "die und die Firma machen es auch nicht" auf jedenfall nicht gelten. Das Argument kannst du beim Kunden auf gar keinen Fall verwenden und hebst dich dann auch nicht von der Konkurrenz ab.

Dein Problem die Parameterverfälschung entsprechend zu umgehen, kannst du auch so durchführen dass du keine Parameter in der URL übergibst sondern nur über Sessions. Das wäre zur den Business Rules ein weiterer Schritt die Anwendung sicherer zu machen.

Ich möchte mit VizOne anschliessen und möchte dir wirklich ans Herz legen, dass du das Thema Sicherheit mit in die Planungsphase mitnimmst.

Q
Quallo Themenstarter:in
992 Beiträge seit 2005
vor 16 Jahren

Original von VizOne
Ich glaube dir natürlich, dass dir die Sicherheit wichtig ist, sonst würdest du dir sicher nicht so viele Gedanken machen. Mit "auf die leichte Schulter nehmen" meinte ich eher, dass du auf der Suche nach einer leichten Lösung vielleicht nicht ganz bis zu Ende gedacht hast.

Mir ging es auch weniger darum, die Möglichkeit der Parameterfälschung zu beurteilen, sondern vielmehr darum, ein Bewusstsein zu schaffen, Sicherheit zu einem First-Class-Member der Programmlogik zu machen. Eben wirklich Sicherheit by Design und nicht "by Zufall der Datenkeys" 😉

Zudem ließe sich eine flexible, wiederverwendbare Lösung sicherlich programmieren. Wenn man Businessrules im Code forciert und Sicherheit zu einer Businessrule erhebt, lässt sie sich relativ problemlos in die Anwendung integrieren. Man kann das aber auch trennen und dann eine recht einfaches API à la bool MayPerform(User user, Action action) verwenden, welches intern die Rollen des Nutzers und z.B. den Zustand der Anwendung überprüft und daraus Rückschlüsse über die Zulässigkeit bestimmter Aktionen zieht.

Viel Erfolg auf jeden Fall weiterhin!

Viele Grüße,
Andre

So eine wie von dir angedachte Lösung habe ich bereits in einem Projekt implementiert. Dort liegt allerdings ein Großteil der Überprüfungslast in der Datenbank und schluckt auch ganz gut Performance (ist aber auch wirklich recht komplex). In der Businessschicht ist im Prinzip nur der Aufruf an die Datenbank schicht, dass das überprüft werden soll. Naja, womit es im Prinzip auch in der Businessschicht liegt... Es ist dann übrigens eher ein MayPerform(Wer, Was, Womit). Womit bezeichnet den Datensatz / die Datensätze.
Die Berechtigungsdaten werden zu Anfang der Session einmalig aus der Datenbank geladen (bzw. bei Berechtigungsänderungen neu geladen). Für die Prüfung auf Satzebene ist dann ein zusätzlicher Roundtrip erforderlich.

War halt sehr viel Arbeit, auch wenn ich es zum Teil migrieren kann.

Vielen Dank für deine Bemühungen auf jeden Fall!

Q
Quallo Themenstarter:in
992 Beiträge seit 2005
vor 16 Jahren

Original von burning snow
Ich für meinen Teil bin für Sicherheit und nicht für generische Lösungen. Es wird bei einer Sicherheitsschicht nie eine generische Lösung wie du das haben möchtest geben.

SSL finde ich beispielsweise eine nette Lösung für jedes Projekt in dem ich Verschlüsselung brauche. Klappt bei Amazon und Ebay, in dem Sinne meine ich generisch!

Und unter anderem sollte das Argument "die und die Firma machen es auch nicht" auf jedenfall nicht gelten. Das Argument kannst du beim Kunden auf gar keinen Fall verwenden und hebst dich dann auch nicht von der Konkurrenz ab.

Ich denke, dass ich es nicht gut finde, wenn andere soetwas tun und dass ich es auch nicht tun werde, ist wohl klar. Außerdem arbeite ich in einem Laden, der groß genug ist, dass man als Entwickler / Architekt keine Projekte an Land holen muss 😉

Dein Problem die Parameterverfälschung entsprechend zu umgehen, kannst du auch so durchführen dass du keine Parameter in der URL übergibst sondern nur über Sessions. Das wäre zur den Business Rules ein weiterer Schritt die Anwendung sicherer zu machen.

Wie gesagt, es geht nicht nur um Parameter, sondern auch um auf Smart Clients hinterlegte Stammdaten. Das ist nicht innerhalb von Sessions. Ansonsten würde deine Lösung mich schon interessieren, rein vom Konzept her.

Ich möchte mit VizOne anschliessen und möchte dir wirklich ans Herz legen, dass du das Thema Sicherheit mit in die Planungsphase mitnimmst.

Die Planungsphase läuft im Moment, es ist noch keine Zeile Produktivcode geschrieben. Es wird gerade über die Architektur nachgedacht und es werden Prototypen für einzelne Teile entwickelt, nur als Proof-Of-Concept.

Trotzdem danke für die Wünsche und die Hilfe!