Mogeln bei Onlinespiel erschweren

[AllesMeins]

Hiho,

ich stehe gerade vor folgendem Problem. Ich habe ein kleines Onlinespiel gebastelt und ein Teil dieses Spieles ist das man in einer Reihe von Zahlen tippen muss ob die jeweils nachfolgende höher oder niedriger sein wird. Wenn man das mehrmals richtig gemacht hat bekommt man weitere Punkte für das eigentlich Spiel. Soweit so gut. Nun ist heute der erste Fall von Betrügereien aufgetreten indem ein Nutzer sich ein PHP Script geschrieben hat das dies automatisch macht. Damit sowas in Zukunft nicht mehr passiert überlege ich zur Zeit wie ich die gerade angezeigte Zahl verschleiern kann. Im Moment heissen die Dinger noch 1.gif, 2.gif usw. - das ist natürlich leicht auszuwerten. Ich brauche also eine Methode mit der man von dem Dateinamen nicht mehr auf die Zahl schliessen kann. Mein bisheriger Versuch sah folgendermassen aus:

Zufällig wird für den User in der Session eine codierung für die auszugebenden Zahlen erstellt (also kjdadsk = 1, odsadkas = 2 usw.) Diese Codierung wird an ein weiteres PHP Script übergeben das auch Zugriff auf die Session hat und somit auswerten kann welche Zahl nun angezeigt werden soll. Die entsprechende Grafik wird dann abgerufen und per fpassthru ausgegeben.

Das funktioniert in der Theorie recht gut, in der Praxis schaffen es aber weder Mozilla noch der IE die Anweisung:

header("Cache-Control: no-store, no-cache, must-revalidate");
header("Cache-Control: post-check=0, pre-check=0", false);
header("Pragma: no-cache");                         header("Content-Type: image/gif");

richtig auszuführen und nicht zu cachen sondern es wird ab und zu immer wieder eine falsche Grafik angezeigt. Nun bin ich auch nicht ganz zufrieden mit dem Status das nicht gecached wird, denn das heisst höhere Traffic Kosten für mich.

Hat irgendwer von euch eine Idee wie ich dieses dilemma lösen kann?

Marc

[entropie]

Hiho,

Moin

Zufällig wird für den User in der Session eine codierung für die auszugebenden Zahlen erstellt (also kjdadsk = 1, odsadkas = 2 usw.) Diese Codierung wird an ein weiteres PHP Script übergeben das auch Zugriff auf die Session hat und somit auswerten kann welche Zahl nun angezeigt werden soll. Die entsprechende Grafik wird dann abgerufen und per fpassthru ausgegeben.

Keine gute idee. Sessions mögen für den "normalen" anwender unsichtbar sein, aber wenn du einen Textbrowser (lynx,links), PHP, oder auch nur "wget -s" benutzt, kann man das sehr einfach sichtbar machen.

Hat irgendwer von euch eine Idee wie ich dieses dilemma lösen kann?

Ich würde versuchen dieses problem serverseitig zu lösen. Wahrscheinlich direkt in dem script. Dieser coder muss sich erstmal die mühe gemacht seinen User-agent zu ändern, den kannst du per Apache .htaccess oder im script auschliessen.
Eine andere möglichkeit wäre das ganze system umzugestalten um nicht einzelne grafiken, sondern "grafik blöcke" von einem script generiert.

Zu häufige anfragen in einem bestimmten zeitraum könnten auch ein ansatz sein.

Marc

Mfg entropie

[AllesMeins]

Hiho,

Keine gute idee. Sessions mögen für den "normalen" anwender unsichtbar sein, aber wenn du einen Textbrowser (lynx,links), PHP, oder auch nur "wget -s" benutzt, kann man das sehr einfach sichtbar machen.

hmm? Wie denn? Liegen Sessions nicht generell auch auf dem Server und der Client kennt nur die Session-ID? So habe ich das Sessions-Konzept jednefalls bisher verstanden...

Eine andere möglichkeit wäre das ganze system umzugestalten um nicht einzelne grafiken, sondern "grafik blöcke" von einem script generiert.

Da habe ich wieder das Problem mit dem Traffic. Das Spiel verursacht (für meine Verhältnisse) jetzt schon viel zu viel Traffic. Generierte Grafiken die jedesmal neu geladen werden müssen machen es da nicht unbedingt leichter...
Ausserdem schlägt da wieder das Mozilla/IE-sind-zu-doof-den-cache-richtig-zu-verwalten Problem zu...

