Beveiligen PHP, hoe?

[Hendrik6073]

Ik ben bezig met een stukje CMS voor een publieke website. Ik heb wel eens vaker zoiets in elkaar gezet (ben hobbymatig bezig)voor een interne site. Nu moet er natuurlijk een stukje beveiliging inzitten. Wat voor een techniek kan ik hiervoor het beste voor gebruiken ?

 

Verder wil ik gaan werken met includes vwb de gegevens van de server en accounts. kan ik binnen PHP aangeven waar de includes moeten staan of kan dit alleen via de PHP.INI ?

[Big fellow]

Origineel bericht van: Hendrik6073

Ik ben bezig met een stukje CMS voor een publieke website. Ik heb wel eens vaker zoiets in elkaar gezet (ben hobbymatig bezig)voor een interne site. Nu moet er natuurlijk een stukje beveiliging inzitten. Wat voor een techniek kan ik hiervoor het beste voor gebruiken ?

Verder wil ik gaan werken met includes vwb de gegevens van de server en accounts. kan ik binnen PHP aangeven waar de includes moeten staan of kan dit alleen via de PHP.INI ?

Include files kan je overal neerzetten waar de webserver lees rechten heeft. Zet ze uit een publiek toegankelijk pad!
Kwa beveiliging, er zijn vele wegen die naar Rome leiden. Wat ik zelf zou doen (en dus ook doe in sommige scripts) is een sessie aanmaken die aan het IP gekoppelt is, deze met een beperkte geldigheid wegschrijven, en in een database proppen. Dan in ieder script wat wordt aangeroepen controleren of de sessie overeenkomt met de sessie in de database. Op deze manier kan je beveiliging vrij goed voor elkaar krijgen.
Ik zou zelf niet vertrouwen op de ingebouwde validatie (.htaccess / .htpasswd) van Apache...

[Hendrik6073]

Okay, maar zet ik dan achter de include het hele pad ? ipv de php.ini aan te passen ?

 

vwb het beveiligen, is het mogelijk een voorbeeld scriptje te posten / mailen ?

 

Bij voorbaat dank

[Big fellow]

syntax:

Code:

include '../includes/secret.php';

 

Ik zal wel eens kijken voor een klein stukje code. Maar als je een beetje in PHP thuis bent dan is het zo te maken....

 

Kijk maar eens naar dit:

 

$adres = $_SERVER['REMOTE_ADDR']

$sessie = session_id();

 

Lees op php.net de pagina van de session_id functie..

 

Suc6!

[Hendrik6073]

okay, ik ben op weg.

Dank je !

[Puch]

De beste manier van werken is inderdaad met sessions.

 

heel eenvoudig uitgelegd

 

Je zorgt dat je iedereen die kan inloggen in een database staat met login en wachtwoord.

 

Laat ze inloggen al ze op de website komen.

 

Zorg via controle dat de login en het paswoord kloppen.

 

Indien alles klopt maak je een session aan.

 

voorbeeld

 

Code:

<?php//verbind eerst naar de database en haal de benodigde gegevens op.extract($_POST);if(blabla != blabla){  Ga terug naar formulier}elseif(blabla != blabla){  Ga terug naar formulier}elseif(blabla != blabla){  Ga terug naar formulier} else{   $_SESSION['login'] = "ok";}?>

 

Als je nu beveiligde pagina's maakt controleer je op die pagina eerst als de $_SESSION['login'] op ok staat.

 

Indien ja doe je niets en laat je de pagina zien

Indien nee breek je af en geef je een melding of werk je met redirect.

 

Code:

<?phpif ($_SESSION['login'] != "ok"){  die("niet ingelogd");}else{  include("pagina.php");}?>

[Big fellow]

Nadeel van die methode is dat het (theoretisch) mogelijk is om een sessie te hijacken. Dus vandaar mijn advies om de sessie met IP op te slaan in de database, en deze te controleren...

 

Wat ik zelf doe, beetje paranoid, is op het moment dat de sessie niet met de IP overeenkomt, de sessie sluiten en op te ruimen uit de database. Op die manier ben je weer iets veiliger .

[Puch]

Origineel bericht van: Big fellow

Nadeel van die methode is dat het (theoretisch) mogelijk is om een sessie te hijacken. Dus vandaar mijn advies om de sessie met IP op te slaan in de database, en deze te controleren...

Wat ik zelf doe, beetje paranoid, is op het moment dat de sessie niet met de IP overeenkomt, de sessie sluiten en op te ruimen uit de database. Op die manier ben je weer iets veiliger .

Je hebt natuurlijk gelijk, ik wil enkel het basis principe uitleggen.

In beveiliging kan je zo ver gaan als je wil. Ik bekijk altijd welke site het betreft.
Om simpel wat tekstjes aan te passen op een website heb je nu ook niet de super beveiliging nodig.
Als het echt goed moet beveiligd zijn laat ik ook het tijdstip dat de sessie wordt gemaakt in de database opslaan.
Telkens een controle op die tijd en als die ouder is dan 10 minuten breek ik de sessie af. Is hij jonger is dan 10 minuten opnieuw de huidige tijd in db.
Zo kan je nooit langer dan 10 minuten inactief zijn op die website en toch ingelogd blijven. Dit wordt veel voor online banking gebruikt.
session_id koppelen aan ip en tijd.

