[php] Admin Tool veilig?

[Explore]

Ik ben bezig met een (voor mij) nieuwe genaratie Admin Tool en ik vraag me af of het ding een beetje bestand is tegen eventuele hackers.

De tool is gemaakt in PHP, login en password info komt uit een MySQL DB en het zaakje draait op Apache. Passwords zijn gecodeerd met md5 in de DB.

Bovenaan elke pagina wordt een login file included. Hierin wordt nagegaan of men toegang heeft tot die betreffende pagina.

Aanpak is (in volgorde):

PHP:
1. is er form-data meegegeven (in $HTTP_POST_VARS) en is er een random-waarde gezet en bekend in de session?
2. ja, dan password info ophalen uit db waar login naam gelijk is aan db-naam (case-sensative) - bij geen match: foutmelding
3. plak password en random-waarde aan elkaar en haal er een md5 overheen (zoiets: md5($password.$rndval))
4. matched dit met het geposte password (zie stap 7)? nee: foutmelding
5. ja: bezoeker heeft toegang - zet session-variabele

HTML:
6. als de bezoeker geen toegang heeft krijgt deze een login form te zien (met aan het eind een 'exit', zodat het script stopt - doh!)
7. op de onsubmit wordt het password veld overschreven door een javascript-md5 password + de random-waarde uit de sessie. Hier wordt dan weer een md5 overheen gehaald, zodat de random-waarde onherkenbaar wordt gemaakt.

Dat is het zo'n beetje. Ik zou wel source willen posten, maar er staan vrij veel frutsels omheen, die de zaak alleen maar vaag maken.

Vraag is dus: is dit goed secure zo? Ik zit met het ding dat uiteindelijk de zaak valt of staat met het gezet zijn van een session-variabele die zegt of de bezoeker toegang heeft of niet. Valt zoiets te omzeilen? Ik heb wel iets gelezen over 'session-hijacking', maar ik vraag me af wat ik me daar bij moet voorstellen...

[Verwijderd]

Ik vind dat je het een beetje lastig uitlegt, ik heb de tekst namelijk 3 keer over moeten lezen voordat ik een beetje snapte hoe het in elkaar zit.
Maar mij lijkt dit ultra veilig, ik gebruik zelf ook wel MD5 een sessions, maar dat javascript gedoe doe ik niet aan en ik weet ook niet zeker of dat javascript de beveiliging wel ten goede komt!

[Verwijderd]

De manier van proggen is ook erg belangrijk, sluit jij uit dat er user-input mogelijk is waar dat eigenlijk niet mag, lees bijv. eens een artikel zoals op phpfreakz: http://www.phpfreakz.com/artikelen.php?aid=74

[Grum]

2 opmerkingen.

1/ je vereist nu dus een javascript compatible browser.
2/ 2x achter elkaar een md5hash is TOTAAL onzinnig.

[Explore]

M'n verhaaltje was inderdaad misschien een beetje vaag. Excuus. Ik kreeg het er even niet anders uit.

Ik gebruik een Javascript versie van md5 om het password wat de bezoeker invult te coderen, zodat deze niet ongecodeed over 't net wordt gestuurd. Dus ook: ja, Javascript is vereist.

Die dubbele md5 lijkt inderdaad compleet overbodig, maar is noodzakelijk (dacht ik zo) omdat de passwords als md5 in de database staan. Ik kan dus niet zoiets in m'n Javascript doen:

code:

d = document.form;
d.pass = md5(d.pass+d.rndval);

...want dan krijg ik die nooit gematched met het password wat uit de db komt. Daarom doe ik dus:

code:

d = document.form;
d.pass = md5(md5(d.pass)+d.rndval);

Het ingevoerd password wordt dus nog eens apart gecodeerd met md5. Daar wordt de random-waarde aangeplakt. En over het geheel wordt weer een md5 gehaald, om de random-waarde te coderen.

Is het 'over the top' om passwords als md5 op te slaan in een database? Ikzelf vond van niet.

Ik gebruik overal $HTTP_POST_VARS en $HTTP_SESSION_VARS, dus is het niet zomaar mogelijk om in de url waardes mee te geven ofzo.

Ik heb dat artikel op phpfreakz effe doorgescanned, en ik zie dat er nog wel een gaatje in m'n code kan zitten. Maybe... Ik wil de zaak wel effe ergens online zetten, zodat je kan proberen om de zaak te hacken...

[Verwijderd]

md5 zit gewoon in php, lijkt me wat handiger werken... (md5()).

