Via admin (tijdelijk) als normale user inloggen

[Verwijderd]

Wat is een goede manier om wanneer je als admin (van een zelfgemaakt CMS'je) ingelogd bent, om dan (tijdelijk) als een normale user verder te gaan?

In DirectAdmin heb je zoiets als reseller. Je klikt dan als admin op 1 van de users en dan kan je als die user inloggen. Je ziet dan het usermenu i.p.v. het adminmenu. Als je daarna weer uitlogt als die user, ben je weer ingelogd als de hoofdadmin.

Ik kan wel in mijn tabel met de sessie de laatste sessie erin zetten, maar als ik dan uitlog, dan ben ik eruit, want de hoofdadmin is dan inmiddels vergeten. Dus wat is een goede manier hiervoor? Een dubbele sessie maken? Of in de sessietabel nog een veld maken met een 0/1 dat het daarvoor een beheerder was?

[rafler]

Nvm verkeerd begrepen

[ Voor 78% gewijzigd door rafler op 12-05-2016 14:06 ]

[Hydra]

Gewoon in je code inbouwen dat je een user kunt impersonaten? Dus in de logica een extra var bijhouden, $impersonated_user_id voor mijn part, waarvan je de naam, rechten, e.d. gebruikt zolang je niet het impersonaten opheft.

[Verwijderd]

Ik gebruik iets als dit (zwaar versimpeld):

PHP:

// $_SESSION['user'] bevat alle info van de ingelogde gebruiker
function impersonateUser($userid) {
    // voor het gemak aangenomen dat je ingelogd bent en dit mag doen
    // haal gegevens van user uit de database en zet dat in $data
    $_SESSION['savedUser'] = $_SESSION['user'];
    $_SESSION['user'] = $data;
}
function restoreUser() {
    if (isset($_SESSION['savedUser'])) {
        $_SESSION['user'] = $_SESSION['savedUser'];
        unset($_SESSION['savedUser']);
    }
}

[Verwijderd]

Ha, het is gelukt! Dankzij jullie hulp.

Ik heb mijn sessietabel uitgebreid met een veldje imp_user. Zolang dat niet NULL is, heeft een beheerder niet geklikt om als een andere user verder te gaan. Doet hij dat wel, dan wordt dat imp_user veldje gevuld met de waarde van die andere user.

En dan inderdaad de logica toevoegen (met 1 IF'je) dat wanner imp_user niet gelijk aan NULL is, dat dat dan de gebruiker wordt. En op de uitlogpagina check ik dan ook of imp_user niet gelijk is aan NULL. Zo niet, dan zet ik dat wel op NULL (zodat je weer verder gaat als de beheerder) en anders gewoon echt uitloggen.

[ Voor 88% gewijzigd door Verwijderd op 12-05-2016 15:47 ]

[Gerco]

In mijn systeem wat ik een eeuw geleden gemaakt heb had ik een "impersonate user" knop waarmee je dus bovenstaande kunt doen. Cruciaal verschil is echter dat ik geen mogelijkheid had ingebouwd om weer terug te keren naar admin. Er zijn twee redenen hiervoor:

1. Wanneer je een speciale constructie gebruikt om 'half' een bepaalde user te kunnen worden kan het zijn dat bepaalde functionaliteit wel werkt wanneer je 'echt' bent ingelogd en niet wanneer je impersonate of andersom.

2. Als er een mogelijkheid is voor een user om zichzelf in een admin om te toveren (zoals een 'end impersonate' functie) dan kan die functie mogelijk misbruikt worden zonder dat de user eerst admin geweest is door een bug.

Het lijkt me dus veiliger om impersonation één richting op te laten werken. Als je terug wilt naar de admin account moet je dus gewoon opnieuw inloggen.

[tiriaq]

Is het niet handiger om bijvoorbeeld in een andere browser, of in incognito modus, een aparte sessie te hebben als normale user?

[Verwijderd]

Mijn oplossing was wat simpeler te maken omdat ik het vanaf de eerste regel code zo heb gedaan.

Ik heb $_SESS['admin'] en $_SESS['user'], waarbij als je als admin inlogt je beide sessies aanmaakt, waarschijnlijk zelfde ID. Hij gebruikt voor alles wat je doet dus die user sessie. Op het moment dat je dan iemand "overneemt" dan veranderd alleen die user sessie naar die user, alles veranderd dus in 1x.

Omdat jij die admin sessie hebt kan je wisselen. Je gaat dus nooit "terug" naar een admin account, je verlaat het gewoon nooit.

[CH4OS]

Ik begrijp het nut eigenlijk niet zo van impersonation. Log dan met een tweede browser in met een eigen aangemaakte test user. Lijkt mij veel veiliger in elk geval.

[RobIII]

CH40S schreef op vrijdag 13 mei 2016 @ 18:19:
Ik begrijp het nut eigenlijk niet zo van impersonation. Log dan met een tweede browser in met een eigen aangemaakte test user. Lijkt mij veel veiliger in elk geval.

Als je veel verschillende rollen/rechten/settings etc. hebt is 't wel verdomd handig om even in de schoenen van Jantje of Pietje te kunnen springen (en dus zijn/haar rechtenset, settings etc. te hebben) als je een probleem moet troubleshooten dat zich alleen voordoet bij (bijv.) die user (omdat een bep. combinatie van die dingen misschien niet goed werkt ofzo).

Je kunt dan wel een (al dan niet tijdelijke) testuser maken, maar dan heb je nog steeds niet al Pietjes rollen/rechten/settings etc. En al heb je dat dan na veel gedoe helemaal gelijk getrokken, wie weet zit 't probleem wel in zijn/haar "eerste registratiedatum" in combinatie met de exacte inhoud van diens winkelmandje, aantal ontvangen berichten of whatever. Dat ga je met een testuser nooit bereiken (of je moet een "copy from user X"-script bouwen ofzo). Het alternatief is Jantjes password resetten naar iets dat je weet en dan met Jantjes account in te loggen, maar dan kan Jantje niet meer inloggen omdat z'n wachtwoord veranderd is. Impersonaten is dus, in veel gevallen, verdomd handig.

Uiteraard hangt 't ook een beetje van de usecase af; een mogelijkheid tot impersonaten wil je bijvoorbeeld niet (zo snel) hebben bij toegang tot, zeg, medische dossiers of bankzaken (en ook daar zal 't vast her-en-der gebeuren of mogelijk zijn; maar dat heb je het recht om te impersonaten ook alleen maar als je dat ook écht nodig hebt).

[ Voor 13% gewijzigd door RobIII op 13-05-2016 18:30 ]

[CH4OS]

Als een probleem voordoet bij een bepaalde user, zal het probleem eerder 'between keyboard and chair' zitten dan in het systeem, is mijn ervaring. Natuurlijk, het zou kunnen, maar zou dat wel heel vreemd vinden als een bepaalde bug bijvoorbeeld alleen bij die specifieke user is.

Impersonaten gaat dan ook niet al te veel helpen imo; als coder / beheerder weet je immers hoe het systeem werkt en hoe je bepaalde dingen moet doen. Voor 'user error' (om het zo even te noemen) ben je dan gewoonweg 'blind', omdat je als coder / beheerder niet weet hoe een gebruiker met de (web)applicatie werkt.

Met een testuser kun je wel de rollen / permissions whatever overnemen van de gebruiker in kwestie, zodat alles hetzelfde is, behalve de credentials. Is het dan alsnog niet te reproduceren is het duidelijk een user error.

[Cartman!]

Gerco schreef op vrijdag 13 mei 2016 @ 17:58:
1. Wanneer je een speciale constructie gebruikt om 'half' een bepaalde user te kunnen worden kan het zijn dat bepaalde functionaliteit wel werkt wanneer je 'echt' bent ingelogd en niet wanneer je impersonate of andersom.

In feite is het ook one-way want als iemand terug wil dan plaats je gewoon t originele user id weer terug, ingewikkelder dan dat hoeft t niet te zijn.

2. Als er een mogelijkheid is voor een user om zichzelf in een admin om te toveren (zoals een 'end impersonate' functie) dan kan die functie mogelijk misbruikt worden zonder dat de user eerst admin geweest is door een bug.

Een gewone user wordt niet zomaar admin, een user die impersonated is kan dmv een button (kan simpelweg uitloggen zijn) weer terug naar wie ie oorspronkelijk was. Als je er al vanuit gaat dat dit door bugs misbruikt kan worden is je systeem niet in orde en/of is het niet voldoende getest.

[Edwin88]

RobIII schreef op vrijdag 13 mei 2016 @ 18:24:
[...]

Als je veel verschillende rollen/rechten/settings etc. hebt is 't wel verdomd handig om even in de schoenen van Jantje of Pietje te kunnen springen (en dus zijn/haar rechtenset, settings etc. te hebben) als je een probleem moet troubleshooten dat zich alleen voordoet bij (bijv.) die user (omdat een bep. combinatie van die dingen misschien niet goed werkt ofzo).

Je kunt dan wel een (al dan niet tijdelijke) testuser maken, maar dan heb je nog steeds niet al Pietjes rollen/rechten/settings etc. En al heb je dat dan na veel gedoe helemaal gelijk getrokken, wie weet zit 't probleem wel in zijn/haar "eerste registratiedatum" in combinatie met de exacte inhoud van diens winkelmandje, aantal ontvangen berichten of whatever. Dat ga je met een testuser nooit bereiken (of je moet een "copy from user X"-script bouwen ofzo). Het alternatief is Jantjes password resetten naar iets dat je weet en dan met Jantjes account in te loggen, maar dan kan Jantje niet meer inloggen omdat z'n wachtwoord veranderd is. Impersonaten is dus, in veel gevallen, verdomd handig.

Uiteraard hangt 't ook een beetje van de usecase af; een mogelijkheid tot impersonaten wil je bijvoorbeeld niet (zo snel) hebben bij toegang tot, zeg, medische dossiers of bankzaken (en ook daar zal 't vast her-en-der gebeuren of mogelijk zijn; maar dat heb je het recht om te impersonaten ook alleen maar als je dat ook écht nodig hebt).

