nicht angemeldet
curl mit "falscher" IP, Antwort jedoch dennoch bekommen?
0 0 0 0 0 
Der Martin
0
0
curl mit "falscher" IP, Antwort jedoch dennoch bekommen?
robertroth
Gunnar BittersmannHallo,
folgendes Szenario:
- SERVER1 sendet curl-Request mit IP von CLIENT1 an SERVER2
- SERVER2 registriert den eingehenden Request unter der "gefälschten" IP und sendet die Antwort entsprechend zurück.
- CLIENT1 empfängt die Antwort (ggf. über einen zuvor geöffneten http-socket?)
Ist so ein Vorgehen in der Praxis möglich?
-
Tach,
- SERVER1 sendet curl-Request mit IP von CLIENT1 an SERVER2
du meinst einen HTTP-Request, also über TCP?
- SERVER2 registriert den eingehenden Request unter der "gefälschten" IP und sendet die Antwort entsprechend zurück.
- CLIENT1 empfängt die Antwort (ggf. über einen zuvor geöffneten http-socket?)
Ist so ein Vorgehen in der Praxis möglich?
Nicht bei TCP, ohne dass SERVER1 auf CLIENT1 Zugriff auf den Netzwerkstack hat und das schon um die TCP-Verbindung in Schritt 1 aufzubauen und dann kann man das auch direkt auf CLIENT1 machen; mit UDP wäre das etwas einfacher, aber immer noch nicht trivial und vermutlich nicht aus dem Userspace.
mfg
Woodfighter-
Hi
Nicht bei TCP, ohne dass SERVER1 auf CLIENT1 Zugriff auf den Netzwerkstack hat und das schon um die TCP-Verbindung in Schritt 1 aufzubauen und dann kann man das auch direkt auf CLIENT1 machen; mit UDP wäre das etwas einfacher, aber immer noch nicht trivial und vermutlich nicht aus dem Userspace.
Und angenommen, ich habe vollen Zugriff auf SERVER1 & CLIENT1?
-
Tach,
Nicht bei TCP, ohne dass SERVER1 auf CLIENT1 Zugriff auf den Netzwerkstack hat und das schon um die TCP-Verbindung in Schritt 1 aufzubauen und dann kann man das auch direkt auf CLIENT1 machen; mit UDP wäre das etwas einfacher, aber immer noch nicht trivial und vermutlich nicht aus dem Userspace.
Und angenommen, ich habe vollen Zugriff auf SERVER1 & CLIENT1?
dann ist es möglich; aber dann wäre erheblich einfacher den Request einfach vom Client aus abzusetzen. Was möchtest du denn eigentlich erreichen?
mfg
Woodfighter-
Hi,
hast du hier irgendeine Referenz, die mich ggf. in die richtige Richtung weist?
dann ist es möglich; aber dann wäre erheblich einfacher den Request einfach vom Client aus abzusetzen. Was möchtest du denn eigentlich erreichen?
SERVER2 benötigt an dieser Stelle einen HTTP-POST-Request, den ich clientseitig (Browser) nicht abschicken kann. (Auch nicht mit JS, da CrossOrigin)
Der Request muss also von SERVER1 (PHP curl) erfolgen - allerdings wird das Ergebnis (Link mit Hashtag) direkt an die IP der Anfrage gebunden. Befindet sich CLIENT1 also nicht im selben Netzwerk wie SERVER1, ist das Ergebnis für ihn unbrauchbar.
-
Hallo,
SERVER2 benötigt an dieser Stelle einen HTTP-POST-Request, den ich clientseitig (Browser) nicht abschicken kann.
warum nicht? Wer hindert dich daran?
(Auch nicht mit JS, da CrossOrigin)
Ach was. Du kannst doch jederzeit ein Formular per POST an einen Server in einer anderen Domain absenden. Entweder von Hand ausgelöst, oder sogar per JS automatisiert.
Es ist zwar richtig, dass man mit JS normalerweise keine Requests an eine fremde Domain richten kann, aber das Abschicken eines Formulars mit passender URL im action-Attribut ist trotzdem möglich. Und einfacher, als sich mit den Zehen am Ohr zu kratzen, so wie du es derzeit versuchst.
So long,
Martin-
Hi,
Ach was. Du kannst doch jederzeit ein Formular per POST an einen Server in einer anderen Domain absenden. Entweder von Hand ausgelöst, oder sogar per JS automatisiert.
CLIENT1 ist nur an besagtem Link (Mit Hashtag) interessiert & möchte nicht, das der Übrige Code (der Teil des zurückgesendeten Ergebnisses ist), ausgeführt wird. Ein POST-Formular, das bei klick (ob nun automatisiert oder nich), auf die Seite von SERVER2 leitet, ist also keine Option.
-
-
Tach,
hast du hier irgendeine Referenz, die mich ggf. in die richtige Richtung weist?
nicht wirklich, das was du vorhast, wird nicht gehen, ohne den Browser auf dem Client zu patchen und je nach Betriebssystem den Netzwerkkartentreiber/-stack ebenso; aus den Fragen, die du stellst, würde ich schließen, dass das außerhalb deiner aktuellen Fähigkeiten liegt.
dann ist es möglich; aber dann wäre erheblich einfacher den Request einfach vom Client aus abzusetzen. Was möchtest du denn eigentlich erreichen?
SERVER2 benötigt an dieser Stelle einen HTTP-POST-Request, den ich clientseitig (Browser) nicht abschicken kann. (Auch nicht mit JS, da CrossOrigin)
Der Request muss also von SERVER1 (PHP curl) erfolgen - allerdings wird das Ergebnis (Link mit Hashtag) direkt an die IP der Anfrage gebunden. Befindet sich CLIENT1 also nicht im selben Netzwerk wie SERVER1, ist das Ergebnis für ihn unbrauchbar.
hatte also schon seinen Grund, warum mir das bekannt vorkam. Wie dort schon geschrieben, ist das einzig sinnvoll mögliche, den Proxy zu spielen.
mfg
Woodfighter-
nicht wirklich, das was du vorhast, wird nicht gehen, ohne den Browser auf dem Client zu patchen und je nach Betriebssystem den Netzwerkkartentreiber/-stack ebenso; aus den Fragen, die du stellst, würde ich schließen, dass das außerhalb deiner aktuellen Fähigkeiten liegt.
Die Cross-Origin-Policy direkt im Browser zu deaktivieren & den POST-Request anschließend mittels JS abzuschicken wäre wohl die einfachste Option. Allerdings brauche ich eine Lösung die mehr "Plug & Play" ist. :)
hatte also schon seinen Grund, warum mir das bekannt vorkam. Wie dort schon geschrieben, ist das einzig sinnvoll mögliche, den Proxy zu spielen.
Aktuell tue ich genau das.. allerdings verfüge ich nicht über unbegrenzte Bandbreite. Gibt es wirklich keine andere Option?
-
Tach,
Die Cross-Origin-Policy direkt im Browser zu deaktivieren & den POST-Request anschließend mittels JS abzuschicken wäre wohl die einfachste Option. Allerdings brauche ich eine Lösung die mehr "Plug & Play" ist. :)
ich habe ein Firefox-Addon gefunden, dass CORS deaktivert und das ich jetzt nicht verlinke, weil es eine dämliche Idee wäre, das zu installieren; der Name ist cors-everywhere.
hatte also schon seinen Grund, warum mir das bekannt vorkam. Wie dort schon geschrieben, ist das einzig sinnvoll mögliche, den Proxy zu spielen.
Aktuell tue ich genau das.. allerdings verfüge ich nicht über unbegrenzte Bandbreite. Gibt es wirklich keine andere Option?
Du könntest aufdringliche Werbung installieren, um den Traffic zu finanzieren, so wie die Seite, die du zu umgehen versuchst.
mfg
Woodfighter -
Moin!
Gibt es wirklich keine andere Option?
Ja. Doch. Sprich mit den Anbieter, ob er Dir eine geeignetere Schnittstelle zur Verfügung stellt. Für mich sieht das nämlich so aus, als wölltest Du etwas haben, was ein Dritter jedenfalls in der Form nicht rausgeben will - z.B. um sich selbst davor zu schützen, dass Dritte seine Daten "abgreifen" und in aufbereiteter Form für eigene Projekte nutzen, gar weiterverkaufen.
Wenn Du dem Anbieter einen Nutzen bieten kannst, dann könnte es für ihn denkbar sein, Dir eine Schnittstelle anzubieten. Und womöglich ist das auch billiger als wenn Du versuchts ihm hinterherzuentwickeln, denn wenn er was ändert, dann musst Du das auch. Folge: geradezu regelmäßig tagelanger Ausfall Deines Angebotes und hohe Kosten (das gilt auch dann, wenn Du Deine Arbeitszeit nicht mit Geld bezahlst).
Jörg Reinholz
-
-
-
-
-
-
Moin!
Ist so ein Vorgehen in der Praxis möglich?
Ja. Das heisst, je nach dem ob es von allen Seiten erwünscht oder erwartet wird, "Proxy" oder "Man in the middle-Attacke".
Jörg Reinholz
-
Liebe Mitdenker, liebe Wissende, liebe Neugierige,
Ist so ein Vorgehen in der Praxis möglich?
Ja. Das heisst, je nach dem ob es von allen Seiten erwünscht oder erwartet wird, "Proxy" oder "Man in the middle-Attacke".
Man-in-the-middle und Proxy gehen anders, als der OP das gefragt hat. Da würde der Request von dem Gerät ausgehen, wohin auch die Antwort kommt.
Er will einen Request absetzen von einem anderen Client, als die Antwort nacher landet. Das wäre dann aber für den Zielclient ein Push, weil ja auf dessen Netzwerkstack keine offene Anfrage mehr wartet und deshalb auch der Port nicht offen sein muss.
Spirituelle Grüße
Euer Robert
robert.r@online.de--
Möge der wahre Forumsgeist ewig leben!-
Liebe Mitdenker, liebe Wissende, liebe Neugierige,
was der OP hier beschreibt, nennt sich "IP-Spoofing".
https://de.m.wikipedia.org/wiki/IP-SpoofingAber das wird per TCP/IP aus den von Jens erwähnten Gründen nicht klappen.
Da würde der Angreifer schon Hilfe von innen bebötigen.Spirituelle Grüße
Euer Robert
robert.r@online.de--
Möge der wahre Forumsgeist ewig leben!
-
-