Beveiliginsprobleem met Socket.io

Pagina: 1
Acties:

Onderwerpen


Acties:
  • 0 Henk 'm!

Verwijderd

Topicstarter
Ik werk al een tijdje aan een online game. De game bestaat uit een website, waarop users hun account kunnen beheren en matches kunnen spelen tegen andere users. De basis van de website is opgebouwt met php, maar het matchmaking gedeelte is gebouwd in javascript. Dankzijn websockets kunnen users live andere users inviten om een match te spelen. De game zelf is in AS3 geschreven.

Nu komt het probleem: het werkt goed, alleen is het javascript gedeelte zo lek als een mandje. Als een user is ingelogd output php de <script> tag met de benodigde javascript bestanden om een live connectie op te zetten. Het script kijkt in een verborgen div om het userid te achterhalen. Dit user id word vervolgens naar de nodejs server gestuurt.

Users kunnen echter via de browserconsole alle javascript variablen aanpassen, is er een manier om dit enigzins te beveiligen?

Joël

Acties:
  • 0 Henk 'm!

Verwijderd

Nee, controleer alles server-side. Je kunt niets van de client vertrouwen.

Acties:
  • 0 Henk 'm!

Verwijderd

Topicstarter
Weet ik. Maar hoe kan ik de user dan identificeren? Javascript moet toch weten welke user hij is?
Zou ik met php het userid door kunnen sturen naar de server?

[ Voor 24% gewijzigd door Verwijderd op 26-11-2011 20:08 ]


Acties:
  • 0 Henk 'm!

  • mithras
  • Registratie: Maart 2003
  • Niet online
Je wil op een of andere manier de sessie delen tussen socket.io en php. Het gebruiken van een user id is onverantwoordelijk: als ik de id van een admin weet zou ik ineens alles wat de admin mag kunnen uitvoeren. Zoals Cheatah zegt: altijd alles server side valideren.

Ik heb het niet getest, maar er bestaat het project nodePhpSessions waarbij je in node.js de sessies van php kan opvragen. Wanneer je sessies in de db opslaat, kan je daarmee ook de gegevens van de user achterhalen. Iets soortgelijks zal ook met socket.io kunnen. Dat lijkt me in ieder geval al een stukje veiliger, hoewel je dan nog met het probleem van session hijacking zit...

[ Voor 4% gewijzigd door mithras op 26-11-2011 20:20 ]


Acties:
  • 0 Henk 'm!

  • Styxxy
  • Registratie: Augustus 2009
  • Laatst online: 15:22
mithras schreef op zaterdag 26 november 2011 @ 20:14:
[...]Iets soortgelijks zal ook met socket.io kunnen. Dat lijkt me in ieder geval al een stukje veiliger, hoewel je dan nog met het probleem van session hijacking zit...
Indien dat je niet wilt dat sessies overdraagbaar zijn, kan je en sessie vastkoppelen aan userid, ip, browser user-agent en mogelijk nog enkele user afhankelijke gegevens. Daarmee beveilig je je al grotendeels tegen sessie-hijacking.

Acties:
  • 0 Henk 'm!

  • Bosmonster
  • Registratie: Juni 2001
  • Laatst online: 10-09 08:45

Bosmonster

*zucht*

Of je kunt users een account laten aanmaken met een wachtwoord.

Een userid is identificatie, geen beveiliging.

[ Voor 28% gewijzigd door Bosmonster op 27-11-2011 00:46 ]


Acties:
  • 0 Henk 'm!

Verwijderd

Topicstarter
Bedankt @mithras, volgens mij heb je me in de juiste richting gewezen. Ik heb php nu zover gekregen sessies in de db te storen. Nu allen nog cookies accessen vanaf nodejs, en dan met nodejs via een query de sessid valideren. Is dit 'the way to go'?

Acties:
  • 0 Henk 'm!

Verwijderd

Topicstarter
Voor de geintresseerden: Ik heb het probleem opgelost door met php het sid door te geven aan javascript:
code:
1
2
3
<script type="text/javascript">
  var sid = '<?php echo session_id(); ?>';
</script>

Vervolgens gebruik ik met php een custom session handler, eentje die sessies daar de database wegschrijft.
Bij het verbinden met node.js laat ik de server het door de client opgestuurde phpsid controleren door een query op de database uit te voeren. Als er in de databse een entry zit met het kolom sessionID = sid, gaat de server door met het aanmelden van de user. Zo niet, wordt je niet aangemeld. Eigenlijk zou ik de connectie dan moeten killen, want nu kan je nog wel socketcomminucatie met de server voeren terwijl je al bent afgewezen. Dus ik ben er nog niet.

Beveiliging is een bitch
Pagina: 1