Hallo zusammen,
aufgrund eines aktuellen Vorfalls (siehe Forumthread) möchte ich mein Browsergame Aysalia Arena sicherer gestalten.
Würde mich jemand dahingehend unterstützen und das Spiel auf Sicherheit prüfen (kann man sich auch ohne Passwort in Accounts einloggen, kann man durch bestimmte Formulareiengaben etc. Cheaten) und mir gegebenenfalls weitere Tipps geben?
aysalia.de
Sicherheit testen: Aysalia Arena
gepostet vor 16 Jahre, 4 Monate von azamaroth
gepostet vor 16 Jahre, 4 Monate von Dunedan
Du solltest eigentlich selbst wissen ob sowas möglich ist.
Aber grundsätzlich gilt: Eingaben die von Benutzerseite kommen nie irgendwo ungefiltert verwenden. Immer schön escapen. Das ist schon mal ein erster wichtiger Schritt.
Aber grundsätzlich gilt: Eingaben die von Benutzerseite kommen nie irgendwo ungefiltert verwenden. Immer schön escapen. Das ist schon mal ein erster wichtiger Schritt.
gepostet vor 16 Jahre, 4 Monate von Kampfhoernchen
Und natürlich alles auf Plausibilität prüfen. Sprich: Nicht auf gewünschte Baustufen oder vom Browser gelieferte IDs verlassen, sondern diese gegenprüfen.
gepostet vor 16 Jahre, 4 Monate von progs
Original von Dunedan
Du solltest eigentlich selbst wissen ob sowas möglich ist.
Aber grundsätzlich gilt: Eingaben die von Benutzerseite kommen nie irgendwo ungefiltert verwenden. Immer schön escapen. Das ist schon mal ein erster wichtiger Schritt.
Es gibt immer Sicherheitslücken, von daher ist sowas nicht verkehrt. Wenn ich Zeit hätte, würde ich mich dazu bereiterkären.
gepostet vor 16 Jahre, 4 Monate von Dunedan
Original von progs
Es gibt immer Sicherheitslücken, von daher ist sowas nicht verkehrt. Wenn ich Zeit hätte, würde ich mich dazu bereiterkären.
Natürlich gibt es immer Bugs. Sicherheitslücken muss es allerdings nicht zwangsläufig geben.
Und meine Aussage spielte auf das einloggen ohne Passwort an. Denn da sollte man sich schon sicher sein.
gepostet vor 16 Jahre, 4 Monate von progs
Beim einloggen und solchen Standardsachen würde ich auch sagen, das sollte eigentlich ohne Lücken sein. Aber bei den anderen Sachen passiert es sehr oft, dass man halt von den 30 Werten nur 29 überprüft und eine vergisst.
gepostet vor 16 Jahre, 4 Monate von mail-me
Original von progs
Beim einloggen und solchen Standardsachen würde ich auch sagen, das sollte eigentlich ohne Lücken sein. Aber bei den anderen Sachen passiert es sehr oft, dass man halt von den 30 Werten nur 29 überprüft und eine vergisst.
deswegen baut man nicht erst hinterher die checks ein, sondern man überlegt sich bzw. verwendet von Anfang an eine Struktur, bei der das nicht passiert
gepostet vor 16 Jahre, 4 Monate von Fobby
Original von mail-me
Original von progs
Beim einloggen und solchen Standardsachen würde ich auch sagen, das sollte eigentlich ohne Lücken sein. Aber bei den anderen Sachen passiert es sehr oft, dass man halt von den 30 Werten nur 29 überprüft und eine vergisst.
deswegen baut man nicht erst hinterher die checks ein, sondern man überlegt sich bzw. verwendet von Anfang an eine Struktur, bei der das nicht passiert
Sollte man - wenn einem aber erst später gesat wird, wie man das macht, muss es auch anders gehen
Da hier viele Hobbyprojektler unterwegs sind, ist dies sicher kein Einzelfall. Aber dann lieber 29/30 Sicherheitslücken gestopft als eine "offene" Datenbank für jedes Scriptkiddie.
gepostet vor 16 Jahre, 4 Monate von None
Hmmm
* Formulare immer prüfen
* URL Parameter immer prüfen
* Escaping abfangen
* SQL-Injections abfangen (Tip: bei PHP mal PDO ansehen)
Gaaaannnzzzz grob gesagt
* Formulare immer prüfen
* URL Parameter immer prüfen
* Escaping abfangen
* SQL-Injections abfangen (Tip: bei PHP mal PDO ansehen)
Gaaaannnzzzz grob gesagt
gepostet vor 16 Jahre, 4 Monate von Drezil
[list=1]
[*]Schauen, ob alle angaben aus $_REQUEST, $_POST, $_GET, $_COOKIE gegengeprüft werden (schnell gemacht mit "suchen" nach diesen vars im editor) durch funktionen wie intval(), abs(), numeric(), oder bei strings regex, mysql_real_escape_string, etc.
[*] Parameter immer auf plausabilität prüfen (z.b. ein && uid=... bei sql-deletes anhängen (wobie uid natürlich auch gecheckt werden muss, macht man aber eig immer bei der loginprüfung), schauen, ob vorraussetzungen stimmen, etc. pp.)
[*]DB-verändernde Aktionen in Tranaktionen kapseln um so die gängigsten Nebenläufigkeitsprobleme auszuschalten
[*]keine wichtigen sachen PLAIN im cookie speichern und cookie mit einem cookiehash (inkl. dynamischem salt) sichern
[*]Bei längeren Texteingaben (Nachrichten etc.) auf JS-Code prüfen. Am besten HTML ganz verbieten und einen bb-code ähnlichen parser verwenden. Sonst kann man per JS z.b. die session hijacken, daten im hintergrund an andere server senden (die same-origin-policy kann man duch einbinden von imgs mit passenden parametern umgehen), das cookie (das vielleicht das gehashte pw oder andere sensible informationen enthält) auslesen, per xmlhttprequest weitere anfragen senden (z.b. an options.php?changepw=foo etc.) und noch viel andere tolle sachen mehr (XSS :p).
[/list=1]
Wenn die punkte alle sicher sind, dann seher ich eigentlich keine häufigen angriffsvektoren mehr.
[*]Schauen, ob alle angaben aus $_REQUEST, $_POST, $_GET, $_COOKIE gegengeprüft werden (schnell gemacht mit "suchen" nach diesen vars im editor) durch funktionen wie intval(), abs(), numeric(), oder bei strings regex, mysql_real_escape_string, etc.
[*] Parameter immer auf plausabilität prüfen (z.b. ein && uid=... bei sql-deletes anhängen (wobie uid natürlich auch gecheckt werden muss, macht man aber eig immer bei der loginprüfung), schauen, ob vorraussetzungen stimmen, etc. pp.)
[*]DB-verändernde Aktionen in Tranaktionen kapseln um so die gängigsten Nebenläufigkeitsprobleme auszuschalten
[*]keine wichtigen sachen PLAIN im cookie speichern und cookie mit einem cookiehash (inkl. dynamischem salt) sichern
[*]Bei längeren Texteingaben (Nachrichten etc.) auf JS-Code prüfen. Am besten HTML ganz verbieten und einen bb-code ähnlichen parser verwenden. Sonst kann man per JS z.b. die session hijacken, daten im hintergrund an andere server senden (die same-origin-policy kann man duch einbinden von imgs mit passenden parametern umgehen), das cookie (das vielleicht das gehashte pw oder andere sensible informationen enthält) auslesen, per xmlhttprequest weitere anfragen senden (z.b. an options.php?changepw=foo etc.) und noch viel andere tolle sachen mehr (XSS :p).
[/list=1]
Wenn die punkte alle sicher sind, dann seher ich eigentlich keine häufigen angriffsvektoren mehr.
gepostet vor 16 Jahre, 4 Monate von None
Drezil hat es ja auch schon angesprochen und zwar das Salt(en) bei einem Hash Wert.
phpsec.org/articles/2005/password-hashing.html
phpsec.org/articles/2005/password-hashing.html
gepostet vor 16 Jahre, 4 Monate von cherry
Wilde Sachen koennen auch passieren wenn man die Benutzereingabe zwar gegencheckt und nichts macht falls sie Mist enthaelt aber sie dennoch einfach ausgibt. Das passiert wenn Du zum Beispiel mit der Eingabe des vorhergehenden Seitenaufrufs die neue Seite befuellst.
Damit kann sehr einfach die Ausgabe und das Verhalten Deiner Seite veraendert werden und Besucher koennen mit manipulierten Links hinters Licht gefuehrt werden.
Damit kann sehr einfach die Ausgabe und das Verhalten Deiner Seite veraendert werden und Besucher koennen mit manipulierten Links hinters Licht gefuehrt werden.
gepostet vor 16 Jahre, 4 Monate von azamaroth
Danke schonmal für eure Antworten,
eigentlich war es von Anfang an nicht geplant, dass Aysalia "offiziell" wird. Es war eigentlich ein Übungsprojekt um PHP + SQL zu lernen. Es lief dann aber doch ganz gut, so dass ich es dann öffentlich gemacht habe.
Naja, und seit kurzem beschäftigt mich halt das Thema "Sicherheit"...
eigentlich war es von Anfang an nicht geplant, dass Aysalia "offiziell" wird. Es war eigentlich ein Übungsprojekt um PHP + SQL zu lernen. Es lief dann aber doch ganz gut, so dass ich es dann öffentlich gemacht habe.
Naja, und seit kurzem beschäftigt mich halt das Thema "Sicherheit"...
gepostet vor 16 Jahre, 4 Monate von TheUndeadable
> Naja, und seit kurzem beschäftigt mich halt das Thema "Sicherheit"...
Ein guter Blog zu dem Thema:
blogs.msdn.com/hackers/default.aspx
Dort findest du auch weitergehende Links, die nicht nur für ASP.Net, sondern für jede Art von Webprojekten relevant sind.
Filterung von Daten ist nicht alles!
Ein guter Blog zu dem Thema:
blogs.msdn.com/hackers/default.aspx
Dort findest du auch weitergehende Links, die nicht nur für ASP.Net, sondern für jede Art von Webprojekten relevant sind.
Filterung von Daten ist nicht alles!
gepostet vor 16 Jahre, 4 Monate von splasch
Weiters sollte man auch drauf achten das die Session nicht so einfach geklaut werden kann.
Ist auch eine beliebte Methode um sich wo zugang zu verschaffen ohne das man sich Einlogen muß.
Dabei ist zu beachten das Session Id von fremden vorgeben werden können.Daher beim Login script drauf achten das immer eine neue Session id erstellt wird und nicht die übergeben wurde ( http aufrufs,link ).
(bsp login.php/?PHPSESSID=vorgeben) Wenn sich nacher das Opfer mit dem link einlogt.
Dann ist dem Angreiffer gleich auch die Session Id bekannt wenn kein schutz getroffen wurde.Und auch wirklich beim Login mit übernohmen wird und der Angreiffer nur mehr warten muß bis sich jemand mit dem Link eingelogt hat.
Danach kann der Angreiffer die Session benutzen wenn keine Schutz vorkehrungen getroffen wurden.
Desweiteren werden gern Session id im cookies gespeichert die der Angreiffer auslesen kann und dann wenn kein schutz exitert weiter verwenden kann.
Daher immer prüfen ob der Session besitzer auch wirklich der ist der sich Eingelogt hat bwz ob jemand fremdes nun auf diese Session zugreift.
Zum Thema Sicherheit und cheatschutz gibst sovieles was man beachten muß.
Das es momentan zuviel were alles aufzuzählen.
Aber bei bestimmten Anfragen kann man sicher dann darauf näher eingehen.
Wie man sich dafür schützen kann und was man alles verwenden kann um solche angriffe zu erkennen und dementsprechend dann auch blockieren.
Mfg Splasch
Ist auch eine beliebte Methode um sich wo zugang zu verschaffen ohne das man sich Einlogen muß.
Dabei ist zu beachten das Session Id von fremden vorgeben werden können.Daher beim Login script drauf achten das immer eine neue Session id erstellt wird und nicht die übergeben wurde ( http aufrufs,link ).
(bsp login.php/?PHPSESSID=vorgeben) Wenn sich nacher das Opfer mit dem link einlogt.
Dann ist dem Angreiffer gleich auch die Session Id bekannt wenn kein schutz getroffen wurde.Und auch wirklich beim Login mit übernohmen wird und der Angreiffer nur mehr warten muß bis sich jemand mit dem Link eingelogt hat.
Danach kann der Angreiffer die Session benutzen wenn keine Schutz vorkehrungen getroffen wurden.
Desweiteren werden gern Session id im cookies gespeichert die der Angreiffer auslesen kann und dann wenn kein schutz exitert weiter verwenden kann.
Daher immer prüfen ob der Session besitzer auch wirklich der ist der sich Eingelogt hat bwz ob jemand fremdes nun auf diese Session zugreift.
Zum Thema Sicherheit und cheatschutz gibst sovieles was man beachten muß.
Das es momentan zuviel were alles aufzuzählen.
Aber bei bestimmten Anfragen kann man sicher dann darauf näher eingehen.
Wie man sich dafür schützen kann und was man alles verwenden kann um solche angriffe zu erkennen und dementsprechend dann auch blockieren.
Mfg Splasch
gepostet vor 16 Jahre, 4 Monate von Kallisti
Original von Drezil
[list=1]
[*]keine wichtigen sachen PLAIN im cookie speichern und cookie mit einem cookiehash (inkl. dynamischem salt) sichern
[/list=1]
Wo genau ist da der Sinn? Cookies brauchst du um eine Session zuzuordnen, ob da nun nen hash oder die session id drin steht, ist im Falle eines Angriffes mal total egal - hijacken kann man sie so oder so, warum also hashen?
gepostet vor 16 Jahre, 4 Monate von splasch
warum also hashen
Hash werden gern dazu verwendet um zu prüfen ob sich nun 2 User an und der selben Session vergreiffen.Wird so ein zugriff festgestellt dann werden beide User ausgelogt und die Session wird ungültig.
Beim Hash handelt sich meisten um ein Zufällige Zahl die ständig geändert wird.Sobald 2 oder mehre User drauf zugreiffen stimmt diese nicht mehr überein. Und das script leitet einen logout ein.
Mfg Splasch
gepostet vor 16 Jahre, 4 Monate von Kallisti
Okay, das war mir so noch nicht bekannt, aber da tut es jede beliebige Zufallszahl und du brauchst keine dynamischen salts oder so (ich seh noch ein, dass man hashed um ne bessere Verteilung zu bekommen^^).
Dynamische Salts sind wieder so nen Thema beim Hashen des eigentlichen Passworts in der Datenbank, allerdings wuerde ich das ganze dann nicht als salt in der DB speichern, sondern eher z.B. den Username + einen festen string im code an den pw string haengen. Nicht jeder, der die db crackt, hat auch direkt Zugriff auf den Code selbst und wenn man sowieso vorhandene Daten (wie den Namen) als Salt nutzt, ist das nicht so offensichtlich wie eine extra Spalte.
Geht ja auch primaer darum die Effizienz von Rainbow tables zu untergraben (wobei es bei den cleveren Verfahren dann wieder net so einfach ist).
www.matasano.com/log/958/enough-with-the-rainbow-tables-what-you-need-to-know-about-secure-password-schemes/
Dynamische Salts sind wieder so nen Thema beim Hashen des eigentlichen Passworts in der Datenbank, allerdings wuerde ich das ganze dann nicht als salt in der DB speichern, sondern eher z.B. den Username + einen festen string im code an den pw string haengen. Nicht jeder, der die db crackt, hat auch direkt Zugriff auf den Code selbst und wenn man sowieso vorhandene Daten (wie den Namen) als Salt nutzt, ist das nicht so offensichtlich wie eine extra Spalte.
Geht ja auch primaer darum die Effizienz von Rainbow tables zu untergraben (wobei es bei den cleveren Verfahren dann wieder net so einfach ist).
www.matasano.com/log/958/enough-with-the-rainbow-tables-what-you-need-to-know-about-secure-password-schemes/
gepostet vor 16 Jahre, 4 Monate von Kallisti
Um meine eigene Frage zu beantworten, ich denke bei hashed cookies ging es vielmehr um dies:
search.cpan.org/~oliver/Catalyst-Plugin-HashedCookies-0.05/lib/Catalyst/Plugin/HashedCookies.pm
Das mit dem Session einschraenken funktioniert ja auch nur extrem begrenzt, um Hijacking zu vermeiden... Wenn der Hijacker schnell genug ist, sperrt man damit den eigentlichen User aus.
search.cpan.org/~oliver/Catalyst-Plugin-HashedCookies-0.05/lib/Catalyst/Plugin/HashedCookies.pm
When HTTP cookies are used to store a user's state or identity it's important that your application is able to distinguish legitimate cookies from those that have been edited or created by a malicious user.
Das mit dem Session einschraenken funktioniert ja auch nur extrem begrenzt, um Hijacking zu vermeiden... Wenn der Hijacker schnell genug ist, sperrt man damit den eigentlichen User aus.