Bien débuter le développement d'une application web niveau sécurité

Suite à une discutions sur les forums d'IPBR-Fr initiée par Darken, et à la critique émise lors de mon précédent billet : je me demande, comment bien partir dans le développement d'application web (Ou mod IPB) du point de vu sécurité ? En effet, la question de la sécurité doit être pensé lors du développement et non après coup.

I. Ne plus utiliser de fonction dévaluées :

php est un langage en perpétuelle évolution. Certaines vieilles fonctions sont toujours supportées dans les dernières versions mais sont fortements dévaluées... Pour des raisons de sécurité et de compatibilité dans les futures versions, éviter de telles fonctions se révèle une bonne chose.
Ainsi, par exemple, on préfèrera $_SESSION['TOTO'] à session_register().

II. register_global = Off :

L'un des point de sécurité les plus important celon moi.
Depuis php 4.2, register_global prend la valeur off et php.net préconise de le laisser comme ça. Malheureusement trop de script ne tourne pas en environnement register_global = off, ce qui fait que les serveurs professionnels tourne sous On. Cela n'est pas grave en soit si vous avez développé votre application en Off car elle sera sécurisée.

Imaginez que vous utilisiez une variable $login pour identifier un visiteur de votre site et que vous n'ayez pas travaillé dans un environnement registerglobal = On. Si $login n'est pas présent dans la session, php ira le chercher dans le cookie puis dans les supers variables POST et GET... Comment savoir d'où est affectée cette variable dans ce cas là ?

La réponse est simple, si vous devez chercher cette variable dans la session, faite $_SESSION['login'], dans un cookie : $_COOKIE['login'] et dans $_POST et $_GET pour les autres supers variables. Ainsi, vous saurez exactement d'où provient la valeur prise par une variable et pourrez la contrôler.

III. Typage de variable :

Le point fort de php est d'être facile à apprendre et entreprendre. De ce fait, il n'y a pas de typage des variables à proprement parler...
De cette facilité, née une faille de sécurité dont l'une des principales conséquences sont les injonctions SQL (Objet d'un prochain billet).
Forcer le typage des variables issues notamment de $_GET et surtout celle qui ne sont pas des chaînes de caractère se révèle donc indispensable.
Ainsi si notre variable $login représente un identifiant entier nous la récupèrerons ainsi :

$login_id = intval(@$_GET['login'])

 

La sécurité dans le domaine du web est devenue un point primordial de tout développement. Au risque de me répéter, cette question doit être abordée lors de l'analyse/conception de votre application.
Quel variables dois je récupérer à partir de super variables ? Comment dois je passer certaines informations de page en page ? Cookies ou sessions ? Sont autant de question non négligeable.

6 réactions

  • De Darken De Darken - 02/05/2005, 01:15 #1

    Intéressant, assez clair et efficace. De plus, pour ceux qu'ils veulent tester si leurs scripts tournent sous register_global à Off est de tester leurs scripts en local sous un serveur à register_global à Off.

    Ceci ne sera pas pleinement persuasif si le script est bien sécuritaire mais va mettre l'heure juste s'il utilise le global à ON ou bien à OFF... (Disons que c'est une technique extremement primitif mais pour un utilisateur lambda, rapidement pratique pour ce dire : hmmm, fonctionne pas !? hmmm, j'installe pas ça en mode production.) et ça, c'est déjà un bon départ. Sinon, il suffit de vérifier le code. :)

    D'ailleurs, vous pouvez vérifier si votre hébergeur est à ON ou à OFF recherchant ceci dans la configuration (via php_info) : «register_globals - On - On» ou bien «register_globals - Off - Off» et ainsi de suite...

  • De LLaumgui De LLaumgui - 02/05/2005, 08:59 #2

    Le problème c'est que même des applications comme phpNuke, ayant pignon sur rues, ne tourne pas en register_global = On... En tout cas c'était le cas la dernière fois que j'ai testé...

  • De Fantome De Fantome - 05/05/2005, 11:44 #3

    Je pense aussi que Register_Global est important mais je rajouterais qu'il faut pense a initialiser une variable si elle doit étre testé.

    exemple de code faux (il me semble)
    <php
    ....
    if($_GET['mid']==1) $admin = 1;
    ...
    if($admin){
    ....
    }
    ?>

    si je me trope pas et que Register_Global est On on peut ettribuer la valeur 1 a $admin simplement dans l'url. Donc il y a une faille de sécurité il faudrais mettre
    <php
    ...
    if($_GET['mid']==1){
    $admin = 1;
    }else{
    $admin = 0;
    }...
    ?>

    Merci de me coriger si je me trompe.

  • De LLaumgui De LLaumgui - 05/05/2005, 11:52 #4

    Oula... Là tu passe admin via hxxp://www:toto.toto.com/index.php?mid=1. Faut plutôt mettre le login et mots de passe (md5) dans le cookie qui génère ton mid dans la session et la tu fais:

    if( $_SESSION['mid'] == 1 ){
    $admin = 1;
    }
    else{
    $admin = 0;
    }

    C'est vrai que si tu mets pas le else, et que t'es sous register_global = On, tu peux alors passer l'admin via l'url hxxp://www:toto.toto.com/index.php?admin=1 ce qui reviendrait en fait à faire le truc stupid :

    $admin = $_GET['admin'];
  • De cedras De cedras - 17/04/2006, 16:03 #5

    C'est vrai que si tu mets pas le else, et que t'es sous register_global = On, tu peux alors passer l'admin via l'url hxxp://www:toto.toto.com/index.php?admin=1 ce qui reviendrait en fait à faire le truc stupid :

    $admin = $_GET['admin'];

    donc si j'ai bien compris ce qui a été dit je vais conclure que c'est cette ligne qu'on utilise pour initialiser une variable à travers l'url. Sinon, comment faire pour initialiser une variable à partir de l'url

  • De LLaumgui De LLaumgui - 17/04/2006, 20:17 #6

    Tu récupère tes variables directement à partir du tableau $_GET. Perso, j'utilise un tableau $kernel->_GET perso que je traite (quote, utf, etc...).

Attribution - Partage dans les Mêmes Conditions 4.0 International