PHP Sessie variabelen tbv authorizatie

[Mas-ih]

Hallo mede tweakers,

Ik ben voor ons klein bedrijfje een urenregistratie en klanten administratie webapplicatie aan maken en wil graag bij jullie toetsen of mijn idee voor user authorizatie wel zal werken of dat ik er te makkelijk over denk.


Mijn vraag
Hoe veilig is om $_SESSION variablen te gebruiken als authorizatie middel? De website zal geen session cookie gebruiken tbv authenticatie.


Wat ik al gevonden of geprobeerd heb
Wat ik bedacht en gebouwd heb en wat functioneel ook werkt is het volgende simpele stukje.

Haal de rol van de ingelogde persoon op uit de DB en plaats het in een sessie variabele, bijv. $_SESSION['rol'] = 2.

Op iedere pagina de controle inbouwen voor de rol, zoiets als if $_SESSION['rol'] =< 2 header ('Location: welcome.php').

Alvast dank voor jullie reacties!

[merauder]

Ik zou dit anders doen. Sowieso niet in sessies, want wanneer je rechten intrekt worden deze pas actief op het moment dat je deze rechten intrekt.

Wellicht slimmer om voor dit soort taken een class te bouwen, die je vervolgens include in je code. Dit scheelt heel erg veel herhalen van code.

code:

Class Authorisatie {
    function function CheckRol($userid) {
    // haal data op om te checken of user rol heeft verder niet toegevoegd.
    if(userheefttoegang) { return true; } else { return false; }
   }
}

Vervolgens doe je in de pagina iets zoals dit.

code:

require (Authorisatie.php);
$Auth = new Authorisatie()
if(!$Auth->CheckRol($userid) { 
    // doorsturen naar login
}

[Hiroj]

Het is prettig om te weten of je de applicatie enkel in een intern bedrijfsnetwerk beschikbaar maakt of dat men vanuit huis via een specifiek adres ook kan laten inloggen.

In de laatste scenario is eerder genoemde oplossing van @merauder de juiste. Mocht je kant-en-klare library zoeken, dan zou ik de term PHP ACL eens bij Google gebruiken!

[Mas-ih]

Dank beide voor de reacties.

De applicatie zal in eerste instantie enkel vanaf ons intern netwerk te bereiken zijn, maar zou in de toekomst ook via internet te bereiken moeten zijn. Maar nogmaals dat is voor de toekomst.

Iets meer achtergrond, we zijn nu met 8 medewerkers en de bedoeling is dat mensen hun gewerkte uren (+klant en soort activiteit) in een dynamische formulier invullen en dat deze opgeslagen wordt in de db. Vervolgens kunnen ze op een andere pagina hun reeds opgeslagen uren voor een bepaalde maand inzien. Dit is functionaliteit wat alle medewerkers moeten kunnen.
Daarnaast is er een stukje klantadministartie, dit is voor de adm.medewerker en de 'admin'(ik dus), waarin nieuwe klanten opgevoerd kunnen worden en betaande klanten gewijzigd kunnen worden.
En als laatste is er een rapportage stuk, wat enkel toegankelijk zou moeten zijn voor de admin, waarin gewerkte uren per medewerker, per klant, per maand, per etc..

Zoals ik zei is het een relatief simpel webapplicatie, met 3 verschillende functionele paginas, en 3 verschillende rollen.

Vandaar dat ik ook met de sessie variablen ben gaan werken, omdat voor mn gevoel dit meer past qua complexiteit. Maar ik wil dus zeker weten dat een gebruiker niet op de een of andere manier zijn de sessie variabele kan aanpassen (zonder sessie hijacks etc, het zijn geen IT mensen ).

Sorry voor de lap tekst!

[Harrie_]

Mas-ih schreef op donderdag 31 augustus 2017 @ 12:49:
lap tekst!

Niks mis met sessies; en nee gebruikers kunnen sessie-variabelen niet aanpassen. Het hele idee van een sessie is dat je een cookie plaatst waarbij de data niet bij de client wordt opgeslagen, maar op de server.

Je sessie-cookie bevat dan een hash in de trant van:

code:

ab5b55873792168c489980a7

Hoe het serverside exact technisch werkt weet ik ook niet precies, maar daar stored hij de sessie info zoals:

code:

[ab5b55873792168c489980a7]:[Naam] => "Jan Jansen"
[ab5b55873792168c489980a7]:[Rol]  =>  2
[ab5b55873792168c489980a7]:[VarX] => "WaardeY"

Om te voorkomen dat iemand een sessie hijackt (de server controleert immers op de hash in de cookie) zou je nog gebruik kunnen maken van session_regenerate_id.

In feite zijn sessies gewoon veilig en foolproof, mits:
• gebruik wordt gemaakt van session_regenerate_id
• gebruik wordt gemaakt van SSL

Je geeft aan dat het een interne webapplicatie betreft; dan komt het natuurlijk iets minder nauw maar zorg er wel voor dat je zeker weet dat de machine waarop de webapp draait niet van buitenaf benaderbaar is.


_{OT: PHP-topics mogen in Programming i.p.v. in Webdesign}

[ Voor 31% gewijzigd door Harrie_ op 01-09-2017 13:53 ]

[RGAT]

Daarmee kan iemand dus wel je sessie jatten, misschien niet zo snel gebeurt op een intranet maar op het internet wel degelijk...
Als je dat doet dan wel regelmatig de sessie-id vernieuwen om dat tegen te gaan.

[Mas-ih]

Bedankt! Dat is wat Ik wilde weten. Ik ga weer terug naar de tekentafel

[Harrie_]

Mas-ih schreef op vrijdag 1 september 2017 @ 14:09:
Bedankt! Dat is wat Ik wilde weten. Ik ga weer terug naar de tekentafel

Succes!
_{En de volgende keer PHP vragen in Programming posten dan krijg je sneller en meer antwoorden}

[Mas-ih]

Ik had het al aangemerkt bij de mods:)

[Verwijderd]

Harrie_ schreef op vrijdag 1 september 2017 @ 13:44:
Hoe het serverside exact technisch werkt weet ik ook niet precies

Da's heel simpel een bestandje genaamd sess_[sessionid] in een tijdelijke map met daarin de sessionvariabelen als serialized string.

[Creepy]

Even een tikje door naar Programming..