Script auf entfernten Server absichern

[Forumsgast]

Hallo,

Ich habe ein PHP-Script inkl. HTML-Formular an einem Server A laufen, welches per iframe an einem entfernten Server B eingebunden ist.
Wie ist es möglich, dass das iframe nur über den Server B erreichbar ist, und nicht durch den absoluten Link im "src" des iframes, sollte man da draufklicken?

[Gast]

Das ist eigentlich gar nicht sicher möglich.. Man könnte vielleicht den Referer nehmen (nicht zuverlässig) oder vielleicht das Ganze über ein Token steuern (umständlich und unsicher).

Besser wäre es, Du würdest das Skript von Server B serverseitig von Server A holen lassen - Dann kannst Du auch beliebige Authentifizierungs-Mechanismen benutzen.

[Forumsgast]

Das iframe ist innerhalb eines Login-Systems eingebettet, nur genügt der Einblick in den Browserquellcode um einen direkten Aufruf des Scripts zu starten, weshalb ich das insofern unterbinden möchte, dass der Aufruf nur unter Server B möglich ist.

Edit: Auf Server B - wo das Ergebnis dargestellt werden soll ist kein PHP-Interpreter aktiv.

Welche Möglichkeit/en gibt es da?

[Forumsgast]

Du könntest src vom iframe per javascript verschleiern (aber auch nicht 100% sicher). Im html als src eine belanglose Seite angeben, dann per javascript deine echte URL zusammenbauen (so, daß er im Code nicht gleich sichtbar ist) und dem src zuweisen.

[Forumsgast]

Und wenn jemand Javascript deaktivieren sollte?

[Forumsgast]

Ist meines Erachtens in der Konstellation nicht trivial möglich.

Referrer und jegliche Header-Daten können manipuliert sein. Du kannst auch kein Secret verwenden, weil der Quellcode von A einsehbar ist und damit jegliche Verschlüsselung hinfällig ist. Das könnte man durch unregelmäßig wechselnde Schlüssel (auf beiden Seiten) unterbinden, aber auf Server A darf ja kein PHP laufen.

Darf man dort denn etwas anderes laufen lassen? Vielleicht batch/shell oder so? Dann kannst du eine asynchron verschlüsselte Nachricht als Pseudo-Authentifizierung mit in den Header mitgeben. Darin am besten dann noch deine synchron verschlüsselte Prüfsumme des Referers, der IP und sonstigen Späßen.

Der andere Server kann das dann alles auf Richtigkeit prüfen und liefert entweder den gewünschten Inhalt oder eben ein 401/403. Ist aber alles noch sehr wackelig, muss enorm gut dokumentiert werden und ist, wie gesagt, keine einfache Aufgabe.

[Forumsgast]

Auf dem Server B (wo kein PHP aktiv ist) kann batch ausgeführt werden - ist eine Linux-Kiste.
Vielleicht kannst du die Idee etwas näherbringen, weil trivial hört sich das keinenfalls an

Zumal, inwiefern hindert das den "src" - also den absoluten Link zum PHP-Script/Formular direkt aufzurufen.

[Forumsgast]

Hier ist von 2 unterschiedlichen Varianten die Rede. Mal stark vereinfacht:
1. Du schaust auf Server A nach, woher die Anfrage kommt. Wenn die nicht vom Server B kommt, wird einfach nichts gemacht oder eine Fehlerseite geliefert. Da die Header-Daten der Anfrage manipuliert sein können, ist dies nicht sicher.
2. Die javascript-Variante auf Server B verschleiert die src-Information nur in der Art, daß die nicht sofort im Browserquellcode sichtbar ist. Wer die echte URL kennt, kommt immer drauf.

[Forumsgast]

Bei Methode 1 stellt sich mir die Frage, werden von Server B überhaupt irgendwelche Header-Informationen mit aufgenommen (außer die HTTP-Informationen des Clients), wenn das Script, welches auf Server A liegt, bei Server B als iframe eingebunden ist?

[Forumsgast]

Hm... als ich ugf. bei der Hälfte meine Antwort war, hab ich festgestellt, dass das auch nicht möglich ist... Sorry.

Die Konstellation ist denkbar ungünstig um da irgendeine Form der verlässlichen Security reinzubringen...

Selbst wenn du Header-Daten vergleichst, kann man nicht davon ausgehen, dass der Request wirklich von Server A stammt. HTTP-Header kann man beliebig editieren. Du müsstest schon auf den IP-Stack runter, was mit PHP meines Wissens nicht geht.

Egal wie ich es drehe und wende, ohne PHP auf Server A sehe ich schwarz. Und noch besser wäre eine Verbindung zwischen Server A und B - In Form einer Datenbank o.ä., also einem zweiten Kanal.

[Forumsgast]

Mit einer Bash-Lösung lässt sich da deiner Meinung nach auch nichts bewerkstelligen? - was meintest du mit "runter auf den IP-Stack"?

[Forumsgast]

btw: Ich hab hier was gefunden, da hat jemand aus Spaß und der Freud einen kleinen TCP/IP-Stack in PHP geschrieben^^

http://developers.slashdot.org/artic...id=126&tid=169

[Forumsgast]

Die Überlegung war, die IP im echten Netzwerkpaket zu überprüfen, ob die von dem Server kommt, von dem du sie erwartest... Funktioniert aber im Nachhinein auch nicht, weil ja Proxys etc. dazwischen liegen könnten, die dir die IPs versauen.

[Forumsgast]

Nunja, beim Webserver ist meist nur eine feste IP-Adresse erreichbar - und so wie ich das verstehe würde das bedeuten, wenn die IP nicht vom Server B ist dann gibt nix aus. Oder verstehe ich das falsch? - weil sogar, wenn der Proxy eine andere IP ausgibt dürfte nix passieren. Das einzige was natürlich auftreten kann, dass ein zwischengeschalter Proxy die IP vom Server B annimmt und die Ausgabe dennoch erfolgen kann.

Gibt es da weitere Parameter, die man beachten kann um eventuell doch eine Lösung zu finden?

[Forumsgast]

Nicht dass ich wüsste - Du kannst dir dieses Framework ja mal anschauen. Wenn du da eine Möglichkeit hast, auf das Source Address Feld zuzugreifen, könntest du das damit reißen. Das muss dann halt identsch zu dem Server sein, den du erwartest.

Probleme gibts nur dann, wenn du einen richtig findigen Hacker hast, der dieses Feld ebenfalls beeinflusst - allerdings bringts ihm auch nichts, weil er die Antwort dann ja nicht kriegt. Dann würde eigentlich nur noch Man in the Middle bleiben, wogegen dich dann wiederrum nur PKI, SSL etc. schützen kann.