Übertragung von Daten nur wenn Anfrage von einem bestimmten Server stammt


EnesE

Grünschnabel
Hallo Community,

ich habe eine Frage, wozu ich bisher keine Lösung gefunden habe.

Ich möchte gern ein Script schreiben, womit ich Daten zwischen zwei Servern austauschen kann, wenn die Anfrage von einem Server mit einer bestimmte IP-Adresse bzw eine bestimmten URL stammt.

Hier ein simples Beispiel:
(Ich benutze jetzt absichtlich sehr simple Daten zur Übertragung)

Ein Nutzer besucht die Seite "example.com/date"
Hinter "example.com/date" steckt ein PHP-Script, was mit "cURL" oder "file_get_contents()" eine Anfrage an "meinServer.de/data/datum" sendet.
"meinServer.de/data/datum" ist ebenfalls ein PHP-Script, was die Anfrage verarbeiten soll und prüfen soll, ob die Anfrage von "example.com" (oder wenn es geht inkl. Pfad also "example.com/date") stammt.
Stammt die Anfrage von "example.com/date" soll eine Ausgabe zurück gesendet werden.
Stammt die Anfrage von "badserver.net" soll stattdessen eine 404 oder sonst was ausgegeben werden.

Wie kann ich bei der Überprüfung auf "meinServer.de" überprüfen, dass der Request tatsächlich von "example.com" stammt?
Ich möchte keine Parameter an meinServer.de senden womit die Identität überprüft wird (also keinen Lizenzschlüssel o. ä. über GET, POST, etc.).

Geht das so überhaupt?
 

EnesE

Grünschnabel
Okay, ich schätze mal $_SERVER['REMOTE_ADDR'] ist die beste Lösung um an die IP zu kommen. Schöner fände ich es, wenn man die URL auslesen könnte, da mehrere Domains auf dem selben Server meistens gehostet wird, wobei ich jedoch denke, dass dies ohne weiteres nicht möglich ist.

Um dann die entsprechende Antwort zurückzugeben müsste man dann nur noch die Remote Adresse mit einer Liste/einem Wert überprüfen:

PHP:
if($_SERVER['REMOTE_ADDR'] == "11.111.111.111) {
    echo 'whitelist';
} else {
    echo 'Fehler';
}
 

ComFreek

Mod | @comfreek
Moderator
Wie kann ich bei der Überprüfung auf "meinServer.de" überprüfen, dass der Request tatsächlich von "example.com" stammt?
Das übersetzt sich zu: Du möchtest Authentifikation.
Ich möchte keine Parameter an meinServer.de senden womit die Identität überprüft wird (also keinen Lizenzschlüssel o. ä. über GET, POST, etc.).
Das übersetzt sich zu: Du möchtest keine Daten für Authentifikation herumschicken.

Dein Vorhaben ist also grundsätzlich nicht möglich. Warum möchtest du keine zusätzlichen Daten herumschicken?

Schöner fände ich es, wenn man die URL auslesen könnte
Die URL example.com/date, die der Nutzer besucht hat, ist überhaupt kein Teil mehr der cURL-Anfrage. Das sind zwei unabhängige Dinge: Website wird versucht und PHP-Skript ausgeführt und PHP-Skript macht eine cURL-Anfrage.

Die IP-Adresse ist dann der einzige Weg, wenn du keine zusätzlichen Daten verschicken möchtest. Das ist unsicher, siehe unten.
 
Zuletzt bearbeitet:

EnesE

Grünschnabel
Dein Vorhaben ist also grundsätzlich nicht möglich. Warum möchtest du keine zusätzlichen Daten herumschicken?
Habe mich dazu entschlossen die anfragende IP-Adresse der Website/des Servers zu überprüfen, welche zB mit file_get_contents() versucht Daten von Server B zu kriegen und dafür zusätzlich einen Authentifizierungskey mit sendet. Also quasi eine 2-Fache Überprüfung.


Warum möchtest du keine zusätzlichen Daten herumschicken?
Um Missbrauch zu vermeiden, da man den Lizenzkey schließlich auslesen kann wenn man Zugriff zum Dateisystem hat bzw. den Key dann mehrfach nutzen kann
 

ComFreek

Mod | @comfreek
Moderator
Du kannst mit einem Proxy keine vorgegebene IP-Adresse abfälschen, außer es läuft gerade ein Proxy unter dieser IP-Adresse.
Man kann jedoch ein einzelnes TCP-Paket mit gefälschter IP-Adresse senden, aber dann nicht mehr empfangen. Es kommt also nie zu einem kompletten TCP-Handshake, demnach würde ich mal behaupten, dass das "sicher" ist. Das ist unsicher, siehe unten.
 
