Browsergames (Techniken)

[Manni]

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.

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*

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.

[mitaki]

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!

1. Wird die SID in der URI mitgegeben? Dann muss eine IP Prüfung gemacht werden!
2. 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.

[DFYX]

Wobei man hier zwei Fälle unterscheiden muss!

1. Wird die SID in der URI mitgegeben? Dann muss eine IP Prüfung gemacht werden!
2. 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?

[mitaki]

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.

[DFYX]

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.

[mitaki]

Man kann Cookies auch manipulieren, ohne den Browser zu wechseln.

...

Ja, du denkst da aber an einen anderen Aspekt als ich.

Demnach ist die Überprüfung ziemlich schwachsinnig.

...

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.

Und zuverlässig ist sie schon zweimal nicht, weil man als Browserinfo so ziemlich alles senden kann.

...

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.

[Antares]

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.

[DFYX]

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.

[mitaki]

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?

...

Daran hab ich, erhlichgesagt, garnich gedacht, sondern an den klassischen Cookieklau per XSS.

Ich frag mich, warum man ein so kleines Browsergame explizit gegen sowas absichern sollte.

...

Ich schrieb ja auch eventuell. Ich wusste halt, dass das gemacht wird und brachte es in den Post ein.

Allgemein sollte man eher Sicherheitslücken vermeiden als es den Hackern zu erschweren, sie zu nutzen.

...

Richtig, aber das täte es ja.
Wenn ich annehme, dass ein Besucher immer mit dem selben Browser kommt, dann nehme ich auch an, dass nur dieser das Cookie besitzen kann. Hat ein anderer das Cookie sage ich nein.
Nehme ich allerdings an, dass ein Cookie von überall kommen kann, dann wird ein Hacker nicht ausgeschlossen, wenn er die selben Cookies wie der echte Spieler hat, aber einen anderen Browser.

Woher soll ein Programm wissen, dass es sich um einen falschen Cookie handelt. Oder wie soll ein Browsergame verhindern, dass ein Bot die Cookies durchstöbert?
XSS sollte der Autor vermeiden, ja. Aber mehr kann er in der Hinsicht wohl nicht tun.

PHP-Code:

mysql_query('SELECT * FROM `users` WHERE `username`=\''.addslashes($_GET['username']).'\''); 

Ja, aber man sollte doch für SQL-Abfragen, immer die entsprechende Escapefunktion verwenden (mysql_real_escape_string()), welche alle Zeichen escaped, die dem String gefährlich werden könnten.
Außerdem würde ich hier die unnötige maskierung vermeiden. Mich bringt sowas immer durcheinander.

PHP-Code:

mysql_query('SELECT * FROM `users` WHERE `username`="' . mysql_real_escape_string($_GET['username']) . '";'); 

[Jesus_666]

BTW, falls man Zugriff auf PHP 5.1 oder höher hat kann man auch PDO verwenden. Mit PDO hat man nicht nur auto-escapte Variablen (Achtung, % und _ werden AFAIK immer noch nicht gefiltert) sondern auch Zugriff auf erweiterte Funktionalität wie Transaktionen, die, sobald man sich etwas mit ihnen beschäftigt hat, sehr nützlich sein können.

[Antares]

Welches Anzeigesystem benutzt man denn hauptsächlich bei Browsergames?
Frames?
Include? (?content=)
Oder doch diese ominösen Templates?

[Lukas]

Kann man alles, muss man gar nichts. Wobei Templates schon geschickt waeren (wie bei jeder Art von Website).

[Jesus_666]

Zumal Templates keine Alternative zu Frames und Includes sind - Templates bauen auf Includes auf und können mit Frames kombiniert werden.

Templates funktionieren ganz grob so:
1.) Du lädst das Template in eine Variable.
$template = file_get_contents('templates/omgsupertemplate.htm');
2.) Das Template enthält Platzhalter, die du durch konkrete Werte ersetzt.
$template = str_replace('%sinndeslebens%', 'Brot essen', $template);
$template = str_replace('%fontsize%', $variable, $template);
3.) Nachdem du alle Ersetzungen durchgeführt hast machst du, was auch immer du mit dem Output tun willst.
echo $template;

Zur Veranschaulichung hier noch mal ein Vorher-Nachher-Vergleich. ($variable == 42)
VORHER

Code:

<html>
  <body>
    <div style="font-size: %fontsize%">
      Der Sinn des Lebens ist: %sinndeslebens%.
    </div>
  </body>
</html>

NACHHER

Code:

<html>
  <body>
    <div style="font-size: 42">
      Der Sinn des Lebens ist: Brot essen.
    </div>
  </body>
</html>

Templates sind ziemlich mächtig und erlauben es dir, PHP- und HTML-Code sauber zu trennen, was die Wartbarkeit der Seite beträchtlich erhöhen kann. Du kannst auch problemlos Templates ineinander verschachteln (wie das geht sollte offensichtlich sein) und so auch komplexe Layouts hinkriegen.


Edit:
Ich wurde darauf hingewiesen, daß es nicht offensichtlich ist. Hier also noch mal genau:

Wenn du dein Template abgearbeitet hast, also mit Schritt 2 durch bist, hast du den ganzen Kram in einer Variable. Die kannst du nun wiederum ganz normal in ein anderes Template einfügen. Und schon hast du den Kram verschachtelt. Du muß nur eben darauf achten, daß du alles, was in einem Untertemplate abgearbeitet wird, in einer eigenen Templatedatei ablegst.