[PHP/Flash] URL versleutelen

[Genoil]

Ik ben bezig met een PHP scriptje dat de highscores uit een Flash-game opslaat. De URLs die naar dat scriptje verstuurd worden zien er zo uit:

savescore.php?name=Genoil&score=42

Het is echter te eenvoudig om de boel te flessen, omdat deze URL ook prima in de adresbalk van een willekeurige browser is te plakken en gemanipuleerd kan worden om zodoende vals te spelen.

Daarom probeer ik een manier te vinden om zeker te weten dat de URL aangeroepen wordt vanuit het Flash-spelletje. Ik kom er echter niet helemaal uit. Ik heb zo'n idee dat ik iets moet doen met een versleuteling en een sleutel, maar 100% waterdicht krijg ik het niet.

Het enige waarvan ik weet dat het in ieder geval een heel klein beetje helpt, is het md5en van de variabelen die ik meestuur:

savescore.php?name=Genoil&score=42&hash=1b32c537d8e8c388b9fd8d0e5765ecaf

zodat de allersneuste kiddies in ieder geval niet zomaar straffeloos met de variabelen kunnen rommelen, maar dan nog zou iemand die zelf de beschikking heeft over md5() met wat probeerwerk de juiste manier kunnen vinden om de boel te versleutelen.

maar ik ben dus op zoek naar iets waterdichts. maar aangezien Flash client-side is en PHP server side, zou ik niet weten hoe ze beide een unique hash kunnen genereren zonder dat de sleutel opde een of andere manier via http gecommuniceerd wordt.

[curry684]

Public/private key

Je spreekt als private key af bijv. de string "GoT is een stoer forum", welke je hardcode in zowel de Flash als de PHP app. Vervolgens stuur je dus "savescore.php?name=Genoil&score=42&hash=" inderdaad als webstring, en als hash de concatted string van de 2 waardes en de private key, oftewel:

PHP:

$url = "savescore.php?name=$name&score=$score&hash=".md5($name.$score.$privkey);

De PHP applicatie kan vervolgens omdat die ook de private key weet verifieren of de hash geldig is, en pas daarna de variabelen accepteren of rejecten

[RwD]

Waterdicht gaat niet lukken, moeilijker kun je het wel maken.

Als je die score toch wilt gaan gokken serverside, plak je er toch nog iets extra's aan vast. Bijv score=!@#$%^&42 maar dan nog ff md5 er overheen.

Maar dat is maar een idee. Als je dat niet goed genoeg vindt, of mensen kunnen dit zo uitlezen vanuit flash, dan wordt het wachten op mensen met goede ideeen

Edit:
Hmm, dit is ongeveer hetzelfde als Curries idee, welke de naam er aan toe voegt voor een gevarieerder patroon. Slimmere zet

Edit:
Bovendien gokt zijn systeem niet

[ Voor 25% gewijzigd door RwD op 18-08-2004 14:23 ]

[Genoil]

ah okee thx, ik zat al in die richting te denken, maar ik wilde perse m'n private key ook generiek hebben . maar dat gaat dus niet. en met een Flash decompiler kun je de key nog weer achterhalen...

[chem]

curry684 schreef op 18 augustus 2004 @ 14:20:
Public/private key

Je spreekt als private key af bijv. de string "GoT is een stoer forum", welke je hardcode in zowel de Flash als de PHP app. Vervolgens stuur je dus "savescore.php?name=Genoil&score=42&hash=" inderdaad als webstring, en als hash de concatted string van de 2 waardes en de private key, oftewel:

PHP:

$url = "savescore.php?name=$name&score=$score&hash=".md5($name.$score.$privkey);

De PHP applicatie kan vervolgens omdat die ook de private key weet verifieren of de hash geldig is, en pas daarna de variabelen accepteren of rejecten

De noemen we niet public/private maar een salt string.

[curry684]

chem schreef op 18 augustus 2004 @ 14:26:
[...]

De noemen we niet public/private maar een salt string.

Ya k met hashing heb je gelijk, maar in de praktijk functioneert dit als een private key, met de gegeven waardes als public keys

[frickY]

Alles wat je in flash doet valt volgens mij te decompilen/tracen.. dus in dat geval zul je het nooit waterdichter krijgen als bovengenomd salt-voorbeeld.

Je kan ook ipv de salt mee te md5-en, het gebruikersnaam achterstevoren md5-en.. oid... zolang je maar iets md5t waarvan anderen niet weten wat je md5t is het niet terug te halen.. zonder je SWF te cracken

[Eelke Spaak]

Je kan ook als aanvulling op deze manier nog een challenge/response systeem erin bouwen.

