White-Label-Script mit Remote Files

[Mazze]

Hallo zusammen,

Folgende Problemstellung:

Auf meinem Server soll ein Script liegen, das von einem anderen Server aufgerufen wird. Dies ist offensichtlich mit include möglich, allerdings ist mir nicht bekannt/ bewusst ob es andere Sicherheitsprobleme als bei Get- oder Post-Requests gibt.

Für ein einziges Script, das Inhalt ausgibt ist dies ja schön und gut aber wie sieht es mit komplexen Anwendungen aus, die ja nicht aus einem sondern zahlreichen Scriptdateien bestehen.

Z.B. ein Gästebuch, das auf Inhalte meiner Datenbank zugreift. Reicht es, wenn ich sämtlichen Include-Anweisungen die komplette URL gebe? Kommt jemand so böswillig an die Scripte oder z.B. ans Datenbankpasswort selbst dran?

Gibt es andere Lösungen für ein White-Label-Konzept, z.B. dass sämtliche Scripte auch von meinem Interpreter ausgeführt werden, d.h. auf meinem Server laufen und lediglich die HTML-Ausgabe in die Fremdpage eingfügt werden? Dazu gehören auch Eingabeformulare und Bestätigungsseiten, also sämtliches HTML.

Danke für alle Tipps,

Mazze

[wahsaga]

hi,

Gibt es andere Lösungen für ein White-Label-Konzept, z.B. dass sämtliche Scripte auch von meinem Interpreter ausgeführt werden, d.h. auf meinem Server laufen und lediglich die HTML-Ausgabe in die Fremdpage eingfügt werden?

genau das passiert doch sowieso, wenn das includen über HTTP stattfindet (andernfalls wäre der webserver gröbstens fehlkonfiguriert).

mir scheint, allzu intensiv hast du dich mit der thematik noch nicht auseinandergesetzt.

gruß,
wahsaga

[Christoph Zurnieden]

Hi,

Auf meinem Server soll ein Script liegen, das von einem anderen Server aufgerufen wird. Dies ist offensichtlich mit include möglich, allerdings ist mir nicht bekannt/ bewusst ob es andere Sicherheitsprobleme als bei Get- oder Post-Requests gibt.

Nun, so ganz spontan stellen sich da bei mir erstmal sämtliche Haare senkrecht ;-)

Tust Du das über das öffentliche Netz sogar zu recht. Das es überhaupt geht wäre also PHP anzulasten und ein Sicherheitsloch.
Halt, doch nicht gleich hauen! Ich korrigiere: es wäre eine recht einfache Möglichkeit sich selber in den Fuß zu schießen.

Aber ich gehe einfach mal davon aus, das Du das entweder über SSL und mit Schlüsseln erledigst, die so lang wie möglich sind oder über ein privates Netz im Rack.

Ich sollte es mir zwar abgewöhnen, die Frage nach dem Sinn zu stellen, kann es aber nicht: worin liegen die Vorteile, Scriptlistings von anderen Servern zu nutzen, statt einer lokalen Kopie?

Für ein einziges Script, das Inhalt ausgibt ist dies ja schön und gut aber wie sieht es mit komplexen Anwendungen aus, die ja nicht aus einem sondern zahlreichen Scriptdateien bestehen.

Das spielt in diesem Fall keine Rolle.

Z.B. ein Gästebuch, das auf Inhalte meiner Datenbank zugreift. Reicht es, wenn ich sämtlichen Include-Anweisungen die komplette URL gebe? Kommt jemand so böswillig an die Scripte oder z.B. ans Datenbankpasswort selbst dran?

Je nach Art und Weise der Verbindung: klar, kein Problem, kann einfach abgefangen werden.
Aber auch hier wieder: warum möchtest Du da andere Listings includen statt gleich eine lokale Kopie zu nutzen?

