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.
<?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;
}
?>
Alvast bedankt voor de input
[size=xsmall]Toevoeging op 28/10/2025 18:38:33:[/size]
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.
nee de identeificatiecode/autorisatiecode is opgeslagen in de database en wordt gekoppeld aan een gebruiker. op de pagina moet de identificatiecode/authorisatiecode dan toch ook komen om te vergelijken? uiteraard kan er op de pagina een include komen te staan die de identificatiecode/authorisatiecode binnenhaalt. de identificatie staat dan opgeslagen buiten de root uiteraard.
[size=xsmall]Toevoeging op 29/10/2025 12:59:55:[/size]
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.
[size=xsmall]Toevoeging op 29/10/2025 13:04:02:[/size]
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).
[size=xsmall]Toevoeging op 29/10/2025 13:05:09:[/size]
de authorisatiecode/identificatiecode is dan de naam van de website zeg maar. dus bijv. websitevanjohan.nl
(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....
[size=xsmall]Toevoeging op 29/10/2025 13:15:56:[/size]
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
Bedankt voor je input en ik snap je aanpak tot op zekere hoogte. het bestand met content staat op de server, dus er komt geen database bij kijken. je geeft aan "Nu kun je in de betreffende pagina opslaan dat die hoort bij gebruiker 123". dus gewoon in de pagina zetten. $autorisatiecode = 123; ? of $autorisatiecode = "websitevanjohan.nl' en dan toch vergelijken met de opgehaalde authorisaticode van de ingelogde gebruiker. dit is wat ik vanaf begin op doelde. kom ik even terug op begin van mijn bericht. is simpel, maar is het ook verder veilig?
Je kunt het bestand bewerken. Dus dan kun je waarschijnlijk ook $autorisatiecode=123 veranderen, al dan niet bewust, in $autorisatiecode=1234;
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.
ik snap wat je bedoeld, maar het hele system is al klaar en er is goed over nagedacht. het systeem laat het trouwens niet toe dat php kan worden ingevoegd gewijzigd etc. ook is het niet mogelijk dat een gebruiker een authorisatiecode kan aanpassen of zelf kan invoegen. Het systeem is zo gebouwd dat dat niet kan. de gebruiker heeft geen ftp gegevens tot de beschikking aangezien de site draait op mijn hosting.
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
<?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>
?>
[size=xsmall]Toevoeging op 29/10/2025 15:14:06:[/size]
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.
[size=xsmall]Toevoeging op 29/10/2025 15:48:13:[/size]
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.
[size=xsmall]Toevoeging op 29/10/2025 15:48:13:[/size]
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.
"chatgpt" en "dus" in 1 zin, is niet een goede benadering.
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.
ik begrijp je punt. en zal daarop letten en het systeem evt. aanpassen waar nodig. Ik vind dit allemaal zeer interessant. heb trouwens al een andere aanpak zodat het veiliger wordt. op de pagina wordt opnieuw verbinding gemaakt met de server die de authorisaitie van de gebruiker opnieuw ophaald. en die wil ik dan vergelijken met de autthoisatiecode van de sessie.
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?
Als je een goed inlogsysteem wilt, dan moet je controle hebben over de inlogsessies, die je in een database opslaat.
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)
bedankt voor de toelichting. dan weet ik wat ik moet doen. ga ermee aan de slag. zal de oplossing als ik ermee klaar ben wel hier posten zodat jullie ernaar kunnen kijken of het goed is verder.