Communicatie zal er dan ongeveer zo uit zien (wat ik zo eventjes bedenk; misschien moet het wel wat aangepast worden voor jouw specifieke systeeem):

1) Flash applicatie 'meldt zich aan' bij de PHP-applicatie, dit kan bv. als volgt:
savescore.php?action=requestchallenge

2) PHP-applicatie stuurt een challenge (op basis van iets randoms, of de tijd, o.i.d.) naar de Flash:
result=ok&challenge=1b32c537d8e8c388b9fd8d0e5765ecaf

3) Wanneer er een score moet worden verzonden, berekent de Flash het volgende: var response = md5(name + score + privKey + challenge); en stuurt dat naar de server:
action=submitScore&name=Genoil&score=42&response=blabla

Nu is het ook niet meer direct te hacken door de Flash te decompilen. Het is natuurlijk nog steeds te kraken, maar wéér een stukje moeilijker .

[Erkens]

Vladimir G. schreef op 18 augustus 2004 @ 21:43:
Nu is het ook niet meer direct te hacken door de Flash te decompilen. Het is natuurlijk nog steeds te kraken, maar wéér een stukje moeilijker .

simpel, ik stuur een request naar savescore.php?action=requestchallenge en daar is die challenge
vervolgens bereken ik md5(name + score + privKey + challenge) en stuur die naar de server
Om dit "cheaten" tegen te gaan heb je wat sterkers nodig, alleen je kan het nooit waterdicht maken. Alles wat over een netwerkverbinding gaat kan je onderscheppen en kijken wat er verstuurt wordt. Zeker dit http verkeer is eenvoudig te doen.

[ Voor 37% gewijzigd door Erkens op 18-08-2004 23:05 ]

[Billie]

Erkens schreef op 18 augustus 2004 @ 23:05:
[...]

simpel, ik stuur een request naar savescore.php?action=requestchallenge en daar is die challenge
vervolgens bereken ik md5(name + score + privKey + challenge) en stuur die naar de server
Om dit "cheaten" tegen te gaan heb je wat sterkers nodig, alleen je kan het nooit waterdicht maken. Alles wat over een netwerkverbinding gaat kan je onderscheppen en kijken wat er verstuurt wordt. Zeker dit http verkeer is eenvoudig te doen.

Als je dan bijv. md5(sha1(sha1(name + score + privKey + challenge)))) doet? Dat is iig een stuk minder makkelijk te voorspellen.

[curry684]

Billie schreef op 19 augustus 2004 @ 00:22:
[...]


Als je dan bijv. md5(sha1(sha1(name + score + privKey + challenge)))) doet? Dat is iig een stuk minder makkelijk te voorspellen.

Een salt is onmogelijk te voorspellen zonder decompilen. En als je decompiled weet je dit ook.

Sterker nog: dit is extreem zwak wat je hier doet Een hash van een hash limiteert namelijk per definitie de keyspace, omdat er vrijwel per definitie clashes voorkomen in de volledige space van 32-byte-strings, en je dus een bruteforce eenvoudiger maakt

Essentie is simpel: zolang een hacker aan de code kan komen, kan ie het faken, en dat is per definitie zo als ie toegang heeft tot de encrypting code. Ik zou dus gewoon voor de salted approach gaan, want als je dan iemand ziet cheaten gaat ie gewoon op de IP-ban

[ Voor 4% gewijzigd door curry684 op 19-08-2004 01:29 ]

[frickY]

Erkens schreef op 18 augustus 2004 @ 23:05:
Zeker dit http verkeer is eenvoudig te doen.

Welkom in de wondere wereld welke SSL heet

Overigens kan je nog op de User-Agent checken (Flash gebruikt zijn eigen User-Agent ID.. niet die van de browser).. Even nagekeken.. is neit waar
En om het helemaal lastig te maken.. zodra er ook maar 1 ding niet klopt in wat je binnen krijgt van een user (bijv verkeerde hash, of foute user-agent) meteen het IP bannen om diegene geen kans te geven door te blijven proberen tot het wel goed is

[ Voor 12% gewijzigd door frickY op 19-08-2004 19:19 ]

[Anders]

Met de huidige stand van zaken mbt Flash is niks waterdicht.
SSL biedt geen enkele bescherming want je probleem zit niet bij hackers van buitenaf (zoals bv het geval is bij personen die creditcard-gegevens proberen te onderscheppen), maar bij personen die client-side gaan zitten rommelen. Met een programmaatje als "burp proxy" kun je alle querystring editen voordat je ze ontvangt of verzend. Keys die je meestuurt vanaf de server kunnen worden onderschept. etc etc.

Naast van de encryptie die reeds besproken is (want al is het niet waterdicht, je moet het wel zo lastig mogelijk maken), zou ik je adviseren om getallen als modulus te verzenden.