Gibt es andere Lösungen für ein White-Label-Konzept, z.B. dass sämtliche Scripte auch von meinem Interpreter ausgeführt werden, d.h. auf meinem Server laufen und lediglich die HTML-Ausgabe in die Fremdpage eingfügt werden? Dazu gehören auch Eingabeformulare und Bestätigungsseiten, also sämtliches HTML.

Die von mir nun zum dritten Mal angefragte lokale Kopie?
Was, um Gottes Willen, hält Dich davon ab?

so short

Christoph Zurnieden

[Mazze]

Hallo,

Tust Du das über das öffentliche Netz sogar zu recht. Das es überhaupt geht wäre also PHP anzulasten und ein Sicherheitsloch.
Ich korrigiere: es wäre eine recht einfache Möglichkeit sich selber in den Fuß zu schießen.

Geht es etwas konkreter? Meine Frage war ja die, ob es unsicherer ist als Get- oder Post-Requests.

Aber ich gehe einfach mal davon aus, das Du das entweder über SSL und mit Schlüsseln erledigst, die so lang wie möglich sind oder über ein privates Netz im Rack.

Mein Plan wäre, eine ca 20stellige Codenummer dem include-Befehl auf dem Fremdserverscript voranszustellen.

Ich sollte es mir zwar abgewöhnen, die Frage nach dem Sinn zu stellen, kann es aber nicht: worin liegen die Vorteile, Scriptlistings von anderen Servern zu nutzen, statt einer lokalen Kopie?

Die Vorteile stehen eigentlich schon recht griffig im Betreff. "WhiteLabel" bedeutet, dass ich (in diesem Fall mein Auftraggeber) einen Service anbietet, den ein ihm bekannter zahlender Kunde auf seiner Seite nutzen kann. Die Daten liegen aber auf der Seite des Anbieters d.h. in dessen Datenbank und auf dessen Server.

So muss das Script nicht preisgegeben werden (bitte nicht gleich schlachten - so wünschen es sich eben die Auftraggeber)

Ein weiterer Vorteil könnten Updates sein, aber dies nur am Rande.

Gruß,

Mazze

[Sven Rautenberg]

Moin!

Die Vorteile stehen eigentlich schon recht griffig im Betreff. "WhiteLabel" bedeutet, dass ich (in diesem Fall mein Auftraggeber) einen Service anbietet, den ein ihm bekannter zahlender Kunde auf seiner Seite nutzen kann. Die Daten liegen aber auf der Seite des Anbieters d.h. in dessen Datenbank und auf dessen Server.

So muss das Script nicht preisgegeben werden (bitte nicht gleich schlachten - so wünschen es sich eben die Auftraggeber)

Nochmal langsam zum mitmeißeln - folgende Fixpunkte habe ich aus deinen Schilderungen bislang entnommen:

1. Das Skript ist auf "deinem" Server gespeichert (also dem, der von deinem Auftraggeber verwaltet wird).
2. Die Datenbank ist auf dem Server des Kunden gespeichert (Kunde = der, der "deinen" Server nutzen will, um Dinge zu erledigen).
3. Sinn der Übung soll sein, dass der Kunde nicht das Skript ausgehändigt bekommt.

Dann würde ich doch mal ganz spontan sagen: Funktioniert nicht, wenn nicht gewisse Sicherheitsmechanismen komplett außer Acht gelassen werden sollen.

Damit du dein Skript nicht aus der Hand gibst, muß es zwingend von "deinem" Server ausgeführt werden. D.h. du mußt die Rechenleistung zur Verfügung stellen und darfst dann außerdem nur generierte Daten (wie HTML, Bilder etc.) ausliefern. Das Problem ist dann: Wie kommst du an die Datenbank deines Kunden ran? Wenn der Kunde dir da keinen remote zugänglichen Zugang einrichtet (wobei die Frage ist, ob er das überhaupt kann), dann kannst du seine Daten nicht mit deinem Skript auf "deinem" Server verarbeiten. Ich hätte als Kunde jedenfalls aus zwei Gründen ein ungutes Gefühl bei dieser Sache: 1. bedeutet ein offener Datenbankzugang natürlich ein zusätzliches Risiko, und 2. bedeutet das Nutzen einer entfernten Datenbank auch zusätzlichen Traffic und eine eingeschränkte Performance.

