nicht angemeldet
POST auf einen fremden Server?
Hallo Forum,
ist es eigentlich möglich, ein Posting auf einen fremden Server durchzuführen?
<form action="http://fremdeDomain/datei.php" ... method="post">
Wenn nein, durch welchen Mechanismus wird das verhindert?
Das ganze im Get-String müsste doch aber gehen, oder?
Gruß
Tom
-
Hi,
ist es eigentlich möglich, ein Posting auf einen fremden Server durchzuführen?
<form action="http://fremdeDomain/datei.php" ... method="post">
hast du's schon probiert?
LG Orlando
--
SELF-TREFFEN 2002
http://www.rtbg.de/selftreffen/
http://www.megpalffy.org/temp/penneninhh.html-
Hi Orlando,
hast du's schon probiert?
ja klar. Wir haben hier ja genug Server rumstehen. Aber die Vielfalt der Möglichkeiten ist einfach zu groß.
Ein lokal gespeichertes HTML-Formular wird scheints gar nicht erst abgeschickt. Unterbindet das der Browser?
Gruß
Tom
-
Hi,
hast du's schon probiert?
ja klar. Wir haben hier ja genug Server rumstehen. Aber die Vielfalt der Möglichkeiten ist einfach zu groß.na sicher ist sie das, und das heißt: Es gibt immer Fälle, in denen es nicht geht. Bei dem pauschalen Charakter Deiner Frage reicht jedoch _ein_ erfolgreicher Test, um sie zu bejahen.
Ein lokal gespeichertes HTML-Formular wird scheints gar nicht erst abgeschickt. Unterbindet das der Browser?
Vielleicht der Browser, vielleicht ein defekter HTML-Code, vielleicht aber auch die Erdstrahlung. Möglicherweise auch die serverseitige Programmlogik.
Cheatah
-
Hi Cheatah,
hast du's schon probiert?
ja klar. Wir haben hier ja genug Server rumstehen. Aber die Vielfalt der Möglichkeiten ist einfach zu groß.na sicher ist sie das, und das heißt: Es gibt immer Fälle, in denen es nicht geht. Bei dem pauschalen Charakter Deiner Frage reicht jedoch _ein_ erfolgreicher Test, um sie zu bejahen.
Ein lokal gespeichertes HTML-Formular wird scheints gar nicht erst abgeschickt. Unterbindet das der Browser?
Vielleicht der Browser, vielleicht ein defekter HTML-Code, vielleicht aber auch die Erdstrahlung. Möglicherweise auch die serverseitige Programmlogik.
Ich wußte gar nicht, dass Du ein Spezialist für übersinnliche Phänomene bist. Danke jedenfalls für Deine Tipps. Ich werde sofort den Versuchsaufbau ändern.
Muss ich die Ersstrahlen jetzt unterbinden oder verstärken? Funktioniert das nun nicht, weil zu wenig oder zuviele Erdstrahlen da sind?
Wenn Du mir da noch mal helfen könntest...
Grüßle
Tom
-
Hi,
Ich wußte gar nicht, dass Du ein Spezialist für übersinnliche Phänomene bist.
erst ab dem Großen PSI-Ereignis im Mai 2014.
Muss ich die Ersstrahlen jetzt unterbinden oder verstärken? Funktioniert das nun nicht, weil zu wenig oder zuviele Erdstrahlen da sind?
Was ich Dir mit meiner Antwort sagen wollte ist, dass Du keinerlei Informationen lieferst, die eine genauere Antwort ermöglichen. Schon die Fehlerbeschreibung fehlt, von dem was Du eigentlich gemacht hast ganz zu schweigen, Du sagst nicht mal, _welchen_ Browser Du eigentlich benutzt, erwähnst nichts über eventuelle Proxies oder Firewalls, sagst nichts über das fremde Script, ob es eventuell clientspezifische Prüfungen vornimmt oder oder oder. Drum kann man nur im Ausredenkalender blättern.
Cheatah
-
Aua, nun sag doch nicht gleich krummer Hund zu mir!
Ich habe das mit zwei Apache-Servern im Intranet ausprobiert. Beide laufen auf Linux 7.2 und haben php4 als Modul.
Der Client ist ein stinknormaler Win98-PC mit M$IE 5.5
Es handelt sich nur um einen Versuch. Ich möchte wissen, ob es mit wenig Aaufwand möglich ist, die Postdaten von einem xbeliebigen PC im Internet einfach an einen Server zu schicken, von dem das Formular nicht vorher geholt wurde.
Mit einfachen HTML-Mitteln scheint es ja nicht möglich zu sein. Aber genau das möchte ich genauer wissen.
Es ist mir auch nicht wirklich wichtig, ob es mit einzelnen Browserversionen _nicht_ funktioniert, wenn dann z.B. die Mehrheit der Browser dies ermöglichen.
Und wie soll ich einen Server gegen HTML-Uploads oder Posts schützen, wenn sie doch üblicherweise auch benötigt werden?
Grüße aus Braunschweig
Tom
PS: wer wird gewinnen? Die Brasilianer oder die Deutschen?
-
Hi,
Aua, nun sag doch nicht gleich krummer Hund zu mir!
hab ich das?
Ich habe das mit zwei Apache-Servern im Intranet ausprobiert. Beide laufen auf Linux 7.2 und haben php4 als Modul.
Sind die entsprechenden Rechner und Server prinzipiell erreichbar von dort aus, wo Du es getestet hast?
Es handelt sich nur um einen Versuch. Ich möchte wissen, ob es mit wenig Aaufwand möglich ist, die Postdaten von einem xbeliebigen PC im Internet einfach an einen Server zu schicken,
Sagen wir mal so: Es gibt kostenlose Formmailer-Provider. Rate mal, wie die funktionieren.
von dem das Formular nicht vorher geholt wurde.
HTTP ist zustandslos. Der Begriff "vorher" existiert nicht.
Mit einfachen HTML-Mitteln scheint es ja nicht möglich zu sein.
Und eben diese Schlussfolgerung ist mir nicht begreiflich. Auf welche Weise bist Du zu ihr gelangt?
Und wie soll ich einen Server gegen HTML-Uploads oder Posts schützen, wenn sie doch üblicherweise auch benötigt werden?
Hm? Von was für einem Schutz redest Du, und was ist wann/wo/wie benötigt? Ich kann Dir leider nicht folgen.
PS: wer wird gewinnen? Die Brasilianer oder die Deutschen?
Beim letzten Mal waren es die Alliierten. Mir war allerdings nicht bekannt, dass Brasilien auch mitgekämpft hat.
Cheatah
-
Moin!
Es handelt sich nur um einen Versuch. Ich möchte wissen, ob es mit wenig Aaufwand möglich ist, die Postdaten von einem xbeliebigen PC im Internet einfach an einen Server zu schicken, von dem das Formular nicht vorher geholt wurde.
Mit einfachen HTML-Mitteln scheint es ja nicht möglich zu sein. Aber genau das möchte ich genauer wissen.
Warum sollte es nicht gehen? Der Browser setzt die teilweise Action-Angabe ja auch zu einer vollständigen URL zusammen. Wenn das Formular die Adresse http://www.server1.tld/pfad/formular.html hat, dann führt
diese action="..." zu diesem Request
auswertung.php http://www.server1.tld/pfad/auswertung.php
/auswertung.php http://www.server1.tld/auswertung.php
/weg/auswertung.php http://www.server1.tld/weg/auswertung.php
../weg/auswertung.php http://www.server1.tld/weg/auswertung.php
http://www.wohin.tld/cgi-bin/script.cgi http://www.wohin.tld/cgi-bin/script.cgiGanz easy eigentlich. Und dabei ist es unerheblich, ob mit Methode GET oder POST gearbeitet wird, rein vom HTTP-Verhalten und der URL-Ermittlung her sind diese beiden Methoden ziemlich identisch.
Es ist mir auch nicht wirklich wichtig, ob es mit einzelnen Browserversionen _nicht_ funktioniert, wenn dann z.B. die Mehrheit der Browser dies ermöglichen.
Alle Browser können es.
Und wie soll ich einen Server gegen HTML-Uploads oder Posts schützen, wenn sie doch üblicherweise auch benötigt werden?
Was willst du genau tun? Gegen Requests kannst du einen Server nur teilweise schützen, denn Requests werden bei jeder Seitenanforderung benötigt.
Du kannst POST komplett oder basierend auf ein paar Regeln (z.B. welcher Absender oder welche Empfangs-URL) abschalten, aber GET abzuschalten wäre blödsinnig, weil du dann keinerlei Seiten mehr kriegst (die werden auch mit GET angefordert).
Grüße aus Braunschweig
Tom
PS: wer wird gewinnen? Die Brasilianer oder die Deutschen?
-
Danke Sven,
das ist ja auch der Sinn des Servers, dass er Requests beantwortet. Dann liegts aber wahrhscheinlich am M$IE (5.5), dass die auf der lokalen Platte liegenden Forms einfach nicht an eine Adresse im Internet abgeschickt werden.
Ich werde das nochmal weiter untersuchen, wenn ich Zeit habe.
Demnach ist es aber möglich, (php-)Script auf dem Server mit getürkten Anfragen zu übreschütten, also einfach diverse Standardbezeichner für Variablen in ein Form zu packen. Namen, die ben jeder mal so nimmt... Und wenn Treffer dabei sind, kann man das Script gehörig durcheinander bringen und den Server nebst Admin zum Schwitzen.
Jetzt gilt es also herauszuarbeiten, wie Scripte in PHP einigermaßen "eigensicher" gestaltet werden können. Die dürfen also nur auf eine bestimmte Kombination von Variablenbezeichner und Wert reagieren.
Soweit jedenfalls meine Überlegungen
Grüße aus Braunschweig
Tom
-
Hi,
Demnach ist es aber möglich, (php-)Script auf dem Server mit getürkten Anfragen zu übreschütten,
ja, das ist korrekt. Es ist in HTTP auf keinen Fall erforderlich, dass Requests ausschließlich "von der Seite" (diese Formulierung macht in dem Protokoll eh nur wenig Sinn) kommen, die der Entwickler dafür vorgesehen hat.
also einfach diverse Standardbezeichner für Variablen in ein Form zu packen.
Damit sprichst Du ein Sicherheitsrisiko von PHP an, das jedoch dadurch umgangen werden kann, dass statt magisch generierten Variablen dynamischen Namens ausschließlich Default-Variablen fixen Namens und (natürlich) eigens deklarierte (und initialisierte) sowie sinnvolle Methoden verwendet werden. Also $_GET und $_POST verwenden, um URL- und POST-Parameter auszulesen, getenv() für Environment-Werte. Sowas wie "if ($submit)" hat in einem Script nichts verloren, solange die Variable nicht vorher z.B. mittels "$submit = $_GET['submit'];" gefüllt wurde.
Namen, die ben jeder mal so nimmt... Und wenn Treffer dabei sind, kann man das Script gehörig durcheinander bringen und den Server nebst Admin zum Schwitzen.
DoS-Attacken sind übrigens strafbar.
Jetzt gilt es also herauszuarbeiten, wie Scripte in PHP einigermaßen "eigensicher" gestaltet werden können.
Bitte sehr, gern geschehen :-) Ich bin mir übrigens sicher, dass man in der php.ini (o.ä.) die automagische Variablen-Erzeugung deaktivieren kann, kann Dir aber leider nichts genaues dazu sagen.
Cheatah
-
Yo!
das ist ja auch der Sinn des Servers, dass er Requests beantwortet. Dann liegts aber wahrhscheinlich am M$IE (5.5), dass die auf der lokalen Platte liegenden Forms einfach nicht an eine Adresse im Internet abgeschickt werden.
Ich sehe keine grundsätzlichen Probleme, warum ein Browser ein Formular, egal woher es geladen wird, nicht an einen Server senden können sollte. Gibt die komplette URL (mit http vorn) an, und es sollte funktionieren.
Demnach ist es aber möglich, (php-)Script auf dem Server mit getürkten Anfragen zu übreschütten, also einfach diverse Standardbezeichner für Variablen in ein Form zu packen. Namen, die ben jeder mal so nimmt... Und wenn Treffer dabei sind, kann man das Script gehörig durcheinander bringen und den Server nebst Admin zum Schwitzen.
Tja, das Problem hast du zumindest schon mal gut erkannt. Elementar ist, daß man seine im Script benutzten Variablen initialisiert und ansonsten auf $HTTP_*_VARS (oder moderner $_GET, $_POST, $_COOKIES, $_FILES) zurückgreift - dadurch weiß man, welche Quelle man anzapft, und es ist schonmal unmöglich, daß man aus versehen ein GET-Formular erhält, wo nur ein POST-Formular existiert und versendet werden soll.
Jetzt gilt es also herauszuarbeiten, wie Scripte in PHP einigermaßen "eigensicher" gestaltet werden können. Die dürfen also nur auf eine bestimmte Kombination von Variablenbezeichner und Wert reagieren.
Die dürfen auf alle Kombinationen reagieren - sie sollten nur lediglich keinerlei PHP-Variablen erzeugen, auch wenn das auf den ersten Blick ziemlich praktisch erscheint.
Wie sehr man sich täuschen kann, was die eigene Sicherheit angeht, habe ich exemplarisch mal in http://forum.de.selfhtml.org/archiv/2002/6/15268/#m85650 erforscht anhand eines real existierenden und zum Glück nicht von mir geschriebenen Scriptes. Dort siehst du hoffentlich recht eindeutig, was das Sicherheitsproblem ist, und daß man es im Prinzip auf eine ganz simple Weise lösen könnte: Variablen initialisieren, und zwar immer!
- Sven Rautenberg
-
-
-
-
-
-
-
-