RootForum Community

Beff wrote:Frage:
Ist es mit dieser Konfiguration möglich, dass ein Angreifer die Daten anderer Kunden manipulieren oder gar Root-Rechte auf dem Server erlangen kann? Falls ja, geben Sie ein beliebiges Stück PHP-Code an, mit dem dies möglich wäre.

Ja, denn Du hast den grössten Fehler der "Standardinstallationen" noch nicht beseitigt: Alle webXX befinden sich in der gleichen Gruppe und können nach wie vor auf die Daten der anderen webXX mindestens lesend zugreifen...

@Beff: Klar, open_basedir macht den Server dicht, aber die Skriptsicherheit an sich ist doch wohl mit der Serversicherheit gleichzusetzen.
Was nützt es, wenn man auf nem Server zwar nicht Root-Rechte durch böswillen Code erlangen kann, sich aber einen Kundenaccount hacken lässt und z.B. ein Angreifer dessen Datenbestände lesen/manipulieren/löschen kann. Für die zahlende Kundschaft ist letzteres nämlich genau so ärgerlich wie ein Totalausfall des Servers. Dementsprechend ist Query-Sanitizing und register_globals off ein weiterer Basisbestandteil der Server-Sicherheit.

Die Daten anderer Kunden lassen sich - so wie behauptet - nicht manipulieren, wenn man open_basedir und eingeschränkte SQL-Benutzer hat.

Hier treffen mal wieder die verschiedenen Welten und Anforderungen aufeinander!

Mich interessiert recht wenig, ob ein Kunde seine Daten preisgibt, weil er irgend ein Dusselscript von seinem Neffen laufen läßt .... :twisted:

Ich möchte mal den Unterschied zwischen Administrator und Entwicklern erwähnen. Der Administrator hat doch (unter anderem) die Aufgabe zu erfüllen, dass die Systeme zur Verfügung stehen und sicher sind. Dort liegt die Priorität! :!:

Als Entwickler bewege ich mich in dem vom Administrator zur Verfügung gestellten Raum und versuche in erster Instanz die geforderte Funktionalität zu erfüllen. :!:

Wenn nun die Ziele des Admins mit den Zielen des Entwicklers kollidieren ist die Frage welche Lösung gefunden werden kann. Ich bezweifele das dieses individuelle und situationsabhängige Problem in einer allgemeinen Diskussion geklärt werden kann.

Doch wenn ich als Betreiber ein erhötes Sicherheitsrisiko eingehe, wiege ich dies mit dem resultierenden Gewinn auf ... 8)

Joe User wrote:

Beff wrote:Frage:
Ist es mit dieser Konfiguration möglich, dass ein Angreifer die Daten anderer Kunden manipulieren oder gar Root-Rechte auf dem Server erlangen kann? Falls ja, geben Sie ein beliebiges Stück PHP-Code an, mit dem dies möglich wäre.

Ja, denn Du hast den grössten Fehler der "Standardinstallationen" noch nicht beseitigt: Alle webXX befinden sich in der gleichen Gruppe und können nach wie vor auf die Daten der anderen webXX mindestens lesend zugreifen...

Nein!

Denn die Daten der anderen Kunden liegen außerhalb das Basedirs und damit außerhalb der erlaubten Pfade. Probier's ruhig aus, du wirst eine Fehlermeldung bekommen ;).

Manfred, das Mammut wrote:@Beff: Klar, open_basedir macht den Server dicht, aber die Skriptsicherheit an sich ist doch wohl mit der Serversicherheit gleichzusetzen.
Was nützt es, wenn man auf nem Server zwar nicht Root-Rechte durch böswillen Code erlangen kann, sich aber einen Kundenaccount hacken lässt und z.B. ein Angreifer dessen Datenbestände lesen/manipulieren/löschen kann. Für die zahlende Kundschaft ist letzteres nämlich genau so ärgerlich wie ein Totalausfall des Servers. Dementsprechend ist Query-Sanitizing und register_globals off ein weiterer Basisbestandteil der Server-Sicherheit.

Es ist schon richtig, dass ich mit register_globals Off das eine oder andere Kundenskript besser gegen Manipulation geschützt wird. Meiner Meinung nach - und das ist eine Meinung, und damit immer eine persönliche Position - sieht das bei mir auf dem Server so aus:

Es gibt z.B. 100 Skripte, die schlecht programmiert sind (bei PHP leider kein Wunder), und damit manipulierbar sind.

Wenn ich register_globals Off schalte, dann sind immer noch z.B. 90 Skripte manipulierbar (Beispiele hat kawfy genug genannt ;)). Dafür gehen aber dann 200 andere Skripte überhaupt gar nicht mehr.

Ich muss hier also abwägen und meine Entscheidung ist gefallen. Natürlich kann man über diesen Standpunkt streiten, aber letztendlich ist der Kunde dafür verantwortlich, was er da auf seinen Webspace stellt. Mein Sicherheitsziel ist es, eine Sandbox zu bauen, und das habe ich getan ;).

Die Daten anderer Kunden lassen sich - so wie behauptet - nicht manipulieren, wenn man open_basedir und eingeschränkte SQL-Benutzer hat.

DAS war mir eigentlich wichtig. register_globals On ist nicht zwingend eine Todsünde ;).

Beff wrote:Nein!

Denn die Daten der anderen Kunden liegen außerhalb das Basedirs und damit außerhalb der erlaubten Pfade. Probier's ruhig aus, du wirst eine Fehlermeldung bekommen ;).

Es gibt nicht nur PHP und da wir hier über Security diskutieren...

Das ist dennoch keine korrekte Antwort auf meine Fragestellung, denn diese bezog sich ganz klar auf PHP. Ich bleibe beim "nein" ;).

Aber gut, dass du es trotzdem ansprichst: Diese Geschichte mit dem Verzeichnis- und Datenbank-Sandkasten muss selbstredend auch für CGI, Python oder was man sonst auch immer dem Kunden zum spielen gibt, gelten. Da hast du selbstverständlich Recht (wäre ja noch schöner, wenn nicht ;)).

Und dann kommen natürlich noch so Geschichten wie regelmäßige Updates, Logs anschauen, richtiger Umgang mit Passwörtern, Dienste checken, Infos über Sicherheitslücken lesen, und und und. Ich denke, damit hätte man schon das kleine Einmaleins der Serversicherheit ganz grob umrissen. Wenn wir schon mal dabei sind ;).