[Java] Beste manier om client-server te beveiligen?

[killingdjef]

Onlangs was ik een beetje aan het brainstormen en zat met het volgende punt waar ik niet helemaal uit kwam.

Stel je hebt een applicatie gemaakt die je op een server wil gaan hosten. Andere gebruikers kunnen gebruik maken van de diensten die die applicatie aanbiedt door een client te downloaden. De client heeft zowiezo een library nodig van 50mb waardoor het dus onmogelijk wordt om alles te laten streamen via de server.

Nu wil het zo dat de applicatie die gehost wordt op de server belangrijke functies bevat. Zo kan het een database manipuleren.. de standaard meuk. Hoe zou er in dit geval een manier bedacht kunnen worden binnen Java dat men niet de client gaat reverse-engineeren en een paar leuke functies gaat uitvoeren?

Hiernaast, de client die gedownload kan worden heeft een aantal libraries die door de grootte meegestuurd moeten worden met de client. Het "openbreken" van die libraries betekend dat de gebruiker toegang heeft tot iets wat hij niet zou mogen inzien.

Wat ik dus eigelijk wil weten, wat is de beste manier om een java client in dit voorbeeld te beveiligen tegen nieuwsgierige gebruikers? Het liefst laat je natuurlijk zoveel mogelijk server-sided afhandelen maar met bepaalde onderdelen kan dat niet omdat de client dan onwerkbaar wordt.

Als iemand een hint/tip kan geven waarnaar ik zou moeten kijken zou dat een hoop helpen!

[Y0ur1]

Ik heb er niet gek veel ervaring mee, maar kun je het niet een beetje zien als een webapplicatie? Niks vertrouwen wat van de userkant komt(alles is met sockets te manipuleren), geen database wachtwoorden in je client opslaan etc. Belangrijke dingen op de server uitvoeren doe je met de credentials van je user, daar ga je kijken of een user er toestemming voor heeft. Kort samengevat, alle business logica zit op je server, en die roep je vanuit de client aan en dan kijk je of de user er rechten voor heeft.

[ Voor 16% gewijzigd door Y0ur1 op 12-03-2007 22:33 ]

[kenneth]

killingdjef schreef op maandag 12 maart 2007 @ 22:26:
Het liefst laat je natuurlijk zoveel mogelijk server-sided afhandelen maar met bepaalde onderdelen kan dat niet omdat de client dan onwerkbaar wordt.

Beide kan natuurlijk ook. Client-side voor de werkbaarheid/gebruiksvriendelijkheid, en dan gewoon server-side nog 'ns controleren of de boel zuiver is binnengekomen.

[killingdjef]

@Y0ur1
Ja, dat is ook de meest ideale manier om het aan te pakken maar dat gaat niet lukken omdat een client die libraries nodig heeft en je deze niet kan streamen. Het is dus zo dat je een Client hebt.. en een library die nodig is om de client te kunnen "bouwen". Vergelijk het bijvoorbeeld met een computergame. Daar heb je bepaalde handelingen ook client-sided omdat streamen daarvan onwerkbaar is.

Maar hoe je het wend of keert, als een client ge-reverse-engineerd is zie je welke functies er aangeroepen worden op de server. Dan is het kinderspel om andere variabelen in de functie te stoppen en kan de server-side alsnog illegaal gemanipuleerd worden.

Omdat er binnen Java een hoop technieken zijn en het een volwassen taal is hoop ik een manier te vinden hoe je zo'n client dus heel goed kan versleutelen en hoe je dit hele process zo veilig kan laten verlopen zonder dat een hacker alles vernielt.

@kenneth

Das een goeie suggestie... meerdere checks server-sided nbouwen die ervoor zorgen dat alles goed verloopt. Maar je kan het op deze manier nooit 100% afvangen denk ik. Daarnaast, is het onacceptabel als iemand de client reverse-engineerd en er besluit met de code vandoor te gaan aangezien de client vrij fors is, los van het feit dat de belangrijkste handelingen op de server uitgevoerd worden.

[ Voor 18% gewijzigd door killingdjef op 12-03-2007 22:48 ]

[Y0ur1]

killingdjef schreef op maandag 12 maart 2007 @ 22:43:
@Y0ur1
Dan is het kinderspel om andere variabelen in de functie te stoppen en kan de server-side alsnog illegaal gemanipuleerd worden.

Je checkt toch bij alles wat er op je server binnenkomt of dat een geldige waarde is?

[killingdjef]

