Scholieren.com forum

Scholieren.com forum (https://forum.scholieren.com/index.php)
-   Software & Hardware (https://forum.scholieren.com/forumdisplay.php?f=20)
-   -   [PHP] Optimale beveiliging (https://forum.scholieren.com/showthread.php?t=755837)

Martin 22-02-2004 17:43

[PHP] Optimale beveiliging
 
Iedereen streeft naar een optimale beveliging van zijn of haar PHP-scripts (tenminste, dat mag ik toch hopen). Maar hoe realiseer je een zo veilig mogelijk script? Ja, je kan bovenin het PHP-bestand een exit; plaatsen, dan is hij inderdaad veilig, maar niet echt gebruiksvriendelijk.

Nu komt mijn vraag:

Waarop moet ik allemaal extra letten bij de beveiliging van mijn pagina's? SQL-query's moet je natuurlijk beveiligen met de mysql_real_escape_string()-functie, maar aan wat voor dingen moet ik nog meer denken?

Fade of Light 22-02-2004 17:53

variabelen initialiseren.

Martin 22-02-2004 17:54

Citaat:

Fade of Light schreef op 22-02-2004 @ 18:53:
variabelen initialiseren.
?

eddie 22-02-2004 18:04

de #1-rule is toch wel:
Never trust user input

Martin 22-02-2004 18:05

Citaat:

eddie schreef op 22-02-2004 @ 19:04:
de #1-rule is toch wel:
Never trust user input

Duh ;)

Maar hoe kan je dit soort invloeden het beste beveiligen? M.a.w., welke functies zijn het meest geschikt en op welke manier?

Manuzhai 22-02-2004 22:59

htmlentities() is wel goed bruikbaar: je wil geen malafide HTML/JavaScript in ingezonden text/code hebben. Verder zorgen dat als je includes op .inc eindigen ook daadwerkelijk aan PHP gerelateerd zijn zodat de source niet openstaat, en gewoon in het algemeen je user input heel erg goed checken. Er zijn weinig specifieke regels te bedenken omdat het toch erg van je applicatie afhangt.

Screaming Slave 22-02-2004 23:17

Citaat:

Martin schreef op 22-02-2004 @ 18:54:
?
int c = 0;
++c;

ipv

int c;
++c;

in hoeverre dit bij php nodig is, weet fade of light beter dan ik. :p

Enlightenment 23-02-2004 00:47

In PHP hoef je variabelen niet te declareren of te typecasten, maar het initialiseren van variabelen is wel heel netjes, maar niet altijd nuttig. Als Register Globals UITstaat zoals dat braaf hoort, zie ik het nut van variabelen initen niet echt in, de gebruiker heeft er dan geen enkele invloed op. Behalve als je met user input gaat werken natuurlijk, maar dat spreekt voor zich. Als je je houdt aan het escapen van strings in SQL queries, Register Globals uitschakelt en de gouden regel onthoudt (zie eddie) dan ben je in principe een heel eind.

Dat je moet oppassen met exec() spreekt verder voor zich.

Martin 23-02-2004 08:40

Citaat:

Enlightenment schreef op 23-02-2004 @ 01:47:
Dat je moet oppassen met exec() spreekt verder voor zich.
Exec()?

TIGEK 23-02-2004 09:44

http://nl.php.net/exec

Dus het uitvoeren van programma's op de server :)

eXo 23-02-2004 10:32

Wat is de beste (veiligste manier) om een string te escapen (ed) om 'm veillig in een database weg te stoppen?

Martin 23-02-2004 10:38

Citaat:

eXo schreef op 23-02-2004 @ 11:32:
Wat is de beste (veiligste manier) om een string te escapen (ed) om 'm veillig in een database weg te stoppen?
Ik gebruik deze functie:

PHP-code:

function MakeStringSafe($type,$string){
    if(
$type == 1){
        if(
is_numeric($string)){
            return 
$string;
        }
        else{
            echo 
"Illegal string. Script terminated";
            exit;
        }
    }
    elseif(
$type == 'a'){
        
$string mysql_real_escape_string($string);
        return 
$string;

    }



In het bestand doe ik dan:

PHP-code:

MakeStringSafe("a",$_GET['page']); 

Met de eerste VAR geef ik aan wat voor soort var het moet zijn (nummeriek of een letter) en met de 2e var submit ik de string naar de functie.

In de functie kijk ik wat voor soort string het had moeten zijn en die controleer ik vervolgens. Daarna stuur ik de string weer terug.

eXo 23-02-2004 11:05

Wow.. da's wel heel grondig :D

Ik pass alleen strings door naar m'n db, dus in principe kan ik dan volstaan door mysql_real_escape_string($string) te gebruiken?

(wat doet de functie precies (ik snapte de uitleg op php manual niet :bloos: ))

Martin 23-02-2004 11:11

Citaat:

eXo schreef op 23-02-2004 @ 12:05:
Wow.. da's wel heel grondig :D

Ik pass alleen strings door naar m'n db, dus in principe kan ik dan volstaan door mysql_real_escape_string($string) te gebruiken?

(wat doet de functie precies (ik snapte de uitleg op php manual niet :bloos: ))

Die zorgt ervoor dat er geen symbolen in de query kunnen worden gebruikt die de query zouden kunnen beïnvloden.

Scooter B0y 23-02-2004 11:26

het ziet er leuk uit hoe je programmeert maar mijn doel blijft toch om zo snel mogelijk te programmeren, beveiliging komt altijd wel goed :p

Martin 23-02-2004 11:28

Citaat:

Scooter B0y schreef op 23-02-2004 @ 12:26:
het ziet er leuk uit hoe je programmeert maar mijn doel blijft toch om zo snel mogelijk te programmeren, beveiliging komt altijd wel goed :p

Safety first!

eXo 23-02-2004 12:33

Citaat:

Scooter B0y schreef op 23-02-2004 @ 12:26:
het ziet er leuk uit hoe je programmeert maar mijn doel blijft toch om zo snel mogelijk te programmeren, beveiliging komt altijd wel goed :p
domdomdom..

Fade of Light 23-02-2004 13:22

Citaat:

Martin schreef op 22-02-2004 @ 18:54:
?
Citaat:

Enlightenment schreef op 23-02-2004 @ 01:47:
Als Register Globals UITstaat zoals dat braaf hoort, zie ik het nut van variabelen initen niet echt in, de gebruiker heeft er dan geen enkele invloed op. Behalve als je met user input gaat werken natuurlijk, maar dat spreekt voor zich.
there ya go.

En natuurlijk netjes alles bewijzen met GCL! :evil:

Screaming Slave 23-02-2004 23:08

ieuw, hoorde ik daar gcl?

eXo 25-02-2004 00:04

Nee dat las je. Wat is dat GCL?

Fade of Light 25-02-2004 00:26

Citaat:

Screaming Slave schreef op 24-02-2004 @ 00:08:
ieuw, hoorde ik daar gcl?
:evil:


Exo: GCL = guarded command language, een of andere schrale semiprogrammeertaal waarmee je de correctheid van standaardalgoritmen kunt bewijzen. Nadat je dit hebt gelezen, kun je het maar beter weer vergeten :P

Screaming Slave 25-02-2004 10:48

Citaat:

eXo schreef op 25-02-2004 @ 01:04:
Nee dat las je.
ubersaai. :p


Alle tijden zijn GMT +1. Het is nu 22:51.

Powered by vBulletin® Version 3.8.8
Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.