Sikring af trafikkens oprindelse

da en applet kan downloades og decompiles så er det svært at gøre det helt sikker

gode råd:

- ikke noget brugernavn/password i applet koden - det skal indtastes af brugeren

- kør applet koden gennem en obfuscater så den er sværere at decompile

- brug HTTPS og ikke HTTP så trafikken ikke kan aflyttes

Kunne man evt spærre adgangen til serverne og klienterne af med firewalls og VPN, således at kun autoriserede personer har adgang til apletter og servere, og så derer mulighed for at logge hvad der downloades af hvem

"Problemet" er (som jeg kan se, jeg har glemt at skrive...) at alle skal have adgang til appletten, sålænge den side den er embedded i ligger på en godkendt server.

Vi har spekuleret lidt i, at serveren skal holde styr på, hvem der requester download af appletten - men en "ondsindet" bruger kan naturligvis blot downloade appletten i sin applikation...

Jeg har svært ved at se at det kan gøres helt sikkert.

Sikkerheden bør være baseret på noget der kan kontrolleres servers side (password,
IP adresse etc.).

Det er uheldigvis lidt den samme konklusion vi selv kom til :(

Jeg lader lige spørgsmålet stå til i eftermiddag - hvis der skulle komme en forbi med en brilliant idé :)

Det kan ikke lade sig gøre at sige noget definitivt om den klient du taler med (hvis du finder en løsning, så ring til blizzard og scor kassen). Alle online spil bøvler med den slags problemer. Det bedste bud er at indføre nok "security through obscurity" til at det ikke er bøvlet værd at arbejde sig igennem det. Du må dog ikke lade disse teknikker stå for "adgangskontrol", de bør kun bruges til at gøre det svært at lave alternative klienter.

Et par forslag til at gøre det bøvlet at lave en alternativ klient:
- Implementer din protokoltolkning/styring således at du let kan skifte hvordan de datastrukturer der sendes sker ud. Kan laves sådan at et build script random kan vælge forskellige faktorer, fx rækkefølge på data, navne hvis det er en tekst protokol osv. (Vigtigt at browseren gøres opmærksom på at en cachet applet ikke skal genbruges i det tilfælde)

- Lad webserver og jeres applikationsserver samarbejde. Requests godkendes kun hvis siden er blevet tilgået inden for en hvis tid. Din webserver kan også generere forskellige kodestrenge som parametre til appleten som den skal sende med ned. Formattet, navnet, antallet på disse kan også ændres ofte ligesom ovenstående

- Lad klienten autorisere med en kode-streng, fx et krypteret digest af username,password, en streng fra serveren og et timestamp. Ganske vist kan man decompile klienten, men du kan gøre det til et rigtigt træls job at finde ud af hvilken krypteringsnøgle og algoritme der anvendes. Du kan fx selv skrive små kode-stumper i bytekode som der ikke findes nogen java ævkivalens til. En del af genereringen kan måske udføres af et indlejret script sprog og script fortolker. Igen, det kan læses, men bestemt ikke noget hurtigt og let job. Se fx et script sprog som http://www.daimi.au.dk/~eriksoe/Flip/index.html :) ikke sjovt at finde ud af hvad alt sådan noget går ud fra ud fra noget obfusceret kode.

Det kan du så bruge en masse tid på =) Men igen, det her er kun en højere barriere for  3rd party apps. Brug det hvis du vil nedsætte risikoen for at folk laver deres egen klient, fx hvis det ville kunne give dem en fordel i et spil. Det duer ikke som grundlæggende sikkerhed. Se evt. http://en.wikipedia.org/wiki/Security_through_obscurity

der er også visse muligheder i Java for at lade hackerne arbejde lidt for
sagen - hvad med f.eks. at lade appletten hente en klasse som er en classloader
der så bruges til at loade krypterede klasser med ?

Yep det gør det alt sammen bøvlet, der er dog måske nogle begrænsninger på en unsigned-applet? (kan ikke lige huske præcis hvad de er). En vigtig detalje jeg glemte er at du selvfølgeligt også skal gøre det svært for "hackeren" bare at bruge din kode. Det nytter ikke meget at ændre protokol hvis han bare fra sit program kan bruge din kode. Med andre ord, obfuskeringen skal som minimum give forskellige klasse og metode navne hver gang du "shuffler". Du kan gå et trin videre og foretage små strukturændringe r i programmet. Det kan i den sammenhæng være smart at noget af koden er krypteret (eller bare encoded i en eller anden form) og loades dynamisk. Gør det sværere at lave et script til at reverse-engineere filerne og så søge efter fx java.net.

Når du vil lave noget svært at tyde (og bruger en obfuscator) så er det i øvrigt mega smart at sprede det ud over et par klasser. Sørg for at klasserne har ca. samme mængde metoder, indhold osv så man ikke så let kan identificere hvad der er hvad (du kan evt. lave et script der gør dette for dig). Det er en giga opgave at trævle sådan noget op hvis der kaldes frem og tilbage mellem statiske og ikke statiske metoder, ændres i class variabler (arrays) og disse ændringer bruges i scriptsne. Når så al ting hedder A, B eller C så bliver det rigtigt træls =)

Man kan blive ved med ideer til hvordan en hacker kan bremses, og hvis du har en stor applikation hvor det har betydning (world og warcraft :) så bør fortsætte på denne måde og hele tiden ændre hvilke teknikker der bruges. For et lille program uden den store offentlige opmærksomhed så kan du på en eftermiddag gøre det meget uattraktivt at lave sin egen klient.

Okay sidste post, promise =) Nu at kryptering af class filer blev nævnt så vil jeg bare lige nævne at det i sig selv ikke rigtigt giver noget. Vil bare lige sikre mig det ikke lød for fristende som "løsningen!". VM'et skal jo havde den ukrypterede class fil for at indlæse klassen, og det er meget simpelt at få fat i den. Men igen, det kan være et ekstra irriterende trin, og sammen med andre teknikker kan det gøre det ekstra svært at gennemskue præcist hvad der sker.

arne og webster - jeg takker for jeres idéer. Jeg tror de vil hjælpe os en del til at gøre det besværligt for udenforstående.

Hvad siger I til 50p hver?  Så skal I bare lige lægge et svar :)

ok

webster - jeg godkender arne's svar nu. Hvis du vil have 50p må du lige lægge en kommentar her, så opretter jeg et spørgsmål med 50p til dig.

Jeg lukker her nu.