Was natürlich funktionieren würde, wäre das Ausführen des Skriptes auf dem Kundenserver. Dann wäre es relativ egal, wo die Datenbank des Kunden untergebracht ist, solange man vom Kundenserver aus drauf zugreifen kann (z.B. ein Datenbankserver im Intranet des Providers, oder eben auch lokal). Das Problem dabei ist aber, dass der Kunde in diesem Fall den PHP-Quellcode kriegt.

Abgesehen davon hat dieses Szenario auch noch ein ungutes Gefühl: Der Kunde muß remote codeinclude erlauben, d.h. über das Internet und wohlmöglich über eine ungesicherte Verbindung ausführbare Skripte auf seine Maschine laden. Sowas ist grundsätzlich böse, weil es zwingend tendentiell unsichere Einstellungen für PHP erfordert. Außerdem sind die Angriffsszenarien auf den Kundenserver sofort vervielfacht. Könnte ja sein, dass "dein" Server übernommen wird, es wird böser Code eingespeist und auf allen fremden Servern ausgeführt, die den Dienst nutzen. Wenn man sowas subtil genug macht, ist das ein schönes Spielzeug.

- Sven Rautenberg

[Mazze]

Hallo Sven,

danke für die ausführliche Antwort. Leider habe ich wohl misverständlich ausgedrückt.

1. Das Skript ist auf "deinem" Server gespeichert (also dem, der von deinem Auftraggeber verwaltet wird).

Ja.

2. Die Datenbank ist auf dem Server des Kunden gespeichert (Kunde = der, der "deinen" Server nutzen will, um Dinge zu erledigen).

Nein. Auch die Datenbank (in der Metadateien zu Videofiles liegen) sowie die Videofiles selbst sind auf "meiner Seite".

3. Sinn der Übung soll sein, dass der Kunde nicht das Skript ausgehändigt bekommt.

Jein. Es geht darum, dass mein Auftraggeber Videodateien für seine Kunden erstellt (encodiert, metadatiert etc.) und ihm dann ein Hosting dafür anbietet, d.h. eine Oberfläche zum Durchsuchen und Vorschauen der Videos. Jetzt hat aber ein potentieller Kunde meines Auftragsgebers gefragt, ob er diese Distributionsseiten in seine Website einbetten kann, beispielsweise per php-include in den Content-Bereich seiner Website. Von dieser Idee angefixt blökte mein Arbeitgeber gleich in die Welt hinaus, dass es sich bei dem Distributionssystem um eine "White-Label"-Lösung handelt, also etwas wo der Besucher einer Kundenseite nicht offensichtlich sehen kann, von wem das eigentliche Hosting realisiert wird, die ganzen Lorbeeren einstreichen wird ;-), etc.  Dafür muss der Kunde dann aber eben etwas mehr zahlen, als wenn das Hosting auf einer erkennbar fremden Seite wäre.

Mein Auftraggeber möchte aber nicht, dass die Scripts rausgegeben werden u.a. deswegen, weil ja dann der Datenbankzugang für den Kunden sichtbar wird und weil updates automatisch erfolgen können, ohne dass die Kunden neue Scripts integrieren müssen.

An und für sich eine nicht zwingend verwerfliche Angelegenheit, wie ich finde.

Meine Frage diesbezüglich war, ob es andere und neue Sicherheitslücken gibt als bei üblichen Gets und Posts, aber z.B. auch wie es sich mit Sessions verhält (werden die auf "meinem" oder auf "seinem" Server abgelegt) oder wie überhaupt ein Script auf ein entferntes Post-Formular reagiert. Eben einfach ob da jemand Erfahrungen mit hat.

