Cheatbeveiliging Js-games

[Clay]

Als ik voor een js game een highscore wil bijhouden zal er enige vorm van beveiliging in moeten zitten om te voorkomen dat spelo's absurde scores kunnen cheaten.

Het gaat er vooral om dat de score gepost moet worden om verwerkt te kunnen worden in een database, ingame cheaten is vrij makkelijk tegen te houden, maar die post kan je te makkelijk saboteren, en dat wil ik nou juist zo goed en zo kwaad het kan tegengaan.

Laatst bleek uit een topic dat je de submit van een form kan overschrijven met een eigen methode, zodat het dus niet meer mogelijk is om in de locatiebalk .submit() te gebruiken. Ook de .click() van een submitbutton kan je op deze manier mollen, zodat een gebruiker echt op die submit knop zal _moeten_ drukken. Gecombineerd met een hidden veld dat na een check op de onsubmit de "geldigheid" van de score garandeert kom je dus al een heel end, zeker als je daarnaast ook nog intervals zonder handler (dus niet clearable via locatiebalk) laat lopen die dingen controleren op misbruik.

Maar hoever moet je hier ueberhaupt in gaan voor het overkill wordt? Je kan namelijk alsnog via de locatiebalk ALLES aanpassen. Globale vars, hele methodes kan je aanpassen en laten doen wat jij wil iig als je er genoeg van weet. Tot nu toe heb ik ook alles wat ik heb verzonnen weten te "kraken"

Heeft iemand hier meer mee gedaan?

[Pelle]

Nog nooit echt wat mee gedaan, maar ook wel eens over zitten brainstormen (volgens mij was dat met McVirusS.. ging over Flash en hiscores geloof ik).

Ik denk dat je er nooit aan zult ontkomen dat JS clientside is en dus ten alle tijden bekeken en dus aangepast kan worden.

Ik kan me echter wel een aantal dingen verzinnen die het een eventuele kwaadwillende lame score-hax0r moeilijker kunnen maken.
Je zou de variabelen die voor je scores relevant zijn, serverside kunnen genereren.. maak er een of andere vage md5-hash van ofzo. Dan moet je zowiezo al veel meer geduld hebben om uit te vogelen welke variabele waarvoor gebruikt wordt.

Verder kun je natuurlijk je game in een popup rossen, zonder locatiebalk enzo, en er een check inbouwen die kijkt of er wel een opener bestaat. Zo niet, dan is 'ie niet in een popup, en dus met locatiebalk.

Dan heb je natuurlijk ook nog code obfuscators, ligt een beetje in het verlengde van m'n eerste ideetje over ranzige var-naams laten genereren.

Hmm.. lastig.. misschien dat je je variabelen waarmee je de score berekent, zo kunt instellen dat de score op de server pas wordt opgeslagen als de score die verstuurd is, te delen is door een of ander wazig priemgetal wat je alleen op de server kent. Als daar een heel getal uitkomt, was de score valid. Als dat niet het geval was, is er op de een of andere manier gekloot met de score.

[Bosmonster]

je kunt wel verificeren of level-variabelen niet aangepast zijn door deze met de score mee te sturen.

Maar zolang de score zelf al een variabele is

[Verwijderd]

Even een base64 encodering erover heen halen

[Verwijderd]

De beloning voor een highscore de moeite van het hacken niet waard maken

[Bosmonster]

volgens mij zijn hack-cheats alleen op volgende manieren mogelijk:

A. Via location-bar
B. Via download/edit

Optie B is vrij makkelijk te achterhalen door te checken oftie wel op jouw server staat.

Optie A is lastiger. Pelle's check om deze uit te schakelen met een popup/check werkt al een heel eind. Maar is er geen manier om te achterhalen vanwaar een functie is uitgevoerd?

[Janoz]

Op maandag 10 juni 2002 15:48 schreef Bosmonster het volgende:
volgens mij zijn hack-cheats alleen op volgende manieren mogelijk:

A. Via location-bar
B. Via download/edit

Optie B is vrij makkelijk te achterhalen door te checken oftie wel op jouw server staat.

Optie A is lastiger. Pelle's check om deze uit te schakelen met een popup/check werkt al een heel eind. Maar is er geen manier om te achterhalen vanwaar een functie is uitgevoerd?

B .. De refferer is ook erg simpel te facken hoor. Het blijft communicatie tussen client en server.. Iemand kan zich als browser voor kunnen doen en gewoon de juiste gegevens opvragen en de juiste gegeven versturen..

Een clientside webbased spel is nooit onhackable te maken..

[roytanck]

Ik heb ff geen url's bij de hand, maar er zijn een aantal tools die scripts kunnen encrypten tot iets compleet onleesbaars. Die pagina's doen het dan nog wel, maar je moet (echt!) van goeden huize komen om er iets in te veranderen...