Op zich lijkt het me nu wel veilig. Je kan voor de zekerheid nog een .htaccess toevoegen als het een apache server is, maar dan moet de gebruiker uiteraard wel 2x inloggen. Hangt er een beetje af hoe belangrijk de site is.

[Explore]

Een .htaccess lijkt me een beetje over de top. Ik zou eventueel nog SSL kunnen toepassen, maar lijkt me ook overbodig, aangezien de zaak al wordt encrypted met md5.

Ik heb het nog even nagekeken, maar login of password opgeven met van die 'hack-codes' lukt niet: ik gebruik geen simpele 'select * from table where bla=bla', maar gebruik de sql strcmp-function om er voor te zorgen dat de zaak case-sensative is. Bijkomend plus-punt is dat die codes niet werken.

Het enige wat me nog dwars zit, is dat de zaak nog steeds staat of valt met 1 enkele variabele in de sessie die bepaald of iemand toegang heeft of niet. De vraag blijft: is dit allemaal secure zo?

Ik heb overigens nog een counter toegevoegd die er voor zorgt dat je maar 5x mag proberen in te loggen. Je kan daarna wel de cookies verwijderen en de browser herstarten, maar het maakt brute-force hacken wat lastiger, lijkt mij.

[drm]

Explore:
Een .htaccess lijkt me een beetje over de top.

Tenzij de authentication via HTTP doet:
http://www.php.net/manual/en/features.http-auth.php

Ik zou eventueel nog SSL kunnen toepassen, maar lijkt me ook overbodig, aangezien de zaak al wordt encrypted met md5.
[..]
Het enige wat me nog dwars zit, is dat de zaak nog steeds staat of valt met 1 enkele variabele in de sessie die bepaald of iemand toegang heeft of niet. De vraag blijft: is dit allemaal secure zo?

Kijk, als je secure wilt, moet je SSL gebruiken. Wil je het zelf, dan blijft dat laatste punt het probleem.

Ik heb overigens nog een counter toegevoegd die er voor zorgt dat je maar 5x mag proberen in te loggen. Je kan daarna wel de cookies verwijderen en de browser herstarten, maar het maakt brute-force hacken wat lastiger, lijkt mij.

Ik ga heus niet brute-force hacken via een browser, hoor, laat staan eentje die cookies accepteert

[red_indian]

ik zie het nut van die random waarde niet echt? client-side md5 encoden om het oversturen van het paswoord te beveiligen vind ik wel aardig.

misschien ook handig om ff het ip van de gebruiker op te slaan in een sessie. zodat de sessie niet overgenomen kan worden (als dat al mogelijk is?).

btw. hoe veilig zijn php sessies eigenlijk? is hier misschien een leuk docje over?

[Grum]

Ze zijn zo veilig als de zwakste schakel in het geheel .. en dat is (zoals bijna altijd) de coder

[LuCarD]

Op woensdag 24 april 2002 15:17 schreef red_indian het volgende:
ik zie het nut van die random waarde niet echt? client-side md5 encoden om het oversturen van het paswoord te beveiligen vind ik wel aardig.

misschien ook handig om ff het ip van de gebruiker op te slaan in een sessie. zodat de sessie niet overgenomen kan worden (als dat al mogelijk is?).

btw. hoe veilig zijn php sessies eigenlijk? is hier misschien een leuk docje over?

Tuurlijk heeft dat nut..... Nu beveilig je namelijk het wachtwoord. Want anders zou je met een netwerk sniffer het wachtwoord of in iedergeval de md5 hash daarvan kunnen achterhalen en bij hem inloggen.

[MisterData]

Op woensdag 24 april 2002 15:17 schreef red_indian het volgende:
misschien ook handig om ff het ip van de gebruiker op te slaan in een sessie. zodat de sessie niet overgenomen kan worden (als dat al mogelijk is?).

IP adressen gebruiken voor je beveiliging en identificatie is niet bepaald handig om de volgende twee redenen :
1. Je krijgt problemen als mensen via een proxy inloggen
2. IP's zijn te 'spoofen'

Als dit niet zou zijn geweest dan had men ook geen dingen als cookies enzo uitgevonden

[LuCarD]

Op woensdag 24 april 2002 19:58 schreef MisterData het volgende:

[..]

IP adressen gebruiken voor je beveiliging en identificatie is niet bepaald handig om de volgende twee redenen :
1. Je krijgt problemen als mensen via een proxy inloggen
2. IP's zijn te 'spoofen'

Als dit niet zou zijn geweest dan had men ook geen dingen als cookies enzo uitgevonden

1. Geen probleem.
2. Spoofen kan je alleen dat mee zenden en niet mee ontvangen.

