PHP Session und Formularfeld

Domi83

Rear Admiral
Registriert
Feb. 2010
Beiträge
5.348
Hallo Leute, ich habe da mal eine PHP technische Frage...
Wir haben ein Formular mit Buchungsmaske, diese wird via iFrame auf einigen anderen Domains bei uns eingebunden. Nun sind ja z.B. der Internet Explorer so eingestellt das sie Cookies von "Drittanbieter-Seiten" blockieren.

Damit man nicht jedem erklären muss warum das so ist etc., habe ich mal geguckt. Session ID "PHPSESSID" kann man via Cookie, Post und Get übergeben. Wie drehe ich es denn jetzt so, dass er mir die Session ID beim ersten laden in mein Formularfeld packt und auch nach "Refresh" oder F5 diese nicht verändert? :)

Ich könnte das ganze auch in die URL oben rein packen, möchte ich aber eigentlich nicht da sich dort noch andere Parameter befinden. Das ganze ist mit Sicherheit eine ganz simple Geschichte, aber irgendwie finde ich den Ansatz nicht :(

Mit der Session und Cookies läuft alles ohne Probleme, aber sobald halt die Cookies geblockt sind.. steht man im Wald. Somit hatte ich dann auf php.net noch mal geschaut und google gefragt und bin halt auf den Ansatz mit dem Formularfeld gekommen.

Allerdings wird ja die ID neu generiert, sobald ich F5 drücke. Kann ich diese irgendwie fest setzen? Oder wäre das nur mit einem Cookie möglich?!

Gruß, Domi
 
Kannst die ja in ein unsichtbares Feld im Formular eintragen, dann bekommst die übergeben und kannst es direkt wieder dort eintragen. Damit kannst deine erste halten.

Also Formularfeld mit type="hidden"
 
Jou, ein Fehler von mir.. Mangel an Informationen :D
@IC3HANDS, genau das war der Plan.. ich baue ein hidden Formularfeld, name wäre "PHPSESSID" und im Value steht die ID drin.

Ganz grob hab ich das eben mal zusammen gebaut und scheint zu funktionieren...
Code:
<?php
 ini_set('session.use_only_cookies', 0);
 session_start();
 if($_POST) {
  $_SESSION['test'] = trim($_POST['test']);
 }
?>
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml" lang="de">
 <head>
  <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
  <meta name="keywords" content=" " />
  <meta name="description" content=" " />
  <meta name="robots" content="noarchiv, noindex" />
  <title>Session Test</title>
 </head>
 <body>
  <form name="" action="/tests/session.php" method="post" />
   <input name="PHPSESSID" value="<?php echo session_id(); ?>" size="40" type="text" READONLY /><br />
   <input name="test" value="<?php echo $_SESSION['test']; ?>" size="40" type="text" /><br />
   <input name="senden" value="senden" type="submit" />
  </form>
<?php if(!empty($_SESSION['test'])) { ?>
  <?php echo $_SESSION['test']; ?><br />
<?php } ?>
 </body>
</html>
Nachtrag: Mir ist aufgefallen, so kann ich es nicht lösen. Ich muss es über die URL mit einem GET machen. Problematik ist, es gibt form1.php, form2.php und form3.php! Im Aktion von dem Formular ruft er die gleiche Seite auf, prüft ob alles passt, speichert es in einer Session ab und geht DANN zu form2.. und da verliert er dann die Session ID, weil es keinen neuen Post mehr gibt.

Es gibt also kein "formular.php?seite=1" oder so etwas.
 
Zuletzt bearbeitet:
Zugriffe über Domains hinweg unterliegen recht strengen Sicherheitskontrollen. Spätestens wenn JavaScript ins Spiel kommt sind iframe-Zugriffe auf Fremd-Domänen nicht mehr ohne weiteres möglich.

Andere Frage: Hast du die Kontrolle über die Formulare, die Scripts, die die Rückgabewerte verwalten und über den Code der Seiten, in die die Formulare eingebettet werden sollen? Dann gib die Formulare "nackt" zurück und lade sie per cURL direkt in die Zielseiten.
 
Joa, dass Thema mit diversen Scripten (z.B. JavaScript) haben wir bei anderen Versicherern festgestellt. Die haben teils JavaScript für ihre Eingabe benutzt. Ich habe hingegen auf JS verzichtet und mit PHP, Sessions + Cookies gearbeitet.

Aber an die Geschichte, dass der IE Cookies von Drittanbieter-Seiten blockt habe ich nicht gedacht. Ich habe gesehen, dass man auch irgend welche Datenschutzrichtlinien vergleichen lassen könnte im IE.. dann könnte er die Cookies annehmen ohne sie explizit zu aktivieren. Gibt es da noch eine Möglichkeit? :)

