POST und GET von extern sperren?

[KernelX]

Hi,

mein Problem ist, dass ich auf meinem Server Formulare liegen habe, die ein paar Daten auch per -> hidden <-.
jemand von außerhalb könnte aber eine Seite schreiben, und die hidden-values manipulieren und abschicken.

Kann man nicht irgendwie dafür sorgen, dass ausschließlich die Daten, die von meinem Server aus geschickt werden auch von PHP weiterverarbeitet werden ... und das die Daten, die von extern per Formular auf meinen Server geschickt werden einfach ignoriert werden?

mfg.
KernelX

[Cheatah]

Hi,

Kann man nicht irgendwie dafür sorgen, dass ausschließlich die Daten, die von meinem Server aus geschickt werden auch von PHP weiterverarbeitet werden ...

sicher, Du kennst schließlich die IP Deines Servers. Ich vermute aber, dass Du auch diejenigen Requests zulassen möchtest, welche von einem anderen Client stammen, der "auf Deinem Server war", richtig? Nun - solche Requests kannst Du von anderen nicht unterscheiden.

Cheatah

[Marko]

Hi,

vergiß es, Du kannst zwar vielleicht noch einen Refferer auswerten, oder z.B. mit SessionID's arbeiten, das macht es schwerer zu manipulieren. Refferer Auswertung bringt allerdings Probleme sobald ein Browser keinen Refferer mitsendet. Wenn es aber jemand partout darauf anlegt Dein Script zu verarschen hast Du keine Chance das zu verhindern, da HTTP nunmal ein Verbindungsloses Protokoll ist.
Die Frage wäre: Wovor hast Du eigentlich Angst ? Es ist eigentlich meistens recht unwahrscheinlich, dass jemand mutwillig versucht sich in Deine Anwendung einzuhacken, wenn es nicht gerade um Onlinebanking oder so geht. Und mach bitte nicht dauernd neuen Threads auf.

Gruss

Marko

[Cheatah]

Hi,

Refferer Auswertung bringt allerdings Probleme sobald ein Browser keinen Refferer mitsendet.

wenn jemand genug kriminelle Energie aufbringt, um das Formular zu simulieren, ist es sehr wahrscheinlich, dass er auch in der Lage (und willens) ist, den Referer (der sich übrigens mit einem "f" und drei bis vier "r" schreibt) zu fälschen. Wie Du schon sagst: Man kann es erschweren, indem man auf welche Weise auch immer einen vorherigen Request verbindlich macht - nur wird niemand daran gehindert, auch diesen Request (automatisiert) durchzuführen.

Wenn es aber jemand partout darauf anlegt Dein Script zu verarschen hast Du keine Chance das zu verhindern, da HTTP nunmal ein Verbindungsloses Protokoll ist.

Japp.

wenn es nicht gerade um Onlinebanking oder so geht.

Für solch sicherheitsrelevante Dinge sollte man a) per SSL arbeiten, b) TANs einsetzen und ggf. c) tunlichst einen eigenen Client liefern (z.B. per Java-Applet), welcher mit einem eigenen Protokoll (bzw. einer eigenen Unterart) agiert. Und sei es nur, um Unterschiede in den vorhandenen HTTP-Clients auszugleichen.

Und mach bitte nicht dauernd neuen Threads auf.

Hm, der letzte Thread von ihm hatte zwar ein ähnliches Subject, aber IMHO eine andere Fragestellung.

Cheatah