Zu häufige anfragen in einem bestimmten zeitraum könnten auch ein ansatz sein.

Das hatte ich (zum Glück) schon vorher unterbunden und das ausliefern der Seite bei jedem Spielzug mit nem sleep(1) künstlich verzögert um die Traffickosten der normalen Spieler etwas unter Kontrolle zu bringen. An irgendwelche Scripte habe ich da noch gar nicht gedacht...

Marc

[entropie]

Hiho,

Keine gute idee. Sessions mögen für den "normalen" anwender unsichtbar sein, aber wenn du einen Textbrowser (lynx,links), PHP, oder auch nur "wget -s" benutzt, kann man das sehr einfach sichtbar machen.

hmm? Wie denn? Liegen Sessions nicht generell auch auf dem Server und der Client kennt nur die Session-ID? So habe ich das Sessions-Konzept jednefalls bisher verstanden...

ein auszug:

HTTP/1.1 200 OK
Date: Thu, 25 Nov 2004 16:46:58 GMT
Server: Apache/1.3.31 (Unix) FrontPage/5.0.2.2635 PHP/4.3.9
X-Powered-By: PHP/4.3.9
Set-Cookie: PHPSESSID=7b1db0f3d7cc39e8528b2a9ee095cfbc; path=/

Wäre die session korrekt initialisiert, könnte man variablen samt inhalt auslesen.

Eine andere möglichkeit wäre das ganze system umzugestalten um nicht einzelne grafiken, sondern "grafik blöcke" von einem script generiert.
Da habe ich wieder das Problem mit dem Traffic. Das Spiel verursacht (für meine Verhältnisse) jetzt schon viel zu viel Traffic. Generierte Grafiken die jedesmal neu geladen werden müssen machen es da nicht unbedingt leichter...

Du musst sie nicht jedesmal generieren. Einmal am tag, einmal die woche... wie du willst. Und natürlich auch nicht für jeden user einzeln.

Ausserdem schlägt da wieder das Mozilla/IE-sind-zu-doof-den-cache-richtig-zu-verwalten Problem zu...

Ich hatte ein ähnliches problem. Die einzige lösung die dann letzendlich funktionierte war die umbennung der datei die nicht gecacht werden soll.

Zu häufige anfragen in einem bestimmten zeitraum könnten auch ein ansatz sein.

Das hatte ich (zum Glück) schon vorher unterbunden und das ausliefern der Seite bei jedem Spielzug mit nem sleep(1) künstlich verzögert um die Traffickosten der normalen Spieler etwas unter Kontrolle zu bringen. An irgendwelche Scripte habe ich da noch gar nicht gedacht...

Lege eine mindestzeit zeit fest (das spiel wird ja sicher ein bisschen dauern, pro seite). Wenn zu viele anfragen, bannen oder 'näher beobachten'.

Kombiniere ein paar solcher oder ähnlicher stolperfallen, und der scripter wird keine lust haben (denke ich).

Marc

Mfg entropie

[AllesMeins]

Hiho,

Wäre die session korrekt initialisiert, könnte man variablen samt inhalt auslesen.

Hmm, stellt sich mir die Frage wozu zum Teufel es gut sein soll den Variableninhalt aus den Sessions zum Client zu schicken. Also mal abgesehen davon das es (wie in meinem Fall) störend ist, sehe ich auch absolut keinen sinnvollen Verwendungszweck dafür...

Du musst sie nicht jedesmal generieren. Einmal am tag, einmal die woche... wie du willst. Und natürlich auch nicht für jeden user einzeln.

Aso, ich hab dich falsch verstanden. Ich dachte du meinst einen Grafikblock im Sinne von "bei jedem Spielzug eine breite Grafik generieren auf der alle bisher aufgedeckten Zahlen gemeinsam sind".

Ich hatte ein ähnliches problem. Die einzige lösung die dann letzendlich funktionierte war die umbennung der datei die nicht gecacht werden soll.