3 en niet beschreven probleem:
Er zijn bedrijven die met meerdere IP's het net op gaan en doormiddel van load balancing dit verdelen over clients. Het kan dan dus gebeuren dat je verschillende IP's krijg binnen 1 sessie

[red_indian]

Op woensdag 24 april 2002 19:58 schreef MisterData het volgende:
Als dit niet zou zijn geweest dan had men ook geen dingen als cookies enzo uitgevonden

ik spoof liever een cookie via een header dan een ip

ip sla je op aan het begin van de sessie. wist trouwens niet dat je meerdere ips kon krijgen tijdens 1 sessie.

[Explore]

Zit in de session-data niet ergens het IP opgeslagen? De sessions werken met cookies. Ik dacht dat men op deze manier ook sessions over kan nemen, dus inderdaad dmv. ip-spoofing.

Hoe dat werkt weet ik dus niet precies, maar er zijn hackers die 't wel weten. En daar wil ik de zaak dus tegen beveiligen.

Het lijkt me vreemd als het IP-nummer binnen een sessie veranderd. Vrij veel websites zijn gebouwd op het feit dat het IP van een client gelijk blijft. Als dat niet zo zou zijn dan loopt de zaak behoorlijk in 't honderd.

Ik kan me voorstellen dat men wil load-balencen, maar dan laat je toch 'gewoon' 1 IP 'vollopen' en dan ga je naar de volgende... Er staan bv. 3 proxy-servers die met een verschillend IP 't net op gaan. Elke proxy server kan bv. 100 clients aan. Pas als 1 proxy vol is, gaat een client die 't net op wil naar de volgende. Todat die weer vol is, etc... Ik kan me niet voorstellen dat 1 client in 1 sessie tussen proxies wisselt. Maargoed, ik kan me vergissen.

Hoe dan ook, voegt SSL nog wel wat toe als het password toch al wordt beveiligd? Het enige wat unencrypted wordt verstuurd is de login-naam. Die wordt in feit alleen gebruikt zodat het systeem weet wie er inlogt en er rechten kunnen worden gezet.

Toegang tot het systeem wordt bepaald door de combinatie van login en password, maar de login-naam is hier ondergeschikt.

drm:
Ik ga heus niet brute-force hacken via een browser, hoor, laat staan eentje die cookies accepteert

Het systeem waar je mee probeert in te loggen moet toch cookies accepteren, anders gaat het helemaal niet werken. Althans... Effe kijken...

[red_indian]

Op donderdag 25 april 2002 14:33 schreef Explore het volgende:
Het systeem waar je mee probeert in te loggen moet toch cookies accepteren, anders gaat het helemaal niet werken.

hoeft niet hoor. je kunt gewoon doen alsof je cookies accepteert. cookies uit de teruggestuurde header slopen en die weer terugsturen, maar niet opslaan dus. zo kun je ook eindeloos blijven proberen, je stuurt iedere keer gewoon het eerste cookie mee. veiliger is om serverside het aantal pogingen bij te houden binnen een sessie.

[sebas]

Ben je van plan om zend encoding te gebruiken?
Zijn er nog meer users op dezelfde machine?

andere users op de server kunnen namelijk wel i je scripts kijken en op die manier passwords veranderen en dus inloggen.

[thomaske]

Op vrijdag 26 april 2002 19:01 schreef Sebas het volgende:
[..]
Zijn er nog meer users op dezelfde machine?

andere users op de server kunnen namelijk wel i je scripts kijken en op die manier passwords veranderen en dus inloggen.

Dat hangt helemaal af van de server-configuratie. Bij een beetje professionele hosting-provider is dat niet mogelijk!

[Explore]

Serverside bijhouden van inlogpogingen lijkt me inderdaad een goed plan. Ik snap wat je bedoeld met die cookies. Inderdaad vrij 'simpel' te omzeilen.

Het systeem is een shared server, zoals zoveel op internet. Maar de passwords zijn dus encrypted opgeslagen in een database, dus dan moet je erg je best doen om daar achter te komen.

Momenteel staat er op de server waar ik dit systeem aan 't ontwikkelen ben php versie 4.0.2 - beetje oud. Ik weet niet hoe het daar zit met Zend Encoding. Overigens heb ik daar geen ervaring mee.

[sebas]

Op vrijdag 26 april 2002 19:10 schreef thomaske het volgende:

[..]

Dat hangt helemaal af van de server-configuratie. Bij een beetje professionele hosting-provider is dat niet mogelijk!

... en bij een beetje standaard hosting provider is het wel mogelijk helaas.