nicht angemeldet heinetz
TS
heinetz
Rolf b
Camping_RIDER
Camping_RIDER
heinetz
Camping_RIDER
heinetz
Hallo Forum,
ich stehe vor folgender Aufgabe:
unter (a)http://domain.org/form.php wird ein Formular ausgeliefert, dass nach http://domain.org/form.php?PHPSESSID=abcdefghijklmnop abgesendet wird. Nach dem Absenden werden die Formulardaten serverseitig verarbeitet und statt des Formulars ein Hinweis als Text angezeigt.
Das Formular unter (a) soll auch im Content der Seite (b)http://example.org angezeigt werden und dort genauso funktionieren.
Nun könnte ich das Formular einfach als iFrame auf der Seite (b) einbinden und es würde genauso funktionieren. Aber ich müsste mit zwei Einschränkungen bei der Darstellung leben. Erstens kann ich von (b) aus keinen Einfluss auf die Darstellung/CSS von (a) nehmen. Um den Content von (b) auf der Seite (a) vollständig und ohne Scrollbars anzuzeigen, müssten sich die Breite und oder zumindest Höhe des iFrames auf Seite (a) abhängig vom Content der Seite (b) anpassen. Beide Seiten (a) und (b) sind zwar responsiv aber ich sehe trotzdem nicht, wie das gehen sollte. Deshalb denke ich über Alternativen nach und mir ist eine eingefallen:
Könnte ich den Content von (b) nicht vor (b) aus per Ajax nachladen und dann per javascript im DOM "einbauen" und dann das in (b) eingebaute Formular mit POST per Ajax an (a) senden? Das dürfte doch prinzipiell gehen, oder?
was meint Ihr?
gruss, heinetz
Hello,
willst Du es wirklich kapern? Dann bekommst Du von mir nur ein plonk
Aber ich ahne jetzt mal, dass Du nur dasselbe Formular in mehreren Seiten verwenden willst. Welche Eigenschaften des Formulars sollen denn gleich bleiben?
Ich bitte, wie immer in solchen Fällen, um eine Grafik!
Liebe Grüße
Tom S.
Hallo,
danke erstmal, dass Du auf meinen Beitrag geantwortet hast.
Ziel ist, wie beschrieben, das Formular, dass unter (a) ausgeliefert wird mit sämtlichen Funktionalitäten auch auf einer Seite unter (b) anzuzeigen. Sämtliches HTML mit sämtlichen Formularfelder und allen Attribute sollen gleich bleiben. Ich möchte dass das Formular an nach (a) abgeschickt, dort verarbeitet und die Response unter (b) dann wieder angezeigt wird. Beide Domains zeigen wahrscheinlich auf den selben Server und ich könnte u.U. auch serverseitig von 8b) auf (a) zugreifen aber ich möchte wissen, ob ich das browserseitig lösen kann und meine Idee funktioniert. Ich habe ja in meinem Betreff ganz bewusst "kapern" geschrieben, weil es mir irgendwie unseriös vorkommt. Aber da ich ja selbst nur den Wunsch meines Kunden erfüllen möchte, de sowohl (a) als auch (b) verwaltet und meine kriminelle Energie gerade nicht reich, um mir Schindluder vorzustellen, dass man damit treiben kann, frage ich Euch. Abgesehen davon geh ich davon aus, dass das nicht funktionieren würde, wenn es nicht funktionieren darf. Mein Ziel ist lediglich, das Formular so in eine Seite unter (b) einzubinden, dass ich es per CSS so anpassen kann, dass es vernünftig aussieht.
Bilder unter:
http://temp.herrhein.com/form/input.jpg und http://temp.herrhein.com/form/response.jpg
gruss, heinetz
Wenn die Domains unterschiedlich sind, liegt XSS vor und das musst Du explizit ermöglichen. Das ist machbar, wenn Sender und Empfänger mitspielen. Dazu gibt es das CORS Konzept (Cross Origin Resource Sharing), eine Einführung findest Du hier. Ich selbst habe es noch nicht gemacht, ich wusste nur, dass es da etwas gab.
Auf diese Weise könntest Du per Ajax in der Domain B das Formular aus Domain A holen. Der Postback nach Domain A setzt zumindest mal voraus, dass das Form im nachgeladenen HTML eine absolute Adresse in der Action verwendet. Allerdings hast Du nun einen Post von Domain B zur Domain A, der nicht mehr per Ajax erfolgt sondern direkt vom Browser ausgelöst wird; ich weiß nicht, in wie weit das von CORS abgedeckt wird. Lies Dich in der MDN mal ein - hier im Self-HTML Wiki scheint mir das Thema etwas dünn behandelt (oder ich war zu dumm zum suchen).
Rolf
Aloha ;)
willst Du es wirklich kapern? Dann bekommst Du von mir nur ein plonk
Hacking ist nicht wie Voodoo oder schwarze Magie, wo man grundsätzlich die Techniken und Rituale geheimhalten sollte, um die Verbreitung zu stoppen.
Dem Hacking wirkt man am Besten durch gezielte Sicherheitskonzepte entgegen, deshalb ist es gut und wichtig, sich mit Hacking auszukennen, da man nur, wenn man genau weiß, wie Attacken funktionieren, sich solcher auch sinnvoll erwehren kann beziehungsweise Gegenmaßnahmen entwickeln kann.
Ich halte es also für sinnvoll, Hacking-Tipps auszutauschen, wenn man über welche verfügt, anstatt mit solchen hinterm Berg zu halten, weil man den Missbrauch befürchtet. Mangelndes Wissen über Hacking spielt letztendlich wieder den bösen Hackern in die Hände.
Ich weiß, dass war sehr offtopic, aber ich musste das jetzt mal anmerken, weil es nicht das erste Mal ist, dass auf Hacking in der Manier angespielt wird.
Grüße,
RIDER
Aloha ;)
Könnte ich den Content von (b) nicht vor (b) aus per Ajax nachladen und dann per javascript im DOM "einbauen" und dann das in (b) eingebaute Formular mit POST per Ajax an (a) senden? Das dürfte doch prinzipiell gehen, oder?
Da domain.org nicht der selbe Origin ist wie example.org darfst du aufgrund der same-origin-policy nicht mit einem Skript, das im Kontext example.org läuft auf Inhalte der Domain domain.org zugreifen.
Ganz so einfach wirst du das, was du willst, also nicht bekommen. Es gibt aber dennoch Möglichkeiten:
#Möglichkeit 1: CORS verwenden#
Wenn du auf beide Domains vollen Zugriff hast, kannst du auf domain.org (a) einen entsprechenden Header mitschicken, der Zugriffe aus dem Kontext von example.org explizit erlaubt.
#Möglichkeit 2: Über den eigenen Server umleiten#
Disclaimer: Ich habs nicht getestet, das ging mir nur die Tage durch den Kopf, als wir schonmal über SOP diskutiert hatten. Möglich, dass irgendwo noch ein - möglicherweise entscheidender - Denkfehler steckt.
Jedenfalls meine Idee: Während der Browser / JS durch die Same-Origin-Policy beschränkt wird, trifft das auf deinen Server (unter example.org (b)) nicht zu. Du solltest also in der Lage sein, ein php-Skript auf example.org aufzusetzen, das nichts anderes tut, als einen http-Request zum Server unter domain.org zu schicken, das Formular dadurch entsprechend abzurufen, und wieder genau so wie erhalten auszugeben. Dann kannst du bequem deinen AJAX-Request an den eigenen Server schicken, kriegst also kein Problem wegen SOP, während das Abrufen des Formulars dann über die beiden Server in direkter Kommunikation abgewickelt wird. Du erhältst natürlich ein wenig Overhead, weil eine Verbindung mehr "unterwegs" notwendig ist, und du solltest sicherstellen, dass dein php-Skript ausreichend geschützt ist[1].
Natürlich kann das durch den Domaininhaber von (a) schon auch blockiert sein / werden, aber es kann genauso gut auch wirklich so abrufbar sein.
...hast du ja genau das was du wolltest, nämlich eine Adresse, an die du einen AJAX-Request richten kannst, der dann entsprechend den Inhalt der Webseite unter (a) zurückliefert und aus dem man für die Verwendung auf (b) den benötigten Teil ums Formular herum extrahieren kann.
Grüße,
RIDER
Es ist vielleicht bequem, aber nicht in deinem Sinn, dadurch beliebige HTTP-Requests absetzen zu lassen; du solltest zur Sicherheit die Adresse entsprechend hardcoden und Maßnahmen gegen den Zugriff von außerhalb deiner Domain treffen, damit du nicht Berge von traffic von Dritt-Nutzern bekommst. ↩︎
Alles klar. Die Same Origin Policy lässt es nicht zu, dass ich per xhttprequest von (b) auf (a) zugreife.
Richtig verstanden?
Nun gibt es eine Möglichkeit, diese grundsätzliche Beschränkung aufzuheben und den Zugriff explizit zu erlauben. Die heisst CORS und funktioniert so dass im Header von (a) die Info mitgeliefert wird, dass es (b) erlaubt ist, auf (a) zuzugreifen.
Richtig verstanden?
Ich habe mich nicht weiter damit auseinandergesetzt, wie das funktioniert, weil meine Frage grundsätzlich beantwortet ist. Ich kann das Formular von (a) im Content von (b) nur in einem iFrame anzeigen. Um das was ich vorhabe zu realisieren, muss (a) immer irgendwie angepasst werden.
Und da ich selbst (a) nicht anpassen kann, sollte diese Anpassung mit so wenig Aufwand wie möglich vorzunehmen sein. Wenn (a) und (b) auf der selben Maschine laufen, dürfte es ja mit relativ wenig Aufwand möglich sein, das Formular nicht nur über (a) sondern auch über (b) auszuliefern. Dann dürfte ich den Content ja relativ einfach per Ajax abholen und per JS in meine Seite einbauen können um es dann genauso per Ajax zu verschicken, die Response auszuwerten dann genauso per JS in meine Seite einzubauen.
Oder?
gruss, heinetz
Aloha ;)
Alles klar. Die Same Origin Policy lässt es nicht zu, dass ich per xhttprequest von (b) auf (a) zugreife.
Richtig.
Nun gibt es eine Möglichkeit, diese grundsätzliche Beschränkung aufzuheben und den Zugriff explizit zu erlauben. Die heisst CORS und funktioniert so dass im Header von (a) die Info mitgeliefert wird, dass es (b) erlaubt ist, auf (a) zuzugreifen.
Auch richtig.
Ich kann das Formular von (a) im Content von (b) nur in einem iFrame anzeigen. Um das was ich vorhabe zu realisieren, muss (a) immer irgendwie angepasst werden.
Nein. Ich würde an deiner Stelle dann mal Möglichkeit 2 ausprobieren - ein PHP-Skript auf (b), dessen Inhalt sowas ist wie
Julius<?php echo file_get_contents("http://domain.org/form.php"); ?>
(vielleicht etwas weniger minimalistisch, aber für einen ersten Test sollte das reichen) und dann kannst du an dieses PHP-Skript auf (b) einen XMLHttpRequest absetzen, der dir im günstigsten Fall das zurückgibt, was du brauchst - nämlich das HTML-Dokument unter http://domain.org/form.php, welches du dann mittels Javascript (oder schon in deinem PHP-Skript vor dem echo, wie du willst - das hätte den Vorteil von weniger Traffic) auf das benötigte Formular zusammenschnippelst, welches du dann am Ort deiner Wahl mit innerHTML einhängen kannst.
Keine Garantie, dass es funktioniert (es gibt Umstände und Einstellungen im Bereich sowohl von (a) als auch von (b), die das verhindern könnten), aber einen Versuch ist es wert, denke ich. Zumal ein einfacher Test sehr zügig geht. Wenn du etwas mächtigeres als file_get_contents brauchst / willst (z.B. um nicht nur den Dateiinhalt, sondern auch die Header mit zu verwursten) kannst du cURL verwenden.
Und da ich selbst (a) nicht anpassen kann, sollte diese Anpassung mit so wenig Aufwand wie möglich vorzunehmen sein.
Auch CORS ist nicht viel Aufwand; das ist ein Eintrag in einer htaccess-Datei im Zweifelsfall. Geht aber eben nur, wenn du Zugriff auf (a) hast oder dir das jemand, der Zugriff auf (a) hat, einträgt.
Wenn (a) und (b) auf der selben Maschine laufen, dürfte es ja mit relativ wenig Aufwand möglich sein, das Formular nicht nur über (a) sondern auch über (b) auszuliefern. Dann dürfte ich den Content ja relativ einfach per Ajax abholen und per JS in meine Seite einbauen können um es dann genauso per Ajax zu verschicken, die Response auszuwerten dann genauso per JS in meine Seite einzubauen.
Auch richtig.
Grüße,
RIDER
Nein. Ich würde an deiner Stelle dann mal Möglichkeit 2 ausprobieren - ein PHP-Skript auf (b), dessen Inhalt sowas ist wie
<?php echo file_get_contents("http://domain.org/form.php"); ?>
(vielleicht etwas weniger minimalistisch, aber für einen ersten Test sollte das reichen)
Ich hab's eben erfolgreich gestestet und so wird jetzt unter (b) der selbe Content ausgegeben, wie unter (a). Aber natürlich funktioniert die Verarbeitung der Daten so noch nicht und ich hab's nun mal auf eigene Faust probiert:
<?php
//Formulardaten verarbeiten
if ($_SERVER['REQUEST_METHOD'] === 'POST') {
//entspricht dem Wert in form-action
$url = 'http://domain.org/form.php?PHPSESSID='.$_GET['PHPSESSID'];
$data = $_POST;
// use key 'http' even if you send the request to https://...
$options = array(
'http' => array(
'header' => "Content-type: application/x-www-form-urlencoded\r\n",
'method' => 'POST',
'content' => http_build_query($data)
)
);
$context = stream_context_create($options);
$result = file_get_contents($url, false, $context);
if ($result === FALSE) { /* Handle error */ }
echo($result);
exit;
}
else {
//Formular ausgeben
header("content-type: text/html; charset=iso-8859-1");
$form = file_get_contents("https://domain.org/form.php");
//form-action-Attribut im HTML-Quelltext abändern
$form = str_replace("://domain.org/", "//example.org", $form );
echo $form;
}
?>
Was habe ich gemacht?
Nachdem die "minimalistische" Version funktionierte, habe ich als erstes dafür gesorgt, dass das Formular nicht an (a) sondern an (b) abgeschickt wird und versucht, dort die Daten aus POST serverseitig an (a) zu schicken. (a) liefert auch etwas zurück aber nicht die Bestätigungsseite. D.h. die Daten werden nicht verarbeitet bzw. nicht für valide erklärt. Aber zu klären warum, erscheint mir sehr knifflig.
Die erste Frage ist vielleicht, ob mein Code richtig aussieht.
gruss, heinetz
gruss, heinetz
Aloha ;)
Ich würde an deiner Stelle dann mal Möglichkeit 2 ausprobieren - ein PHP-Skript auf (b), dessen Inhalt sowas ist wie
<?php echo file_get_contents("http://domain.org/form.php"); ?>
(vielleicht etwas weniger minimalistisch, aber für einen ersten Test sollte das reichen)
Ich hab's eben erfolgreich gestestet und so wird jetzt unter (b) der selbe Content ausgegeben, wie unter (a).
Schön zu sehen, dass meine Idee funktioniert. So weit, so gut.
Nachdem die "minimalistische" Version funktionierte, habe ich als erstes dafür gesorgt, dass das Formular nicht an (a) sondern an (b) abgeschickt wird und versucht, dort die Daten aus POST serverseitig an (a) zu schicken. (a) liefert auch etwas zurück aber nicht die Bestätigungsseite. D.h. die Daten werden nicht verarbeitet bzw. nicht für valide erklärt. Aber zu klären warum, erscheint mir sehr knifflig.
Das ist mir nicht klar. Warum versuchst du, das Formular beim Senden über deinen Server zu schicken? Das Abrufen des Formulars via JavaScript wird zwar durch die SOP verhindert, die SOP greift aber nur spezifisch bei Skriptzugriffen aller Art. Das Senden eines Formulars wird dadurch nicht beeinträchtigt. Es gibt also keinen Grund, beim Senden über den Server zu gehen - du kannst ganz einfach das Formular so nehmen wie es ist und entsprechend an die ursprüngliche Adresse senden lassen.
Sollte das nicht funktionieren, d.h. sollten die Daten auf diese Art nicht vom Server unter (a) akzeptiert werden, dann deshalb, weil der Server unter (a) noch zusätzliche Schutzmechanismen implementiert hat, z.B. um sich gegen CSRF zu schützen, beispielsweise durch Prüfung des Referrer oder ähnliches.
In diesem Fall bist du machtlos, da kann dir auch dein Server nicht helfen - wenn der Server unter (a) alle Daten ablehnt, die nicht von einer Seite aus dem Angebot von (a) kommt, dann lehnt er sowohl die Daten ab, die ein Client von einer Seite aus dem Angebot von (b) abschickt, als auch die Daten, die der Server (b) abschickt.
Bisher ging es darum, die Same Origin Policy von Javascript zu umgehen - soweit so gut. Das ist kein großes Problem, sondern lediglich eine bewusste Einschränkung einer Technologie, die man umgehen kann. Wenn nun aber Sicherheitsmechanismen greifen, die von (a) extra eingesetzt werden, um so etwas, wie du es vorhast, zu verhindern, tätest du gut daran, die Sache ruhen zu lassen - die Betreiber von (a) wissen schon, warum sie einen solchen Sicherheitsmechanismus einsetzen, und das aktive Umgehen eines solchen Sicherheitsmechanismus ist nicht Sinn der Sache.
Wenn dein Anliegen gerechtfertigt ist haben die Betreiber von (a) sicher Verständnis und öffnen dir ein Türchen in ihrem Sicherheitsmechanismus - oder erklären dir, warum sie das nicht wollen. Wenn dein Anlegen nicht legitim ist, müssen wir nicht mehr weiter darüber diskutieren.
Grüße,
RIDER
Das ist mir nicht klar. Warum versuchst du, das Formular beim Senden über deinen Server zu schicken? Das Abrufen des Formulars via JavaScript wird zwar durch die SOP verhindert, die SOP greift aber nur spezifisch bei Skriptzugriffen aller Art. Das Senden eines Formulars wird dadurch nicht beeinträchtigt. Es gibt also keinen Grund, beim Senden über den Server zu gehen - du kannst ganz einfach das Formular so nehmen wie es ist und entsprechend an die ursprüngliche Adresse senden lassen.
Weil ich ja die gesamte Funktionalität des Formulars von (a) auf meiner Seite (b) abbilden will. Wenn ich das Formular zwar im Content der Seite (a) integrieren kann, es dann aber durch die form action nach (b) abgeschickt wird, verlässt der User beim Abschicken die Seite (b) und die Response wird ihm unter (a) angezeigt. Ich wollte aber die gesamte Interaktion auf der Seite (b) abbilden. D.h. dass sowohl das Formular als auch der Content, der von (a) nach dem Abschicken dessen zurückgeliefert wird im Content von (b) integriert werden.
gruss, heinetz
Aloha ;)
Weil ich ja die gesamte Funktionalität des Formulars von (a) auf meiner Seite (b) abbilden will. Wenn ich das Formular zwar im Content der Seite (a) integrieren kann, es dann aber durch die form action nach (b) abgeschickt wird, verlässt der User beim Abschicken die Seite (b) und die Response wird ihm unter (a) angezeigt. Ich wollte aber die gesamte Interaktion auf der Seite (b) abbilden. D.h. dass sowohl das Formular als auch der Content, der von (a) nach dem Abschicken dessen zurückgeliefert wird im Content von (b) integriert werden.
Ah, richtig. Stimmt, das ist mir durcheinandergegangen. Mea culpa. Dann ist dein Ansatz gar nicht so falsch.
Grüße,
RIDER
Aloha ;)
Die erste Frage ist vielleicht, ob mein Code richtig aussieht.
Nachdem meine ersten Unklarheiten geklärt sind: Ja, sieht richtig aus.
Einen Fehler sehe ich so auf die schnelle nicht.
Hast du überprüft, ob in deinem Skript alle Werte richtig gesetzt sind?
Also insbesondere einmal $_POST und einmal $_GET['PHPSESSID'] ausgegeben lassen? Überprüft, ob du die PHPSESSID aus dem Original-Dokument richtig herausziehst?
Erst weiterlesen, wenn das keine Ergebnisse gebracht hat.
In der Theorie könnte ich mir vorstellen, dass es an der Session scheitert - im Gegensatz zu dem Fall, dass dein Browser das Formular abruft, bekommt hier dein Server unter (b) die Session beim Server unter (a) zugewiesen. Das könnte entweder unerwünschte Konsequenzen haben (ein Benutzer öffnet eine Session auf (a) via (b) und alle anderen Benutzer des Systems unter (b) benutzen die Session mit) oder für dein Problem verantwortlich sein (die Session bei (a) wird von (b) sofort nach Anfordern des Dokuments verworfen, so dass sie dann aber für ein Auswerten des Formulars schon nicht mehr zur Verfügung steht).
Leider bin ich mit Sessions nicht 100% firm, vor allem dann nicht, wenn ein Server mit PHP auf der Clientseite steht.
Wenn die Session das Problem ist müsstest du das irgendwie hinbekommen, dass die Session vom Abrufen des Dokuments durch deinen Server gehalten wird und entsprechend für den Request, der die Daten sendet, wieder aufgenommen wird. Ob die Angabe von PHPSESSID als GET-Parameter dafür eigentlich schon ausreichen müsste oder nicht vermag ich aus dem Stegreif nicht zu sagen.
Grüße,
RIDER
Hallo Camping_RIDER, @heinetz
Leider bin ich mit Sessions nicht 100% firm, vor allem dann nicht, wenn ein Server mit PHP auf der Clientseite steht.
Man muss sich die Session-ID „merken“ und dann später wieder mitsenden. Auslesen des HTTP-Headers:
$content=file_get_contents('https://google.com');
print_r($http_response_header);
... ergibt u. a.:
[16] => Set-Cookie: NID=98=Tv6c1wAK4LlKiRlk5M9zv8NHvG1lURRegy18LKdCKfc3SwIwqUKgimerYjGKjxP4yqOdCWrREt808EY-yS2YciLG353Wa-57ESrTxgFm91l5-Rj77oePOhFES5iFhnLK; expires=Thu, 31-Aug-2017 05:16:34 GMT; path=/; domain=.google.de; HttpOnly
Das Cookie müsste man dann nur noch auslesen und wieder senden, das sollte mittels eines Stream-Kontexts gelingen.
Wenn die Session das Problem ist müsstest du das irgendwie hinbekommen, dass die Session vom Abrufen des Dokuments durch deinen Server gehalten wird und entsprechend für den Request, der die Daten sendet, wieder aufgenommen wird.
Das Cookie kann man entweder an den Nutzer „durchreichen“ oder wiederum in einer Session (auf Server 1) speichern:
Nutzer ↔ Server 1 ↔ Server 2 (Ursprungsserver des Formulars)
SID=123 SID=456
Ob die Angabe von
PHPSESSIDals GET-Parameter dafür eigentlich schon ausreichen müsste oder nicht vermag ich aus dem Stegreif nicht zu sagen.
Das ist Einstellungssache, Cookies sind gegenüber der Übermittlung als URL-Parameter zu bevorzugen – ich denke nicht, dass der Server die SID via URL entgegennimmt, wenn er auf Cookies konfiguriert wurde.
Gruß
Julius
Hello,
Man muss sich die Session-ID „merken“ und dann später wieder mitsenden. Auslesen des HTTP-Headers:
$content=file_get_contents('https://google.com'); print_r($http_response_header);... ergibt u. a.:
[16] => Set-Cookie: NID=98=Tv6c1wAK4LlKiRlk5M9zv8NHvG1lURRegy18LKdCKfc3SwIwqUKgimerYjGKjxP4yqOdCWrREt808EY-yS2YciLG353Wa-57ESrTxgFm91l5-Rj77oePOhFES5iFhnLK; expires=Thu, 31-Aug-2017 05:16:34 GMT; path=/; domain=.google.de; HttpOnlyDas Cookie müsste man dann nur noch auslesen und wieder senden, das sollte mittels eines Stream-Kontexts gelingen.
oder man benutzt sowieso gleich fsockopen().
Da weiß man dann wenigstens (fast), was man tut. Nur die uintegrierte DNS-Abfrage bekommt man noch nicht einzeln angefasst. Da hängen die Module dann manchmal noch, wenn der DNSd keine Antwort schickt.
Liebe Grüße
Tom S.