$blurredscore = $score + rand(0, 1000) * $modulus

$score = $blurredscore%$modulus;

Die $modulus moet je dan wel vooraf definiëren in je code en het is verre van waterdicht, maar je maakt het er wel weer een stuk verwarrender op.


Zie ook [rml][ php/flash/e.a.] hoe kan je webprogramma's beveiligen[/rml]

[Genoil]

frickY schreef op 19 augustus 2004 @ 19:14:
[...]

En om het helemaal lastig te maken.. zodra er ook maar 1 ding niet klopt in wat je binnen krijgt van een user (bijv verkeerde hash, of foute user-agent) meteen het IP bannen om diegene geen kans te geven door te blijven proberen tot het wel goed is

he da's eigenlijk best handig. je kunt natuurlijk ook wat milder zijn en dat IP gewoon nog wel je spelletje kunnen laten spelen maar gewoon geen highscore meer laten saven.

[Anders]

Hou wat dat betreft wel rekening met het beveiligingsniveau dat je nastreeft. Zeker als er wat mee te winnen valt zijn er genoeg mensen die simpelweg via anonymous-proxy-IP's surfen. Dat zijn er misschien niet al te veel in verhouding tot het totaal aantal spelers, maar het nou net wel diegenen die je topscores verkloten.

[Genoil]

Anders schreef op 19 augustus 2004 @ 21:13:
Met de huidige stand van zaken mbt Flash is niks waterdicht.
SSL biedt geen enkele bescherming want je probleem zit niet bij hackers van buitenaf (zoals bv het geval is bij personen die creditcard-gegevens proberen te onderscheppen), maar bij personen die client-side gaan zitten rommelen. Met een programmaatje als "burp proxy" kun je alle querystring editen voordat je ze ontvangt of verzend. Keys die je meestuurt vanaf de server kunnen worden onderschept. etc etc.

Naast van de encryptie die reeds besproken is (want al is het niet waterdicht, je moet het wel zo lastig mogelijk maken), zou ik je adviseren om getallen als modulus te verzenden.

$blurredscore = $score + rand(0, 1000) * $modulus

$score = $blurredscore%$modulus;

Die $modulus moet je dan wel vooraf definiëren in je code en het is verre van waterdicht, maar je maakt het er wel weer een stuk verwarrender op.


Zie ook [rml][ php/flash/e.a.] hoe kan je webprogramma's beveiligen[/rml]

euh ik snap nog ff niet hoe dat werkt, maar iig bedankt, en dat ander topic is ook erg bruikbaar

oh wacht zolang modulus maar groter is dan 1000

[ Voor 4% gewijzigd door Genoil op 19-08-2004 21:23 ]

[Eelke Spaak]

Anders schreef op 19 augustus 2004 @ 21:13:
Met de huidige stand van zaken mbt Flash is niks waterdicht.
SSL biedt geen enkele bescherming want je probleem zit niet bij hackers van buitenaf (zoals bv het geval is bij personen die creditcard-gegevens proberen te onderscheppen), maar bij personen die client-side gaan zitten rommelen. Met een programmaatje als "burp proxy" kun je alle querystring editen voordat je ze ontvangt of verzend. Keys die je meestuurt vanaf de server kunnen worden onderschept. etc etc.

Naast van de encryptie die reeds besproken is (want al is het niet waterdicht, je moet het wel zo lastig mogelijk maken), zou ik je adviseren om getallen als modulus te verzenden.

$blurredscore = $score + rand(0, 1000) * $modulus

$score = $blurredscore%$modulus;

Die $modulus moet je dan wel vooraf definiëren in je code en het is verre van waterdicht, maar je maakt het er wel weer een stuk verwarrender op.


Zie ook [rml][ php/flash/e.a.] hoe kan je webprogramma's beveiligen[/rml]

Dit lijkt me nu niet de slimste manier . De score is namelijk niet meer terug te krijgen door de server op deze manier. Dit komt door de random-factor; de server kan nooit meer terugrekenen welke random-factor de Flash-applicatie heeft gebruikt in het 'blurren' van de score.

[RSpliet]

Misschien is het een idee om aan het begin door de flash te laten weten dat het spel start. Dit sla je op in een databeest, je geeft m een session ID, en aan het eind verstuurt de flash applet dat session id + score + spel. Dan kan je aan de hand van dat session ID natrekken waneer hij is begonnen, en hoe lang het spelletje heeft geduurt. Zo kan je dus een filter maken op onmogelijke scores, want meer dan x punten per minuut kan niet .

[ Voor 5% gewijzigd door RSpliet op 19-08-2004 21:42 ]

[Anders]