Je kan natuurlijk ook als admin een sessie opzetten op naam van een bepaalde user. Je hoeft natuurlijk niet perse met een username/wachtwoord in te loggen, je kan exact dezelfde inlog bereiken door username/IKBENADMIN=true...

Afhankelijk van je login implementatie is dit waarschijnlijk ook de beste optie; Je hoeft niet te rommelen met impersonations enzo, je logt gewoon in als die user (maar dan niet met een wachtwoord...)

[Hydra]

CH40S schreef op vrijdag 13 mei 2016 @ 18:38:
Als een probleem voordoet bij een bepaalde user, zal het probleem eerder 'between keyboard and chair' zitten dan in het systeem, is mijn ervaring.

Yup. Maar als dat je standaard uitgangspunt is ben je gewoon een slechte dev. En om het te testen zul je in moeten kunnen loggen als die user en hem om z'n password vragen is natuurlijk geen optie.

[Verwijderd]

Gerco schreef op vrijdag 13 mei 2016 @ 17:58:
In mijn systeem wat ik een eeuw geleden gemaakt heb had ik een "impersonate user" knop waarmee je dus bovenstaande kunt doen. Cruciaal verschil is echter dat ik geen mogelijkheid had ingebouwd om weer terug te keren naar admin. Er zijn twee redenen hiervoor:

1. Wanneer je een speciale constructie gebruikt om 'half' een bepaalde user te kunnen worden kan het zijn dat bepaalde functionaliteit wel werkt wanneer je 'echt' bent ingelogd en niet wanneer je impersonate of andersom.

2. Als er een mogelijkheid is voor een user om zichzelf in een admin om te toveren (zoals een 'end impersonate' functie) dan kan die functie mogelijk misbruikt worden zonder dat de user eerst admin geweest is door een bug.

Het lijkt me dus veiliger om impersonation één richting op te laten werken. Als je terug wilt naar de admin account moet je dus gewoon opnieuw inloggen.

Dit klopt allebei niet, althans, niet in het systeempje dat ik heb gebouwd.

1. Er is geen sprake van 'half'. Er wordt gekeken naar het id in het ene, of in het andere veld. Geen tussenweg.

2. In het 'hoofdveld' blijft altijd het id van de user/beheerder staan dat bij inloggen is ingevuld. Alleen in geval van een beheerder kan het 2e veldje met een user-id gevuld worden. Een 'end impersonate' functie kan hier dus niets aan veranderen, omdat dan altijd naar het 1e veldje wordt gekeken en dat is niet veranderd. Zelfs al zou een user dat 2e veldje kunnen manipuleren, dan nog is met 1 simpele check dicht te timmeren dat bij een user die geen beheerder is sowieso nooit naar dat 2e veldje gekeken wordt.