Sonst wäre die Variante mit dem cURL ganz gut. Aber die Lösung mit dem iFrame findet Chef und mein Kollege interessanter. Wir wollen nämlich ab Herbst Partner werben, die anschließend nur das Formular von uns als iFram einbinden bräuchten mit einer ID in der URL zur Provisions-Zuweisung. Ärgerlich wäre es dann, wenn der Partner keine IT bei sich hat die das mit einem cURL in deren Seite einbauen könnte.

Gruß, Domi
 
Hi Domi83,

eine weitere Möglichkeit wäre den Sessionskram mit hilfe einer Datenbank zu verwalten.

Wenn du selber kein System dafür schreiben möchtest, empfehle ich dir stark das PHP-Framework Codeigniter.

Es vereinfacht die Arbeiten ungemein. Fragen auch gerne per PM.
 
Moin... Also wegen XSS und den Sicherheiten bezüglich Sessions die nicht via Cookie gespeichert werden, habe ich im phpforum schon die Infos gelesen. Ich habe es ja auch so gebaut das aktuell im funktionierenden System die Sessions nur via Cookie übergeben werden :)

Doof ist nur, wenn der IE mit der Standard Einstellung ankommt, dass er Cookies von Drittanbieter-Seiten verbietet. Das iFrame was wir von unserer eigenen Seite in eine andere Seite von uns gebaut haben, soll ja später bei gewonnen Partnern auch eingebunden werden.. UND auch in weiteren Domains von uns eingebaut werden. Die Variante mit cURL ist definitiv gut, werde ich wohl auch einführen! Aber vorerst muss ich mir mal eine Lösung für das blockierte iFrame suchen :)

Kann man eigentlich irgendwelche Datenschutzrichtlinien auf der eigenen Domain hinterlegen, die der IE abrufen und verarbeiten kann?

@PascalK, joa.. den Gedanken hatte ich auch schon gehabt. Im Prinzip müsste man in der DB ja nur eine unique ID erstellen, und diese von Seite zu Seite durch reichen um die "Session" aufrecht zu halten. Oder ist das falsch?
 
@Domi83:

Ein Besucher ist ja immer eindeutig zu bestimmen. Betriebssystem, Browser, Ip... Du überprüfst halt, ob dieser Benutzer in einem gewissen Zeitraum eine Aktion (Seite laden) getätigt hat und wenn ja, setzt den Timer, bis die Session zerstört wird, wieder zurück.
 
Trotzdem solltest du Session-Daten IMMER filtern.
Einfaches Beispiel: Du hast einen (zugegeben, schlecht konfigurierten) Shared-Webhosting-Account, und jemand schafft es, einen beliebigen anderen Account zu kompromittieren. Die Session-Dateien sind bei PHP in der Grundeinstellung für alle Scripte les- und schreibbar. Der Angreifer könnte somit deine Session-Daten überschreiben und dir darüber ein XSS-Script in deine Seite einbinden. Und das wäre uncool.
 
Öhm, hast Du mal ein simples Beispiel für mich, damit ich das durch testen kann ob das bei mir funktioniert oder eben nicht?! Ich habe zwar das Skript selbst auf meinem vServer und auch die Domain auf der das meiste läuft liegt auch auf diesem vServer, aber dann kann ich das Szenario mal durch spielen.

Aber ich glaube, ich verstehe was Du meinst.
Gruß, Domi
 
Ganz einfach: Erstell einen Cookie und schau dir (Debian!) /var/lib/php5/ an.
 
Okay, dass kenne ich.. Ohne Suhosin-Patch sind die Daten sogar im rohformat und klar einsehbar. Mit dem Patch, sind sie verschlüsselt. Das meinst Du doch, oder?

Hab ja Debian Systeme.. und da hatte ich das einmal beobachtet. Zu Anfang ohne Suhosin, und anschließend mit.. :D
 
Zum Beispiel. Das Problem mit Suhosin ist halt, dass trotzdem jede Anwendung auf alle Cookies zugreifen kann, also auch auf deine.
 
Zurück
Oben