Arrays in arrays in formularen

[rantanplan62]

Hallo, PHP-Experten!

Ich möchte über ein Formular Daten aus einer Datenbank zur weiteren Verarbeitung per POST versenden.

Im Formular sieht das so aus:

php code
$orderdet=array($id,$networker,$cadneu,$datumfirstcadneu,$zeitfirstcadneu,$datumlastcadneu,$zeitlastcadneu,$path,$orderno,‚update‘);
php code

Im Formular
Diesen Auftrag zum ZIP-Ordner hinzufügen";

Dann müßte ich doch ein Array orderdetails haben, in dem sich weitere arrays gem $orderdet befinden.
Mit print_r sagt er mir aber nur
Array ( [0] => Array [1] => Array [2] => Array [3] => Array [4] => Array [5] => Array )

Was mache ich falsch?

print_r müßte mir auch untergeordnete Arrays anzeigen, aber anscheinend hat das Array orderdetails nur die Worte Array gespeichert, aber nicht die korrekten Arrays gem. orderdet

Für Eure Hilfe wäre ich sehr dankbar.

Gruß,

Rantanplan

[alx]

Hallo,

$orderdet=array($id,$networker,$cadneu,$datumfirstcadneu,$zeitfirstcadneu,$datumlastcadneu,$zeitlastcadneu,$path,$orderno,‚update‘);

Im Formular
Diesen Auftrag zum ZIP-Ordner hinzufügen";

Da steht jetzt als value nur „Array“… weil so kann man das mit echo nicht ausgeben…
htmlentities(serialize($orderdet)) könnte helfen… schaue einmal in den ausgegebenen HTML-Quelltext…

Dann müßte ich doch ein Array orderdetails haben, in dem sich
weitere arrays gem $orderdet befinden.
Mit print_r sagt er mir aber nur
Array ( [0] => Array [1] => Array [2] => Array [3]
=> Array [4] => Array [5] => Array )

Logisch…

Mit der Zeile oben steht erst mal nur ein hässlicher String drin, das kannst du aber per $orderdetails = array_map(‚unserialize‘, $orderdetails) wieder „entpacken“.

Was mache ich falsch?

print_r müßte mir auch untergeordnete Arrays anzeigen, aber
anscheinend hat das Array orderdetails nur die Worte Array
gespeichert, aber nicht die korrekten Arrays gem. orderdet

Ja, was aber nicht am print_r liegt, sondern an am echo…

Alexander

PS: Was du da machst ist aus sicherheitstechnischer Sicht bedenklich, da jemand auch auf die Idee kommen könnte, die Daten zu manipulieren… Speichere besser die Daten in einer Session und übergibe nur id im Formular…

[rantanplan62]

Hallo, Alexander!
Erst mal: Danke für schnelle Antwort.
serialize und unserialize geht irgendwie auch nicht.
Schreibe jetzt manuell einen string mit den Inhalten und explode ihn dann im empfangenden script. Mal sehn, ob das so funzt wie ich das will.

PS: Was du da machst ist aus sicherheitstechnischer Sicht
bedenklich, da jemand auch auf die Idee kommen könnte, die
Daten zu manipulieren… Speichere besser die Daten in einer
Session und übergibe nur id im Formular…

Wie soll jemand die Daten manipulieren? In dem Formular gibt es nur Buttons, keine Eingabefelder. Zudem sind dies Daten in einem Intranet, die aus Datenbankfeldern stammen, die beim Anlegen bereits überprüft werden. Und die Daten werden mit POST verschickt, also kann auch keiner die URL böse verändern. In der URL wird nichts übergeben.

Gibt es jetzt immer noch eine Sicherheitslücke?

[rantanplan62]

Hallo, Alexander!
Erst mal: Danke für schnelle Antwort.
serialize und unserialize geht irgendwie auch nicht.
Schreibe jetzt manuell einen string mit den Inhalten und
explode ihn dann im empfangenden script. Mal sehn, ob das so
funzt wie ich das will.

Jo, das funzt!

PS: Was du da machst ist aus sicherheitstechnischer Sicht
bedenklich, da jemand auch auf die Idee kommen könnte, die
Daten zu manipulieren… Speichere besser die Daten in einer
Session und übergibe nur id im Formular…

Wie soll jemand die Daten manipulieren? In dem Formular gibt
es nur Buttons, keine Eingabefelder. Zudem sind dies Daten in
einem Intranet, die aus Datenbankfeldern stammen, die beim
Anlegen bereits überprüft werden. Und die Daten werden mit
POST verschickt, also kann auch keiner die URL böse verändern.
In der URL wird nichts übergeben.

Gibt es jetzt immer noch eine Sicherheitslücke?

[MunichFreak]

Sicherheitslücke: Ja!

