[PHP/Security] Veiligheid van code

[BKJ]

Ik ben bezig met een site te ontwikkelen en geef users de mogelijkheid om een profiel met foto aan te maken. Nu kan dit profiel door iedereen worden opgevraagd zonder in te loggen (noodzakelijk). In dit profiel wordt ook melding gemaakt van het emailadres van deze user. Nu wil ik niet al te voorspelbaar het profiel op kunnen vragen. Dus onwenselijk is het volgende:

code:

show_profile.php?userid=20

Dit zou betekenen dat iemand met een beetje script-kennis zo mijn DB kan harvesten op emailadressen. Dus ik dacht laat ik een crypt functie erop los met eigen passphrase:

PHP:

crypt($gegevens['id'], 'passphrase');

Probleem is echter dat crypt ook in de uitvoer / kan hebben, niet echt handig bij het opvragen van url's. Ik heb toen geprobeerd te urlencoden maar dit heeft geen effect en de slashes blijven staan bij opvragen van profiel. Erg vaag..

Nu heb ik het volgende bedacht:

PHP:

base64_encode(crypt($gegevens['id'], 'passphrase'));

Dit geeft bijvoorbeeld voor id = 20 en een passphrase die ik niet verraad de volgende code:

code:

Z2laLmJBcXgwenZ5Lg==

Nu kan je dus alleen het profiel opvragen doordat je bijvoorbeeld de link van iemand hebt gekregen. Mijn vraag: is dit afdoende als beveiliging? Voorkom ik zo dat je alle profielen kunt opvragen?

[Gonadan]

Is het niet slimmer om de e-mail adressen als plaatje o.i.d. weer te geven?
Dan zijn ze ook een stuk lastiger te harvesten.

[bonzz.netninja]

maar dan moet je dat overtikken als je het als normale gebruiker wilt gebruiken

[sariel]

En in plaats van al dat gezeur met base64, encrypt en bla bla bla, gewoon een random ID geven aan gebruikers, die bij aanmaak gegenereerd wordt, en daarna altijd het ID is?

maw:

code:

$query = "insert into users (username,password,id) values ($username, $password, substr(md5($username.$password.$time), 0, 10));"

[ Voor 5% gewijzigd door sariel op 11-05-2006 11:48 ]

[sariel]

en wat dat email adres betreft....maak gewoon een mail-naar-gebruiker pagina. die vraagt een email adres (of gebruikt die uit je profiel), een naam, en een bericht. heb je minder gezeur van spammers.

[BKJ]

sariel schreef op donderdag 11 mei 2006 @ 11:49:
en wat dat email adres betreft....maak gewoon een mail-naar-gebruiker pagina. die vraagt een email adres (of gebruikt die uit je profiel), een naam, en een bericht. heb je minder gezeur van spammers.

Emailadres is slechts 1 van de dingen die ik wil beveiligen. Een heel profiel moet wat mij betreft gewoon niet al te openbaar zijn.

[sariel]

"niet al te openbaar".......jaja.....

als je niet wil dat niet-ingelogde mensen email adressen zien, dan laat je die toch gewoon niet outputten? of is dat te makkelijk?

[GlowMouse]

Gonadan schreef op donderdag 11 mei 2006 @ 11:44:
Is het niet slimmer om de e-mail adressen als plaatje o.i.d. weer te geven?
Dan zijn ze ook een stuk lastiger te harvesten.

Inderdaad. Harvesters zullen sneller links volgen dan zelf id's gaan raden in de URL. Eventueel kun je Javascript gebruiken ipv een plaatje, als je het klikbaar wilt houden.

[dip]

GlowMouse schreef op donderdag 11 mei 2006 @ 12:19:Inderdaad. Harvesters zullen sneller links volgen dan zelf id's gaan raden in de URL. Eventueel kun je Javascript gebruiken ipv een plaatje, als je het klikbaar wilt houden.

je laatste suggestie is lang niet waterdicht. Ik zou er eerder voor kiezen via een plaatje en een mailer op je site te werken dan via een obfuscator je mail adres te encoderen. De nieuwste harvesters zijn hier al tegen bestend namelijk.

[Verwijderd]

Kun je niet een gedeelte van het profiel beschikbaar maken voor mensen die niet ingelogd zijn en een gedeelte voor mensen die wel ingelogd zijn. Dan laat je alleen het email zien aan ingelogde mensen.