[r0bert]

>> score in js variabele binnen pagina bewaren.
>> ready, posten via post-method naar hiscore.php (hidden field ofzo)
--
>> ref checken
>> uitlezen $_POST["scorevariabele"] en schrijven naar db

wat is daar fout mee dan ?

[André]

Op maandag 10 juni 2002 15:48 schreef Bosmonster het volgende:

Optie A is lastiger. Pelle's check om deze uit te schakelen met een popup/check werkt al een heel eind.

Pelle's check kun je volgens mij omzeilen door op Ctrl-N te drukken.

Is er niet een onchange event o.i.d. voor de locationbar.

[Clay]

met arguments.caller en arguments.callee kan inderdaad enigszins tracken waar de aanroep vandaan komt

Op maandag 10 juni 2002 15:54 schreef r0bert het volgende:
>> score in js variabele binnen pagina bewaren.
>> ready, posten via post-method naar hiscore.php (hidden field ofzo)
--
>> ref checken
>> uitlezen $_POST["scorevariabele"] en schrijven naar db

wat is daar fout mee dan ?

Omdat je dus retemakkelijk kan beinvloeden wat er gepost wordt.

[Bosmonster]

Op maandag 10 juni 2002 15:53 schreef Janoz het volgende:

[..]

B .. De refferer is ook erg simpel te facken hoor. Het blijft communicatie tussen client en server.. Iemand kan zich als browser voor kunnen doen en gewoon de juiste gegevens opvragen en de juiste gegeven versturen..

Een clientside webbased spel is nooit onhackable te maken..

Bedoelde ook niet de referrer, maar kijken wat de locatie van je pagina is (location). Dat is niet te faken voor zover ik weet.

met arguments.caller en arguments.callee kan inderdaad enigszins tracken waar de aanroep vandaan komt

En?

[Anders]

Op maandag 10 juni 2002 15:53 schreef Janoz het volgende:
B .. De refferer is ook erg simpel te facken hoor. Het blijft communicatie tussen client en server.. Iemand kan zich als browser voor kunnen doen en gewoon de juiste gegevens opvragen en de juiste gegeven versturen..

Dit hebben we - ik ben Klei's collega en verantwoordelijk voor de server-side grappen rond het spel - in het concrete geval waaruit de post voortkwam, opgelost door bij aanvang van het spel twee unique variableen aan te maken:

PHP:

<?$form_id = md5(uniqid(rand(),1));$save_id = md5(uniqid(rand(),2));?>

.. die beide in de database worden opgeslagen, en waarvan form_id client-side wordt meegestuurd en save_id in een session-cookie wordt gezet. Na het spel en voor het invoegen van de score in de database wordt gekeken of de combinatie van de variable vanuit het formulier en de session_cookie, in de database voorkomt. Zo nee, vette pech. Als je de boel kopieert en thuis submit (bijv) heb je geen session_cookie en zal ie de submit niet accepteren. Wanneer je cookies uitschakelt (om sessies sowieso te omzeilen) werkt er helemaal niks.

Een clientside webbased spel is nooit onhackable te maken..

Klopt, daar kom je eenvoudigweg niet onderuit. Ik was bezig met het schrijven van deze reactie, waarin ik schreef dat iedereen (die het kan, tenminste) simpelweg een webbrowser kan schrijven die sommige javascript-reut wel, en andere niet uitvoert. Daarbij moest ik opeens denken aan The Proxomitron, een soort proxyprogrammaatje dat ebpagina's door een filter kan halen en waarmee je dus heel simpel allerlei reut (zoals banners, geluidjes) kunt filteren. Ik heb dat losgelaten op de game en bv. de volgende stukjes tekst:

• onsubmit
• onLoad
• onerror

.. vervangen door

• Xonsubmit
• XonLoad
• Xonerror