Hmm, die Idee an sich ist nicht schlecht. Wie ist es wenn ich statt dem umbenennen die Datei durch den rewrite engine jage. Also sprich ein images/rötzötz.gif wird umgeschrieben auf imagescript.php?p=rötzpötz und auf diese Weise die Grafik zurück gegeben. Dann können die Bilder immer noch normal benannt auf dem Server liegen und das entschlüsseln der Namen erledigt ein Script beim Aufruf.
Könnte das klappen oder bekommt der Browser trotzdem mit das es sich dabei nicht um ein normales Bild handelt und bringt evtl. den cache durcheinander?

Lege eine mindestzeit zeit fest (das spiel wird ja sicher ein bisschen dauern, pro seite).

Leider nicht wirklich. Das ist ein Mini-Simpel-Spielchen im eigentlichen Spiel. Und jede Seite dürfte ale Mensch ähnlich schnell abgearbeitet werden wie mit nem Script. Nur hat ein Script mehr Geduld, aber ich kann ja nicht bannen nur weil jemand mal nen Nachmittag davor sitzt...

Marc

[entropie]

Hiho,

Wäre die session korrekt initialisiert, könnte man variablen samt inhalt auslesen.

Hmm, stellt sich mir die Frage wozu zum Teufel es gut sein soll den Variableninhalt aus den Sessions zum Client zu schicken. Also mal abgesehen davon das es (wie in meinem Fall) störend ist, sehe ich auch absolut keinen sinnvollen Verwendungszweck dafür...

Naja, irgend ne <form> wo man nen username und nen pw eingibt, das peides in die session (md5(pw)), und jedesmal ne abfrage machen.

Ich hatte ein ähnliches problem. Die einzige lösung die dann letzendlich funktionierte war die umbennung der datei die nicht gecacht werden soll.

Hmm, die Idee an sich ist nicht schlecht. Wie ist es wenn ich statt dem umbenennen die Datei durch den rewrite engine jage. Also sprich ein images/rötzötz.gif wird umgeschrieben auf imagescript.php?p=rötzpötz und auf diese Weise die Grafik zurück gegeben. Dann können die Bilder immer noch normal benannt auf dem Server liegen und das entschlüsseln der Namen erledigt ein Script beim Aufruf.

Apropro apache und mod_rewrite, mod_access (HTTP-authenifizierung), könnte ein weiter ansatz sein.

Könnte das klappen oder bekommt der Browser trotzdem mit das es sich dabei nicht um ein normales Bild handelt und bringt evtl. den cache durcheinander?

Wenn worher in dem script oder vom server der korrekte mime-type ausgegeben wurde, dürfte das unproblematisch sein.

Marc

Mfg entropie

[Julian von Mendel]

Hi!

Sessions mögen für den "normalen" anwender unsichtbar sein, aber wenn du einen Textbrowser (lynx,links), PHP, oder auch nur "wget -s" benutzt, kann man das sehr einfach sichtbar machen.

Blödsinn. Du verwechselst Sessions mit Cookies. Bei einer Session wird nur die ID clientseitig per Cookie oder über so ein GET- bzw. POST-Parameter transportiert. Die Daten selbst, werden, wenn alles korrekt programmiert wurde, serverseitig gespeichert. Ich speichere bei lokalen Anwendungen manchmal mehrere hundert kB in Sessions - es wächst nicht etwa das Cookie-Verzeichnis des Browsers sondern das serverseitige Tmp-Verzeichnis wo die Sessions gespeichert werden. Es wäre ja auch unlogisch die ganzen Daten jedesmal zu übertragen, und würde eine Sicherheitslücke bei diversen Webanwendungen darstellen. In dem von dir zitiertem Header wird außerdem auch nur eine Session-ID übertragen. Und die braucht man ja für die serverseitige Zuordnung zu den Daten. Alles weitere auf http://de3.php.net/manual/de/ref.session.php

Schöne Grüße
Julian

[entropie]

http://de3.php.net/manual/de/ref.session.php

Da steht folgendes:

Das Session-Modul bietet keine Garantie dafür, dass Informationen, die Sie in einer Session speichern, nur vom Benutzer gesehen werden können, der die Session erzeugt hat. Sie müssen zusätzliche Maßnahmen ergreifen, um die Integrität der Session ihrer Wichtigkeit entsprechend angemessen aktiv zu schützen.

Ich bin mir nicht mehr ganz sicher, aber:
In ruby konnte man einfach den HTTP header vor die auszugebenden daten schreiben. So kann man auch sessions und cookies erzeugen.