En als je met POST werkt ipv GET dan scheelt dat ook al weer een hoop.

[ Voor 16% gewijzigd door Verwijderd op 11-05-2006 12:28 ]

[BKJ]

Verwijderd schreef op donderdag 11 mei 2006 @ 12:26:
Kun je niet een gedeelte van het profiel beschikbaar maken voor mensen die niet ingelogd zijn en een gedeelte voor mensen die wel ingelogd zijn. Dan laat je alleen het email zien aan ingelogde mensen.

En als je met POST werkt ipv GET dan scheelt dat ook al weer een hoop.

Dat is zeker een optie, aan de andere kant geef ik niet graag concurrent gevoelige info prijs: hoeveel members er zijn etc...

[tech-no-logical]

ik ben met sariel in deze : gebruik random id's. ik gebruik daar altijd de php-functie 'uniqid' voor, en heb nog nooit een collision gehad. auto_increment id's gebruik je alleen intern, in je eigen code...

[MSalters]

dip schreef op donderdag 11 mei 2006 @ 12:22:
[...]

[Javascript] is lang niet waterdicht.

Toch wel. De enige manier waarop een harverster de output van Javascript kan bepalen is door die Javascript te runnen, dat is een vrij simpele vuistregel.

[Erkens]

hitchhacker schreef op donderdag 11 mei 2006 @ 12:30:
Dat is zeker een optie, aan de andere kant geef ik niet graag concurrent gevoelige info prijs: hoeveel members er zijn etc...

Dus dat is je eigenlijke "probleem" als ik je goed begrijp?
Kies dan niet voor een nummertje maar bijvoorbeeld random tekenreeks als primary key in je database

[Verwijderd]

Waarom niet gewoon een simpele if en zeg je dat als er naar het profiel gegaan wordt vanuit een externe website dat hij een melding geeft met die dat de profielen niet van buitenaf benaderd kunnen worden?

Een tweede suggestie: Laat input van een gebruiker nooit alleen gecontroleerd worden op client-side (dus javascript) maar ook server side met een if of case ik heb zo bijvoorbeeld namelijk al verhalen gelezen dat er computers verkocht werden voor $1,- omdat de prijs gewoon niet aan de server-side gechecked werd.

[ Voor 44% gewijzigd door Verwijderd op 12-05-2006 11:13 ]

[Snake]

MSalters schreef op donderdag 11 mei 2006 @ 19:35:
[...]

Toch wel. De enige manier waarop een harverster de output van Javascript kan bepalen is door die Javascript te runnen, dat is een vrij simpele vuistregel.

En denk je dat er een bots bestaan die javascript verstaan? Wel dus

[Voutloos]

snake903 schreef op vrijdag 12 mei 2006 @ 23:03:
[...]
En denk je dat er een bots bestaan die javascript verstaan? Wel dus

'Er is' != 'alle'. Je vangt welzeker een behoorlijk deel van de bots af.

Verwijderd schreef op donderdag 11 mei 2006 @ 12:26:
Kun je niet een gedeelte van het profiel beschikbaar maken voor mensen die niet ingelogd zijn en een gedeelte voor mensen die wel ingelogd zijn. Dan laat je alleen het email zien aan ingelogde mensen.

Dit is zeker een handige maatregel. Als iemand niet wil registreren en met de community wil meedoen, hoeft hij ook niet alle gegevens van die community te zien. Uiteraard is alleen deze maatregel niet voldoende als registreren simpel is.

En als je met POST werkt ipv GET dan scheelt dat ook al weer een hoop.

Bah, bah bah. Door GET en POST requests in de verkeerde situatie te gebruiken werk je in strijd met 1 van de belangrijkste http features. Je breekt bookmarks, navigeren wordt een ramp (back button en vervolgens krijg je de vraag of je weer het formulier wil submitten ) en je kan niet aan de link zien waar je heen gaat. Laten we alsjeblieft POST puur gebruiken waar het voor bedoelde is, bijvoorbeeld het POSTen van een formulier waar een niet idempotente actie op volgt.

Als jij dankzij POST-misbruik het navigeren op je site vervelender maakt, raak je niet alleen (misschien) een bot kwijt, maar zeker weten mij als bezoeker.

[ Voor 9% gewijzigd door Voutloos op 12-05-2006 23:23 ]