Ja.. maar stel je hebt een functie genaamd "Optelsom" op de server die aangeroepen wordt door de client. De client geeft 2 waardes mee die de door input van de gebruiker worden gegenereerd. De server kan nooit weten dat getal X wel mag en getal Y niet. Je kan wel eventuele maxima en minima definieren, maar als iemand toegang heeft tot die functie kan hij er nog steeds van alles mee uitspoken en waardes meegeven die tussen de maxima en minima zitten. Dit is dus naar mijn mening een grote security leak.. en zo zijn er nog een aantal voorbeelden waarom je wil dat de gebruiker zo min mogelijk code in hun handen hebben.

[RobIII]

killingdjef schreef op maandag 12 maart 2007 @ 23:32:
Ja.. maar stel je hebt een functie genaamd "Optelsom" op de server die aangeroepen wordt door de client. De client geeft 2 waardes mee die de door input van de gebruiker worden gegenereerd. De server kan nooit weten dat getal X wel mag en getal Y niet. Je kan wel eventuele maxima en minima definieren, maar als iemand toegang heeft tot die functie kan hij er nog steeds van alles mee uitspoken en waardes meegeven die tussen de maxima en minima zitten. Dit is dus naar mijn mening een grote security leak..

De functie "optelsom" doet dan toch precies wat 'ie hoort te doen? Waarom zou dat een security leak zijn? Als je bepaalde functionaliteiten alleen maar wil kunnen laten gebruiken afhankelijk van (bijv.) een bepaalde licentie of bepaalde rechten van een user dan voer je daar toch server-side ook een check op uit (authenticatie en dat soort dingen). Of je die dan bij iedere call mee stuurt, of met een "sessie" werkt of whatever is dan een implementatiedetail, maar ik zie in de verste verte geen "security leak"

[ Voor 7% gewijzigd door RobIII op 13-03-2007 01:27 ]

[Y0ur1]

killingdjef schreef op maandag 12 maart 2007 @ 23:32:
Ja.. maar stel je hebt een functie genaamd "Optelsom" op de server die aangeroepen wordt door de client. De client geeft 2 waardes mee die de door input van de gebruiker worden gegenereerd. De server kan nooit weten dat getal X wel mag en getal Y niet. Je kan wel eventuele maxima en minima definieren, maar als iemand toegang heeft tot die functie kan hij er nog steeds van alles mee uitspoken en waardes meegeven die tussen de maxima en minima zitten. Dit is dus naar mijn mening een grote security leak.. en zo zijn er nog een aantal voorbeelden waarom je wil dat de gebruiker zo min mogelijk code in hun handen hebben.

zoiets heb je toch ook bij een webapplicatie, daar vertrouw je ook niet op javascript checks maar check je alles serverside goed.

[Zyppora]

Zoals Y0ur1, kenneth en RobIII al aangeven, zul je alle user input server-side willen controleren. Als je een integer waarde tussen 0 en 10 uit je socket verwacht, zul je daarop moeten controleren. Als de gemiddelde hacker dan een 11 meestuurt, kun je gewoon een error terugsturen of zo (of in elk geval het processen van die waarde stopzetten).

Het enige wat je op deze manier niet kunt controleren, is een licentie of verdere distributie (hoewel je het toch aardig moeilijk kan maken).

Als je het protocol tussen client en server strak aan de lijn houdt, mogen de hackers met je client in principe doen wat ze willen

[Flard]

Aan de ene kant moet je dus de gegevens valideren op de server, al vind ik een zin als "De server kan nooit weten dat getal X wel mag en getal Y niet" wel erg raar. Ik denk dat dat juist de dingen zijn die een server hoort te weten, aangezien je de client dus niet kunt vertrouwen.

Daarnaast zou ik inderdaad, zoals RobIII ook al geeft, een soort sessie-mechanisme maken:
Als de client iets bij de server gedaan wil hebben, dient hij zich eerst te registeren bij de server. Bijvoorbeeld een functie: string authenticate(string username, string password)
(Voor optimale veiligheid zul je echter het password moeten hashen, met een salt die je eerst aanvraagt bij de server)
Het resultaat van deze functie is een string met daarin een session-key. Deze sleutel moet mee worden gegeven bij alle andere aanroepen. Zowel aan de server- als clientkant zul je dus de session-key moeten bijhouden.

Op die manier weet je in ieder geval dat alleen geldige users bij de server dingen uit kunnen voeren. Om tegen te gaan dat geldige users in de code gaan hacken, zul je dus genoeg/alle validatie aan de serverkant moeten implementeren.

[djluc]

Kan je niet iets concreter aangeven wat voor soort applicatie het is en welke gegevens beinvloed kunnen worden door de gebruiker?

[Verwijderd]

Een beveiligde verbinding (liefst VPN, maar SSL kan ook goed) scheelt al een hoop hacks van buitenaf, maar als je de client zo goed mogelijk wilt beveiligen tegen reverse engineering, kijk dan 's naar obfuscation.

