[PHP] optimale beveiliging beheerfunctie

imp4ct schreef op donderdag 16 augustus 2007 @ 15:55:
Nu 't zal waarschijnlijk misschien niet zo nuttig zijn. Maar stel dat je geen session vars gaat gebruiken, want dat is dus eigenlijk info opslaan. Maar dus eigenlijk constant de gebruiker z'n toegang checkt via de database. Het voordeel is dan dat wanneer je rechten van een user wijzigt dit ook direct wordt doorgevoerd.

Als je met session vars gaat gebruiken blijven de rechten bestaan totdat de sessie opnieuw is aangemaakt en de user opnieuw aanmeld. Natuurlijk kan je bij toewijzing van nieuwe rechten de session natuurlijk altijd verwijderen en de user verplichten opnieuw in te loggen.

Nadeel van constant te checken in de DB is dat bij een drukke site er dus een massa verkeer loopt tussen DB & site wat misschien dan vertraging kan opleveren.

Verwijderd schreef op vrijdag 17 augustus 2007 @ 08:59:
ah ok, ik begrijp er al weer wat meer van. In mijn geval zijn er echter maar een paar beheerders en dit zullen er niet snel meer dan 5 worden. Verder zijn er alleen gewone gebruikers en beheerders dus er zijn slechts twee groepen. Binnen die groepen heeft iedereen precies dezelfde rechten. Waar het mij nu vooral nog om gaat is of het veilig is om beheerders en gewone gebruikers van dezelfde pagina's (dus dezelfde php files) gebruik te laten maken. In ieder file wordt dan inderdaad de status van de gebruiker gecheckt en vervolgens worden alleen als de status beheerder is ook de beheerfunctie weergegeven en anders alleen de gewone functies.

japaveh schreef op vrijdag 17 augustus 2007 @ 09:40:
[...]
Let wel op dat je niet alleen links verbergt voor de gebruikers

imp4ct schreef op vrijdag 17 augustus 2007 @ 09:50:
[...]


Hoe doe je dit ?

1
2
3
4
5
6
7
8
9
10
11
12

if ($user->status == 'admin') {
   print '<a href="http://domein.nl/forum/edit_message/10">Pas dit bericht aan</a>' ;
}

//en dan..
if ($action == 'edit_message') {
   if ($user->status != 'admin') {
      die ('Scheer hier weg');
   }
   
   // etc
}

[ Voor 19% gewijzigd door japaveh op 17-08-2007 10:17 . Reden: parse error... ]

iH8 schreef op donderdag 16 augustus 2007 @ 12:42:
sla in de sessie ook het ip op en controlleer bij elke pageview of dat het session_ip nog hetzelfde is als het remote_addr om zo sessionhijacking te voorkomen.

DexterDee schreef op vrijdag 17 augustus 2007 @ 16:54:
[...]

Veiliger is het om nog meer CGI variabelen te gebruiken behalve het IP adres. Zo is de browserversie en operating system en ingestelde taal ook statisch. Ook is het handig om naar de X-FORWARDED-FOR header te kijken en deze mee te nemen als deze bestaat.
Het makkelijkst is het om van een aantal van die variabelen een MD5 digest te maken en deze digest elke keer te vergelijken. Zo voorkom je dat door proxy gebruik session hijacking nog steeds mogelijk is.
Zorg er ook voor dat voordat er belangrijke admin acties uitgevoerd worden, dat het session id geregenereerd wordt (zie functie session_regenerate_id)

[ Voor 6% gewijzigd door FragFrog op 19-08-2007 16:31 ]

FragFrog schreef op zondag 19 augustus 2007 @ 16:31:
Op zich is dit een van de moeilijkste dingen om je tegen te beveiligen, zelf controleer ik doorgaans met $_SERVER['HTTP_REFERER'] of admin-acties wel vanuit een adminpagina aangeroepen worden, maar helemaal veilig is dit ook niet. Zorg er in ieder geval voor dat gevaarlijke acties niet uitgevoerd kunnen worden door enkel een locatie te openen, dan kom je al een heel eind

FragFrog schreef op zondag 19 augustus 2007 @ 16:31:
In principe wel, wat het doet is zorgen dat een oud sessie-id niet meer werkt. Als iemand nu achter het sessie-ID van een admin komt is dat bij de volgende pagina-refresh alweer ongeldig, mits je'm maar elke pagina aanroept.

Een tip: waar je tot nu toe nog geen enkele aandacht aan besteed hebt zo te zien is cross-site-scripting. Als iemand een javascriptje maakt met iets als window.open('http://jouwsite.nl/admin/delete/45'); en een ingelogde admin komt op die site zal hij als je geen conformatie hebt zonder het zelf uberhaupt te merken iets verwijderen. In combinatie met bijvoorbeeld een lek in jpg afhandeling van laatst (waarbij het mogelijk werd javascript uit te voeren door een corrupte header mee te geven met een plaatje) kun je voor elkaar krijgen dat je als gebruiker een plaatje kan uploaden of linken wat ervoor zorgt dat hij feitelijk jou admins kan laten doen wat'ie wil.

