[PHP / Flash] Veilige communicatie tussen Flash en PHP

[Navi]

Zit al een behoorlijke tijd met een probleem waar ik zelf tot nu toe nog geen waterdichte oplossing voor gevonden heb, en als ik zo eens rond google merk ik dat heel veel mensen tegen dit probleem aan lopen.

Het gaat om een veilige manier van communiceren tussen Flash en PHP, stel je voor een Flash spel waarbij een score gehaald kan worden. Deze dient aan het eind opgestuurd te worden naar een webapplicatie in PHP, zodat deze opgeslagen wordt in MySQL en zo getoond kan worden op een website.

Dit systeem werkt prima, op dit moment wordt er vanuit Flash een POST gedaan en PHP vangt deze op en geeft een OK terug.

Nu komt de beveiliging hiervan om de hoek, iedereen weet dat Flash gemakkelijk te decompilen is, hiervoor zijn verschillende oplossingen en ik heb gekozen voor secureSWF, deze "encrypt" de broncode zodat als deze gedecompiled wordt je alleen random zooi ziet staan.

Echter het heen en weer zenden van de vars, wat is nu een goede manier om te voorkomen dat mensen er mee gaan rommelen, de flash decompilen, met packet sniffers gaan kijken etc, of op een andere manier een nep score op kunnen sturen en zo de wedstrijd winnen? (Er wordt wel https gebruikt)

Ik heb al tientallen oplossingen gelezen, van standaard encryptie tot uitgebreide systemen met hashes en salts die heen en weer gaan, maar uiteindelijk komen ze allemaal op de basis neer: Je moet er vanuit gaan dat iemand jouw swf broncode kan lezen en hier dus een manier omheen kan bedenken.

Desnoods kan er met tools zoals CheatEngine gewerkt worden waarbij het geheugen uitgelezen wordt en alle variabelen zo in beeld komen.

Wie heeft hier een intressant idee voor om het te voorkomen, mits dit mogelijk is, of anders zo moeilijk te maken, dat er gewoonweg niet uit te komen is zonder de serverside PHP code te weten?

Ik zit zelf te denken in een soort van request token systeem, dat er dus aan PHP een bepaalde token opgevraagd moet worden die aan het eind ook weer mee teruggestuurd zal moeten worden, maar hoe dit waterdicht te krijgen ben ik nog niet helemaal uit.

[Guru Evi]

Flash is client-based, PHP is server-based. Als je client-based bezig bent moet je ervan uitgaan dat je client altijd volledige controle heeft over alles die er op de client gebeurt. Dus als je een score moet doorgeven, dan kan je client altijd die score 'emuleren'.

Zie ook: DRM en waarom DVD's en Blu-Ray schijfjes alsook XBox en PlayStation altijd gekraakt kunnen worden: je moet zowel de public als de private key meegeven aan je client. Of om in lekentaal te zeggen: Je wilt een bericht versturen van Alice naar Bob zonder dat Mallory het kan lezen. Echter je zit met het probleem dat zowel Alice als Mallory dezelfde persoon zijn.

Oplossingen zijn er simpelweg niet. Je kunt het moeilijk maken, maar dat is dan ook alles. Eenmaal de kost om het te kraken groter is dan de reden om het te kraken kun je een systeem maken. Als je vb. een miljoen euro in prijzen weggeeft zijn er altijd mensen die dit de tijd 'waard' vinden om het te kraken. Echter bij zulke 'hacks' gaat het niet altijd over de geld waarde - hoeveel is het een persoon 'waard' om de top score te krijgen?

Een alternatief is om je toepassing server-side te draaien en enkel de benodigde input door te geven naar de server. Dat vereist meer van je server maar is op zich wel mogelijk (Zie ook: Fusion Render Cloud). Een ander alternatief is om toepassingen zoals PunkBuster te verzinnen. Dit zijn toepassingen die server-side nakijken of er niets verkeerd gebeurt (zoals mensen die verder schieten dan het wapen mogelijk is of doorheen muren wandelen etc.) ofwel client-side meekijken of er niets veranderd wordt aan de binary of bepaalde delen van het spel niet worden aangepast door vb. een debugger maar ook deze dingen zijn gemakkelijk te omzeilen - als je server-side uitrekent wat de maximum score is die een perfecte persoon kan krijgen, dan kun je gewoon brute forcen totdat je toch op de lijst geraakt. Sommige flash-spel-sites verwijderen gewoon de topscores elke week zodat op die lijst komen niet echt een permanent gegeven is.

[ Voor 37% gewijzigd door Guru Evi op 17-03-2010 20:04 ]

[Verwijderd]

SanderAlterNET schreef op woensdag 17 maart 2010 @ 19:43:Ik heb al tientallen oplossingen gelezen, van standaard encryptie tot uitgebreide systemen met hashes en salts die heen en weer gaan, maar uiteindelijk komen ze allemaal op de basis neer: Je moet er vanuit gaan dat iemand jouw swf broncode kan lezen en hier dus een manier omheen kan bedenken.