Abgesehen davon hat dieses Szenario auch noch ein ungutes Gefühl: Der Kunde muß remote codeinclude erlauben, d.h. über das Internet und wohlmöglich über eine ungesicherte Verbindung ausführbare Skripte auf seine Maschine laden. Sowas ist grundsätzlich böse, weil es zwingend tendentiell unsichere Einstellungen für PHP erfordert. Außerdem sind die Angriffsszenarien auf den Kundenserver sofort vervielfacht. Könnte ja sein, dass "dein" Server übernommen wird, es wird böser Code eingespeist und auf allen fremden Servern ausgeführt, die den Dienst nutzen. Wenn man sowas subtil genug macht, ist das ein schönes Spielzeug.

Nun. Wenn ich das richtig interpretiere, heisst das, das ein includiertes PHP-Script auf meinem Server ja nicht nur Text oder HTML zurückgeben kann, sondern auch z.B. Bilder oder objects etc. Aber ist es tatsächlich möglich, dass ich ihm php-Code zurückgebe, der auf seinem Server ausgeführt wird? Das hiesse ja, wenn ich böse wäre und er bereit die include-Zeile einzufügen, könnte ich z.B. seinen Server ausspionieren etc. Wie ist das denn dann mit z.B. RSS-Newsfeeds, könnten die Anbieter da nicht auch Schindluder mit treiben, wenn obiges zutrifft?

Danke für die Hilfe.

Mazze

PS: Ein nettes Besipiel für einen Verein dem ich nicht blind vertrauen würde wäre:
http://www.cducsu.de/rssfeed.aspx?hash=c2VjdGlvbj02JnN1YnNlY3Rpb249NCZpZD0wJg==&control=2027511011911510773201208271041112011624998

[Christoph Zurnieden]

Hi,

nachdem also nun klar ist, das meine erste Reaktion (die Sache mit den zu Berge stehenden Haaren, Du erinnerst Dich?) zu Recht erfolgte ...

Mein Auftraggeber möchte aber nicht, dass die Scripts rausgegeben werden u.a. deswegen, weil ja dann der Datenbankzugang für den Kunden sichtbar wird und weil updates automatisch erfolgen können, ohne dass die Kunden neue Scripts integrieren müssen.

An und für sich eine nicht zwingend verwerfliche Angelegenheit, wie ich finde.

Nein, eine wirklich gute Idee sogar. Man mag über die Gründe streiten, aber vom sicherheitstechnischem Standpunkt ist indirekter Zugriff vorzuziehen.

Meine Frage diesbezüglich war, ob es andere und neue Sicherheitslücken gibt als bei üblichen Gets und Posts, aber z.B. auch wie es sich mit Sessions verhält (werden die auf "meinem" oder auf "seinem" Server abgelegt) oder wie überhaupt ein Script auf ein entferntes Post-Formular reagiert. Eben einfach ob da jemand Erfahrungen mit hat.

Der Kunde sollte einfach den Service nutzen können. Keine Includes oder sonstigen Driss sondern schlichte Frage-Antwort-Spielchen:

[SSL-Verbindung]
Kunde: gib mir eine Liste aller Filme auf denen ein Mops zu sehen ist
Host: Ihre ID bitte
Kunde: ID
Host: 1,"Kleine Hunde, Teil 22";2,"Möpse in allen Farben"; ...

Der Kunde verfährt also einfach so, als ob er die Datenbank selber abfragt, jedoch stattdessen eine einfach zu bedienende API bekommt. Gibt der Kunde euch ein Template, schmeißt ihr halt einfach alle Daten da rein.

Die obige Unterhaltung kann mühelos via PHP laufen, der Endabnehmer bekommt davon rein gar nichts mit, wenn der Kunde sich nicht allzu blöd anstellt. Aber selbst das ist dann im Grunde genommen auch nur wieder eine Möglichkeit einen Service anzubieten und somit auch damit Geld zu verdienen ;-)

