De PHPhulp kroeg
is dit een goede manier om een pagina te beveiligen?
Ik vraag mij af of de onderstaande methode een goede manier is om een pagina te beveiligen.
Ik heb in mysql een tabel users met de volgende velden:
gebruikersnaam
wachtwoord: (is gehastet)
toegangscode:
veldnaam toegangscode bevat de paginacode om toegang te krijgen tot elke pagina die dezelfde toegangscode bevat.
via bijv login.php, kan de gebruiker inloggen. Wanneer de gebruiker succesvol is ingelogd wordt zowel de gebruikersnaam als de toegangscode opgeslagen in elk een cookie/ vervolgens wordt de gebruiker doorgestuurd naar het controlpanel. Hier kan hij dan pagina's openen.
de pagina zelf heeft onderstaande inhoud (voorbeeld). hier wordt eerst gecontroleerd of beide sessies "gebruiker". en "toegangscode". aanwezig zijn. Vervolgens wordt nog gecontroleerd of de sessie "toegangscode" overeenkomt met de toegangscode op de pagina.
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
<?php
session_start();
$toegangscode = "pagina10";
$baseUrl = 'https://' . $_SERVER['HTTP_HOST'];
// controle of sessie gebruiker en toegancode zijn aangemaakt
if (!isset($_SESSION['gebruiker']) || !isset($_SESSION['toegangscode'])) {
header("Location: $baseUrl/system/check-toegang/geen-toegang.php");
exit;
}
// controle of sessie toegangscode overeenkomt met inhoud toegangscode op deze pagina
if ($_SESSION['toegangscode'] !== $toegangscode) {
header("Location: $baseUrl/system/check-toegang/geen-toegang.php");
exit;
}
?>
session_start();
$toegangscode = "pagina10";
$baseUrl = 'https://' . $_SERVER['HTTP_HOST'];
// controle of sessie gebruiker en toegancode zijn aangemaakt
if (!isset($_SESSION['gebruiker']) || !isset($_SESSION['toegangscode'])) {
header("Location: $baseUrl/system/check-toegang/geen-toegang.php");
exit;
}
// controle of sessie toegangscode overeenkomt met inhoud toegangscode op deze pagina
if ($_SESSION['toegangscode'] !== $toegangscode) {
header("Location: $baseUrl/system/check-toegang/geen-toegang.php");
exit;
}
?>
Alvast bedankt voor de input
Toevoeging op 28/10/2025 18:38:33:
even een toelichting: de toegangscode is uniek. de inhoud pagina10 is niet helemaal een goed voorbeeld. was als voorbeeld bedoeld. je zou meer denken om een code zoals bijv. : A3we1242Hfd1231Eq. deze code kan dus op meerdere pagina's staan en dus alleen toegangelijk die deze toegangscode ter beschikking heeft.
Gewijzigd op 28/10/2025 18:39:46 door Paul Weiss
Quote:
Wanneer de gebruiker succesvol is ingelogd wordt zowel de gebruikersnaam als de toegangscode opgeslagen in elk een cookie/
Hier maak je al een grote fout, de 'sleutel' meegeven in een cookie. Cookies zijn tekstbestanden die je eenvoudig kan bekijken.
Gewijzigd op 28/10/2025 18:42:18 door - Ariën -
Ik zou na een succesvole loging ook een sessie kunnen aanmaken zoals bijv. toegang met de waarde "ja". wanneer succesvol is ingelogd. wanneer op de pagina wordt gecontroleerd of de waarde "ja" is dan wordt pas de topegangscode vergeleken. bij nee wordt de gebruiker uiteraard doorgestuurd naar de pagina geen-toegang.php
Op deze wijze zou de gebruikersnaam altijd verborgen blijven.
Ik zou na een succesvolle login ook alleen de toegangscode kunnen opslaan in de cookie. of is dat te weinig controle?
Paul Weiss op 28/10/2025 18:47:51:
Ik zou na een succesvolle login ook alleen de toegangscode kunnen opslaan in de cookie. of is dat te weinig controle?
Waarom wil je dat? Wat doe je met die toegangcode, als die al gevalideerd is?
Stap 1: maak na een goede inlogvalidatie een sessie aan $_SESSION['logged_in'] = true;
Stap 2: maak na het ingeven van de toegangscode een sessie aan met $_SESSION['accessed'] = true;
een gewone gebruiker heet "medewerker"
iemand die de voorraden kan beheren heeft daarnaast ook de rol "magazijn"
Iemand die op de afdeling Inkoop werkt, is naast medewerker ook gerechtigd met de rol "inkoop" om bestellingen te doen.
En op een php pagina staat dan een functie
controleerToegang($_SESSION['gebruikerID'], ['magazijn', 'inkoop'])
En dan zoek je op in de database op de gebruiker met $gebruikerID de rol "magazijn" of "inkoop" heeft.
Zo niet, dan Geen Toegang melden.
Of je haalt bij het inloggen alle rollen op (iemand kan best meerdere rollen hebben)
en dan stop je die in een $_SESSION-var.
dan wordt het
controleerToegang($_SESSION['gebruikerID'], $_SESSION['rollen'], ['inkoop', 'admin']);
Dat is misschien efficiënter als je een menu aan het opbouwen bent, zodat je niet per linkje moet controleren in de db
Maar misschien is het ook handig om per rol een menu te hebben dat dan ge-include wordt.
--
en ik denk/hoop dat je de term cookie verwart met sessions.
Cookies staan in de browser en zijn eenvoudig aan te passen.
Voor sessions staat een session-cookie in de browser, maar die lange code verwijst naar een bestandje op de server, zodat die informatie niet bij de gebruiker bekend is en zeker ook niet aangepast kan worden.
De noodzaak om de toegang tot een pagina te regelen met een code "A3we1242Hfd1231Eq" is er dan ook niet.
"inkoop" als toegangsregel is veel begrijpelijker en voorkomt verwarring en opzoekwerk later: o nee! ik heb de code voor simpele gebruiker toch gekoppeld aan het overzicht van alle salarissen!"
aan de hand van de toegangscode kan nl gecontroleerd worden of de gebruiker toegang mag hebben tot alle pagina';s binnenin deze direcory. Je kunt dat uiteraard ook een "rol". bekijken. de gebruiker heeft de eigenaarsrol. Maar ik ga er mee aan de slag.
Als het om rechten gaat, kan je ook kijken naar een RBAC (Role-Based Access Control) rechtensysteem. Het hoeft eigenlijk niet heel gecompliceerd te zijn. Je kan ook heel simpel met userlevels werken, zoals 1 = user, 2 = moderator, 3 = beheerder, 4 = hoofdbeheerder. Dan kan je eenvoudig met de vergelijkingsoperators van PHP kijken wat iemand mag doen.
Het is dan wel een alles-of-niets methode. Want misschien wil je liever gebruikersgroepen hebben die aan een rol en actie gekoppeld zijn, zoals:
Administrator = Mag alles
Moderator nieuws = mag alleen nieuws beheren
Stagiar nieuws = mag nieuws plaatsen, maar met controle vooraf
Moderator reportages = mag reportages beheren
Moderator agenda = mag agenda beheren
Fotoredactie = mag foto's aan het systeem toevoegen
Dan kan je iemand bijvoorbeeld de groepen 'Moderator nieuws' en 'fotoredactie' krijgen, zodat die vanzelfsprekend nieuws mag beheren, en foto's aan het systeem kan toevoegen.
Zoiets gebruik ik ook in mijn eigen geschreven CMS, en het is behoorlijk flexibel met C-R-U-D (Create (aanmaken), Read (lezen), Update (bijwerken) en Delete (verwijderen)) acties, en een toegevoegde 'Publish'-actie. Al hoort die eigenlijk niet echt in het model ;-).
Toevoeging op 29/10/2025 11:48:32:
Ik zie net Ivo zijn oplossing. Het klinkt ook goed, maar ik zou rollen niet in een sessie zetten. Als een medewerker bonje heeft, waarna zijn rechten worden ingetrokken, blijven de rollen in de sessie, en kan diegene lekker verder klooien (tot de baas hem achter zijn pc vandaan mept ;-) ).
Gewijzigd op 29/10/2025 11:49:03 door - Ariën -
Toevoeging op 29/10/2025 12:38:41:
Ik heb trouwens maar in principe 1 gebruiker die toegang tot deze pagina's kan/mag krijgen. mocht er een tweede gebruiker zijn die ook toegang wil hebben, maak ik deze aan en geef hem toegang tot deze pagina's.
zo kan evt. zowel gebruiker1 als gebruiker2 de authorisatiecode. "website-a". hebben. beide gebruikers hebben dan ieder toegang tot elke pagina met autorisatiecode "website-a".
Gewijzigd op 29/10/2025 12:40:27 door Paul Weiss
En wat nu als deze code nu uitlekt, en jij tijdens een welverdiende vakantie op Kreta, ligt te zonnen? Hoe ga je dan de boel aanpassen?
Voor een goed rechtensysteem heb je sowieso een database nodig.
Gewijzigd op 29/10/2025 12:50:12 door - Ariën -
Ik ben benieuwd naar je keuze waarom je het gebruik van een database probeert te ontwijken? Je probeert op kazige wijze het wiel opnieuw uit te vinden.
Gewijzigd op 29/10/2025 12:49:53 door - Ariën -
Toevoeging op 29/10/2025 12:59:55:
cms systeem is al klaar en werkt zonder database. alle content wordt opgeslagen op de server. enige wat dus in de database staat zijn de gebruikers met hun toegangsrechten.
Toevoeging op 29/10/2025 13:04:02:
ik heb gewoon een vrij wimpel toegangssysteem. gebruiker heeft 100% of geen toegang tot alle pagina's binnenin een direcory/website.
dus mijn vraag is of de aanpak veilig is? Dus autorisatiecode/identieficatiecode die in de database staat en is gekoppeld aan de gebruiker en de autothorosatieocode/idententiteitscode plaatsen op elke pagina en dan met elkaar wordt vergeleken met de autorisatiecode/identiteitscoce van de ingelogd gebruiker (via sessie).
Toevoeging op 29/10/2025 13:05:09:
de authorisatiecode/identificatiecode is dan de naam van de website zeg maar. dus bijv. websitevanjohan.nl
Gewijzigd op 29/10/2025 13:07:55 door Paul Weiss
Nu kun je in de betreffende pagina opslaan dat die hoort bij gebruiker 123. Of je bestandsnaam luidt
123.inleiding.php
123.verhaaltje.php
of je hebt een tabel in je database, waarin staat:
Code (php)
1
2
3
4
2
3
4
gebruikerid, paginanaam paginabestand
123 inleiding 6556577e-47cc-4b66-a002-2acf5d8e036b
123 verhaaltje 224e3fe6-f499-4636-8f65-25827e170631
957 mystory 521e9306-a499-4ba2-bc37-3b18018ee90e
123 inleiding 6556577e-47cc-4b66-a002-2acf5d8e036b
123 verhaaltje 224e3fe6-f499-4636-8f65-25827e170631
957 mystory 521e9306-a499-4ba2-bc37-3b18018ee90e
(die namen zijn uuid's die je uniek kunt genereren)
Die bestanden hoeven geen bekende naam te hebben: als je je site voor de bezoeker genereert dan vind je in de database wel dat je voor de site van 123 als je de inleiding wilt tonen je bestand 6556577e-47cc-4b66-a002-2acf5d8e036b moet includen.
Maar dan kun je de inhoud van het bestand ook wel in plaats van met file_put_contents() in een bestand wegschrijven middels INSERT INTO naar de database....
Toevoeging op 29/10/2025 13:15:56:
of als het niet direct aan de gebruiker gekoppeld is:
dan heb je een tabel "sites"
daarin staat
1 paulswebsite.nl
2 johanswebsite.com
en bij gebruiker 123 staat dan dat site met id = 1 van hem is.
En mijn lijstje hierboven met 3 kolommen, krijgt dan in plaats van gebruikersid een kolom siteid met 1 in plaats van 123
Gewijzigd op 29/10/2025 13:52:18 door Paul Weiss
Of verwijderen.
Tenzij jouw opsla-proces zelf die code toevoegt en bij het ophalen voor bewerken er weer uithaalt.
Is er een reden waarom je dit dmv het bewerken van bestanden probeert te doen?
Je haalt alleen maar problemen op je nek, waarbij het bewerken er maar 1tje is.
In een database kun je data georganiseerd kwijt.
Kun je eenvoudig een backup maken.
Eenvoudig een site op non-actief stellen, zonder alle bestanden te moeten verwijderen.
Ik vrees een beetje dat je bestanden ook php kunnen bevatten. In dat geval kan een gebruiker ook zelf PHP invoegen en dat wordt direct uitgevoerd. Of in het geval van syntax-fouten werkt het meteen niet meer.
Ik snap dat je in eerste instantie voor "bewerken van files" gaat bij het maken van een site / cms.
Maar nu je meerdere gebruikers en sites in het pakket plaatst, ben je dit stadium eigenlijk wel voorbij.
Ja, mijn eerste site schreef ik ook zo. Of in elk geval het gastenboek dat we toen hadden.
CGI en Perl hadden toen nog niet zo veel mogelijkheden.
Maar toen de server PHP 4 kreeg en een database, werd zo veel meer mogelijk...
maak gewoon een tabel aan in je database, waarbij je de teksten daarin opslaat.
Overal waar je de bestanden gebruikte, doe je dan een query.
Daarbij kun je dan direct gebruik maken van alle beveiligingen die je wilt voor het verkomen van niet toegestane acties: neem het gebruikers id op in de query en hij kan al niet meer op andermans account werken.
Ja het kost je een middagje bestandsinhouden kopieren naar de tabel
Maar alles wordt daarna eenvoudiger.
Het is nu alsof je een reis wilt maken waar iemand een auto voor zou inzetten, maar jij wilt een paardenkar, maar dan zonder paard en zeshoekige wielen.
Het zal gaan, maar met allemaal extra maatregelen en onhandigheden.
Graag wil ik nog weten of onderstaande veilig is als ik dat op een pagina plaats? verbinding is https: uiteraard. onderstaande pagina staat dan als voorbeeld op websitevanpaul.nl
onderstaande is bijv de pagina wiebenik.php
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
<?php
session_start();
$toegangscode = "websitevanpaul.nl";
$baseUrl = 'https://' . $_SERVER['HTTP_HOST'];
// controle of sessie gebruiker en toegancode zijn aangemaakt
if (!isset($_SESSION['gebruiker']) || !isset($_SESSION['toegangscode'])) {
header("Location: $baseUrl/system/check-toegang/geen-toegang.php");
exit;
}
// controle of sessie toegangscode overeenkomt met inhoud toegangscode op deze pagina
if ($_SESSION['toegangscode'] !== $toegangscode) {
header("Location: $baseUrl/system/check-toegang/geen-toegang.php");
exit;
}
<h1> je hebt toegang</h1>
<h2>mijn naam is henk...</h2>
<p>ik woon in</p>
?>
session_start();
$toegangscode = "websitevanpaul.nl";
$baseUrl = 'https://' . $_SERVER['HTTP_HOST'];
// controle of sessie gebruiker en toegancode zijn aangemaakt
if (!isset($_SESSION['gebruiker']) || !isset($_SESSION['toegangscode'])) {
header("Location: $baseUrl/system/check-toegang/geen-toegang.php");
exit;
}
// controle of sessie toegangscode overeenkomt met inhoud toegangscode op deze pagina
if ($_SESSION['toegangscode'] !== $toegangscode) {
header("Location: $baseUrl/system/check-toegang/geen-toegang.php");
exit;
}
<h1> je hebt toegang</h1>
<h2>mijn naam is henk...</h2>
<p>ik woon in</p>
?>
Toevoeging op 29/10/2025 15:14:06:
kan een php sessie op deze wijze onderschept worden? of kan een hacker op deze wijze de inhoud van de sessie aanpassen? zoals gezegd alles is https verbinding.
Toevoeging op 29/10/2025 15:48:13:
chat gpt kwam met dit antwoord. dus is inderdaad niet veilig om alleen de toegangscodee )op deze manier) te controleren:
Hardcoded toegangscode (“123”) is voorspelbaar.
Zelfs al is het maar één gebruiker die deze code heeft, een aanvaller hoeft alleen maar te raden dat dit de waarde is die de site controleert.
De autorisatie hangt af van een enkel sessieveld dat makkelijk te manipuleren is (als er bijvoorbeeld een kwetsbaarheid elders in je code zit, of XSS).
Een aanvaller kan dan gewoon $_SESSION['toegangscode'] = "123"; zetten.
Geen controle op serverniveau.
Je controleert niet in de database welke gebruiker deze toegangscode heeft; je vertrouwt puur op de sessie.
Dat betekent dat als iemand erin slaagt een sessie te stelen of aan te passen, hij directe toegang krijgt.
Toevoeging op 29/10/2025 15:48:13:
chat gpt kwam met dit antwoord. dus is inderdaad niet veilig om alleen de toegangscodee )op deze manier) te controleren:
Hardcoded toegangscode (“123”) is voorspelbaar.
Zelfs al is het maar één gebruiker die deze code heeft, een aanvaller hoeft alleen maar te raden dat dit de waarde is die de site controleert.
De autorisatie hangt af van een enkel sessieveld dat makkelijk te manipuleren is (als er bijvoorbeeld een kwetsbaarheid elders in je code zit, of XSS).
Een aanvaller kan dan gewoon $_SESSION['toegangscode'] = "123"; zetten.
Geen controle op serverniveau.
Je controleert niet in de database welke gebruiker deze toegangscode heeft; je vertrouwt puur op de sessie.
Dat betekent dat als iemand erin slaagt een sessie te stelen of aan te passen, hij directe toegang krijgt.
Gewijzigd op 29/10/2025 15:29:54 door Paul Weiss
Als chatgpt het omgekeerde beweerde, dan had je mogelijk ook "dus het is zo" gezegd?
Ik heb al antwoorden gekregen die in de tweede regel de eerste al tegenspraken:
"voor een voertuig hoger dan 2 meter geldt tarief A. Voor een voertuig met een hoogte tussen 2 en 3 meter geldt tarief B".... Daar zit een overlap in. A geldt trouwens voor kleiner dan 2 meter.
Vertrouw nooit een soort van horenzeggen antwoord.
Dat terzijde.
Die 123 komt niet zichtbaar langs bij je gebruikers.
dus of dat nu 123 is of een uuid maakt al niet zo veel uit.
Eerder zou je je zorgen mogen maken als gebruikers elkaars sessions kunnen uitlezen. Of zelfs hun eigen session.
Je zou je toegangscode ipv in $_SESSION ook in de database kunnen laten, en dan per keer dat je hem nodig hebt, ophalen met een query.
Maar daarbij heb je dan ook weer je gebruikersid of gebruikersnaam nodig die in diezelfde session zit.
Uiteindelijk komt het erop neer
* wie is de gebruiker?
* mag deze gebruiker dit bestand zien/bewerken?
** kan gebruiker zelf manipuleren wat hij kan zien?
de vraag met ** is van belang: in de browser mogen geen cookies staan die veranderd kunnen worden.
Urls moeten zo weinig mogelijk extra gegevens bevatten.
Dus niet iets met editbestand.php?file=inleiding.txt&user=123&accesscode=234asj234s
het gaat steeds om de controle van 3 dingen
* wat is de paginacode van de pagina?
* wie is de gebruiker?
* heeft deze gebruiker de genoemde paginacode?
Controleer dus niet alleen de code, maar ook de combi met de gebruiker.
i.p.v. de gebruikersnaam in de sessie te plaatsen zal ik de id ervan erin plaatsen. dus de gebruikersnaam komt nooit in een sessie te staan. dus samengevat. er worden dan 2 sessies aangemaakt na een succesvolle login. en wel id en authorisatocode van de gebruiker. wanneer een pagina wordt geopend wordt via de sessie "id". de bijbehorende authorisatie opgehaald uit de database, en dan vergeleken met de waarde van de sessie "autorisatiecode". deze authorisatiecode kan evt ook opnieuw worden aangepast, zodat de waarde niet altijd hetzelfe blijft. enige vraag is wanneer moet het systeem dit doen? gewoon om de zoveel tijd aanpassen en dan de gebruiker gewdwongen laten uitloggen?
Gewijzigd op 29/10/2025 16:30:28 door Paul Weiss
Worden de rechten gewijzigd als iemand ingelogd is zijn er twee opties mgoelijk:
Of de rechten worden direct aangepast omdat je die bij elke request ophaalt.
Of je logt de gebruiker uit en past de rechten aan.
Verder is een sessie normaal gesproken gekoppeld aan een cookie. Dus als iemand je PHP_SESS cookie kan bemachtigen, dan heb je een probleem. Dus zorg dat er geen XXS mogelijk is in je site. En daarnaast kan je na een inlog een sessie een ander ID geven met session_regenerate_id. Mocht iemand via een vies truukje XXS kunnen toepassen op een inlogformulier, dan is die sessieID snel waardeloos. (session hijacking)
Gewijzigd op 29/10/2025 16:35:43 door - Ariën -
https://github.com/OWASP/rbac
Het is al een poosje niet onderhouden, maar who knows heeft iemand het opnieuw uitgebracht?