Hier zal je toch aan moeten toegeven. Alles wat client-side runt kan toch wel decompiled/reversed engineered worden. Je kan het inderdaad wat lastiger maken, maar meer moeite dan een het een implementeren van een symmetric cipher in je send() routine is het waarschijnlijk niet waard.

[_eXistenZ_]

Regel 1: ALLE ( _ALLE_) data die van de client komt moet gevalideert worden. Dus ook flash / javascript met hun eigen restricties, die zijn wel handig op bijv dropdowns ofzo zodat ze geen rare datum sturen maar niks weerhoudt ze ervan om als ze kwaad willen dit met Firebug / een of andere toffe Flash decompiler te omzeilen.

Had ik al gezegd dat alle data (ALLES) gevalideert moet worden?

Regel 2: Pas regel 1 toe. Altijd.

/edit

In jouw geval: er is geen mogelijkheid om te voorkomen dat ze een aantal nullen bij de score op zullen drukken, tenzij je zoals gezegd alles via PHP laat bewegen en dan coordinaten oid doorstuurt naar je client; bij een schaakspel kan dit, bij racegame al minder goed vanwege alle belasting op de server en de lag die je zult krijgen.

[ Voor 32% gewijzigd door _eXistenZ_ op 17-03-2010 21:17 ]

[Bozozo]

Je kunt serverside het scoreverloop bijhouden, en zo onrealistische scores filteren. Verder zijn er zat mogelijkheden voor encryptie, die inderdaad niet 100% te vertrouwen zijn. Beveiliging is nooit een kwestie van 100% zekerheid, maar van 'maak het zo moeilijk dat het niet de moeite waard is'.

[T-MOB]

Een vrij eenvoudige manier om extra info te krijgen over de geldigheid van een score is het bijhouden van de speeltijd. Bij de start van een spel haal je bij de server een (versleutelde) timestamp op. Deze stuur je mee bij het doorgeven van de score. Hierdoor weet je altijd hoe lang er gespeeld is. De speeltijd geeft je een indicatie van de geldigheid van de score.
Je kunt het verder dichttimmeren door niet alleen een timstamp op te vragen, maar ook een token op te halen. De token-timestamp-combinatie sla je serverside op. Voor elk token accepteer je maar een keer een score. Wordt er voor een token twee keer een score gemeld, of wordt de verkeerde timestamp meegegeven voor het token dan log je dat.
Iemand die de boel wil kraken kan dit nu lastig doen zonder dat jij het kunt merken.

[321X]

Als je niet wil dat een Flash Client communiceert met een PHP server moet je dit verplaatsen naar server side, waarbij je met Server Side Actionscript eventueel dmv ZendAMF kan communiceren met PHP.

Use Server-Side ActionScript™ to write server-side code for an Adobe® Flash® Media Interactive Server application. You can use Server-Side ActionScript to control login procedures, control events, communicate with other servers, allow and disallow users access to various server-side application resources, and let users update and share information.

http://help.adobe.com/en_...3e3d11a11aff5ba-7f8b.html

Heb je wel een Flash Media Server nodig. Ik weet ff niet of er 'server' producten zijn die dit ondersteunen.

[ Voor 7% gewijzigd door 321X op 18-03-2010 09:53 ]

[TJHeuvel]

100% waterdicht is onmogelijk, maar je kan het wel erg moeilijk maken.
Zoals je aangeeft, een token systeem zou erg goed werken.

Dit kan bijvoorbeeld zo gaan:

• De client haalt een token op, de server associeert deze client met de token.
• Voor elke request stuurt de client een hash mee, welke bijvoorbeeld MD5(alle_argumenten + token) is.
• Server checked of de hash klopt, door weer te achterhalen wat de token was van deze client de encryptie nogmaals te doen.

[Bozozo]

CyCloneNL schreef op donderdag 18 maart 2010 @ 10:16:
100% waterdicht is onmogelijk, maar je kan het wel erg moeilijk maken.
Zoals je aangeeft, een token systeem zou erg goed werken.

Dit kan bijvoorbeeld zo gaan:

• De client haalt een token op, de server associeert deze client met de token.
• Voor elke request stuurt de client een hash mee, welke bijvoorbeeld MD5(alle_argumenten + token) is.
• Server checked of de hash klopt, door weer te achterhalen wat de token was van deze client de encryptie nogmaals te doen.

Die token kun je gewoon afluisteren. Dat er wordt geMD5't zie je vervolgens terug in de gedecompilede source.

Als je de veiligheid echt zo belangrijk vindt moet je elke 'move' communiceren naar de server; dan wordt valsspelen en sjoemelen met de score onmogelijk. Alleen kunnen mensen dan nog bots bouwen