Re: Wg. Sicherheitslücke(n) - baseportal Forum - Web-Anwendungen einfach, schnell, leistungsfähig!
baseportal
English - Deutsch "Es gibt keine dummen Fragen - jeder hat einmal angefangen"

 baseportal-ForumDie aktuellsten 10, 30, 50, 100 Einträge anzeigen.  

 
 Ausgewählter Eintrag: Zur Liste 
    Beitrag von sascha fitzner (1 Beitrag) am Montag, 21.Januar.2002, 21:07.
    Re: Wg. Sicherheitslücke(n)

      hallo christoph!

      wir hatten diesbezüglich ja auch vor einiger zeit schon mal kontakt. auch ich habe das anders interpretiert wie du es dir gedacht hattest. ich wurde darauf durch einen anderen baseportaluser aufmerksam der micht freundlicherweise darauf aufmerksam gemacht hat. dafür nochmal ein grosses dankeschön an ihn. ich habe daraufhin auch konsequenzen gezogen und so gut wie möglich geblockt. weiterhin habe auch ich befreundete baseportaluser darauf hingewiesen wo es eventuell nachzubessern gilt. meine meinung zu der sache ist das templates nur auf eigene datenbanken zurückgreifen dürfen. bedeutet: wenn ich denn user mauritius bei baseportal habe muss das / (root) im userhome (mauritius) liegen. es darf meiner meinung nach nicht möglich sein aus seinem eigenem HOME rauszukommen und mit ../../ oder was auch immer in irgendwelchen anderen roots rumturnen um sich von dort in andere HOME's runterzuhangeln. meine definifion hierzu ist auch, dass jeder darf .... bedeutet das jeder mit "meinem" template darf was ich in der datenbank erlaube und nicht mit "seinem" template. ich kann schliesslich immer noch steuern welche felder angezeigt werden und welche nicht.

      ich denke das sollte erstmal die basis sein. sollte es user bei baseportal geben die accountübergreifend arbeiten müssen dann - sorry - aber erstmal gelitten.
      es kann dann nicht kurzfristig darum gehen eine lösung für alle zu finden, das muss ein langfristiger plan sein. kurzfristig musst du erstmal die sicherheitsansprüche der meisten user befriedigen.

      ich denke vielleicht ist es ja auch möglich so eine art freigabe zu machen, like "auf meine daten dürfen auch die accounts x, y und z zugreifen! ich denke aber das das accountübergreifende nicht die regel ist. ich denke die regel ist das "vermutlich fast jeder" auch mit stovnormalen templates irgendwo was macht um eben den aufwand für quickies zu minimieren und das innerhalb seines account. gerade die neueinsteiger werden erstmal mit normalen datenbanken anfangen und sich die benötigten templates erstmal generieren lassen ohne sich von anfang an mit perl rumzuschlagen. und das bedeutet für mich das newbies erstmal unsichere datenbanken haben müssen bis sie soweit sind das sie sich mit perl auskennen und die türen schliessen können.

      meine bitte deshalb: erstmal sperren das ein account an daten eines anderen account ran kann. somit ist erstmal sicherheit gewährleistet. dann wird man schon sehen wie hoch die notwendigkeit ist sich über eine freigabe für einen anderen account gedanken zu machen.

      das solche sachen wie der unloader dann nicht mehr funktionieren ist mir persönlich ganz egal. dann soll der halt in die bib gestellt werden und jeder der ihn braucht soll ihn sich von dort ziehen.

      gruss sascha fitzner


    Antworten

 Alle Einträge zum Thema: Zur Liste 
    Beitrag von Christoph Bergmann (8110 Beiträge) am Montag, 21.Januar.2002, 14:23.
    Wg. Sicherheitslücke(n)

      So, hier is wohl ein kurzes Statement fällig.

      Wer die untenstehenden Threads verfolgt hat, ist jetzt vielleicht etwas verwirrt...

      Ausgegangen ist das Ganze von jemand, der meinte, dass man mit Claus Export-Template "einfach so" auf fremde Datenbanken zugreifen kann. Das ging (soweit ich weiss) NICHT. Was ging und was immer noch geht ist, dass man auf fremde Datenbanken zugreifen kann, wenn die entsprechenden Rechte gesetzt sind.

      Also, nochmal so klar wie möglich:

      Wenn bei "Datenbank / Verwaltung" ein Häkchen bei "Jeder darf Daten abrufen?" gesetzt ist DARF _JEDER_ die DATEN ABRUFEN (Jeder = auch von anderen baseportal-Accounts. Das ist ein -bewusst eingebautes- Feature, keine Lücke!)

      Ich weiss wirklich nicht wie man diesen Satz anders verstehen kann. Genaueres dazu im Thread hier: http://baseportal.de/cgi-bin/baseportal.pl?htx=/baseportal/forum&wcheck=1&Pos=4539.00002

      In diesem Thread hab ich den etwas vermessenen Satz geschrieben, dass man auf eine Datenbank deren Rechte nicht gesetzt sind auch nich zugreifen könne, "weder mit Claus Template, _noch sonstwie_". Vermessen ist das deshalb, weil genauso wie Fehler auch Sicherheitslücken nie 100% auszuschliessen sind. Dieses Los teilt sich bp mit jeder anderen komplexeren Software, wie man bei http://www.cert.org/nav/index_red.html sehen kann, wo ständig Sicherheitslücken in Windows, IE, FTP und sogar speziellen "Sicherheitsprogrammen" wie SSH etc. gemeldet werden.

      Das hat Andreas Jurenda gereizt und er hat sich hingesetzt, um eine Lücke in bp zu finden - was ihm auch gelungen ist. 1 Punkt für ihn! ;-)

      Diese Lücke ist aber nun -natürlich- geschlossen, d.h. es bleibt dabei: Datenbanken deren Rechte entsprechend gesetzt (bzw. eben NICHT gesetzt) sind, sind sicher... Zumindest solange bis jemand eine neue Sicherheitslücke findet, was leider immer im Bereich des Möglichen ist... (Und wahrscheinlich reizt diese Aussage wieder zum Versuch des Gegenbeweises)

     Antworten

    Beitrag von Oliver ;-) (439 Beiträge) am Montag, 21.Januar.2002, 17:22.
    Re: Wg. Sicherheitslücke(n)

      Hallo Christoph,

      ein bisschen hört sich das bei dir so an, wie ich es mal am Atelco-Serviceschalter gelesen habe: Wer lesen kann ist klar im Vorteil!

      Aber so einfach ist das wohl nicht.

      Natürlich steht in der Verwaltung einer jeden Datenbank hinter dem Auswahlfeld der Text "Jeder darf Daten abrufen". Aber für mich als Anwender ist dadurch nicht automatisch klar, dass JEDER die GESAMTE Datenbank auslesen kann.

      Für einen Laien - und somit auch für mich - standen diese Felder eher in Bezug auf "do action". D.h., ich ging davon aus, dass ich damit lediglich die Funktionalität von "do action" beeinflusse und über die entsprechenden Befehle auch beeinflussen kann, welche Felder jeder abrufen kann.

      Dass dem nicht so ist, weiß ich nun erst seit gestern bzw. bin ich mir erst seit gestern bewusst.

      Vielleicht solltest du das auch in der Doku noch deutlicher machen, dass jemand, der mit "do action" arbeitet, keine datenschutzrelevanten DBs einrichten sollte.

      Grüße
      Oliver ;-)

     Antworten

    Beitrag von ohne namen (1 Beitrag) am Montag, 21.Januar.2002, 17:45.
    Re: Wg. Sicherheitslücke(n)

      aus sicherheitsgründen kein name.

      ich habe hier eine datenbank mit allen lese und schreib rechten, aber im temlate kann man nur ein feld beschreiben.
      es werden auch nicht alle felder im template angezeigt.

      somit ist nun doch ein sicherheitsloch vorhanden !!!

     Antworten

    Beitrag von Christoph Bergmann (8110 Beiträge) am Montag, 21.Januar.2002, 18:11.
    Re: Wg. Sicherheitslücke(n)

      Nein, so einfach ist es nicht...

      Du bist ja nicht der Einzige der das so interpretiert und da ist wirklich das Problem. Wenn ein bestimmter Prozentsatz (sagen wir > 10%) der Nutzer "Jeder darf Daten abrufen" so interpretiert, dass dies NICHT die gesamte DB betrifft, sondern nur Teile davon, die man z.b. per "listfields" bestimmen kann, dann sollte man was ändern... ;-)

      Da das mit den Rechten aber eigentlich überall so ist (z.B. bei Betriebssystemen) ging ich davon aus, dass das klar wäre:

       - Die Rechte die bei "Verwaltung" vergeben werden, sind tatsächlich die grundlegenden Rechte die _jeder_ bei einem Lese/Schreib/Änder-Zugriff auf die (gesamte) Datenbank inne hat.
      

       - Das Template und die Parameter "listfields" o.ä. sind nur Ausgabeeinschränkungen die erst _nach_ dem eigentlichen Zugriff (z.B. Lesen) auf die Datenbank greifen. D.h. die Daten sind voll da, es werden halt nur nicht alle ausgegeben.

      Ok, mehrere Lösungen:

      a) Es bleibt wie es ist, der Sachverhalt wird deutlicher dargestellt ;-)

      b) Das Feature wird komplett abgeschaltet - dann wäre aber ein Tool wie Claus Exportseite nicht ohne weiteres möglich (man müsste es sich aus der Bib in das eigene Verzeichnis kopieren etc.) - ausserdem macht es auch für andere Anwendungen Sinn auf andere Accounts zuzugreifen...

      c) Es gibt noch eine zusätzliche Rechtevergabe für andere Accounts - wahrscheinlich die beste Lösung, leider am aufwändigsten ;-)

     Antworten

    Beitrag von Robert Heiden (81 Beiträge) am Montag, 21.Januar.2002, 18:42.
    Re: Wg. Sicherheitslücke(n)

      Ich halte es schon für sinnvoll, zu verhindern, daß die Inhalte einer Datenbank, die ich nicht bewußt freigegeben habe ( z.B. online/offline Schaltung, Rollenverteilung etc.) nicht ohne weiteres von fremden Accounts vollständig ausgelesen werden können.

      Ansonsten ist jeglicher Aufwand, mit sid's etc. etwas zu schützen, nur gegen absolute Laien gerichtet. Dann erscheint mir Lösung b) als die momentan einfachste und gerechteste Lösung, bis zu dem Zeitpunkt, wo Lösung c) fertig programmiert ist.

      Und noch eines:

      baseportal ist eine phantastische Lösung, umfangreiche Daten ins Internet zu stellen. Diese sollte nicht durch Polemik zerstört werden.

      Ob andere eine tolle Exportsoftware erstellt haben oder nicht, ist mir egal. Ich bin für Datensicherheit,
      z.B. sollten in passwort-geschützten Foren nicht unbedingt Außenstehende das alles herunterziehen und weiterverwenden können.

      Ich gehe davon aus, daß nur die Datenbankteile von anderen gelesen werden können, die ich zur Ansicht freigegeben habe. Dann benutze ich wirklich eine professionelle Systemsoftware.

      Baseportal sollte diese Voraussetzung erfüllen.

     Antworten

    Beitrag von Jörg (173 Beiträge) am Montag, 21.Januar.2002, 19:15.
    Re: Wg. Sicherheitslücke(n)

      Hi!

      Ich muss zugeben, dass ich ein wenig schockiert war. Auch ich hab "Jeder darf Daten abrufen" falsch verstanden.
      "Jeder darf Daten abrufen" über meinen Account und nicht anders (so hab ich es verstanden).
      Leider bin ich nicht so fit, alles so schnell zu ändern. Deshalb wäre ich sehr dankbar über die C-Variante!

      Gruss
      Jörg

     Antworten

    Beitrag von sascha fitzner (1 Beitrag) am Montag, 21.Januar.2002, 21:07.
    Re: Wg. Sicherheitslücke(n)

      hallo christoph!

      wir hatten diesbezüglich ja auch vor einiger zeit schon mal kontakt. auch ich habe das anders interpretiert wie du es dir gedacht hattest. ich wurde darauf durch einen anderen baseportaluser aufmerksam der micht freundlicherweise darauf aufmerksam gemacht hat. dafür nochmal ein grosses dankeschön an ihn. ich habe daraufhin auch konsequenzen gezogen und so gut wie möglich geblockt. weiterhin habe auch ich befreundete baseportaluser darauf hingewiesen wo es eventuell nachzubessern gilt. meine meinung zu der sache ist das templates nur auf eigene datenbanken zurückgreifen dürfen. bedeutet: wenn ich denn user mauritius bei baseportal habe muss das / (root) im userhome (mauritius) liegen. es darf meiner meinung nach nicht möglich sein aus seinem eigenem HOME rauszukommen und mit ../../ oder was auch immer in irgendwelchen anderen roots rumturnen um sich von dort in andere HOME's runterzuhangeln. meine definifion hierzu ist auch, dass jeder darf .... bedeutet das jeder mit "meinem" template darf was ich in der datenbank erlaube und nicht mit "seinem" template. ich kann schliesslich immer noch steuern welche felder angezeigt werden und welche nicht.

      ich denke das sollte erstmal die basis sein. sollte es user bei baseportal geben die accountübergreifend arbeiten müssen dann - sorry - aber erstmal gelitten.
      es kann dann nicht kurzfristig darum gehen eine lösung für alle zu finden, das muss ein langfristiger plan sein. kurzfristig musst du erstmal die sicherheitsansprüche der meisten user befriedigen.

      ich denke vielleicht ist es ja auch möglich so eine art freigabe zu machen, like "auf meine daten dürfen auch die accounts x, y und z zugreifen! ich denke aber das das accountübergreifende nicht die regel ist. ich denke die regel ist das "vermutlich fast jeder" auch mit stovnormalen templates irgendwo was macht um eben den aufwand für quickies zu minimieren und das innerhalb seines account. gerade die neueinsteiger werden erstmal mit normalen datenbanken anfangen und sich die benötigten templates erstmal generieren lassen ohne sich von anfang an mit perl rumzuschlagen. und das bedeutet für mich das newbies erstmal unsichere datenbanken haben müssen bis sie soweit sind das sie sich mit perl auskennen und die türen schliessen können.

      meine bitte deshalb: erstmal sperren das ein account an daten eines anderen account ran kann. somit ist erstmal sicherheit gewährleistet. dann wird man schon sehen wie hoch die notwendigkeit ist sich über eine freigabe für einen anderen account gedanken zu machen.

      das solche sachen wie der unloader dann nicht mehr funktionieren ist mir persönlich ganz egal. dann soll der halt in die bib gestellt werden und jeder der ihn braucht soll ihn sich von dort ziehen.

      gruss sascha fitzner

     Antworten

    Beitrag von Robert Heiden (81 Beiträge) am Montag, 21.Januar.2002, 22:02.
    Re: Wg. Sicherheitslücke(n)

      Dieser Meinung kann ich mich voll und ganz anschließen.

      Ansonsten kann man baseportal ja nur als Spiele-Server für belanglose Dinge betrachten, auf den man dann vielleicht auch wiederum verzichten könnte.

      Liebe Grüße

      Robert Heiden

     Antworten

    Beitrag von Christoph Bergmann (8110 Beiträge) am Montag, 21.Januar.2002, 22:20.
    Re: Wg. Sicherheitslücke(n)

      Nich ganz, aber ein Spieleserver wär schon nich schlecht ;-)

     Antworten


     
 Liste der Einträge von 51300 bis 51450:Einklappen Zur Eingabe 
Neueste Einträge << 10 | 9 | 8 | 7 | 6 | 5 | 4 | 3 | 2 | Neuere Einträge < Zur Eingabe  > Ältere Einträge | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 >> Älteste Einträge


Zurück zur Homepage

© baseportal.de. Alle Rechte vorbehalten. Nutzungsbedingungen



powered in 0.06s by baseportal.de
Erstellen Sie Ihre eigene Web-Datenbank - kostenlos!