Wie soll jemand die Daten manipulieren? In dem Formular gibt
es nur Buttons, keine Eingabefelder. Zudem sind dies Daten in
einem Intranet, die aus Datenbankfeldern stammen, die beim
Anlegen bereits überprüft werden. Und die Daten werden mit
POST verschickt, also kann auch keiner die URL böse verändern.
In der URL wird nichts übergeben.
Gibt es jetzt immer noch eine Sicherheitslücke?

man kann die Datei auch speichern und von einer anderen location her aufrufen - dann konnte die Datei ohne weiteres vorher bearbeitet werden.
Einzige Möglichkeit sicher zu gehen ist den referer zu überprüfen, aber den übermitteln nicht alle browser - innerhalb eines Netzwerks mit Standardbrowsern vielleicht kein grosser Akt…?

[rantanplan62]

Hallo, Munich Freak!
erst mal ein dickes Lob, Du bist hier, glaube ich, der aktivste Helfer!!!

Naja, in der Datei gibt es eine Funktion, die überprüft
a: die sessionid
b:
die in der session gespeicherten userdaten wie username und userberechtigungen.
Wenn da nicht alles genau übereinstimmt, hat er Pech und fliegt raus. Ich glaube, damit ist das auch gesichert, oder? Die sessionvariablen werden wiederum aus der Datenbank gespeichert, diese ist NUR direkt von dem Intranetserver aus abzufragen.

[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]

[MunichFreak]

bin mir nicht ganz sicher…
moin

Hallo, Munich Freak!
erst mal ein dickes Lob, Du bist hier, glaube ich, der
aktivste Helfer!!!

Danke, aber andere Leute wie z.b. pumpkin sind auch sehr aktiv

Naja, in der Datei gibt es eine Funktion, die überprüft
a: die sessionid
b:
die in der session gespeicherten userdaten wie username und
userberechtigungen.
Wenn da nicht alles genau übereinstimmt, hat er Pech und
fliegt raus. Ich glaube, damit ist das auch gesichert, oder?
Die sessionvariablen werden wiederum aus der Datenbank
gespeichert, diese ist NUR direkt von dem Intranetserver aus
abzufragen.

ich bin mir nicht ganz sicher - aber die Sessionid kann schon mal per post oder get übertragen werden - ist halt ein Feld mehr… sofern man die eben sieht…
Wenn die Session ID im cookie gespeichert wird ist es noch weniger ein Problem…
Wenn Du allerdings so absicherst, dass nur jemand mit einer gültigen Session was machen darf - und dann auch noch absicherst WAS er machen darf (mit den Userdaten) dann ist das natürlich sicher genug, ja…
Denke ich zumindest *g*
Aber abgesehen von ein wenig manipulation sollte eigentlich da nichts kritisches machbar sein…

[rantanplan62]

moin

auch moin!

ich bin mir nicht ganz sicher - aber die Sessionid kann schon
mal per post oder get übertragen werden - ist halt ein Feld
mehr… sofern man die eben sieht…

Die sieht man schon…
Aber auf jeder Seite erfolgt ein Abgleich mit der Datenbank, ob die Sessionid auch bei dem jeweiligen user gerade eingetragen ist.

Zudem wird mit der Datenbank noch eine Sessionvariable verglichen, welche nur über das php script, welches die Registrierungsanfrage auswertet, geschrieben wird. (Sozusagen mit einer zusätzlichen Sessionid, die mit der normalen Sessionverwaltung nichts zu tun hat).

Wenn die Session ID im cookie gespeichert wird ist es noch
weniger ein Problem…
Wenn Du allerdings so absicherst, dass nur jemand mit einer
gültigen Session was machen darf - und dann auch noch
absicherst WAS er machen darf (mit den Userdaten) dann ist das
natürlich sicher genug, ja…

Denke ich zumindest *g*
Aber abgesehen von ein wenig manipulation sollte eigentlich da
nichts kritisches machbar sein…

Also das ist doch, denke ich, sicher.

Gruß,

Rantanplan

[anon67740076]

Naja, in der Datei gibt es eine Funktion, die überprüft
a: die sessionid
b:
die in der session gespeicherten userdaten wie username und
userberechtigungen.
Wenn da nicht alles genau übereinstimmt, hat er Pech und
fliegt raus. Ich glaube, damit ist das auch gesichert, oder?

naja, also mit den daten:
$orderdet=array($id,$networker,$cadneu,$datumfirstcadneu,$zeitfirstcadneu,$datumlastcadneu,$zeitlastcadneu,$path,$orderno,‚update‘);

na, sicher ist da aber als solches noch nicht:
ich melde mich an, speichere das form auf der platte (habe damit eine gueltige sessid)
und fange einfach mal an mit der orderno und path rumzuspielen…