[...]Das hiesse ja, wenn ich böse wäre und er bereit die include-Zeile einzufügen, könnte ich z.B. seinen Server ausspionieren etc. Wie ist das denn dann mit z.B. RSS-Newsfeeds, könnten die Anbieter da nicht auch Schindluder mit treiben, wenn obiges zutrifft?

Theoretisch ja, wenn der Abnehmer das zuläßt. Aber RSS ist prinzipiell auch erstmal kein ausführbarer Code.

PS: Ein nettes Besipiel für einen Verein dem ich nicht blind vertrauen würde wäre:
http://www.cducsu.de/rssfeed.aspx?hash=c2VjdGlvbj02JnN1YnNlY3Rpb249NCZpZD0wJg==&control=2027511011911510773201208271041112011624998

Aha, ein typisches Beipiel, warum ein include() völliger Blödsinn ist und andere Leute Böses vermuten läßt. (Ich nicht, ich glaube, die sind wirklich so ... ähem ... ungeschickt ;-)
http://www.cducsu.de/rss/rss_style.inc ist ein simples style-Element - die 7 Zeilen kann man auch noch per C&P einbasteln, die anderer Datei ist auch nur schlichtes und zudem nicht ganz sauberes HTML, das kann man auch eben per C&P einbauen. Da die rechtliche Situation wg C&P nicht ganz klar ist (die nötige Schöpfungshöhe wurde ja erst neulich durch ein OLG angezweifelt) würde ich das aber auch nicht machen wollen. Und ein RSS zu parsen, dafür wird viel angeboten, auch in PHP. Allerdings hat die Formulierung "Nutzen Sie dazu von uns vorbereiteten Quelltext." eine recht strikte Anmutung, das man _ausschließlich_ deren Code nehmen soll.

Ob man denen sagen soll, das das ein Sicherheitsloch, groß wie ein Braunkohlentagebau ist?

Auch schön:"Die CDU/CSU-Fraktion behält sich das Recht vor, Websites ohne Angabe von Gründen die Integration von Inhalten zu untersagen"
Ich selber behalte mir dann vor, die CDU/CSU ohne Angaben von Gründen nicht zu wählen.

Allerdings glaube ich auch nicht, das die anderen Parteien da freizügiger sind.

so short

Christoph Zurnieden

[Mazze]

Hallo,

Der Kunde sollte einfach den Service nutzen können. Keine Includes oder sonstigen Driss sondern schlichte Frage-Antwort-Spielchen:

[SSL-Verbindung]
Kunde: gib mir eine Liste aller Filme auf denen ein Mops zu sehen ist
Host: Ihre ID bitte
Kunde: ID
Host: 1,"Kleine Hunde, Teil 22";2,"Möpse in allen Farben"; ...

Der Kunde verfährt also einfach so, als ob er die Datenbank selber abfragt, jedoch stattdessen eine einfach zu bedienende API bekommt. Gibt der Kunde euch ein Template, schmeißt ihr halt einfach alle Daten da rein.

Okay, das ist ein Ansatz für eine Lösung. Letztendlich ist es ja wurscht, ob der Kunde nun eine einzige Sctiprzeile oder einen ganzen Code in seine Page einbettet. Wesentlich sind genannte Vorraussetzungen, wie die dass die Files und die Datenbank auf Host-Seite liegen und die Ergebnisse nicht als Frames oder andersartig fremde Seiten integriert sind, sondern Teil des Kunden-Webauftritts. Ich bin da nich so fit drin, aber hat es was Socket-Verbindungen zu tun? Sollte man an einer Art API bauen wie sie z.B. PayPal anbietet?

Ob man denen sagen soll, das das ein Sicherheitsloch, groß wie ein Braunkohlentagebau ist?