Und da steht gar nichts über HTTP an sicher, das ist nur an der oberflächer gekratzt. Morgen die RFC.

Schöne Grüße
Julian

Mfg entropie

[Julian von Mendel]

Hi!

Das Session-Modul bietet keine Garantie dafür, dass Informationen, die Sie in einer Session speichern, nur vom Benutzer gesehen werden können, der die Session erzeugt hat. Sie müssen zusätzliche Maßnahmen ergreifen, um die Integrität der Session ihrer Wichtigkeit entsprechend angemessen aktiv zu schützen.

Das bezieht sich vermutlich darauf, dass sich eine Session übernehmen lässt, wenn man die Session-ID eines anderen Users kennt. Wenn ich also die Session-ID kenne, mit der du im Moment bei einem Webservice eingeloggt bist, kann ich ohne mich einzuloggen direkt auf die anschließenden Seiten springen, vorrausgesetzt es wird die Session-ID nicht serverseitig noch mit User-Agent oder IP verbunden.

Ich bin mir nicht mehr ganz sicher, aber:
In ruby konnte man einfach den HTTP header vor die auszugebenden daten schreiben. So kann man auch sessions und cookies erzeugen.

Der Header ist natürlich beeinflussbar. Cookies (welche meistens auch für Sessions benötigt werden) werden über die HTTP-Header gesetzt. Bei dem Session-System von PHP wird ein Cookie mit einer eindeutigen ID übertragen, und dann lassen sich Daten dieser ID zuordnen. Die Daten werden aber serverseitig gespeichert. Der Client muss nur die Session-ID übertragen, um festzulegen, welche Daten zu ihm gehören.

Und da steht gar nichts über HTTP an sicher, das ist nur an der oberflächer gekratzt. Morgen die RFC.

Das ist vollkommen unabhängig von der HTTP-RFC. Es geht doch nur darum dass die eigentlichen Daten serverseitig gespeichert werden, und nur die Session-ID clientseitig!

Ich habe gerade zwei PHP-Dateien erstellt, test1.php sieht so aus:
<?php session_start(); $_SESSION["xyz"] = 123; ?>
test2.php sieht so aus:
<?php session_start(); var_dump($_SESSION["xyz"]); ?>
Wenn man erst test1.php aufruft, kommt als Antwort der Befehl zum Cookie-Setzen zurück, in dem eine PHPSESSID steht ("Set-Cookie: PHPSESSID=4665906f77bb1f1e3e8400c1da299d78; path=/"; das path hat dabei laut RFC folgende Bedeutung:
Path=value
      OPTIONAL.  The value of the Path attribute specifies the subset of
      URLs on the origin server to which this cookie applies.). Beim Aufrufen der zweiten Seite wird die im Cookie gespeicherte Session-ID wieder mit zum Server übertragen ("Cookie: PHPSESSID=4665906f77bb1f1e3e8400c1da299d78"), und dieser gibt "int(123)" nach ein paar Headern ohne irgendwelche Informationen (weder Session-ID noch der in der Session gespeicherten Daten) zurück.
Auch mein Browser sagt, er hat als Cookie nur irgendein "PHPSESSID=4665906f77bb1f1e3e8400c1da299d78" gespeichert. In /tmp auf meinem Rechner, wo mein Apache-Server seine Session-Daten speichert (lokal) hingegen wird eine Datei namens "sess_4665906f77bb1f1e3e8400c1da299d78" erzeugt, in der "xyz|i:123;" steht. Das Mitloggen per Ethereal hat ebenfalls ergeben dass _nur_ die Session-ID übertragen wird, nicht der Inhalt der Session - auf Anfrage schicke ich dir auch einen vollständigen Ethereal-Log der Daten.

Schöne Grüße
Julian

[entropie]

Moin,

Ich glaube dem gibt es nichts mehr hinzuzufügen.

Mfg entropie

[Zaphod]

Habe mal bei einem Umfragensystem eine Absicherung gesehen, die verhindern sollte, dass ein Skript dauernd abstimmt. Man musste eine Zahl eingeben, die auf dem Bildschirm angezeigt worden ist. Allerdings war diese Zahl keine Graphik, sondern bestand aus mit Tabellen gebauten Digits.

Wäre wohl ne Möglichkeit die sicher nicht gecacht wird und auch von keinem Skript ohne weiteres ausgelesen werden kann.