Sziasztok,
van egy olyan kérdésem, hogy ti hogyan oldanátok meg a következőt:
php -vel generált változókat adok át egy munkameneten belül flash -nek.
A flash feldolgozás után egy query string -el kéri le az ujabb változókat, mielőtt ezeket kiadom, fel kell dolgozni a stringet, ami a beküldött adatot tartalmazza.
Nade:
A beküldött adat forrását validálnom kell.
Mivel bizonyos időtartam áll rendelkezésre (240 sec. + timeout) ezért ezt követően nem fogadom el a választ, csak az uj paramétereket és hibakódot adok.
Az ezen az időn belül megjelenő visszatérő adat esetén viszont ellenőriznem kell, hogy valóban a flash által van -e feldolgozva, vagy csak egy szimpla url.
Amennyiben a nevezett swf küldte be, akkor feldolgozom.
Abban gondolkoztam, hogy úgy adjak egyedi azonosító ennek a rész-munkamenetnek, hogy letárolom, viszont nem adom tovább a kliensnek (mivel ha ez megvan, a szimpla lekérést követően a kliens máris validálhatja magát bárhogy a következő rész-munkamenetben kapott tokennel), így viszont a kliens nem tudja megmondani, hogy ő most milyen értéket vesz fel.
Az swf-et nem én generálom (bár ez itt majdnem mindegy...).
Előre is köszönöm a válaszokat (lehet, hogy fátol az erdőt effektus...:P).
- 1478 megtekintés
Hozzászólások
Mi a baj az egyszeri jelszóval?
1. A paraméterek között ott a jelszó is
2. a választ csak úgy fogadod el, hogy a választ hitelesíti úgy, hogy átad egy hash-t is: URL + jelszó + só (a só egy fix sztring, amit a kliens és a központ is tud).
3. újabb paraméterek + új jelszó a kliensnek.
Tény, hogy szabadon megy a jelszó, de a só miatt nehéz felhasználnia idegennek.
Mindenesetre kíváncsi lennék jobb megoldásra, mert nekem is meg kell valósítanom hasonlót.
- A hozzászóláshoz be kell jelentkezni
A jelszóval az a baj, hogy már authentikált a user, ráadásul a rendelkezésre álló időben nem is kérhetek tőle ilyet + mivel a flash alapjában véve visszafejthető, így a kapott paraméterek és mondjuk az swf -be forgatott Actioncrypt osztály alapján játszi könnyedséggel tud új adatot generálni, ami valid, így az mcrypt sem megfelelő.
Bár lehet, én gondolom rosszul.
Az a legnagyobb baj, hogy itt a kliens a legmegbízhatatlanabb, nem pedig maga az adatfolyam/paraméterek/változók.
A megoldás valami olyannak tűnik, hogy gyakorlatilag meg kell tudnom mondani a paraméterek kiadásakor, hogy egy érték mi lesz, de úgy, hogy ezt csak szerver oldalon tudjam megállapítani, miközben 5 adatból 4 majdnem tetszőleges értéket vehet fel.
Szerk:
Ha az mcrypt bármilyen formában megfelel erre a célra, én örülök majd a legjobban...
Szerk2:
Tehát:
A szitu az, hogy gyakorlatilag magát a futtató flash -t kell felruháznom egyedi azonosítóval (ami nem is töltődik ujra, úgy könnyű lenne), mikor kap paramétert, de úgy, hogy ezt csak a szerver tudja, mivel csak a flashtől akarok elfogadni paramétert.
szürkehrteg
azenoldalamponthu
- A hozzászóláshoz be kell jelentkezni
Nos, arra gondoltam, hogy a következőképp kellene megoldani:
1. flash generál egy hash -t, olyan adatokból, amit csak ő tudhat (pl jelenlegi futási állapot az összes változó értékével)
2. beküldi majd elfelejti, szerver letárolja
3. ismételt adatbeküldésnél "ismét eszébe jut" _pontosan_, hozzácsapja a kiküldött timestampet, s ezt a hash -t küldi be.
Ezáltal mebízhatóan tudnám azonosítani a flasht.
kérdés: hogyan inicializálok egy állapotot, ami már nem létezik, miközben le sem tárolom?
Gondolkozok még egy sütiben átadott dolgon is, de...hogy biztosítom, hogy csak a flash férhessen hozzá, és csak ő írhassa?
kezdek megzavarodni...:P
szürkehrteg
azenoldalamponthu
- A hozzászóláshoz be kell jelentkezni
> A beküldött adat forrását validálnom kell. [...] Amennyiben a nevezett swf küldte be, akkor feldolgozom.
Szerintem indulj ki abból, hogy nem tudhatod biztosan, honnan származnak az adatok. Azt viszont biztosan tudhatod, hogy a beküldött adatoknak milyen hatásai, következményei lesznek, ezért inkább az adatokat kellene ellenőrizni, felügyelni, a forrásuktól függetlenül.
- A hozzászóláshoz be kell jelentkezni
Az a baj, hogy alapesetben egy adott intervallumon belül bármilyen értéket felvehet egy változó, s azt validként kell elfogadnom ha határidőn belül kapom.
Ha ezt az swf generálja, akkor valós esemény alapján történt a dolog; minden más esetben pedig...
Tehát gyakorlatilag az új változókat is az előző eredmények feldolgozásaként kapom egy GET hatására, GET -ben az előző GET hatására keletkezett paramétereket küldöm flashből és lekérem az uj esemény id -hez tartozó változókat, viszont ha nem tudom azonosítani a forrást biztosan, akkor az intervallum kezdetén érvényes adat beküldésével gond nélkül játszhat a felhasználó.
szürkehrteg
azenoldalamponthu
- A hozzászóláshoz be kell jelentkezni
> Ha ezt az swf generálja, akkor valós esemény alapján történt a dolog; minden más esetben pedig...
Talán ha részletesebben ismertetnéd a körülményeket, elérendő célokat, akkor kaphatnál másféle (nem csak a forrás ellenőrzésére építő), könnyebben implementálható megoldási javaslatokat, amik ugyanúgy kielégítenék a követelményeket.
Például nem világos, hogy az általad említett "valós esemény"-nek van-e figyelembe vehető időigénye vagy nincs? Ha van, akkor mennyi: ~0,5mp, ~5mp? Ha ~5mp, akkor elegendő-e a "hamis" forrás detektálásához, ha az adatok 0,5másodpercenként próbálnak beérkezni? Stb.
- A hozzászóláshoz be kell jelentkezni
Adott egy változósor, amit a flash beolvas.
Ezek:
-Mit kell feldolgoznia? (eventid)
-Mennyi ideje van rá, hogy válaszoljon? (maxtime)
-Milyen értéket vehet fel maximálisan egy változó a feldolgozás végén? (maxeventpoint)
-Timestamp (kikuldott_timestamp)
A visszatérési adatokat a php ez alapján veszi figyelembe:
-current_timestamp - kikuldott_timestamp értéke 0-maxtime közé essen.
- eventid értéke egyezzen az adatbásban lévővel
--ha egyezik:
---eventid alapján megállapított maxeventpoint értéke nem lehet több, mint a paraméterben visszakapott érték
Vizsgálom még:
- user létezzen, be legyen jelentkezve, használjon https protokollt, useragent és ip egyezzen a login időpontjában kapottal (ellenkező esetben nem fut le a fenti ellenőrzést végző függvény sem- addig is létezik)
Szerk:
Az időintervallum első 30 másodpercében nem fogadok adatokat, ez a minimum futásidő a flashben.
szürkehrteg
azenoldalamponthu
- A hozzászóláshoz be kell jelentkezni
Látom nem akarod elmesélni, miről van szó. Nem baj, a te dolgod.
> - eventid értéke egyezzen az adatbásban lévővel
Adatbázisban keresgélni felesleges. Ha átadok X,Y,h,Z adatokat és visszakapok X,Y,h,W-t akkor az X,Y helyessége a visszakapott h=hash(secret,X,Y) újbóli kiszámításával is ellenőrizhető, nem kell hozzá adatbázisban turkálni.
- A hozzászóláshoz be kell jelentkezni
a.) Nem árulhatok el konkrétat, a működési elv szerintem elég; az hogy ez mit is dolgoz fel, látszik.
Nem az a lényeg, hogy dolgozza fel a flash, hanem az, hogy validálhatom e a forrást anélkül, hogy ezt tudatom a forrással.
b.) Azzal, hogy ezeket letároltam sessionban még max az adatbázisműveleteket csökkentem, de nem tudom meg, milyen forrásból jött.
szürkehrteg
azenoldalamponthu
- A hozzászóláshoz be kell jelentkezni
> de nem tudom meg, milyen forrásból jött.
A forrást nem lehet egyértelműen beazonosítani. Még ha minden stimmel, se biztos hogy minden stimmel. Még ha sikeresen beazonosítottad is az swf-et, még mindig ott a kérdés hogy közben a gép előtt ülő személy ugyanaz maradt-e? Ki használta a billentyűzetet, egeret; egy valódi személy, vagy valami automata? Belenyúl-e az swf és a szerver közötti adatfolyamba valami, vagy sem? Stb.
- A hozzászóláshoz be kell jelentkezni
A flash eléggé sok interakciót vár el a usertől, ami nem egyforma gyakorlailag egyetlen lakalommal sem, de emellett maximálisan osztom a véleményed...
szürkehrteg
azenoldalamponthu
- A hozzászóláshoz be kell jelentkezni
gondolom, valami "egyelőre titkos" fejlesztésről van szó, én valami nyerőjátékra vagy hasonlóra tippelnék, lényeg meg vsz. az lenne, hogy ne lehessen az adatfolyam dekódolása után egy robotot beépíteni a kliens flash és a szerver közé (pontosabban a kliens flash helyére).
Persze, minden védelem törhető, tehát, aki akarja, az ezek után még magát a flash klienst is manipulálhatja automatizáltan.
Megoldásnak én mindenképp valami ugrókódos algoritmust javasolnék a flash-be. Induláskor küldesz neki egy szerver által generált kulcsot, amit a flash beépített algoritmusa minden adatküldés előtt módosít, majd ezzel kódolja a küldött adatot. Szerver oldalon természetesen ugyanezzel az algoritmussal módosítod a kulcsot minden lépésben és azzal dekódolsz.
Egy bibi van, ha kiesik a szinkron, akkor vége, bár még akkor is lehet újrakérni az adatot és új indulókulcsot generálni.
Mindezt megbonyolítva időnként visszaküldhetsz az aktuális kulccsal kódolva egy módosított algoritmust a flash számára (pontosabban egy új módosító kulcsot a belső algoritmusnak).
Aztán, aki mindezt visszabányássza - bár biztos lehetsz benne, hogy lesz olyan - az egyéb aljasságokra is képes, úgyse tudsz vele mit kezdeni.
- A hozzászóláshoz be kell jelentkezni
> Mindezt megbonyolítva időnként visszaküldhetsz az aktuális kulccsal kódolva egy módosított algoritmust a flash számára
A max 4 perces válaszidőbe szerintem belefér, hogy egy utánzó programba beépüljön az új algoritmus.
> Aztán, aki mindezt visszabányássza - bár biztos lehetsz benne, hogy lesz olyan - az egyéb aljasságokra is képes, úgyse tudsz vele mit kezdeni.
Egyetértek. A kliens oldalon csak nehezíteni lehet az swf utánzását, megakadályozni nem lehet. Szerver oldalon viszont azt akadályoz amit csak akar.
Persze van még egy lehetőség, saját kliens programot is lehet gyártani, ami aztán megpróbálja a kliens gépet teljesen a felügyelete alatt tartani: mi fut a memóriában; billentyűzet, egér események tényleg a hardvertől jönnek-e; stb.
- A hozzászóláshoz be kell jelentkezni
>A max 4 perces válaszidőbe szerintem belefér, hogy egy utánzó programba beépüljön az új algoritmus.
Mondjuk magát a flash -t is lehet titkosítani, ami nehezebbé teszi pl. az mcrypt -ben használt algoritmusnak a flashes megfelelőjében (Actioncrypt lesz asszem) a megtalálást.
Jómagam épp tegnap láttam hasonlót, a decompilerek gyakorlatilag összevizelték magukat.
szürkehrteg
azenoldalamponthu
- A hozzászóláshoz be kell jelentkezni
> Mondjuk magát a flash -t is lehet titkosítani, ami nehezebbé teszi
A "nehezebbé teszi" az nem azonos a "lehetetlené teszi"-vel. Az meg kérdéses, hogy mi az ami már eléggé nehézzé van téve, és mi az ami nem.
A titkosítás meg nyilván nem lehet eléggé nehéz, ha abból indulok ki, hogy a kódnak titkosítatlanul kell futnia.
- A hozzászóláshoz be kell jelentkezni
> A max 4 perces válaszidőbe szerintem belefér, hogy egy utánzó programba beépüljön az új algoritmus.
Persze, csak ahhoz előbb rá kell jönni, vissza kell fejteni, mi is történik a háttérben. Ha egyszer a teljes algoritmusodat visszafejtették, persze, hogy lehet reprodukálni. Ez egy ilyen szakma :(
- A hozzászóláshoz be kell jelentkezni
> én valami nyerőjátékra vagy hasonlóra tippelnék
majdnem...:P
>Megoldásnak én mindenképp valami ugrókódos algoritmust javasolnék a flash-be.
Hmmmmmm...jó ötletnek tűnik.
Igazából a szinkron meglétét majdhogynem ki is lehetne kötni.
Kérdés: Keep-Alive ilyenkor játszik?
Alapesetben hibás adatbeküldést követően az üzemeltető kap egy mailt, a szerver a hasonló kéréseket pedig 503 -as http kóddal honorálja a hibaelhárításig, de ennek számát redukálni szeretném.
szürkehrteg
azenoldalamponthu
- A hozzászóláshoz be kell jelentkezni
> Hmmmmmm...jó ötletnek tűnik.
Mint írtad: "a flash alapjában véve visszafejthető", így nem is olyan jó ötlet. Vagy közben csendben megváltoztak az elvárásaid.
- A hozzászóláshoz be kell jelentkezni
Nem próbálkoztam még a dologgal, de biztos hogy mindent fel lehet törni.
Viszont, ha valaki egy paranoid módon exportált swf-ből visszabányássza, hogy milyen algoritmusok hogyan módosítanak benne milyen változókat, az meg is érdemli :)
- A hozzászóláshoz be kell jelentkezni
Pontosan.
szürkehrteg
azenoldalamponthu
- A hozzászóláshoz be kell jelentkezni
Máshol viszont azt is írtam, hogy lehet titkosítani magát a flasht is, ami persze szintén visszafejthető, csak nagyságrendekkel nehezebben. (ami kereskedelmi / share/freeware programot láttam, ebbe belebukott.)
szürkehrteg
azenoldalamponthu
- A hozzászóláshoz be kell jelentkezni
Semmi közöm a flash programozáshoz, de ilyen szempontból elég hasonlatos a .NET-hez: egyik sem natív kódot tartalmaz, azt fordítani/interpretálni kell.
Nem tudsz úgy védeni egy ilyen cuccot, hogy az ne legyen "olvasható", hiszen akkor a futtatókörnyezet sem lenne képes megérteni.
Ilyenkor jönnek az olyan megoldások, mint pl. .NET-nél a Dotfuscator és társai. A jobbak olyan szintig képesek elvinni a dolgot, hogy csak assembly szintre tudod visszafejteni. Persze, ez addig igaz, amíg valaki nem veszi a fáradságot, hogy visszafejtse, hogy maga az obfuscator pontosan hogyan dolgozik...
Ha olyan szintű kódolást el tudsz érni, amihez mindenképpen élőmunka kell, hogy érthető algoritmussá álljon össze, akkor már csak egy dolgod van: gyakrabban kell a flash-fájlban a hash-algoritmust változtatni (nem a saltot és hasonlók, ténylegesen az algoritmust!), mint amilyen sebességgel valaki képes az algoritmus megfejtésére.
- A hozzászóláshoz be kell jelentkezni
Szerintem ezt mondtam:
Egyszeri jelszó minden paraméter átadás során.
Lehetne játszani azzal, hogy mindig hozzhash-el a kliens az előző hash-hez valami változót, amit a szerver is ismer, és így biztosítjátok a kommunikáció folyamatosságát, de ha a kliens visszafejthető és nem megbízható, akkor felesleges.
Most te komolyan egy olyan valakivel akarsz biztonságosan kommunikálni, akiben nem bízol meg?
Mert akkor https + szerver ÉS kliens oldali tanúsítvány a biztonságos kommunikációhoz - de ha a klienst emulálják, ez az ellen sem véd.
Mondjuk még mindig nem teljesen tiszta, hogy pontosan mit nem szabad a kliensnek csinálnia a kapott paraméterek segítségével?
- A hozzászóláshoz be kell jelentkezni