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.
Auch komerzieller Webspace hat in der Regel keinen Shellzugriff, den man für Cronjobs braucht.Zitat von Antares
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?
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.
Eine Frage hätte ich noch:
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?
Da gibts zwei Möglichkeiten:
- Du überprüfst serverseitig den Referrer der Seite, d.h. wenn keiner vorhanden -> Weiterleitung zur Startseite.
- Clientseitig per JavaScript. Hier müsstest du vermutlich auch irgendwie den Referrer auslesen und dann die Seite umleiten können.
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.
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.
Dito. ich hab mir auch schonmal eine Injection selbstgemacht, indem ich $_SERVER['REQUEST_URI'] in eine MySQL Abfrage gepackt habe, ohne zu escapen.
Nochmal dito *spam*
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.
--
Geändert von Manni (17.12.2006 um 21:22 Uhr)
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.
--
Die Wespe, der Fuchs und der Vogel gehen erst in die Oper und dann auf Safari. 8)
Nützliche Adressen (HTML, CSS, PHP, MySQL, Werkzeuge) für Webgestalter.
-> Übersicht meiner Artikel (HTML Strict verstehen Teil 1-8 und weitere interessante Themen).
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.
--
Ja, du denkst da aber an einen anderen Aspekt als ich.
Denke ich nicht. Wenn jemand sich mit einem falschen Cookie einloggen will, aber zufällig den falschen Browser dazu verwendet, dann ist letzteres die einzige information, die ein Programm verarbeiten könnte. Von daher sollte man davon ausgehen, dass ein Cookie, das beim falschen Browser liegt, getürkt ist.
Das ist wahr, allerdings: Der Standarduser macht das nicht. Ebensowenig transferiert er Cookies, wenn er nicht gerade von einem Browser zum anderen umsteigt.
Von daher halte ich die Annahme „unterschiedliche Browser -> Hackversuch“, durchaus für gerechtfertigt.
Btw nochmal zum Thema Injections.
Ist es nicht eine einfache und gute Möglichkeit die Usereingabe, bevor sie für den eigentlichen Script verwendet wird, auf Zeichen, wie beispielsweise das Semikolon, oder auf Werte wie "delete" zu überprüfen und diese ggf. aus der Eingabe zu löschen.
Gut, in letzterem Beispiel dürfte kein User das Wort "delete" im Name verwenden, aber was solls.
So wie ich dich verstanden hab, soll das hauptsächlich eine Schutzmaßnahme gegen Bots sein, die sich auf irgendwelchen Rechnern einnisten, deren Cookies auslesen und dann Unsinn anstellen, richtig? Ich frag mich, warum man ein so kleines Browsergame explizit gegen sowas absichern sollte. Die meisten Leute, die das Spiel hacken wollen, haben kein Problem, sich nochmal neu einzuloggen, falls sie überhaupt ein extra Programm verwenden. Allgemein sollte man eher Sicherheitslücken vermeiden als es den Hackern zu erschweren, sie zu nutzen. Erinnert mich grad irgendwie an Microsoft und an die deutsche Politik, so von wegen Airbag einbauen, wenn die Bremse kaputt ist.
@Antares:
Regular Expressions sind dein Freund. Im Programmierforum gabs vor Monaten mal nen sehr schönen Thread von Jeez zu dem Thema. Ich würde aber eher drauf achten, die Befehle sauber zu escapen und in Anführungszeichen zu packen. Folgender Code ist ziemlich ungefährlich:
mysql_query('SELECT * FROM `users` WHERE `username`=\''.addslashes($_GET['username']).'\'');
Da kann der User Anführungszeichen, Semikolons und Delete eingeben, soviel er lustig ist, es wird nichts passieren, außer dass kein Ergebnis gefunden wird. Nur das % sollte man evtl. ausfiltern, wie beispielsweise die Suchfunktion von www.informatikjahr.de zeigt. Einfach mal % eingeben und schaun, was passiert. Die Seite scheint eh kein bisschen gegen Injections geschützt zu sein.
--
Geändert von DFYX (18.12.2006 um 00:28 Uhr)
Berechtigungen
Zitieren