Op zich is dit een van de moeilijkste dingen om je tegen te beveiligen, zelf controleer ik doorgaans met $_SERVER['HTTP_REFERER'] of admin-acties wel vanuit een adminpagina aangeroepen worden, maar helemaal veilig is dit ook niet. Zorg er in ieder geval voor dat gevaarlijke acties niet uitgevoerd kunnen worden door enkel een locatie te openen, dan kom je al een heel eind

Met hem dus

edit:

Verder vind ik het gewoon ranzig ook als je ineens stukjes beheersfunctie door je clientcode heen ziet

[ Voor 44% gewijzigd door SchizoDuckie op 20-08-2007 13:07 ]

[ Voor 6% gewijzigd door FragFrog op 20-08-2007 18:23 ]

DexterDee schreef op vrijdag 17 augustus 2007 @ 16:54:
[...]

Veiliger is het om nog meer CGI variabelen te gebruiken behalve het IP adres. Zo is de browserversie en operating system en ingestelde taal ook statisch. Ook is het handig om naar de X-FORWARDED-FOR header te kijken en deze mee te nemen als deze bestaat.
Het makkelijkst is het om van een aantal van die variabelen een MD5 digest te maken en deze digest elke keer te vergelijken. Zo voorkom je dat door proxy gebruik session hijacking nog steeds mogelijk is.
Zorg er ook voor dat voordat er belangrijke admin acties uitgevoerd worden, dat het session id geregenereerd wordt (zie functie session_regenerate_id)

FragFrog schreef op zondag 19 augustus 2007 @ 16:31:

Op zich is dit een van de moeilijkste dingen om je tegen te beveiligen, zelf controleer ik doorgaans met $_SERVER['HTTP_REFERER'] of admin-acties wel vanuit een adminpagina aangeroepen worden, maar helemaal veilig is dit ook niet. Zorg er in ieder geval voor dat gevaarlijke acties niet uitgevoerd kunnen worden door enkel een locatie te openen, dan kom je al een heel eind

Whizzkid92 schreef op dinsdag 21 augustus 2007 @ 10:22:
[...]

Ik switch weleens tussen browsers...

Grijze Vos schreef op dinsdag 21 augustus 2007 @ 12:12:
Volgens de HTTP spec mag een GET actie ook geen side-effects hebben.

[ Voor 54% gewijzigd door Voutloos op 21-08-2007 12:39 ]

Voutloos schreef op dinsdag 21 augustus 2007 @ 12:36:
[...]

Een actie als 'bekijk gegevens van user X' is idempotent en hoort gewoon via GET gedaan te worden.

Het punt is dat het geheimhouden van admin-urls niet je enige vorm van beveiliging moet zijn, geheime urls is slechts een stukje 'security through obscurity'.

Grijze Vos schreef op dinsdag 21 augustus 2007 @ 12:12:
Volgens de HTTP spec mag een GET actie ook geen side-effects hebben. Kon die JPEG exploit ook posten?

FragFrog schreef op dinsdag 21 augustus 2007 @ 13:30:
[...]

Correct, maar ik herinner me nog de ophef over Googles webaccelerator die ook alleen maar GET requests versnelde Niet iedereen houdt zich aan de specs helaas In principe kun je alle javascript ermee uitvoeren die je maar wilt, dus ook het versturen van POST documenten, zie ook dit t.net artikel.

Voor zover ik weet zijn er drie manieren om je hier tegen te beschermen:
3. Je geeft een uniek ID mee met elke transactie (deze beveiliging gebruik ik bijvoorbeeld in een bepaald CMS voor delete-acties) die je bij het uitvoeren van de transactie weer controleert.

[..]

Methode 3 is voor zover ik weet haast niet te kraken als je'm goed toepast maar een stuk lastiger te implementeren aangezien je unieke controleerbare codes moet genereren.

Overigens is geen enkel systeem echt helemaal waterdicht - kijk bijvoorbeeld naar die banksite die laatst gespoofed is, als iemand je clients' hostfile aanpast en een slimme proxy maakt ga je er alsnog aan als je niet ook een SSL verbinding vereist om maar iets te noemen. Hou daarom ook altijd een transactielog bij en stop desnoods verdachte transacties in een moderatieque - als het om geld gaat zijn hackers helaas verdraaide inventief

FragFrog schreef op maandag 20 augustus 2007 @ 18:22:
Mwoach, kwestie van smaak, zelf gebruik ik doorgaans een aparte class voor beheersfuncties die een constructor heeft die authenticatie checked. Op die manier ben je er zeker van dat alle adminfuncties alleen beschikbaar zijn voor iemand die als admin ingelogd is. Sowieso gooi ik al m'n PHP files op de index na in een folder die niet beschikbaar is dankzij een .htaccess, dan kunnen je gebruikers echt verrekte weinig doen.

Ariën Clay schreef op donderdag 23 augustus 2007 @ 01:03:
kan ook buiten je webroot hoor, als je daar access toe hebt .