Ich muss allerdings gestehen, dass Du zwar dankenswerterweise auf die immensen Sicherheitsrisiken aufmerksam machst, aber bisher kein einziges Beispiel oder keine konkrete Gefahr formuliert hast. Da muss ich Dir dann wohl einfach glauben ;-)

Viele Grüße.

Mazze

[Christoph Zurnieden]

Hi,

Der Kunde verfährt also einfach so, als ob er die Datenbank selber abfragt, jedoch stattdessen eine einfach zu bedienende API bekommt. Gibt der Kunde euch ein Template, schmeißt ihr halt einfach alle Daten da rein.

Okay, das ist ein Ansatz für eine Lösung. Letztendlich ist es ja wurscht, ob der Kunde nun eine einzige Sctiprzeile oder einen ganzen Code in seine Page einbettet. Wesentlich sind genannte Vorraussetzungen, wie die dass die Files und die Datenbank auf Host-Seite liegen und die Ergebnisse nicht als Frames oder andersartig fremde Seiten integriert sind,

Einfachste Abwehr ist dafür natürlich, das man erst gar keine vollständigen Seiten anbietet, sodern einfach nur Pfade (ohne Kundentemplate) oder auch Codeschnippsel verschiedener Größe (mit Kundentemplate).

sondern Teil des Kunden-Webauftritts. Ich bin da nich so fit drin, aber hat es was Socket-Verbindungen zu tun? Sollte man an einer Art API bauen wie sie z.B. PayPal anbietet?

Das könntest Du natürlich tun, aber das ist kompliziert und somit teuer. Der einzige Vorteil ist auch nur der gesparte Overhead gegenüber irgendwelchen übergeordneten Protokollen wie HTTP o.ä.
Für meinen Vorschlag reicht ein HTTP-Server und eine Skriptsprache Deiner Wahl. Mit Perl kannst Du z.B. beides; aber auch nur auf Guru-Level ;-)
Aber da Du Dich wohl eher auf PHP verstehst: Apache + PHP. Der Apache kann auch bequem die Authentifizierung für Dich übernehmen, schonmal ein Kopfschmerz weniger.

Ob man denen sagen soll, das das ein Sicherheitsloch, groß wie ein Braunkohlentagebau ist?

Ich muss allerdings gestehen, dass Du zwar dankenswerterweise auf die immensen Sicherheitsrisiken aufmerksam machst, aber bisher kein einziges Beispiel oder keine konkrete Gefahr formuliert hast. Da muss ich Dir dann wohl einfach glauben ;-)

Nein, natürlich nicht. Ich dachte zwar, das wäre rausgekommen, aber da wohl doch nicht bitte ich um Entschuldigung und gelobe Besserung:

Wenn Du einfach Scripte andere Leute benutzt ohne sie sorgfältig zu prüfen ist das nicht gesund, soweit sollte das schonmal klar sein, oder?
Normalerweise wird entweder durch technische/gesetzliche Mittel ein evt Schaden begrenzt (Sandbox/Haftung) oder das Script händisch/automatisch überprüft.
Beim einfachem include() über unverschlüsseltem Weg funktioniert beides nicht. Du kannst das Script nicht vor der Ausführung prüfen, weder händisch noch automatisch. PHP läuft nicht in einer Sandbox. Da nicht verschlüsselt o.ä. entfällt auch die Haftung, da sich irgendjemand dazwischen geschummelt haben könnte und so den Scriptcode unauffällig(!) verändern kann.
Dazu kommt natürlich noch, das der Anbieter "gerooted" sein kannt, Du dem Sysadmin des Anbieters die Frau ausgespannt hast o.ä. dann ist auch SSL nicht mehr ausreichend. (Allerdings bleibt dann theoretisch die Haftung bestehen)

Es gibt also viel mehr Möglichkeiten, das es nicht funktioniert, als das es klappt.
Deswegen auch meine Hochkantfrisur ;-)

so short

Christoph Zurnieden