Sicherheit

Was tut ihr alles für die Sicherheit eures BGs? Was muss man alles beachten? Mir fällt spontan folgendes ein:

• Überall, wo User irgendwas eingeben dürfen, können sie HTML oder JS eingeben, das ist gefährlich
• User können über GET alles mögliche an den Server übermitteln, auch wenn die Oberfläche keinen Link/Button dafür bietet
• Multis
• Bei dauerhaften Sessions können einem Spieler Links untergeschoben werden, die ihn ungewollt eine Aktion auslösen lassen ()

Was gibts noch zu beachten, wie löst ihr diese Probleme?
Gruß Michael

Bei dauerhaften Sessions können einem Spieler Links untergeschoben werden, die ihn ungewollt eine Aktion auslösen lassen ()

Das versteh ich net.
Grundsätzlich: Alles was von draußen kommt escapen und lieber 2 mal als gar nicht prüfen. Spiel einfach selber mal mit URLs rum.
IP-Checks würde ich ebenfalls aktivieren.

Das mit dem "Links unterschieben" verstehe ich auch nicht, ansonsten.
- Alles, was ein Spieler eingibt und irgendwie an die Datenbank gelangt ordentlich escapen. Numerische Werte auch wirklich in numerische Werte umwandeln (z.B. in PHP mit intval( $_POST['menge'] ); ) um Alphanumerische Werte mit der entsprechenden Escape Funktion der Datenbank (bei MySQL z.B. mysql_escape_real) escapen.
- Alles, was ein Spieler eingibt und irgendwie im Browsergame dargestellt werden kann (Namen, Nachrichten, Profile...) ordentlich HTML escapen (in PHP mit htmlentities( $input ); )
- Immer überprüfen, ob eine Aktion zum gegenwärtigen Zeitpunkt möglich ist. Also nicht nur dafür sorgen, daß der Spieler den Link nicht sieht, sondern immer für den Fall gewappnet sein, daß der Spieler Daten manipuliert.
z.B. Ein Spieler möchte beim Händler Sachen einkaufen, Händler gibt es nur in der Stadt. Hier muß überprüft werden, ob der Spieler wirklich in einer Stadt ist, das ausblenden des Links für "Händler" allein bringt gar nichts
- Es ist übrigens egal, ob die Daten per GET oder POST kommen - fälschen kann man alles

Original von Itchy
- Alles, was ein Spieler eingibt und irgendwie an die Datenbank gelangt ordentlich escapen.

ALLES egal von wo es kommt sollte escapet werden bevor es in die DB kommt
de.php.net/manual/en/security.php
www.hardened-php.net/publications.27.html

