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.Zitat
--
Geändert von Manni (17.12.2006 um 21:22 Uhr)
Wobei man hier zwei Fälle unterscheiden muss!Zitat
- 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).
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.
Ja, du denkst da aber an einen anderen Aspekt als ich.Zitat
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.Zitat
Das ist wahr, allerdings: Der Standarduser macht das nicht. Ebensowenig transferiert er Cookies, wenn er nicht gerade von einem Browser zum anderen umsteigt.Zitat
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.
Daran hab ich, erhlichgesagt, garnich gedacht, sondern an den klassischen Cookieklau per XSS.Zitat
Ich schrieb ja auch eventuell. Ich wusste halt, dass das gemacht wird und brachte es in den Post ein.Zitat
Richtig, aber das täte es ja.Zitat
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.
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.
Geändert von mitaki (18.12.2006 um 00:50 Uhr) Grund: Querykorrektur (genau das meinte ich >.<) Aha, dein Fehler :p
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.
Welches Anzeigesystem benutzt man denn hauptsächlich bei Browsergames?
Frames?
Include? (?content=)
Oder doch diese ominösen Templates?
Kann man alles, muss man gar nichts. Wobei Templates schon geschickt waeren (wie bei jeder Art von Website).
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
NACHHER
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.
Geändert von Jesus_666 (20.12.2006 um 11:03 Uhr)
@Jeez:
Also, im Grunde habe ich das System verstanden, doch bleiben noch ein paar Fragen offen:
Das Includesystem (mit Content) ist ja recht einleuchtend.
Ich schreibe "?content=start"
Und an der jeweiligen Stelle "if($content=="start") { include...."
Bzw ich benutze einen Switch.
Allerdings werden die verschiedenen Seiten bei Templates meineswissens nicht per Variable angesteuert.
Also anstatt "www.blah.de/index.php?content=start" steht dann dort "www.blah.de/start.php"
Und jetzt verstehe ich nicht, wie ich ein solches System mit Templates aufbauen muss.
Zuerst mal natürlich if ($_REQUEST['content'] === 'start'). $content ist nur dann direkt verfügbar, wenn du dir Autoglobals erzeugen läßt - und das ist erstens nicht auf allen Servern eingerichtet und zweitens kann es zu Sicherheitslücken führen, wenn man nicht aufpaßt.
Falls du dir $content aus dem Userinput selbst erzeugt hast ist die Stelle natürlich in Ordnung.
Von deinem System auf meins umzusatteln ist gar nicht so schwer - immerhin funktionieren beide dadurch, daß an der entsprechenden Stelle die Templates geladen werden. Anstatt einfach die Datei zu inkludieren lädst du sie in eine Variable und fügst die in das Haupttemplate ein, das du am Ende ausgibst.
Mein System basiert ja darauf, daß du keinen Output hast, den du nicht explizit anforderst (dadurch, daß du ein echo $bla; machst). Du lädst also erst die Grundseite als Template und fügst dann dort alle weiteren Teile ein. Um also eine andere Seite zu "inkludieren" setzt du einfach an der entsprechenden Stelle in der Grundseite einen Platzhalter und packst da per str_replace() die geladene Seite rein.
BTW, was meinst du mit "werden bei Templates nicht per Variable angesteuert"? Templates sind völlig unabhängig davon, wie man den Inputverarbeitet - und sowohl das, was ich mache als auch das, was du da beschreibst sind Templates; meine sind nur abstrakter gehalten.
@Jeez:
Nunja, was ich mit ansteuern meinte:
Klickt ein User auf den Link "?content=start", so sagt er ja dem Server, dass die Variable Content den Wert "start" annimmt.
Jetzt handelt der Server, beispielsweise nach dem if-Schema, also "wenn die Variable Contetnt den Wert "start" annimmt, dann inkludiert er die start.php an die entsprechende Stelle.
Also steuert man die verschiedenen Inhalte an, indem man per Klick auf einen Link die Variable Content ändert, und der Server demntsprechend reagiert.
Achja und Autoglobals?
Damit arbeite ich gar nicht.
Ich hole mir den Wert von Content einfach mit GET.
Also $content=$_GET["content"];
So und wenn ich ohne dieses System arbeiten würde, so würde ich ganz einfach den Link auf "start.php" setzen.
Allerdings müsste ich auf diese Weise sämtliche Strukturen implementieren.
Also jede einzelne Datei per HTML ein Menü, einen Header, einen Footer, etc. einbringen - und diese Methode ist definitiv zu arbeitsaufwändig, vorallem, wenn sich das Menü mal ändern sollte.
In diesem Fall müsste man Änderungen in sämtlichen Dateien vornehmen.
Und ich dachte mir eben, dass diese letzte Variante eben mit Templates funktionieren würde.
Leider fehlt mir da momentan noch der Durchblick.
Um die Sache verständlicher zu machen ein kleines Beispiel:
Da wäre die Datei "/inhalt/omgrofl.html"
Eine weitere Datei wäre die normale "inhalt/lamor.html"
Index.php
Wie man sieht sollen Standardmäßig die Inhalte der "lamor.html" zu sehen sein.
So, meine Frage hierzu:
Wie muss der PHP Code der index.php aussehen, und wie der Inhalt der "lamor.html" und der "omgrofl.html" ?
Geändert von Antares (20.12.2006 um 18:15 Uhr)
Seiten, die ihren Inhalt auf Dateien mit *.php verteilen arbeiten ebenso mit Inkludierung.
Statt dem Inhalt wird eben das Grundgerüst drum herum inkludiert.
$_GET ist eine Autoglobale, warum nicht direkt damit arbeiten?Zitat