[Skinwalker]

Hiho,
bin nicht so ganz sicher ob es mit der Kategorie stimmt das es sowohl PHP als auch JS betrifft... aber doch eher PHP denk ich.

Und zwar habe ich eine HTML-Datei die per JS ein PHP-Script aufruft alla

setHttpObject();
    httpObject.open('GET', "ajax_save_pos.php?chara="+chara_id+"&px="+old_x+"&py="+old_y+"&map="+map_id);
    httpObject.onreadystatechange = responseOthers;
    httpObject.send(null);

in der datei ajax_save_pos.php wird dann der charakter mit der id char_id gespeichert, und zwar wird eben seine position auf der Karte gespeichert.

Nur gibt es dabei ein kleines Problem, jeder Idiot kann ja einfach den Quellcode anschauen und sich zusammenreimen wie das Script funktioniert.
Und dann einfach im Internet ajax_save_pos.php aufrufen mit den passenden Parametern und seinen Charakter durch die Welt teleportieren T_T

hat jemand eine Idee wie man das verhindern kann?

[Lars]

Arbeite mit Sessions. Dann brauchst du beim HTTP-Request nur die Session-ID anhängen und fertig

Link: Sessions mit PHP

[Skinwalker]

tut mir leid aber ich versteh nicht inwiefern das das Problem lösen soll.

Letztlich müsste die SessionID dann ja auch im JS offen auslesbar sein..
das request würde dann wohl etwa so aussehen:
ajax_save_pos.php?sid=1234567890&x=5&y=5&map=10

aber letztlich braucht doch der User auch da einfach dieses Ding aus dem JS rauszukopieren und tada...er teleportiert sich wieder einfach dorthin wie er will...

oder habe ich was falsch verstanden?

[b.pwned]

Warum überprüfst du serverseitig nicht, ob der Spieler überhaupt berechtigt oder in der Lage ist sich zu teleportieren? Du musst doch immer davon ausgehen, dass dein JS undicht ist!

[Skinwalker]

nur ist eben die frage wie bitte soll ich das denn überprüfen?

gibt es vielleicht eine Funktion die Prüft von wo das Request kam?

[JumperII]

Hallo,

vielleicht verstehe ich es ja falsch, aber ich versuche es mal.

Als erstes scheint es bei Dir ein konzeptionelles Problemchen zu geben. Eine SET-Funktion direkt vom Client aufzurufen mit den zugehörigen Parametern macht per se keinen wirklichen Sinn. Deshalb setze ich mal eine ajax_go2pos.php an. Weniger wegen der Funktion als vielmehr für das Verständnis.

und in dieser php-Datei musst Du jetzt den Weg von der aktuellen position (die im übrigen auf dem Server gespeichert sein sollte -> Session) zur neuen prüfen. D.h. gibt es einen Weg dahin? Wenn Ja, hat er Bedingungen, die erfüllt sind? Oder auch Ist die Schrittweite/Strecke zum zurücklegen zu groß? (Manipulationsverdacht).

Darüber hinaus dient die Session auch davor, dass ein fremder den Spieler beliebig woanders hinräumt. Aber auch hier gilt wieder, Manipulationen können mit Hilfe der Session zwar nicht zweifelsfrei ausgeräumt, aber in den meisten Fällen erkannt werden. D.h. auch dies sollte auf dem Server geprüft werden.

Gruß,
Jumper, the II.

[Skinwalker]

und in dieser php-Datei musst Du jetzt den Weg von der aktuellen position (die im übrigen auf dem Server gespeichert sein sollte -> Session) zur neuen prüfen. D.h. gibt es einen Weg dahin? Wenn Ja, hat er Bedingungen, die erfüllt sind? Oder auch Ist die Schrittweite/Strecke zum zurücklegen zu groß? (Manipulationsverdacht).

das ist eine gute idee... nachdem jeder nur je einen schritt machen darf kann ich einfach schaun ob die neue position nicht mehr als einen schritt vom aktuellen x oder vom aktuellen y entfernt ist.

Darüber hinaus dient die Session auch davor, dass ein fremder den Spieler beliebig woanders hinräumt. Aber auch hier gilt wieder, Manipulationen können mit Hilfe der Session zwar nicht zweifelsfrei ausgeräumt, aber in den meisten Fällen erkannt werden. D.h. auch dies sollte auf dem Server geprüft werden.

ja klar das war soweiso schon integriert...wär ja noch schöner...ausnahme nur für admins die das dürfen.


trotzdem: gibt es denn keine möglichkeit zu checken woher ein Request kommt? dann könnte man nämlich ganz einfach schaun "ok der request kommt von homepage.de/move.php das passt." "ne wo kommt der denn her....so nicht."