[Duwgati]

Ik denk dat als je het publiek toegankelijk wilt maken, dat dan de belangrijkste focus voor beveiliging zou moeten liggen op het voorkomen van allerlei technieken als XSS (cross site scripting), SQL injection etc.

Kortom, alles wat op scripts lijkt en alles wat lijkt op pogingen om je database te manipuleren moet je rücksichtslos uitfilteren.

 

Google maar eens op XSS en SQL injection. Je zult zien dat er heel veel over te vinden is. En gelukkig zijn er ook veel tools die je kunnen helpen bij het bouwen van een goeie defensie.

 

Belangrijke tip: scherm liever teveel af dan te weinig.

 

[Hendrik6073]

ik zal er eens mee gaan expirimenteren. ik vondt het session-ip idee nog niet zo n slechte, maar als het ip wijzigd werkt het natuurlijk niet meer dan dat vind ik dan weer minder.

 

SQL injection etc zegt me niet zo veel, moet ik me eerst eens in inlezen.

[Big fellow]

In antwoord op Duwgati; De beste methode is om alle vars die je terugkrijgt via de webserver/browser te controleren en te typecasten naar hetgeen wat je verwacht.

Zo bijvoorbeeld;

Code:

$num = (int)$_POST['userid']; // Hier wordt $num geforceerd een integerif (($num<1)||($num>$maxuserid)) {  // Genereer error, en stop script  error_log ("Userid out of range", 0);  echo "Invalid request<br />\n"; // Geef nooit teveel informatie terug aan de mogelijke inbreker!  die();}

 

Suc6!

 

[Duwgati]

Da's prima voor het inloggen, maar ik heb het nu even niet over inloggen, maar over de code die in de content verstopt kan worden.

 

Als het een CMS systeem moet worden, dan moet je dus aannemen dat anderen content aan de website kunnen toevoegen. In die content kan natuurlijk ook een script verstopt zijn.

 

Het belangrijkste uitgangspunt bij een goede beveiliging is dat je niet op alleen maar een inlog-procedure vertrouwt. Als iemand een username/password weet te kraken, of stelen of wat dan ook, dan nog moet je alle input controleren/filteren.

Doe je dat niet, dan ga je gegarandeerd een keer voor de bijl.

 

Net zo goed als hier op het forum. Alles wat gepost wordt, moet eerst gefilterd worden, zodat je zeker weet dat alle potentieel gevaarlijke code onschadelijk is gemaakt.

 

[Duwgati]

Even een voorbeeldje om de zaak duidelijk te maken. Stel iemand plaatst een stukje tekst met een plaatje erin. Zo'n plaatje kan heel goed misbruikt worden om er een stuk ongewenste code aan te hangen. Bekijk deze IMG-tag maar eens:

 

<img src="plaatje.jpg" onload="alert('Tadaaaa, javascript uitgevoerd...');" />

 

Als je dus toestaat dat iemand op die manier een plaatje in de tekst zet, wordt iedere keer dat iemand die pagina opent dat stukje JS uitgevoerd. En dan is dit gelukkig een totaal onschadelijk script.

[Big fellow]

Duwgati; Het voorbeeld was alleen maar om te laten zien hoe je gebruk kan maken van typecasting... Ik schreef ook al dat je alle vars moet controleren die terugkomen van een webserver/webbrowser... Met controleren doel ik op strippen van ongewenste html/javascript en elke andere vorm van ongewenste ongein...

 

Er bestaat een functie set in php welke "ubb" tags ondersteund. Als ik een CMS zou schrijven zou ik zeker van die functies gebruik maken. Dan kan je namelijk "lekker makkelijk" alle html uit een var vandaan halen, want de html dient vervangen te worden door ubb tags door de gebruiker. Indien je toch html wilt gebruiken in bijvoorbeeld html code voorbeelden, dan moet je een extra functie scrijven die de "[ code]" tag afvangt en processed met htmlspecialchars.

 

Afhankelijk van hoe uitgebreid je het CMS wilt maken, kan je misschien beter gaan kijken naar open source CMS systemen. Er zijn hele kleine (beperkte) beschikbaar (o.a. tinycms) maar ook zeer uitgebreide (o.a. typo3).

Dus misschien is dat de beste weg om te bewandelen nu, even kijken of je niet bezig bent het wiel opnieuw uit te vinden. Je kan uiteraard beginnen met een CMS ala tinycms en deze uitbreiden etc...

 

(Nogmaals) suc6!

[Hendrik6073]

hartelijk dank voor alle reacties. t mooie van dit soort discussies is dat ik me nu beter beeld kan vormen van o.a. de risico's. Het cms waar ik mee bezig ben is heel klein en zeer beperkt, alle bestaande zouden (waarschijnlijk) al overkill zijn, maar ik ga daar zeker eens naar kijken. Ik ga er mee aan de slag. Nogmaals dank