Link vor Fremdeingabe schützen!

[Kangarooo]

Hallo!
bei mir wird in einem Menü durch klicken eine Sortierung vorgenommen! Je nachdem auf welchen Pfeil man klickt wird es eben ASC oder DESC sortiert, der Wert dafür wird in einem Link übergeben. Wie kann ich es schaffen, dass der Link nicht manipuliert werden kann, denn sobald ich by der Variable "by" im Link etwas anderes eingebe spinnt ja die DB Abfrage total!

menu.php?lang=1&media=38&sort=city&by=ASC 

Danke schonmal für die Hilfe!

[unset]

Verhindern kannst du die Manipulation gar nicht nicht –*aber du musst sie auch nicht auswerten. Genau genommen darfst du sie gar nicht auswerten, denn so lässt sich beliebiger SQL-Code einschleusen, was im schlimmsten Fall einen Einbruch in dein System ermöglicht –*aber auch so schon genug schaden anrichten kann. Mach dich darüber schlau, was SQL-Injections sind und wie man sie verhindert!

[rossixx]

oder mit HASH

arbeiten.

noch besser mit hash , session und https.

sicher ist sicher. wobei nie etwas 100% sicher ist, das ist sicher.

[unset]

Gewöhn du dir mal lieber ab deine Sätze im Betreff zu beginnen und im Text fortzuführen. Das Titel-Feld ist kein Pflichtfeld bei Replies!

[rossixx]

ich versuche es in zukunft zu berücksichtigen.

[TobiaZ]

kannst du die drei Stichwörter vielleicht mal kurz erklären, wie du sie konkret einsetzt/einsetzen würdest?

[rossixx]

Session

wird vergeben, wenn der user eine seite aufruft, ist an die aufrufende IP gebunden, damit kein andere einfach die session übernehmen kann.

hash

es wird ein hash schluessel generiert, der wird mit der seite per get oder post mitgereicht,

dieser schluessel generiet sich aus den mitgereichten variablen / werten und einem geheimen schluessel, werden die daten oder schluessel manipuliert, tritt eine fehler oder warnmeldung auf, und die daten werden auf keinen fall verarbeitet.


https

sollte grundsätzlich eingesetzt werden, wenn private daten oder zu schützende daten wie passwörter / userdaten versendet werden. damit keine unverschlüsselten daten durch netz gehen...


meine beschreibung ist bestimmt nicht die beste, korrekturen und kritik kann ich vertragen.

[TobiaZ]

Also, ich kann durchaus was mit deiner Beschreibung anafangen, jedoch "verhindert" ja lediglich die Hash-Methode ein Manupulieren der URL. Ob de zusätzliche Aufwand gerechtfertigt ist, muss jeder selbst wissen. Da würde ich dir also generell zustimmen.

Der Einsatz einer "IP-gekoppelten Session" kann generell sinnvoll sein, genauso wie der Einsatz von SSL. Jedoch spielt das hier absolut keine Rolle, oder? Wo würdest du die beiden Methoden hier sinnvoll einsetzen?

Ich würde hier generell so vorgehen, wie auch unset es schon beschrieben hat: Nur gültige Werte durchlassen und alles andere mit einer Fehlermeldung quittieren.

[h3ll]

Session

wird vergeben, wenn der user eine seite aufruft, ist an die aufrufende IP gebunden, damit kein andere einfach die session übernehmen kann.

Was ist, wenn der User eine wechselnde IP hat?

[rossixx]

pech.

dann mußt du dir eine andere lösung einfallen lassen. oder nicht auf ip sondern auf browser oder betriebssystem eingrenzen. das wäre eine alternative.

[onemorenerd]

Das hilft doch alles nicht bzw. nicht zuverlässig. Sessions sind aber auch ohne zusätzliche Maßnahmen schon sehr sicher. Es gibt so viele mögliche SIDs und so wenige in Gebrauch, dass man eher im Lotto gewinnt, als eine gültige SID zu erraten. Die üblichen Dinge wie "keine SIDs in URLs", ID-Regenerierung und zeitnaher Verfall des Session-Cookies bieten i.d.R. ausreichend Schutz vor einer Übernahme.
Besonders kritische Aktionen in einer Applikation, z.B. Checkout eines Warenkorbs, sollte man lieber mit erneuter Passwortabfrage absichern. Damit identifiziert man den Menschen und nicht das Gerät - darauf kommt es an.


PS: Ich hoffe es merkt keiner, dass ich nur die letzten 5 Beiträge dieses Threads gelesen habe.

[AmicaNoctis]

Ist das nicht alles etwas kompliziert gedacht, nur um zu verhindern, dass jemand etwas anderes als "asc" oder "desc" verwendet?

Ich würde einfach davon ausgehen, dass erstmal immer "asc" gemeint ist. Nur wenn

isset($_GET["by"]) && strtolower($_GET["by"]) == "desc" 

erfüllt ist, wird auf "desc" umgestellt. Wenn jemand nichts oder was anderes angibt, bleibt es halt bei "asc".

Falls man es doch kompliziert machen möchte, habe ich auch noch was anzubieten: Digest HTTP Authentication.

Gruß,

Amica

[TobiaZ]

PS: Ich hoffe es merkt keiner, dass ich nur die letzten 5 Beiträge dieses Threads gelesen habe.

Nö, rossixx hat ja auch die Hälfte meiner Fragen ignoriert.

[rossixx]

und ich wollte nur mit meinem beitrag dazu beitragen, das der jenige themenstarter sich grundsätzlich gedanken macht zum thema sicherheit.

welche mittel er einsetzt liegt dann an seiner einschätzung, was er denk zu brauchen.

und alle fragen beantworten?!? is halt ne zeitfrage.

[Kangarooo]

Also ich habe jetzt ja einige Sachen gehört..ich werde mich mal drüber erkundigen, danke!
Somit können wir den "Streit" hier beenden :-)