En natuurlijk altijd serverside een goed session management en double/triple checks op de binnenkomende data toepassen.

[PhoneTech]

Precies wat Afterlife zegt. Java heeft standaard SSL er in zitten en je kan je RMI pijp daar ook mee versleutelen. Tevens er voor zorgen dat je je client obfusicate EN een goede server beveiliging gebruiken bijvoorbeel met JAAS.

[Grub]

Tja de theorie lijkt me ook niet zo ingewikkeld hoor. In feite zorgt je server altijd voor de authenticatie en de authorisatie. Dit betekent dat als een gebruiker acties wil uitvoeren op de server via een rich of thin client, eerst zijn credentials worden gecontroleerd door de server. Vervolgens wordt bij elke actie of groep van acties bekeken of de gebruiker geauthoriseerd is om die actie uit te voeren. Ik heb in de EAI oplossingen gezien waar zelfs een fysiek aparte Authentication&Authorization server was die alle gebruikers en rechten bijhield voor alle services verspreid over verschillende andere (fysieke) systemen.

Als design keuze kun je er voor kiezen om een authenticated session te starten, of de credentials mee te sturen met elke actie die uitgevoerd wordt (minder mooie oplossing).

De verstuurde credentials moeten op zn minst versleuteld worden, en afhankelijk van de gevoeligheid van de data die over de wire gaat, kun je dit ook encrypten of over ssl sturen.

Wat betreft de validatie van input richting de server; juist bij een rich client zul je dat aan beide kanten willen implementeren. De gebruiker heeft namelijk geen zin om op validatie te wachten als hij op OK heeft geklikt, sterker nog, als hij een ongeldig getal intypt wil hij direct zien dat het textveld rood wordt of iets dergelijks. Deze logica moet je dus in je form verwerken.
Maar de input validatie moet ook aan de kant van de server gebeuren, zodat de server niet omvalt als iemand de client omzeilt en direct eentjes en nulletjes in de netwerk kabel zit te blazen. Het voordeel is dat de je in dit geval de foutresponse simpel kunt houden, omdat bij een nette rich client die alles afvangt dit alleen voorkomt bij misbruik.

[Bjoss]

Ik denk dat ik de topicstarter wel kan begrijpen, zit nl. zelf in min of meer vergelijkbare situatie.

Stel je even voor dat je client een applicatie is dat gegevens verzamelt uit aangesloten apparaten. Laat ons het even simpel houden: een gps. De client stuurt de coordinaten door naar de server via http.
Nu is de client software gratis te downloaden, en registratie is alsook gratis.

Hoe kan je dit best beveiligen om foute data/misbruik te voorkomen? Maw, wanneer ben je zeker dat de request naar de server wel vanuit de juiste client software komt, en dat de data dus te vertrouwen is.

(hopelijk maakt dit vb het iets duidelijker)

[ Voor 11% gewijzigd door Bjoss op 17-04-2007 20:46 ]

[Voutloos]

Bjoss: foute data is triviaal, welke waarden gelding zijn is een constante van het gebruikte coordinatensysteem. Wat is misbruik dan? Het stelen van accounts? Het geautomatiseerd aanmaken van accounts? Het eerste voorkom je dmv credentials (wachtwoord, mogelijk alleen vanaf bepaald ip adres etc.). Het tweede probleem is wat vager, maar ook daar zijn wel oplossingen voor te vinden (niet vaker registreren met zelfde ip of mailadres, captcha bij registratieformulier etc.).

[Bjoss]

Laat ons het voorbeeld nog even uitbreiden.
Stel dat de server een database is die draadloze netwerken linkt aan een coordinaat. De client software ontdekt dan de draadloze netwerken en submit die samen met de coordinaten gelezen uit de gps.

Vermits de client gratis is te downloaden, en vermits iedereen een mogelijke gebruiker is, kan de uiteindelijke database bij juist gebruik gevuld worden met de correcte gegevens.
Nu stel dat een of andere gebruiker het in zijn hoofd haalt om even de pakketten te sniffen, en/of de client te decompileren. Daarbij dus zelf zijn eigen http posts gaat doen naar de server (met al dan niet foute data). Aan de server kant is er geen manier om te valideren dat die coordinaat wel degelijk geldig is voor het netwerk dat in de request zit.

[Voutloos]

Packet sniffen moet je tegen gaan door integrity en confidentiality (2 security peilers) voor de communicatiepaden af te dwingen.
Verder moet je dus bij kunnen houden welke client (of badguy die zich als die client voordoet) een coordinaat invoert, zodat je iig kan reageren op fout gedrag. Ik zeg hier reageren omdat je inderdaad niet op magische wijze kan garanderen dat het een oprechte user is.