wäre allgemein eine praktische Sache. Nicht nur für diese Problemstellung

[VolkerK]

Nein, diese Möglichkeit gibt es nicht. Alles, was Du dem Benutzer in die Hand drückst, kann mit mehr oder weniger Aufwand nachgebaut und gefälscht werden. Authorisierung, Beschränkungen und Prüfungen müssen immer dort stattfinden, wo der evtl. unberechtigte Benutzer keinen Zugriff hat. In diesem Fall also auf dem Server.

[Skinwalker]

Alles, was Du dem Benutzer in die Hand drückst, kann mit mehr oder weniger Aufwand nachgebaut und gefälscht werden. Authorisierung, Beschränkungen und Prüfungen müssen immer dort stattfinden, wo der evtl. unberechtigte Benutzer keinen Zugriff hat. In diesem Fall also auf dem Server.

wenn sicherheit eine Rolle spielt hast du recht.
das schließt aber nicht aus das es trotzdem eine möglichkeit gibt. bist du sicher das es keine gibt? oder findest du nur das es egal ist ob es eine gibt oder nicht?

[VolkerK]

Es gibt keine vertrauenswürdige Möglichkeit.
Der Client stellt die Anfrage "aus eigener KRaft" an den Server und sämtliche Daten, die mitgesendet werden, können wie auch immer zustande kommen. Dazu muss vorher keine andere Seite "besucht" worden sein o.ä.
Der Client _kann_ über http-referer die vorher besuchte Seite übergeben ...oder irgendwas ganz anderes ...oder nichts, je nach Lust und Laune.

[JumperII]

Hallo Skinwalker,

vor wem willst Du Dich eigentlich schützen? Unabhängig vom Client, mit etwas Kenntnis von HTTP bzw. englischkenntnissen und der passenden RfC baue ich Dir jederzeit die Anfrage 100% erlaubt zusammen.

Wenn es für die Admins ist, wäre es z.B. sinnvoll, für Sprünge eine temporäre Authentifikation mitzugeben, unabhängig von der Session. Da Admins typischerweise auch nicht aller 5 Sekunden Springen, ist es handelbar.

Gruß,
Jumper, the II.

[Skinwalker]

die sache ist einfach das. da ist eine zb eine karte mit was weiß ich 100 Feldern und der Spieler soll von anfang bis ende selbst durchgehen.

nun wird seine position aber bei jedem Schritt gespeichert, und wenn er kein idiot ist hätte er (jetzt nicht mehr) einfach das php_script in einem separaten Fenster aufrufen können mit den fraglichen GET-Angaben und sich ans andere Ende der Karte "speichern" können... das sollte vermieden werden. was ja nun gemacht wurde indem einfach überprüft wird ob die Schirttlänge nicht zu groß ist.

auf die Art kann der User immer noch das Script einzeln aufrufen aber das macht mehr arbeit als das er selbst über die Karte latscht.

Somit ist das Problem eigentlich gelöst

aber was ist eine RfC?

[Ben]

Ähm. Sorry, falls ich jetzt etwas übersehe, aber warum speicherst Du die Daten dann nicht in einer Session? Bin jetzt nicht so der AJAX-Experte , demnach sorry, falls ich da irgendwas übersehen sollte.

Ich meine halt, warum GET-Parameter verwenden, wenn die Gefahr einer Manipulation vorhanden ist (jaja, ist zumeist da, aber ich beziehe das auf diesen Fall hier).

Klär mich auf, falls ich falsch liege.
Grüße, Ben.

[Skinwalker]

Javascript kann Daten in einer Session speichern? das wär mir neu.

[Ben]

Ah, ups. Ich war ca. so gut, wie Lars

[Skinwalker]

kein Ding passiert schon mal XD inzwischen ist das Problem ja eh gelöst.

[JumperII]

Hallo,

RFC = Request for Comments
Z.B. für das HTTP gibt es die RfC 2616: http://www.faqs.org/rfcs/rfc2616.html

@Ben: Ist doch eigentlich egal, ob die Daten per GET, POST oder Cookie hoch zum Server kommen. Manipulieren kann man sie immer auf der Client-Seite. Daher sind entsprechende Schutzmechanismen serverseitig zu implementieren. Diese Schutzmechanismen sollten aber angemessen sein, d.h. dem notwendigen Schutzbedarf sichern. In einigen Firmen gibt es zur Ermittlung des Bedarfs mehrseitige Templates (bis zu 6 Seiten sind mir bekannt), die in einen Audit ausgefüllt werden.

Gruß,
Jumper, the II.