Zuletzt bearbeitet:

ComFreek

Mod | @comfreek
Moderator
@ikosaeder Ist deine Aussage, dass das Prüfen auf IP-Adresse unzureichend ist? Wenn ja, sehe ich nicht ganz, wie man das mit Umleiten einer IP Adresse aushebeln kann. Vielleicht verstehe ich Squid auch nicht ganz, aber das wirkt wie ein einfacher cachender Proxy.
 

ikosaeder

Teekannen-Agnostiker
Sorry, ich habe nicht aufgepasst. Die Lösung Proxy Ip umleiten war für eine andere Frage gedacht.
Der Proxy ermöglicht hier die Authentifizierung.
Server1 -> Server2. Wenn nur die Ip Adresse geprüft wird, dann ist das unsicher.
Server1 -> Proxy -> Server2 ist sicherer, wenn der Proxy ein Authentifizierungstoken verlangt und prüft und erst dann die Verbindung zu Server2 herstellt.
 

EnesE

Grünschnabel
Stimmt mit einem Proxy ist es selbstverständlich sicherer, aber meine Intention war es eine soweit simple aber sichere Authentifizierung durchzuführen.

Deswegen überprüfe ich nun auf Server B die IP Adresse von Server A und sende zeitgleich einen Key von Server A an B.
Server B schaut dann ob der Key und die IP zusammen passen.
 

ComFreek

Mod | @comfreek
Moderator
Ich habe mal jemand anderen gefragt, der mir einleuchtend erklärt hat, dass das alleinige Überprüfen der IP-Adresse unsicher sei.

Präzise: Wenn A eine HTTP Anfrage an B schickt und B nur mittels Sender-IP-Adresse authentifiziert, dann ist das unsicher. Denn jeder Man-in-the-Middle C zwischen dem Routing A <-> B kann einfach TCP und darin enthaltene IP-Pakete so fälschen, dass er die IP-Adresse von A angibt. Wenn nun ein TCP-Paket zurückkommt, fängt C es einfach ab, weil es auf der Route liegt.

Selbst wenn du ein pre-shared-secret bei A und B hast, so lernt C dieses Secret beim Verschicken seitens A. D.h. es funktioniert sicher höchstens einmal. (Höchstens, weil C die Verbindung unterbrechen könnte.)

Wenn A jedoch das pre-shared-secret via HTTPS-Anfrage an B schickt, so ist es verschlüsselt.
 

EnesE

Grünschnabel
Ich habe mal jemand anderen gefragt, der mir einleuchtend erklärt hat, dass das alleinige Überprüfen der IP-Adresse unsicher sei.

Präzise: Wenn A eine HTTP Anfrage an B schickt und B nur mittels Sender-IP-Adresse authentifiziert, dann ist das unsicher. Denn jeder Man-in-the-Middle C zwischen dem Routing A <-> B kann einfach TCP und darin enthaltene IP-Pakete so fälschen, dass er die IP-Adresse von A angibt. Wenn nun ein TCP-Paket zurückkommt, fängt C es einfach ab, weil es auf der Route liegt.

Selbst wenn du ein pre-shared-secret bei A und B hast, so lernt C dieses Secret beim Verschicken seitens A. D.h. es funktioniert sicher höchstens einmal. (Höchstens, weil C die Verbindung unterbrechen könnte.)

Wenn A jedoch das pre-shared-secret via HTTPS-Anfrage an B schickt, so ist es verschlüsselt.
Das stimmt, dass es unsicher ist. Es sollen ja auch nicht wer weiß was für Daten versendet werden, die zwingend geschützt werden müssen.
Ich wollte lediglich eine kleine Authentifizierung damit nicht jede x beliebige Person die Tools nutzen kann, die auf Server B liegen / verarbeitet werden. (Hätte ich auch in die Frage rein schreiben sollen. Mein Fehler)

Und ja beide Server nutzen HTTPS und genauer gesagt werden nur verschlüsselte Daten gesendet und empfangen.
Also Server A schickt verschlüsselte Anfrage an Server B.
Server B entschlüsselt die Anfrage und führt diese aus.
Server B sendet das Ergebnis verschlüsselt zurück an Server A.
Server A entschlüsselt die Daten und macht mit den Daten, was er damit vor hatte.

Ist zwar immer noch nicht 100% sicher, aber das wird es eh nie und die zusätzliche Verschlüsselung ist nur eine kleine zusätzliche Hürde.,
 

Neue Beiträge