[PHP] Memberscript en security flaws

[Verwijderd]

Owkay dan,

Ik ben een scriptje aant maken voor een soort member section,
het inschrijven en het activeren ervan is me al gelukt... Nu nog de edit sectie...
Ze kunnen dan inloggen, en al hun gegevens zien en zonodig dus editen...

Nu kom ik op het volgende probleem bij dit laatste (edit sectie):
*) user logt in (pass check, e.d. - *WERKT*)
*) Print alle gegevens, zoals naam, adres, etc (*WERKT*)
Dit ziet er ongeveer als volgt uit:

code:

|================ edit ==|
| username: $username             |
| password: *********             |
|======================|

|================ edit ==|
| Firstname: $firstname             |
| Lastname: $lastname             |
| etc...etc...                                |
|======================|

als ze dus op edit clicken dan moeten ze dus hun pass kunnen updaten...
ik heb al met een aparte file dit geprobeerd, om het ze zo te laten veranderen,
en nu heb ik iets verzonnen (bij de "edit" <FORM $PHP_SELF><input name=stage value=1><submit> (simpele code, maar jullie snappen het wel)

dus dan komt ie bij DEZELFDE file uit, waar in de source

PHP:

if($stage == "1") { print "we're in stage 1";}

etc...

MAAR... hij geeft de variabele $username NIET door, die ie dus bij de 1e stap (inloggen) WEL aan deze ZELFDE script doorgeeft.. dit komt denk ik omdat de <FORM> alle waarden reset en alleen stage doorgeeft.. Als ik nu <INPUT name=username> erbij zou zetten kunnen mensen dit zien, en als ze dan de script aanroepen met "filename.php?stage=1&username=USER" dan kunnen ze dus illegaal voor IEDERE user die ze weten passwords gaan resetten.. SECURITY FLAW dus.. om er nou een <INPUT name=password> bij te gaan zetten, vind ik ook niet erg veilig...

Heeft iemand misschien een idee hoe ik dit het beste kan oplossen?

[Verwijderd]

Heb je in PHP niet iets als een Session-object?

[Nielsz]

Zet het in een sessie

[Verwijderd]

Ik zou http-authenticatie gebruiken, en niet form inputs. Daarmee voorkom je dit soort gedoe.

[Janoz]

Als je gewoon
1: met post werkt, dan kunnen mensen geen get parameters meer meegeven
2: het oude wachtwoord ook in laat vullen. Dan kan iemand alleen het wachtwoord wijzigen waneer diegene ook het oude wachtwoord geeft.

[Verwijderd]

Dit zal je kunnen helpen, maar dan moet je voor elke variabele een waarde definiëren
<input name="username" type="hidden" value="blaaah">

[Verwijderd]

ja dat is dus wat ik zeg... insecure...

*note: misschien mijn fout dat ik "hidden" ben vergeten te vermelden... maar dat lijkt me nogal vanzelfsprekend dat je al die troep niet op je scherm wilt

[Verwijderd]

je kunt natuurlijk ook de value van de hidden gaan encoden waardoor je het een stuk SECURER maakt

[Bosmonster]

Aan sessies valt weinig te kloten.. als je dat ook nog combineert met zoals Janoz zegt het vragen voor het wachtwoord bij kritieke punten (gegevens wijzigen, bestelling doen whatever).. zit je wel goed.

Sessies verlopen automatisch na een bepaalde tijd of als de gebruiker zijn browservensters sluit.. Bijna alles wordt voor je gedaan dus

[kvdveer]

Verwijderd schreef op 15 oktober 2002 @ 14:31:
Ik zou http-authenticatie gebruiken, en niet form inputs. Daarmee voorkom je dit soort gedoe.

Onjuist... http-authenticatie is (zonder ssl) een van de meest onveilige methoden. Wachtwoord wordt vrijwel plaintext verzonden, wordt op client-side gecached en op serverside. Daarnaast wordt 'ie bij iedere request verzonden, en was 'ie bij oudere versies van IE en NS terug te vinden in de cache. Een sessie is veiliger, omdat deze waardeloos is nadat 'ie gesloten is. Een wachtwoord blijft geldig tot 'ie gewijzigd wordt.

[kvdveer]

Stop inderdaad alles wat je wilt bewaren in een sessie. Die is het veiligst. Wil je nog veiliger, sla ook het ip-adres op in de sessie en controleer dat telkens. In dat geval kan een sessie nooit ge'hijacked' worden, alleen door spoofing. Als je ook rekening wilt houden met spoofing moet je even CERT bellen .

[Bosmonster]

mocht je er cookies aan je sessie willen binden (om je sessie 'te verlengen') dan zou ik zoiets doen overigens:

Sla in de cookie de username en het wachtwoord/userlevel (of iets dergelijks) met een MD5 eroverheen op. Zo hebben ze clientside nooit het wachtwoord staan, maar kun je wel serverside controleren of de cookie klopt. Paas het daarna door naar de sessie en gebruik die verder voor authenticatie ipv constant de cookie.

Overigens sla ikzelf nooit wachtwoorden op in de DB.. simpelweg omdat wachtwoorden vaak voor meer dingen gebruikt worden dan alleen die site en ik niet eens wil weten wat mensen voor wachtwoorden hebben. Ik gooi er dus ook daar een MD5 overheen en controleer daarmee het ingevoerde wachtwoord. Zo voorkom je ook dat als mensen in de server inbreken, wat niet zo heel moeilijk is als PHP niet goed geconfigureerd is, direct wachtwoorden van al je gebruikers in handen hebben.

[kvdveer]

Bosmonster schreef op 15 oktober 2002 @ 22:06:
Overigens sla ikzelf nooit wachtwoorden op in de DB.. simpelweg omdat wachtwoorden vaak voor meer dingen gebruikt worden dan alleen die site en ik niet eens wil weten wat mensen voor wachtwoorden hebben. Ik gooi er dus ook daar een MD5 overheen en controleer daarmee het ingevoerde wachtwoord. Zo voorkom je ook dat als mensen in de server inbreken, wat niet zo heel moeilijk is als PHP niet goed geconfigureerd is, direct wachtwoorden van al je gebruikers in handen hebben.

Het hangt af van de site wat ik exact doe. De wachtwoorden van een 'dommeusers site' staanplaintext in de DB, want die hebben perse een mailbackfunctie nodig, Zodra de passmailer functie niet nodig is, gaat er ook aan mijn kant een MD5 over. (met een seed, om bruteforcen onhaalbaar te maken)

[Bosmonster]

kvdveer schreef op 15 oktober 2002 @ 22:11:
[...]


Het hangt af van de site wat ik exact doe. De wachtwoorden van een 'dommeusers site' staanplaintext in de DB, want die hebben perse een mailbackfunctie nodig, Zodra de passmailer functie niet nodig is, gaat er ook aan mijn kant een MD5 over. (met een seed, om bruteforcen onhaalbaar te maken)

Ach passmailer.. dan maar een "new random password" mailer

[kvdveer]

Bosmonster schreef op 15 oktober 2002 @ 22:13:

Ach passmailer.. dan maar een "new random password" mailer

Dat vind ik ook, maar dat vindt de klant soms niet... Klanten vinden wachtwoorden als W3r$44sSa1009938 onleesbaar... Om maar eens te quoten: "Klanten zuigen" (pelle)

[Bosmonster]

kvdveer schreef op 15 oktober 2002 @ 22:48:
[...]


Dat vind ik ook, maar dat vindt de klant soms niet... Klanten vinden wachtwoorden als W3r$44sSa1009938 onleesbaar... Om maar eens te quoten: "Klanten zuigen" (pelle)

Haha.. of jouw random password generator zuigt

waarom niet gewoon "ab24zdf1" formaat En ze uiteraard direct de optie geven ze te wijzigen..

Maar goed.. we dwalen af

[CyberSnooP]

kvdveer schreef op 15 oktober 2002 @ 22:48:
Dat vind ik ook, maar dat vindt de klant soms niet... Klanten vinden wachtwoorden als W3r$44sSa1009938 onleesbaar... Om maar eens te quoten: "Klanten zuigen" (pelle)

Ach, voor alles een oplossing: Je mailt ze gewoon een url (met daarin een bepaalde wijzigings-key uiteraard) waarop ze direct een nieuw wachtwoord kunnen intikken.. Ongeveer even veilig.

[Verwijderd]

hehe sorry, was in mijn PHP BIBLE nog niet aan hoofdstuk "sessies" gekomen

maar ik heb het nu inmiddels onder de knie!! WERKT PERFECT!! Thanks voor de tip

[Verwijderd]

kvdveer schreef op 15 oktober 2002 @ 21:58:
[...]

Onjuist... http-authenticatie is (zonder ssl) een van de meest onveilige methoden. Wachtwoord wordt vrijwel plaintext verzonden, wordt op client-side gecached en op serverside. Daarnaast wordt 'ie bij iedere request verzonden, en was 'ie bij oudere versies van IE en NS terug te vinden in de cache. Een sessie is veiliger, omdat deze waardeloos is nadat 'ie gesloten is. Een wachtwoord blijft geldig tot 'ie gewijzigd wordt.

DUH! Zeg ik ergens "gebruik vooral geen SSL?". Veilige site is hoedanook SSL gebruiken, want als je dan niet doet wordt altijd vroeger of later het wachtwoord plaintext verstuurd.