Eine einfache Methode wäre, alle numerischen Werte durch intval() und Strings durch addslashes() oder mysql_escape_string() zu jagen und grundsätzlich alle Werte, die übergeben werden in ' ' zu schreiben. Dann kriegt der User im schlimmsten Fall falschen Output, aber die Datenbank bleibt heil.
Den eigenen Server habe ich aus mehreren Gründen empfohlen:
Die meisten Freehoster bieten nicht die nötige Datenbankgröße und die nötige Rechenleistung
Ich kenne keinen Freehoster, bei dem man Cronjobs laufen lassen kann
Bei den meisten Freehostern sind Browsergames gar nicht erlaubt.
Zitat
Gibts nicht auch eine gute Möglichkeit, um eben diese Scripts zu realisieren, ohne mein eigenes Zutun (Aktualisierungsdatei aufrufen), oder Cronjobs zu verwenden?
...
Wie gesagt, schreib Events mit Typ und Timestamp in eine Tabelle und hol sie dir bei jedem Seitenaufruf mit SELECT * FROM `events` WHERE `timestamp` <= UNIX_TIMESTAMP() ORDER BY `timestamp` ASC. Dann kannst du sie der Reihe nach verarbeiten und überall, wo du normalerweise time() verwenden würdest $row['timestamp'] verwenden. Der einzige Nachteil ist, dass die Seitenaufrufe ggf. recht lange dauern.
Edit:
Evtl. wäre es sogar besser nicht UNIX_TIMESTAMP() zu verwenden. Schließlich musst du die Einträge hinterher auch löschen und wenn du da den Timestamp wieder neu generieren lässt, könntest du schon eine Sekunde weiter sein und damit im schlimmsten Fall Events unbearbeitet löschen. Speicher den also lieber in PHP mit time() in ne Variable und übergeb die.
Den eigenen Server habe ich aus mehreren Gründen empfohlen:
Die meisten Freehoster bieten nicht die nötige Datenbankgröße und die nötige Rechenleistung
Ich kenne keinen Freehoster, bei dem man Cronjobs laufen lassen kann
Bei den meisten Freehostern sind Browsergames gar nicht erlaubt.
...
Dachte ich mir doch, dass ich dich falsch verstanden habe.
Du redest von kommerziellem Webspace, aber ich dachte du meinst, dass ich wirklich einen Server mieten soll, das ist ja AFAIK ein Unterschied.
Gut, denn kommerzieller Webspace ist nicht sonderlich teuer, da bekommt man schon guten für 3 Euro im Monat.
addslashes() wird ohnehin ein wichtiges Thema werden, da Magic Quotes abgeschafft werden. Yay.
Die andere Funktion heißt mysql_real_escape_string(), ist aber alleinstehen auch nicht sehr nützlich.
Wenn der User eine vierstellige Jahreszahl eingeben soll, muss man prüfen, ob das Eingabefeld überhaupt gegeben ist, ob es sich um eine Zahl handelt, ob sie 4 stellen hat, eventuell ob es ein gültiges Jahr ist (nicht etwa 2008, außer bei bestimmten Anwendungen).
Strings sind .. anders. Da hilft die oben genannte Funktion schon, aber dann muss man immernoch den Inhalt validieren. D.h. bei der Ein- eventuell auch bei der Ausgabe bestimmte Zeichen überprüfen und ggf. ersetzen. Z.B. <script> Bereiche oder javascript: in URIs, je nach Schema eben.
Kleine Ergaenzung am Rande: einige Leute uebersehen gerne, dass Cookies auch User-Input sind. Ich hab schon mehr als einmal 'ne Webanwendung gesehen, die zwar GET- und POST-Parameter filtert, bei der aber SQL-Injections ueber manipulierte Cookies moeglich waren.
Dachte ich mir doch, dass ich dich falsch verstanden habe.
Du redest von kommerziellem Webspace, aber ich dachte du meinst, dass ich wirklich einen Server mieten soll, das ist ja AFAIK ein Unterschied.
Gut, denn kommerzieller Webspace ist nicht sonderlich teuer, da bekommt man schon guten für 3 Euro im Monat.
...
Auch komerzieller Webspace hat in der Regel keinen Shellzugriff, den man für Cronjobs braucht.
Zitat von Antares
Events?
...
Ich hab sie einfach mal so genannt. Wie genau das aussieht, hängt vom Spiel ab. Im simpelsten Fall zum Beispiel eine Tabelle mit Timestamp, User ID, Eventtyp (Gebäude bauen, Einheit bauen, Truppenbewegung) und Parametern (Position, Art der Gebäude / Einheiten)
type = 42 könnte etwa für Gebäude bauen stehen und die Parameter hießen dann beispielsweise, dass an der Position 423,411 ein Gebäude vom Typ 55 gebaut werden soll.
Wenn der Spieler ein Gebäude in Auftrag gibt, wird einfach so ein Event mit dem Fertigstellungszeitpunkt in die Datenbank geschrieben.
Zitat von mitaki
Strings sind .. anders. Da hilft die oben genannte Funktion schon, aber dann muss man immernoch den Inhalt validieren. D.h. bei der Ein- eventuell auch bei der Ausgabe bestimmte Zeichen überprüfen und ggf. ersetzen. Z.B. <script> Bereiche oder javascript: in URIs, je nach Schema eben.
...
Für die Ausgabe ist da fast immer htmlentities($bla) oder htmlentities(stripslashes($bla)) passend.
Auch komerzieller Webspace hat in der Regel keinen Shellzugriff, den man für Cronjobs braucht.
Ich hab sie einfach mal so genannt. Wie genau das aussieht, hängt vom Spiel ab. Im simpelsten Fall zum Beispiel eine Tabelle mit Timestamp, User ID, Eventtyp (Gebäude bauen, Einheit bauen, Truppenbewegung) und Parametern (Position, Art der Gebäude / Einheiten)
type = 42 könnte etwa für Gebäude bauen stehen und die Parameter hießen dann beispielsweise, dass an der Position 423,411 ein Gebäude vom Typ 55 gebaut werden soll.
Wenn der Spieler ein Gebäude in Auftrag gibt, wird einfach so ein Event mit dem Fertigstellungszeitpunkt in die Datenbank geschrieben.
Für die Ausgabe ist da fast immer htmlentities($bla) oder htmlentities(stripslashes($bla)) passend.
...
Achso, jetzt habe ich in etwa das Grobprinzip der Rohstoffberechnung (bzw der zeitgesteurten Scripts) verstanden.
Es wird gar kein Script in einer bestimmten Zeit ausgeführt, das dem Benutzer eine bestimmte Anzahl von Rohstoffen produziert, sondern der Benutzer ruft das Script quasi selbst auf.
Das heißt, er erhält die Rohstoffe eigentlich nur dann, wenn er das Script indirekt aufruft, würde er sich nicht einloggen, so würde er nach der vorgeschriebenen Zeit die Rohstoffe auch gar nicht bekommen. (bzw die Datenbankwerte würden sich nicht ändern)
Versteh ich das richtig?
Für die Ausgabe ist da fast immer htmlentities($bla) oder htmlentities(stripslashes($bla)) passend.
...
Das ist klar, das andere ist viel wichtiger. Manche Browser lassen z.B. javascript:URIs im <img /> Element zu. Wenn man da nicht aufpasst ist schnell was passiert.
Wie macht es Ogame beispielweise, dass man immer wieder auf die Hauptseite (www.ogame.de) kommt, sobald man eine Url kopiert, im Browser einfügt und absendet?
Hm, das heißt ja dann, dass man sämtliche Informationen problemlos per GET übergeben könnte, denn der User besitzt keine Möglichkeit sie zu ändern.
...
Problemlos bestimmt nicht. Formulardaten können z.B. noch immer beliebigen Inhalt haben.
Ich bin mir nicht sicher, ob das folgende auch auf Webseiten im Cache zutrifft. Aber es gibt Möglichkeiten Webseiten die gerade Angezeigt werden zu bearbeiten. Die Seite wäre dann theorethisch zwar nur im Cache manipuliert, der Inhalt wird aber ohne weiteres an dich gesendet.
Nochmal: nichts, aber auch absolut gar nichts, was vom User gesendet wird, ist vertrauenswuerdig. Man kann ohne Probleme jeden HTTP-Header, den man sendet (GET- und POST-Infos, Cookies, Referrer, alles) manipulieren. Wenn du dich nicht auf User, die exakt das tun, vorbereitest, kannst du damit ganz boese auf die Schnauze fliegen.
Oder so:
1.) Ist eine Session-ID angegeben?
Wenn nein -> Startseite
2.) Gibt es im Server eine aktuelle Session, die der ID entspricht?
Wenn nein -> Startseite
3.) Gehört diese Session auch der IP, die sich gerade meldet?
Wenn nein -> Startseite
Ich mache selten Sessionmanagement; IIRC erledigt PHP diese Arbeit schon und man muß im Wesentlichen fragen, ob es aktuell eine gültige Session gibt oder nicht.
Oder so:
1.) Ist eine Session-ID angegeben?
Wenn nein -> Startseite
2.) Gibt es im Server eine aktuelle Session, die der ID entspricht?
Wenn nein -> Startseite
3.) Gehört diese Session auch der IP, die sich gerade meldet?
Wenn nein -> Startseite
Ich mache selten Sessionmanagement; IIRC erledigt PHP diese Arbeit schon und man muß im Wesentlichen fragen, ob es aktuell eine gültige Session gibt oder nicht.
...
Hm, nein das ist bei Ogame anders, denn du bist selbst derjenige, der diesen Link eingibt.
Anstatt auf "gebaude.php?sesid=jdsjdkjadjsdiafj&build=2" zu klicken kopiert man einfach den Link und fügt ihn selbst im Browser ein und trotzdem kommt man zurück auf die Startseite.
Hm, nein das ist bei Ogame anders, denn du bist selbst derjenige, der diesen Link eingibt.
Anstatt auf "gebaude.php?sesid=jdsjdkjadjsdiafj&build=2" zu klicken kopiert man einfach den Link und fügt ihn selbst im Browser ein und trotzdem kommt man zurück auf die Startseite.
...
Dann wird da vermutlich irgendwo ein JavaScript-Skript drinstecken.
Kleine Ergaenzung am Rande: einige Leute uebersehen gerne, dass Cookies auch User-Input sind. Ich hab schon mehr als einmal 'ne Webanwendung gesehen, die zwar GET- und POST-Parameter filtert, bei der aber SQL-Injections ueber manipulierte Cookies moeglich waren.
...
Dito. ich hab mir auch schonmal eine Injection selbstgemacht, indem ich $_SERVER['REQUEST_URI'] in eine MySQL Abfrage gepackt habe, ohne zu escapen.
Zitat von mq
Nochmal: nichts, aber auch absolut gar nichts, was vom User gesendet wird, ist vertrauenswuerdig. Man kann ohne Probleme jeden HTTP-Header, den man sendet (GET- und POST-Infos, Cookies, Referrer, alles) manipulieren. Wenn du dich nicht auf User, die exakt das tun, vorbereitest, kannst du damit ganz boese auf die Schnauze fliegen.
...
Nochmal dito *spam*
Zitat
3.) Gehört diese Session auch der IP, die sich gerade meldet?
...
Das ist teilweise problematisch, weil die Leute dann nach einem erneuten Verbindungsaufbau sich nicht mehr einloggen können, weil sie dann wahrscheinlich eine neue IP haben. Das ist bei Browsergames zwar nicht so wichtig, aber das sollte man imo bedenken.
Das ist teilweise problematisch, weil die Leute dann nach einem erneuten Verbindungsaufbau sich nicht mehr einloggen können, weil sie dann wahrscheinlich eine neue IP haben. Das ist bei Browsergames zwar nicht so wichtig, aber das sollte man imo bedenken.
...
Wobei man hier zwei Fälle unterscheiden muss!
Wird die SID in der URI mitgegeben? Dann muss eine IP Prüfung gemacht werden!
Wird die SID per Cookie übergeben? Dann sollte eventuell der Browser überprüft werden.
Aber natürlich müssen in Cookies noch andere Angaben vorhanden sein, damit man den Benutzer eindeutig identifizieren kann.
Wird die SID in der URI mitgegeben? Dann muss eine IP Prüfung gemacht werden!
Wird die SID per Cookie übergeben? Dann sollte eventuell der Browser überprüft werden.
Aber natürlich müssen in Cookies noch andere Angaben vorhanden sein, damit man den Benutzer eindeutig identifizieren kann.
...
Deinen Punkt 2. versteh ich nicht wirklich. Inwiefern willst du den Browser überprüfen?
Deinen Punkt 2. versteh ich nicht wirklich. Inwiefern willst du den Browser überprüfen?
...
Serverseitig. Will sagen: Verwendet der Spieler noch immer den selben Browser? Wenn es da zu einem Browserunterschied kommt, ist es wahrscheinlich, dass der Cookie geklaut wurde, weshalb der Zugang nicht gewährt werden sollte.
Machen auch manche Forensoftware so, obwohl sich das auch ausschalten lässt.
Man kann Cookies auch manipulieren, ohne den Browser zu wechseln. Demnach ist die Überprüfung ziemlich schwachsinnig. Und zuverlässig ist sie schon zweimal nicht, weil man als Browserinfo so ziemlich alles senden kann.
Zitat
Zitieren