[Gerco]

Verwijderd schreef op zaterdag 14 mei 2016 @ 15:54:
2. In het 'hoofdveld' blijft altijd het id van de user/beheerder staan dat bij inloggen is ingevuld. Alleen in geval van een beheerder kan het 2e veldje met een user-id gevuld worden. Een 'end impersonate' functie kan hier dus niets aan veranderen, omdat dan altijd naar het 1e veldje wordt gekeken en dat is niet veranderd. Zelfs al zou een user dat 2e veldje kunnen manipuleren, dan nog is met 1 simpele check dicht te timmeren dat bij een user die geen beheerder is sowieso nooit naar dat 2e veldje gekeken wordt.

En wat als een gebruiker dat 'hoofdveld' weet te manipuleren en dan 'end impersonate' aanroept? Dan is die gebruiker opeens admin. Dat kan natuurlijk nooit gebeuren tenzij er ergens anders in de applicatie een bug zit, maar dat kun je nooit uitsluiten. "Defence in depth" heet dat.

Als je bugs zo eenvoudig kon uitsluiten dan zouden dingen als ASLR en Buffer Overflow Protection ook nooit nodig zijn. Als er immers geen bugs in een programma zitten dan zou je die beveiligingen nooit nodig hebben. Toch bestaan ze en ze zijn waardevol genoeg om tegenwoordig standaard geïmplementeerd te worden.

In dit specifieke geval was mijn redenatie:

Een terugkeerfunctie is niet nodig, je kunt immers net zo makkelijk gewoon weer als admin inloggen nadat je als user uitgelogd bent en zo'n functie kan mogelijk misbruikt worden als 'ie bestaat. Het eerste bugvrije programma groter dan Hello, World! moet nog geschreven worden dus als je een functie niet nodig hebt, laat hem dan weg. Zeker als het een functie is om beveiligingsrechten aan te passen.

Als die functie in jouw applicatie wel nodig is, dan moet je die natuurlijk inbouwen. Wees er echter op verdacht dat code gebruikt kan worden op manieren die je bij het ontwerp van de applicatie niet voorzien had. Iedere kwetsbaarheid in iedere applicatie is het resultaat van een ontwikkelaar die niet voldoende voorspeld had hoe zijn of haar code gebruikt kan worden.

[ Voor 9% gewijzigd door Gerco op 14-05-2016 23:08 ]

[Croga]

Gerco schreef op zaterdag 14 mei 2016 @ 22:59:
En wat als een gebruiker dat 'hoofdveld' weet te manipuleren en dan 'end impersonate' aanroept? Dan is die gebruiker opeens admin. Dat kan natuurlijk nooit gebeuren tenzij er ergens anders in de applicatie een bug zit, maar dat kun je nooit uitsluiten. "Defence in depth" heet dat.

Als een gebruiker het hoofdveld kan manipuleren heeft hij "end impersonate" helemaal niet nodig, noch de impersonate functie. Dan kan hij altijd al zichzelf admin maken.


De manier die hier beschreven wordt is veilig in de zin dat alles wat er aan misbruik op gedaan kan worden, ook gedaan kan worden als de functie überhaupt niet zou bestaan. Hij voegt dus geen extra vulnerabilities toe.

Cartman! schreef op vrijdag 13 mei 2016 @ 19:49:
Als je er al vanuit gaat dat dit door bugs misbruikt kan worden is je systeem niet in orde en/of is het niet voldoende getest.

Dat is wel heel kort door de bocht.... Dat is een argument in de categorie "nieuwe kleren van de keizer"....

[ Voor 18% gewijzigd door Croga op 14-05-2016 23:09 ]