Kopierschutz mit include-Dateien

[ralphi]

Hallo Leute,

wie die meisten hier schon wissen, bastel ich viel mit dem kleinen Raspi rum. Mittlerweile hab ich auch eine Applikation (Webapp) mit Hardwareanbindung geschrieben, die ich gerne schützen möchte.
D.h. nicht einfach SD-Karte clonen und in den nächsten Raspi reinstecken. So nicht ;-) - das möchte ich unterbinden.
Da fast alle Module mit Ajax, auf php - Dateien zugreifen, dachte ich, es wäre einfach mit include ("http://mein.externer.server/module/best_raspi/service/php/dscheck_o.php");
die php-Dateien extern zu haben.

also

$.get("php/dscheck.php",function(data,status){  
	//alert( data + "\nStatus: " + status);  
	var x = "<h2>Drucker</h2>";  
	$("#drucker").html(data);	  
});

und in der dscheck.php:

<?php  
include ("http://mein.externer.server/module/best_raspi/service/php/dscheck_o.php");  
?>

Die Applikation setzt eh eine Internetverbindung voraus. In der php greif ich auf socket und DB zu.

Klappt aber nicht.
Kennt jemand den Grund und kann mir vielleicht eine Alternative nennen?
Viele Grüße aus LA

[dedlfix]

Tach!

Da fast alle Module mit Ajax, auf php - Dateien zugreifen, dachte ich, es wäre einfach mit include ("http://mein.externer.server/module/best_raspi/service/php/dscheck_o.php");
die php-Dateien extern zu haben.

Ja, und es ist auch einfach, somit jeden beliebigen Code auszuführen, der über diese URL reinkommt. Das ist nicht gerade sicherheitstechnisch unbedenklich.

Klappt aber nicht.
Kennt jemand den Grund und kann mir vielleicht eine Alternative nennen?

Der Grund ist sicher der, den dir PHP in einer Fehlermeldung mitteilt - oder zumindest hätte, wenn du sie ausblendest. Aus "klappt nicht" kann man den jedenfalls nicht herauslesen. Vermutlich liegt es aber am Default-Wert von allow_url_include.

dedlfix.

[ralphi]

hi

Vermutlich liegt es aber am Default-Wert von allow_url_include.

du bist gut - kommst in die suppe :-)
hab ich in der php.ini auf on gestellt und futzt.

Was meinst du mit Sicherheitsbedenken? Die php - Dateien auf dem externen server, kann man mit GET/POST variablen schützen.
Lokal kann keiner was hochladen oder manipuliere.

Viele Grüße aus LA

[sorb]

Hi Raspi,

Was meinst du mit Sicherheitsbedenken? Die php - Dateien auf dem externen server, kann man mit GET/POST variablen schützen.
Lokal kann keiner was hochladen oder manipuliere.

das ist unsauber und sicherheitstechnisch nicht unbedenklich, weil jeder beliebige Code ausgeführt werden _könnte_.
Besser, du schreibst dir ne kleine API, die du per http ansprichst. Diese stattest du mit einem Satz Methoden aus, die nur genau das zurückliefern, was der user gerade braucht.

Das könnte z.B. ein XML-RPC sein oder irgendwas mit Soap. Oder ganz und gar simpel, da gibts viele Möglichkeiten. Nur externen Code per include einbinden... niemals.

grüße
sorb

[ralphi]

hi,

Besser, du schreibst dir ne kleine API, die du per http ansprichst. Diese stattest du mit einem Satz Methoden aus, die nur genau das zurückliefern, was der user gerade braucht.

Das könnte z.B. ein XML-RPC sein oder irgendwas mit Soap. Oder ganz und gar simpel, da gibts viele Möglichkeiten. Nur externen Code per include einbinden... niemals.

nun - ich hab versucht eine externe php Datei mit $GET auszulesen.
futz nicht!
futzt das überhaupt?
also direkt (im browser) kann ich sie ansprechen und bekomme das (XML text joson etc.) was ich gerne hätte

Viele Grüße aus LA

[Der Martin]

Hallo,

nun - ich hab versucht eine externe php Datei mit $GET auszulesen.
futz nicht!
futzt das überhaupt?
also direkt (im browser) kann ich sie ansprechen und bekomme das (XML text joson etc.) was ich gerne hätte

siehste, und genau das bekommt das übergeordnete PHP-Script auch. Du includierst damit quasi XML oder JSON in ein PHP-Script. Das ergibt Schrott. Aber das habe ich dir ja vor zwei Tagen schon erklärt.

Du kannst natürlich den zweiten Server so konfigurieren, dass er den Quellcode ungeparst und uninterpretiert ausgibt. Noch einfacher wäre, das includierte Script einfach umzubenennen (also nicht die Endung .php zu verwenden). Aber dann kann auch jeder Hirni den Code auf gleiche Weise direkt abrufen, und der Nutzen ist gleich Null.