Die random factor is niet van belang, zolang je client-side en server-side maar dezelfde $modulus gebruikt.

42 + 293 * 100 = 293042
42 + 348 * 100 = 348042
42 + 6 * 100 = 642

293042%100 = 348042%100 = 642%100 = 42

Nou moet je voor modulus een getal gebruiken dat groter is dan de maximale highscore, en een minder mooi getal nemen dan 100 (dus bv. 384732987 of noem maar iets). Oh, en geen rand (0,1000) dus maar bv rand (10, 9999).

Maar zoals gezegd, dit is slechts een klein rookgordijntje, en de $modulus die je definieert kan een beetje hacker wel uit de source peuteren.

---

s3v3n's oplossing vind ik wel interessant. Het zal niet voor elk spel van toepassing zijn maar het is een aardige extra controle-mogelijkheid indien het wel bruikbaar is.

[frickY]

Anders schreef op 19 augustus 2004 @ 21:13:
[...] SSL biedt geen enkele bescherming [...]

SSL encryptie loopt tussen de server en de client.. tussen zijn webserver en flash. Door de proxy zie je alleen maar encrypted shit binnenkomen.

[Verwijderd]

Je kan in Flash toch ook een pagina aanvragen en de variabelen versturen per POST methode?

[Erkens]

Verwijderd schreef op 20 augustus 2004 @ 15:01:
Je kan in Flash toch ook een pagina aanvragen en de variabelen versturen per POST methode?

wat is daar het voordeel van dan?

[Anders]

frickY schreef op 20 augustus 2004 @ 13:42:
[...]

SSL encryptie loopt tussen de server en de client.. tussen zijn webserver en flash. Door de proxy zie je alleen maar encrypted shit binnenkomen.

Welnee. Probeer burp proxy eens op een SSL-verbinding. Alles komt gewoon ontsleuteld voorbij. Probleem is namelijk dat SSL-encrypted data op de client weer decrypted wordt, en daarna kun je er alles mee. Vice versa is het hetzelfde verhaal.

SSL is interessant wanneer je niet wil dat derden van buitenaf client-server-verker kunnen onderscheppen (of er althans iets mee kunnen doen).

[ixi]

Ik heb ooit eens een Flash spel gemaakt waarbij de server de score bijhield. Bij elk punt dat je scoorde liet Flash dit weten aan een PHP script, dit script geeft vervolgens een key terug die Flash gebruikt bij het insturen van het volgende gescoorde punt (volgens een bepaald simpel algoritme, om het niet te makkelijk te maken).

Of deze methode voor jou ook kan werken hangt heel erg van het soort spel af; 5 keer per seconde punten scoren gaat niet echt werken. Je zou dan misschien met een timer kunnen werken die om de 10 seconde doorgeeft hoeveel punten je hebt gescoord. Beter nog zou zijn om het soort punten dat je kunt scoren een key te geven, die het PHP script weer wijzigt elke keer.

Flash.. het blijft 'hack'baar.

[Genoil]

ixi schreef op 21 augustus 2004 @ 13:53:
Ik heb ooit eens een Flash spel gemaakt waarbij de server de score bijhield. Bij elk punt dat je scoorde liet Flash dit weten aan een PHP script, dit script geeft vervolgens een key terug die Flash gebruikt bij het insturen van het volgende gescoorde punt (volgens een bepaald simpel algoritme, om het niet te makkelijk te maken).

Of deze methode voor jou ook kan werken hangt heel erg van het soort spel af; 5 keer per seconde punten scoren gaat niet echt werken. Je zou dan misschien met een timer kunnen werken die om de 10 seconde doorgeeft hoeveel punten je hebt gescoord. Beter nog zou zijn om het soort punten dat je kunt scoren een key te geven, die het PHP script weer wijzigt elke keer.

Flash.. het blijft 'hack'baar.

Dat is idd ook een mooie manier om het weer een stuk moeilijker te maken, het spelletje is er ook zeker geschikt voor.

[Verwijderd]

Erkens schreef op 20 augustus 2004 @ 15:08:
[...]

wat is daar het voordeel van dan?

Dan kan de vervelende gamer tenminste niet de URL manipuleren. En hij kan zonder het Flash filmpje te decompileren ook niet zien welke variabelen ie nodig heeft om de score te manipuleren.

[ Voor 24% gewijzigd door Verwijderd op 21-08-2004 14:16 ]

[Erkens]

Verwijderd schreef op 21 augustus 2004 @ 14:14:
[...]


Dan kan de vervelende gamer tenminste niet de URL manipuleren. En hij kan zonder het Flash filmpje te decompileren ook niet zien welke variabelen ie nodig heeft om de score te manipuleren.

dat kan ook daarmee heel eenvoudig hoor