Alle meine unsicheren PHP Scripte....

[Wolfsbein]

sensible Daten nie über die Browserzeile weitergeben. Entweder POST verwenden oder Sessions....

Das mit Post hast du falsch verstanden. Das was im Link Angezeigt wird mit Get übergeben.Bei Post sieht man nix im Link und wird Bei Formularen verwendet.
...

POST ist genauso unsicher wie GET! Die Daten kann man problemlos mitlesen, bzw. aendern. Wenn du nicht willst, dass man Bilder, User oder was auch immer mit einer fortlaufenden Nummer irgendwoher auslesen kann, musst du entweder ein Rechtesystem implementieren, oder die Werte zumindest hashen und nicht base64_encode oder irgendwas wieder decodierbares nehmen. Das macht zwar ein Auslesen nicht unmoeglich, aber aufwendiger.

 

[split]

Ich bin in meinem Post von einem Rechtesystem ausgegangen.

@bensky: Wenn du Daten - egal wie stark du sie verschlüsselst - über den Client (spricht, per GET, POST, COOKIE) übermittelst, können sie immer entschlüsselt und gelesen werden. Wenn du nur eine Variable "verschieben" willst, dann mach das doch bitte via Session. Sessions werden serverseitig gespeichert und sind auf vernünftig konfigurierten Servern vor Zugriffen von außen geschützt!

 

[Dennis Wronka]

@bensky: Wenn du Daten - egal wie stark du sie verschlüsselst - über den Client (spricht, per GET, POST, COOKIE) übermittelst, können sie immer entschlüsselt und gelesen werden.

Technisch gesehen richtig, nur bei einer ordentlichen Verschluesselung dauert das Knacken den Codes so lange dass es unwirtschaftlich wird ihn zu knacken, vor allem bei der Art von Daten die unsereins in der Regel so rumschiebt.
Und wenn man das alles wirklich haarklein saehe duerfte es kein Online-Banking geben, denn auch SSL/TLS kann ja im Grunde geknackt werden.

 

[split]

Da hast du jetzt wieder recht.

Aber eigentlich wollte v.a. darauf hinaus, dass es wenig Sinn macht, eine Variable an den Client zu schicken und dann wieder zurück zum Server, wenn man diese genauso gut auch gleich serverseitig speichern kann ;-)

 

[bensky]

Also das was ihr sagt (sicherheitstechnisch) kling alles plausiebel, ich will aber keine "sensiblen" Daten über tragen ich will nur das die ollen Scriptkiddies nicht einfach z.B. userprofile oder gruppen "quasi" durchblättern können. Bsp. index.php?showgroup=22 // index.php?showgroup=23 sondern index.php?showgroup=7&726Ghs.
Das ist schon schwerer das zu erraten.

Es soll ja keine interner Bereich sein wo man z.B. die gruppen angezeigt gekommt, man soll den link schon weitergeben können nur halt nicht warlos drin rumblättern.

Ein gute Besipspiel wäre es beim studivz.net wo gruppen bspw so heißen:

http://www.studivz.net/group.php?ids=f2da010d54431d17

 

[split]

Kein interner Bereich, man soll den Link weitergeben können aber die Links sollen nicht zu erraten sein?

Also wenn du das unbedingt so machen willst, kannst du z.B. die Zahl des Datensatzes (es muss ja eindeutig bleiben) gefolgt von einem 5-stelligen Zufallstrings, beispielsweise die ersten 5 Zeichen des MD5-Hashes der aktuellen Zeit, o.ä.

$datensatzNr = 187;
$key = $datensatzNr . substr(md5(time()), 0, 5);

Vielleicht hilft dir das weiter.

 

[bensky]

Naja hilft wir schon aber wie kann das 2te PHP file das die variable braucht die wieder zurückentschlüsseln weil md5() verschlüselt ja nicht das mach ja nurn hash von irgendwas? und den vergleichen kann ich ja nicht? Oder?

 

[split]

Tut mir Leid, ich hab mich falsch ausgedrückt.

Ich meinte, du kannst obiges als Datensatz-ID benutzen, d.h. die Nr. des Datensatzes bildet zusammen mit dem 5-stelligen Angang die ID des Datensatzes.

Aber mir fällt grad noch was besseres ein:
Du kannst - wie vorher - eine ganz normale, numerische eindeutige ID benutzen und ein zusätzliches Feld anlegen, welches den 5-(oder mehr-)stelligen Zufallsstring beinhaltet. Dann sähe ein Link z.B. so aus:
profile.php?uid=5&control=89fda907e3

Und in der profile.php wird eine entsprechende Abfrage ausgeführt:

SELECT * FROM `userdetails` WHERE `id` = '$_GET[uid]' AND `access_code` = '$_GET[control]';

(Aber bitte an SQL-Injection denken!)

Warum also zwei Felder?
Ein Zufallsstring muss nicht zwingend eindeutig sein. Bei einer großen Datenmenge kommt es leicht mal vor, dass zweimal der gleiche String erzeugt wird und spätestens dann hast du ein Problem mit der Eindeutigkeit. Dem könntest du zwar entgegenwirken indem du die Datensatznummer mit in den Primärschlüssel-Wert aufnimmst, das würde dich allerdings eine weitere SQL-Abfrage [-> Zeilen zählen] kostet!). Eine numerische ID ist sowieso immer besser!

 

[bensky]

Ja an sowas hab ich auch schon gedacht, sollte ich dann einfach ein random nehmen oder besser was in der art von: $rand = substr(md5(microtime()),0,5);
Oder vieleicht noch die ip miteinbringen?

 

[split]

Das spielt absolut keine Rolle; es gibt tausend Möglichkeiten einen Zufallsstring zu erzeugen. Du brauchst nur eine