Ciao,
 Martin

[Felix Riesterer]

Lieber ralphi,

eine Applikation (Webapp) mit Hardwareanbindung geschrieben, die ich gerne schützen möchte.
D.h. nicht einfach SD-Karte clonen und in den nächsten Raspi reinstecken. So nicht ;-)

warum? Willst Du damit Geld verdienen? Dann wäre ein Lizenzmodell sinnvoller. Technische Maßnahmen zur Einschränkung lehne ich ab; da halte ich es mit der FSF, denn damit wird Deine Software unfrei (in meinen Augen ein grundsätzlicher Mangel), was bei quelloffenen Produkten (sämtlicher Code ist ja prinzipiell einsehbar) irgendwie unsinnig klingt.

Wenn Du jedoch einen Dienst anbietest, könntest Du eine Form der Authentifizierung anbieten, die dann von Nutzern jeweils auf ihrer Maschine eingegeben werden muss - nach jedem Restart erneut. Damit könntest Du die unerwünschte Verfielfältigung zu verhindern suchen.

Da fast alle Module mit Ajax, auf php - Dateien zugreifen, dachte ich, es wäre einfach mit include ("http://mein.externer.server/module/best_raspi/service/php/dscheck_o.php");
die php-Dateien extern zu haben.

Ist Dir klar, dass das ein Scheunentor für Angriffe ist? Davon kann ich nur dringenst abraten! Ich halte den von Dir gewählten technischen Lösungsansatz für Dein grundsätzliches Problem für falsch und gefährlich.

Liebe Grüße,

Felix Riesterer.

[Der Martin]

Hallo,

<?php

include ("http://mein.externer.server/module/best_raspi/service/php/dscheck_o.php");
?>

  
von allen anderen genannten Bedenken abgesehen - ist dir bewusst, dass du so nur die Ausgabe des Scripts includierst und nicht das Script selbst?  
  
Ciao,  
 Martin  

-- 
Alkohl ist ungesund,  
Rauchen ist schädlich,  
Sex ist unanständig  
- und die Erde ist eine flache Scheibe.  
Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(

[ralphi]

hi

von allen anderen genannten Bedenken abgesehen - ist dir bewusst, dass du so nur die Ausgabe des Scripts includierst und nicht das Script selbst?

stimmt - die mysql geschichten macht er nicht :-(

Viele Grüße aus LA

[M.]

Mahlzeit,

Die Applikation setzt eh eine Internetverbindung voraus. In der php greif ich auf socket und DB zu.

Mal abgesehen davon, dass dein Raspi dann nicht einsatzfähig ist, wenn keine Internetverbindung besteht (das kann dich evtl. verdammt viel geld kosten, wenn jemand deine App einsetzt und durch diese Einschränkung Geld verliert, kein Internet ist 1200%ig ausfallsicher), eine Scriptsprache auf diese Weise absichern zu wollen ist so als wenn du ein Rootpasswort mit 200 stellen einrichtest es aber dann auf die Tastatur schreibst.

Entweder baust du dir ein kleines programm, das kompiliert ist und einen Lizenzcheck macht (was durch Reverse-Engineering relativ leicht auszuhebeln ist, wenn du nicht sehr viel Aufwand treiben willst) oder du nutzt Tools wie IonCube o.ä.

Nach der Menge der Hardwaresteuerungen, die aktuell für den Raspi existieren, muss dein Tool schon absolut revolutionär sein, denn sonst gibt es absolut keinen Grund, sich durch irgendwas gängeln zu lassen, wenn es reichlich Alternativen gibt, die das nicht tun.

Und so nebenbei, wer nen Raspi einsetzt, ist zu 99% ein Bastler und/oder Entwickler. Glaubst du wirklöich, die haben

a: ein Problem, deinen "Schutz" auszuhebeln und
b: nicht die Fähigkeiten, eine solche Hardwareanbinung selbst zu programmieren?

Erzähl doch mal genau was deine App so revolutionär macht, dass ein solcher Schutz nötig ist und dass ein Anwender sich diese Einschränkung aufzwingen lässt.

BTW: Ich habe die Hardwareanbindung selbst in C programmiert und habe nach extern lediglich ne API um mit PHP zu kommunizieren. Wenn ich jetzt die kompilierte C-Datei noch an die MAC-Adresse binde, kannst du nichtmal die SD-Karte in nem anderen Raspi benutzen, wenn ich das nicht will. Ich mach das zwar nicht, aber so sieht ein halbwegs effektiver Schutz aus der nicht in 2 Minuten ausgehebelt ist.