Original von MichaelB
Bei dauerhaften Sessions können einem Spieler Links untergeschoben werden, die ihn ungewollt eine Aktion auslösen lassen (

Damit meine ich etwas ala:
Guckt euch meine tollen Urlaubsfotos auf meiner Seite an: klick
Und auf der Seite befindet sich:
@ Kampfhörnchen
Und was macht der IP-Check?
@all
Was genau heißt escapen? Alle Tags entfernen?

Beispiel:
$db->query('SELECT * FROM bla WHERE blub = "'.$_POST['bla'].'");
Jetzt steht in $_POST['bla'] folgendes drin:

" OR blub = "großer mist"
Damit haste dann folgende Query:
SELECT * FROM bla WHERE blub = "" OR blub = "großer mist"
Die natürlich nicht das liefert was du wolltest, weil da eben z.B. ne Zahl drin stehen sollte, also irgendwas wie
SELECT * FROM bla WHERE blub = "3" erwartest hast.
Google mal nach SQL-Injection.
User sollten kein HTML eingeben können. Dafür gibt es ja BB-Codes. Und wer auf so nen Link klickt -> selbst schuld.
IP-Check prüft die IP des Users. Schützt vor Session-Übernahmen. Allerdings sollte man das Feature abschaltbar machen, da AOL-User öfters mal über verschiedene IPs kommen.

Alles auf Form und Sinn prüfen, was vom User kommt und auch schauen, ob der User authorisiert ist, die Aktion auszuführen. Z.B. nicht einfach eine per ID übergebene Armee auslesen und steuern sondern auch prüfen, ob der User überhaupt mit der Armee was machen darf (ob er überhaupt wissen darf, dass sie existiert).
Jede Zeichenkette, die in die DB kommt vorher escapen (und bitte magic_quotes ausschalten, immer manuell machen).
Wenn GET-Variablen in eine SQL-Abfrage sollen, dann möglichst nur Zahlen übergeben. Die kann man in Integer umwandeln und so kann nichts wie "OR blub = "grosser Mist da drin stehen.
Hatte da schon die skurrilsten Beschwerden...

Ich habe da in meinem Framework einen Filter, der zumindest schonmal grundsätzlich sicherstellt, das ich das bekomme, was ich zu bekommen erwarte (kennt halt die grundsätzlichen Arten: (unsigned) Int, String, (unsigned) float/double, bool).
Das ersetzt natürlich das logische Kontrollieren nicht, aber wenn ich ein Int erwarte, bekomme ich ein Int.
Das bedeutet auch, das man alle Input-Variablen registrieren muss, aber so hat man dann auch gleich eine Übersicht, was denn eigentlich von aussen rein kommt. Natürlich werden alle nicht registrierten Variablen gelöscht, so das auch diese Angriffsfläche ausgeschaltet sein sollte.
Ich denke, das mit dem HTML-Kodieren mach ich da auch gleich mal mit rein, sicher sinnvoller als es bei der Ausgabe umzuwandeln.
Kennt jemand eine gute BB-Code PHP-Bibliothek, die sich leicht integrieren/erweitern lässt und keine Abhängigkeiten hat?
Was kann man eigentlich gegen diese "Cross-Link-Attacke", die MichaelB geschildert hat, unternehmen? Wäre da ein Referer-Check sinnvoll/ausreichend? Bloß gibts ja viele Benutzer, die Referer nicht weitergeben, weil sie nachvollziehbarer Weise ihre Privatsphäre sichern wollen... Wenn man nicht auf permanente Sessions verzichten will, fällt mir aktuell kein Weg ein, solche Angriffe wirklich zu unterbinden.

Mein Lösungsvorschlag für das Problem mit den persistenten Sessions:
Die Session soll wohl persistent bleiben, damit sich der Spieler nicht immer einloggen muß. Dazu reicht aber eine Minisession, bestehend aus dem User-Login.
Wenn man das Game aufruft, erhält der Server das Cookie dieser Minisession und zeigt ihm eine Seite, von der er dann über einen meta-refresh ins eigentliche Browsergame weitergeleitet wird, wo eine neue Session erstellt wird, die dann eben nicht persistent ist, dabei werden alle Aufrufparameter (GET und POST) ignoriert.
Das schlimmste, was man dann mit so einer Attacke erzielen könnte, wäre dann ein Login ins Browsergame.

Bei Image-Uploads darauf achten, dass kein php-Code eingeschleust werden kann:
Dateiendung prüfen
Prüfen, ob es ein gültiges Bild ist
zusätzlich per .htacces für den Bilder-Ordner nur jpeg/png/gif erlauben

Original von Itchy
Mein Lösungsvorschlag für das Problem mit den persistenten Sessions:
Die Session soll wohl persistent bleiben, damit sich der Spieler nicht immer einloggen muß. Dazu reicht aber eine Minisession, bestehend aus dem User-Login.
Wenn man das Game aufruft, erhält der Server das Cookie dieser Minisession und zeigt ihm eine Seite, von der er dann über einen meta-refresh ins eigentliche Browsergame weitergeleitet wird, wo eine neue Session erstellt wird, die dann eben nicht persistent ist, dabei werden alle Aufrufparameter (GET und POST) ignoriert.
Das schlimmste, was man dann mit so einer Attacke erzielen könnte, wäre dann ein Login ins Browsergame.

Und was machst du wenn jemand auf so einen link hereinfällt während er eingelogt ist ? Gab da mal so einen Fall den ich miterlebt hab. Die Leute wahren eingelogt und haben ins Forum geschaut, da war ein link drin auf ne Seite die so ein img hatte und schon war das geld/resourcen überwiesen

Und was machst du wenn jemand auf so einen link hereinfällt während er eingelogt ist ? Gab da mal so einen Fall den ich miterlebt hab. Die Leute wahren eingelogt und haben ins Forum geschaut, da war ein link drin auf ne Seite die so ein img hatte und schon war das geld/resourcen überwiesen

Ok, dann brauchst Du ein zusätzliches Sicherheitsmerkmal.
Eine einfache Lösung wäre ein Sequenz, die eingehalten werden muß, dabei werden die Aufrufe einfach durchnummeriert.
Also:
User logt sich ein und erhält die (zufällig bestimmte) Sequenz "1234". Die nächste Aktion, die der Benutzer durchführt, muß also die Sequenz 1235 tragen, danach die 1236 usw.
Beispiel:
script.php?action=login (1234 wird vergeben)
script.php?action=hauptbildschirm&seq=1235 (ok)
script.php?action=bauen_gebäude&seq=1236 (ok)
script.php?action=schicke_alle_ressourcen_an_spieler_100 (Manipulation, nicht ok!)
Es muß natürlich auch keine Sequenz sein, man könnte auch einen zufälligen Wert dranhängen, der bei der nächsten Aktion kommen muß.

soetwas ähnliches hab ich mir auch schon für mein spiel überlegt, das problem ist allerdings, wenn benutzer 2 fenster offen haben.
bsp: user hat 2 fenster offen mit der sequenz id=10000
1.fenster bekommt nach aufruf die id=10001
nächste gültige sequenz wäre 10002
das 2.fenster hat aber noch die alte sequenz 10000 und ruft 10001 auf -> fehler

Tabbing ist dann aber nahezu ausgeschlossen, oder?
edit: *brummel-grummel* Unwort: "Da war jemand schneller"..

Session-ID zwingend per GET an URL anhängen. Und wer seine Session-ID weitergibt, der sollte eh bestraft werden...

Session-ID zwingend per GET an URL anhängen. Und wer seine Session-ID weitergibt, der sollte eh bestraft werden...

Und dann postet einer im Forum nen Link und schon hat man die die Session-ID im Referer
Ich glaube eher, wer die Session-ID an die URL anhängt, sollte bestraft werden

also ich habe gelernt session id IMMER per Cookie

Sucht euch aus, was besser ist, wenn ihr die Session per Cookie speichert, sind solche Trick-Bilder ohne Probleme möglich (das kann jeder mit ein wenig HTML-Kenntnissen machen), wenn ihr die Session per GET übermittelt, gibt es immer Dumme, die mit ihrer SID um sich werfen...
Das eine kann man nicht verhindern, das andere kann man den Spielern einbrennen, bis sie es verhindern...

Reicht es denn nicht eine generierte Phrase in der session zu speichern und immer wieder an den Link zu hängen? So ein "counter" braucht man da doch eher weniger.
Mit dem Kopieren/einfügen von den Links ists dann auch nciht so schlimm. Kann ja eh keiner was damit anfangen (ausser halt gezielt Leute damit treffen und deren Phrase rausbekommen)
zu dem Escapen. prepared statements sind doch schon erfunden. Wieso nicht nutzen.

Aktionen werden bei mir immer per POST ausgeführt.
Damit ist die Ausführung per Bild schon einmal ausgeschlossen.
Bleiben 'nur' automatische JavaScript-Formulare auf fremden Websites.

Original von Störti
Sucht euch aus, was besser ist, wenn ihr die Session per Cookie speichert, sind solche Trick-Bilder ohne Probleme möglich (das kann jeder mit ein wenig HTML-Kenntnissen machen), wenn ihr die Session per GET übermittelt, gibt es immer Dumme, die mit ihrer SID um sich werfen...
Das eine kann man nicht verhindern, das andere kann man den Spielern einbrennen, bis sie es verhindern...

Sorry Störti, aber Du laberst Müll...
Ich hoffe, das Bild reicht Dir als Beweis.
Quellcode:

$img = imagecreate( 600, 30 );

$white = imagecolorallocate( $img, 255, 255, 255 );
$black = imagecolorallocate( $img, 0, 0, 0 );
imagestring( $img, 3, 10, 5, $_SERVER['HTTP_REFERER'], $black );
header( 'Content-type: image/png' );
imagepng( $img );

das funktioniert aber nur im IE, oder? na ja, ist schlimm genug.

Nein, das funktioniert mit jedem Browser, sofern man den Referer nicht durch irgendeine "Firewall" oder "Privacy-Software" unterdrückt. Wenn man das macht, gibs aber unter Umständen Probleme mit Seiten, die den Referer für legitime Zwecke überprüfen, z.B. werden Bilder oft nur angezeigt, wenn man sich auf der Seite befindet, nicht, wenn man von einem Forum aus linkt.
Das hast Du bestimmt schon mal in Foren gesehen, solche Bilder mit "Hotlinking nicht erlaubt".
Edit: hab gerade gesehen, daß beim Mozilla man das Verhalten der Referer auch im "about: config" Menü einstellen kann.

Hm, da wärs aber generell von der Browserseite her sinnvoller und sicherer, wenn nur die richtige Seite als Referrer übermittelt wird, als alles nach ? weggelassen wird.
Referrer sind schon nicht unsinnvoll und könnten hier auch als Sicherheitsmerkmal eingesetzt werden: Wenn der Referrer nicht auf die eigene Seite zeigt, werden keine Aktionen durchgeführt. Und schon ist dieses Cross-Site-Linking unterbunden...
Probleme gibts dann eben nur mit Leuten, die ihre Referrer unterbinden, aber ich sage mir, das ich als BG-Anbieter durchaus gewisse Sachen einfach voraussetzen kann bei den Usern.
Wer damit nicht leben will, muss sich was anderes suchen (obwohl man so kaum denken wird, wenn man mit dem BG Geld verdienen will... ).

Referer sind als Sicherheitsmerkmal genauso unsicher, da man die ebenso leicht manipulieren kann.
Wer ein Maximum an Sicherheit haben möchte, müßte zum einen ein Request Token (Counter, Hashwert, Zufallszahl, wasauchimmer) einführen, zum anderen wäre auch über SSL Verschlüsselung nachzudenken.
Man sollte aber auch so realistisch bleiben und sich eingestehen, daß 100%ige Sicherheit (insbesondere bei leichtsinnigen Usern) im Internet nicht möglich ist. Ich hab zwar noch von keiner Phishing Attacke bei Browsergames gehört, aber sowas würde natürlich wiederum alle noch so tollen Sicherheitsmechanismen aushebeln, wenn der User darauf reinfällt.

Original von Itchy
Referer sind als Sicherheitsmerkmal genauso unsicher, da man die ebenso leicht manipulieren kann.[..]

Die sind ja als Sicherheit für den User gedacht, wenn ein User seine Referer manipuliert, dann ist er selber schuld.
100%ige Sicherheit gibt es natürlich nicht, aber es ist für mich ein Unterschied, ob ein User einen Nachteil erleidet, weil er so blöd ist seine Userdaten rauszugeben, oder ob er einfach nur auf einen Link (womöglich im Forum des Spiels) geklickt hat.

ich weiß nicht bei mir wird einfach bei jeder aktion vorher geprüft ob die Aktion gültig und sinnvoll ist..
damit schließt sich praktisch alles aus... zb wird die position des spielers über
save_char.php?x=123&y=456&map=sowieso
gespeichert.
klar kann man die seite auch einfach so aufrufen, aber wenn jemand nicht auf einem benachbarten feld von (123,456) auf der karte sowieso steht, passiert nichts.

Original von ItchySorry Störti, aber Du laberst Müll...

Ok, geb mich geschlagen, diese Sache mit dem Referer vergesse ich gerne...

ich weiß nicht bei mir wird einfach bei jeder aktion vorher geprüft ob die Aktion gültig und sinnvoll ist..

damit schließt sich praktisch alles aus... zb wird die position des spielers über
save_char.php?x=123&y=456&map=sowieso
gespeichert.
klar kann man die seite auch einfach so aufrufen, aber wenn jemand nicht auf einem benachbarten feld von (123,456) auf der karte sowieso steht, passiert nichts.
Wenn dein Spiel vom Konzept her sowas zulässt, ist das praktisch, aber wenn du z.B. ein Spiel hast, wo man z.B. ohne Transportmöglichkeiten (Lasttiere, Transportschiffe) an irgendwen einfach Waren schicken kann, dann ist sowas schon ohne weiteres auch sinnvoll:
www.meinspiel.de/handeln.php?aktion=ware_senden&ware=gold&anzahl=1000&empfaenger=1234
Das Script weiss ja nicht, ob das nun gewollt ist oder nicht (und kann es auch nicht wissen).
Wenn man die Daten nun per POST übergibt, ist es zumindest etwas aufwändiger, als einfach ein Bild zu basteln, was sicherlich viele abschreckt (aber möglich ist es immer noch).

oder man macht die sessionid zweigeteilt: der eine Teil ist im Cookie, der andere Teil in der url. Damit sollte man sowohl die leichtsinnige weitergabe der session-id als auch das Phishing verhindern, oder?

Wie verhindert das Phishing?
Außerdem ist Deine Idee nur zur Hälfte gedacht, wenn Du länger drüber nachdenkst, kommst Du wahrscheinlich selber auf den großen Haken

ok, Phishing ist der falsche Ausdruck, ich meinte damit das klicken auf links ala test.de/acc_loeschen.php

Wenn ein User auf eine Phishing-Attacke reinfällt, kann man den Phisher nicht auf halten, da er dann ja die korrekten Accountdaten kennt und sich ganz legal einloggen kann. Damit weisst du nicht mehr, ob es der Phisher oder der richtige User ist und kannst nichts machen...
Solche richtig kritischen Aktionen würde ich immer per E-Mail mit irgendeinem Key bestätigen lassen. Der steht dann nur in der E-Mail und das ist dann wirklich sicher (aussser der Angreifer setzt auf Bruteforce um den key herauszufinden, aber wer macht sowas schon)...

Original von Störti
Solche richtig kritischen Aktionen würde ich immer per E-Mail mit irgendeinem Key bestätigen lassen. Der steht dann nur in der E-Mail und das ist dann wirklich sicher (aussser der Angreifer setzt auf Bruteforce um den key herauszufinden, aber wer macht sowas schon)...

Du willst jetzt aber nicht bei jedem Login eine E-Mail versenden?!

Er redet von kritischen Aktionen. Da seh ich bei BGs eigentlich nur die Accountlöschung, mehr nicht. Und die kann man wohl per eMail bestätigen lassen, denke ich.

Eine kritische Aktion ist aber auch, wenn ein Spieler, der Geld für das Spiel bezahlt, seinen Account wie auch immer an einen anderen Spieler verliert (sei es durch Weitergabe des Passwortes oder aber passiv [Accounthacking]) und dann die Leistungen, für die er bezahlt, nicht nutzen kann.
Dann könnte es vorkommen, dass er dich als Spielenwickler anschwärzen will.
Das sehe ich durchaus auch als kritische Situation an.

Das sollte aber dann doch klar im jeweiligen Vertrag geklärt sein, oder? Würde ich persönlich solche Bezahldienste anbieten, würde ich im Vertrag festlegen, das ich nicht für Unachtsamkeiten des Spielers verantwortlich bin, außer es liegt tatsächlich ein Fehler meinerseits vor. Bekommt man denn von der Bank das Geld zurück, wenn man auf nen Pisher reinfällt? Glaube nicht, außer man erwischt den Pisher.

@Toby, meinst du jetzt Pisser oder Phisher?!
Ich hatte mir schon gedacht, dass er mit kritischen Operationen, Dinge wie Passwort ändern, etc. meinte. Allerdings kam es so rüber als wollte er bei Logins Mails versenden. Man weiss ja nie auf was für Ideen man noch kommen kann
.
PS: So am rande: es wäre eine ziemlich sichere Methode Phishing zu verhindern.

Nein, ich will nicht bei jedem Login (am besten noch bei jeder Aktion) ne Mail versenden und bestätigen lassen...
Sind wir hier denn bei Play-by-E-Mail?
Wer seine Accountdaten weitergibt (ob an einen Sitter oder wegen Phishing) tut dies immer auf eigene Verantwortung. Kann ja jeder kommen "ich verkauf nen Premium-Account an nen Kumpel (schwarz) und klage dann das "verlorene" Geld ein"...
Alles was nicht nachgewiesen meine direkte Schuld (sprich Sicherheitslücken) ist, ist die Schuld des Spielers...

Original von pl-online
@Toby, meinst du jetzt Pisser oder Phisher?!

Beides.

PS: So am rande: es wäre eine ziemlich sichere Methode Phishing zu verhindern.
Das ist jetzt aber Ironie, oder?

Jo, das muß Ironie sein, weil je mehr (echte) E-Mails das System generiert, desto größer ist die Wahrscheinlichkeit, daß ein Benutzer auf eine Phishing-Attacke reinfällt.

Oh wunder, es war natürlich Ironie.
@Topic: Es gibt meines Wissens keinen wirklichen Schutz gegen Phishing. Man kann lediglich beim Auftauchen solcher Phishingmails bzw. Links die User davor warnen und ihnen empfehlen stetig ein Blick auf die URL zu werfen.