Online php spel beveiligen

Ziet er goed uit, alleen 2 minuten voor mijn password? No way, ik heb het zelf geprobeerd, heb hem na 3 dagen maar uitgezet, het duurde me te lang...

Wel leuke tutorial ;)
ik ben momenteel al een spel aan het maken dus kan ik kijken of ik wat dingen onveilig heb gedaan.
Bedankt ;)

Ziet er duidelijk uit
Is html_entities niet een handige toevoeging? Dan kun je in je ubb parser gewoon rekening houden met die entities. Dit voorkomt ook al een redelijk deel van de xss problemen.
En om dat soort dingen automatisch te doen met een foreach over je $_GET en $_POST in bijvoorbeeld je config file is ook handig dan vergeet je het niet zo snel.

oh ja hoor, 3 minuten is meer dan genoeg.

kijk maar even op www.plain-text.info
voor de meeste passes heeft die ongeveer 1-2 minuten nodig, maar voor sommigen ook minder.

en, html_entities beschouw ik als deel van de ubb parser..
natuurlijk is dat slim/nodig;)

edit: htmlspecialchar is NIET gemaakt om sql injection te voorkomen!
alleen al vanwege het feit dat het ' niet standaard converteert, en die parameter nogal eens vergeten wordt..

edit2: plain-text.info is neer..

Best handig.... Bedankt :P

Het gedeelte over timing exploits is interessant. In een vaag verleden heb ik hier iets over gelezen, maar was het alweer vergeten.

Kan je een query laten zien die de controle binnen MySQL doet? Zijn die 'geavanceerder' dan anders, of meer het standaard werk?

mooie tutorial, want ik ben juist bezig met een login systeem en dus is het wel handig dat ik weet waarop ik moet letten :)

@kasper,
gewoon redelijk standaard:
update geld set geld=geld-verstuurd_geld where geld>= verstuurd_geld

Ik vind dit altijd leuk om te lezen, want ik weet er ook wel het e.e.a. van... (ik ben bezig met http://www.chsweb.nl een textbased rpg, en bugfree (a))

Maar nou, ik post hier natuurlijk niet voor niets =')
Ik wou even kwijt dat het script van "Timing exploits" echt om te huilen is.

Je hebt het daarboven over input checken, please check dan ook ff of de input negatief is, want als iemand nu een negatief bedrag invoert, krijgt hij er geld bij. xD
Volgens mij zijn DIT de dingen waardoor spelers weggaan, als mensen hun geld zien verdwijnen waarvoor ze zo lang hebben gespaard.

Goed artikel!! Erg goed. Duidelijk, niet te lang en goede samenvatting van een aantal belangrijke veelgebruikte 'hacks'. Gelukkig kende ik ze allemaal en houd ik er rekening mee ;) maar er zullen zeker veel scripts online staan (vooral spelletjes, maar zoals je al zei, nog veel meer) waar niet met alles rekening gehouden wordt.

@MrJarod
Ik neem aan dat het voorbeeldje niet echt gebruikt wordt. Voor elke actie een functie lijkt me ietwat overdreven. De exploit is echter wel duidelijk uitgelegd en hoe je er rekening mee moet houden

@mrjarod

jung, daar gaat het toch helemala niet om.
ik ga als VOORBEELD toch ook geen compleet framework opzetten,
omdat ik dat als ik een spel zou maken ook zou gebruiken.

het doel van het voorbeeld was om die hack te verijdelen,
niet om een voorbeeld te geven van een 100% veilig bank script.

zo.

@vercetti

dank!:D

als je het doet moet je het ook goed doen

Er zijn nog veel mensen met een dynamisch IP-adres. Die ga je dus elke keer opnieuw laten inloggen? gezellig!

Bovendien, als je met cookies werkt heb je het probleem al niet van die img om iemand te bannen.

Laatste puntje: het logaritme van MD5 is inderdaad gecrackt, maar het is nog steeds relatief veilig.
Het veiligste is nog steeds een eigen hash maken, welke je voor 1x eens NIET opensource maakt! Anders is een combinatie van 2 hashes nog altijd het veiligst, bvb sha1 en md5.

Wim Mari?n wat is het probleem als mensen overnieuw in moeten loggen als ze opnieuw op internet komen. Niks is zo irritant als mensen op het account van een ander gaan zitten omdat ze toevallig bij die pc komen en er meteen vanalles mee uithalen.

En een eigen hash maken kan altijd nog werkt ook nog wel goed. Tevens is het natuurlijk handig om te zorgen dat de hash niet richting de gebruiker gaat, dan kan het ook niet "gekraakt" worden.

@huib

Ik vind, dat als je iets online zet als voorbeeld, dan moet je goede code online zetten, en niet halfgebakken. Daar kan niemand wat van leren.
Het gaat maar om 1 if-statement, dat hoort daar gewoon te staan, maar als je daar te lui voor bent hoor je geen tutorials te schrijven.

En anders reageer je nog even op een script van 14 maand oud waarbij de laatste reactie volgende week precies een jaar geleden is

Ik reageer op dit 50 maanden oud script omdat ik graag wil weten of dit alles nog steeds geldt. Het klinkt zeer logisch en ik vind het erg interessant om te lezen. Bedankt voor het delen!

(Ik merk dat de meeste tutorials hier 50+ maanden oud zijn, ik hoop dat het geen probleem is als ik nog steeds op deze reageer met evt. vragen/opmerkingen)