.. waardoor die dingen niet meer werkten, vervolgens met hetzelfde programmatje de score van het formulier ingevuld en vrolijk gesubmit. Tadaa, een nieuwe highscore. Op die manier kun je echt alles voor elkaar krijgen wat je wilt. Voorbeeldje waarbij ik 'm heb losgelaten op m'n buurman (wat was z'n nick ook alweer):



Conclusie: DHTML-games zijn nimmer te beveiligen. Hooguit is alles verdomd lastig te maken. Bijvoorbeeld een hoop encryptieshit, alles op 1 regel zetten, veel verwarring stichten in je script etc etc.

Gelukkig gaat het in het praktijkgeval om een redelijk low-profile-spel (je kunt er geen auto of reis mee winnen), maar jammer is het wel. Zeker omdat Klei verdomd vette DHTML-spellen kan maken


/Edit: PROEST - ik had het proggie nog aanstaan toen ik deze reactie editte, vandaar dat ik het twee keer over "Klei" heb

[Anders]

Op maandag 10 juni 2002 17:15 schreef Bosmonster het volgende:
Bedoelde ook niet de referrer, maar kijken wat de locatie van je pagina is (location). Dat is niet te faken voor zover ik weet.

Maar hoe zie je dat voor je? Serverside checken heeft geen zin, want bij het submitten van de score vanaf je eigen computer stuur je 'm naar de pagina op de server dus dan klopt de location. Van het JavaScript-spel zelf kun je de source copy-pasten als je op de game-pagina bent, dus daar heb je ook niks met location te maken.
Een JavaScript-location-check op de game-pagina kun je er thuis ook zo uitslopen, en op de submit-pagina zit je weer op de juiste location.

.. of begrijp ik je bedoeling gewoon verkeerd?

[Bosmonster]

Op maandag 10 juni 2002 17:27 schreef Anders het volgende:

[..]

Maar hoe zie je dat voor je? Serverside checken heeft geen zin, want bij het submitten van de score vanaf je eigen computer stuur je 'm naar de pagina op de server dus dan klopt de location. Van het JavaScript-spel zelf kun je de source copy-pasten als je op de game-pagina bent, dus daar heb je ook niks met location te maken.
Een JavaScript-location-check op de game-pagina kun je er thuis ook zo uitslopen, en op de submit-pagina zit je weer op de juiste location.

.. of begrijp ik je bedoeling gewoon verkeerd?

Nee je hebt gelijk Maar als jouw serverside methode werkt dan is dat probleem toch grotendeels opgelost?

De location-bar blijft ook een groot gat.. daar kun je op ieder willekeurig moment functies mee uitvoeren en variabelen mee veranderen...

als die arguments.caller shit te gebruiken is in deze context zou dat ook al aardig opschieten.

[Clay]

En als je nou het hele form wat de reut submit volledig dynamisch aanmaakt.

code:

form = document.createElement("form")
form.setAttributes( blah ...

document.body.appendChild(form);

enz...

Dan lijkt het mij dat je het met proxomitron ook niet meer kan aanpassen. En die arguments.caller moet ik ook nog ff goed bekijken.

[ot]
Waar ik trouwens tegenaanliep bij het spitten in een js ref is iets heel doms;

code:

var hex = "ff"
var dec = parseInt(hex, 16);
alert(dec); //255

var dec = 178;
var hex = dec.toString(16);
alert(hex); //b2

dus ik voelde me toch wel even flink dom dat ik daar altijd handmatige omrekeningen voor maakte en zo is rgb > hex inene heel makkelijk:

code:

function rgbToHex(r,g,b) {
    return '#'+(r<<16 | g<<8 | b<<0).toString(16);
}

alert(rgbToHex(32,64,128));
// mooi kleurtje

En nou gaan jullie me niet vertellen dat ik de enige was die dat niet wist...

[crisp]

Op maandag 10 juni 2002 22:58 schreef Clay het volgende:
En als je nou het hele form wat de reut submit volledig dynamisch aanmaakt.

code:

form = document.createElement("form")
form.setAttributes( blah ...

document.body.appendChild(form);

enz...

Dan lijkt het mij dat je het met proxomitron ook niet meer kan aanpassen. En die arguments.caller moet ik ook nog ff goed bekijken.

[ot]
Waar ik trouwens tegenaanliep bij het spitten in een js ref is iets heel doms;

code:

var hex = "ff"
var dec = parseInt(hex, 16);
alert(dec); //255

var dec = 178;
var hex = dec.toString(16);
alert(hex); //b2

dus ik voelde me toch wel even flink dom dat ik daar altijd handmatige omrekeningen voor maakte en zo is rgb > hex inene heel makkelijk:

code:

function rgbToHex(r,g,b) {
    return '#'+(r<<16 | g<<8 | b<<0).toString(16);
}

alert(rgbToHex(32,64,128));
// mooi kleurtje

En nou gaan jullie me niet vertellen dat ik de enige was die dat niet wist...

[ot]
Die parseInt kon ik al, maar die toString(16) nog niet
parseInt hebben we het een tijdje terug nog over gehad; ik doe altijd parseInt(blaat, 10) om problemen ermee te voorkomen:
parseInt('100') geeft namelijk een andere uitkomst als parseInt('0100')! (bij de 2e wordt aangenomen dat het octaal getalstelsel is!)

[ontopic]
clientside dynamisch javascriptjes includen (dmv document.write), en vervolgens weer vars uit die net geinclude JS gebruiken werkt ook wel lekker verwarrend, zeker als het onduidelijk is naar welk JS bestand er nu uiteindelijk verwezen wordt, en welke vars die overschrijft.