| |
|
| :: |
| Auteur |
Message |
dcz
Administrateur - Site Admin
Inscrit le: 28 Avr 2006
Messages: 13607
|
 Posté le: Dim Jan 27, 2008 9:05 am Sujet du message: Re: PHP_Hack_Trap_1.0-RC1 |
|
|
| Conchise a écrit: |
* if ($ret[ID] != "NOT_FOUND") - corrigé. Mais comment le programme a-t-il pu marcher avant ?
|
Bienvenue dans la sphère php, ou tout peut se mélanger et ou du coup il faut être très vigilant. php est, comme tu dois le savoir, très peu typé, une chaîne peut être évaluée comme un nombre et vice versa. C'est pratique par certains aspect, mais c'est aussi une contrainte quand on veux sécuriser une appli.
Le risque couru dans ce cas est que ID pourrait aussi être une constante, à défaut de constante, php interprète ID comme une chaîne de caractère et ça marche, vu que la clés ID existe. Mais, une déclaration de constante pourrait fausser le code du coup.
| Conchise a écrit: |
Tu veux dire, pour vérifier que la valeur est un entier, ou une chaine ou autre...
|
C'est le corollaire, la souplesse c'est pratique, mais pour la sécurité, il faut imposer les type à chaque fois que c'est nécessaire. En fait, il faut presque agir comme si php n'était pas souple 
Donc, intval() (transorme toute variable en nombre entier, texte et nombre) pour des entiers avant un select sur une ID, c'est pratique, ça vire les virgules éventuelles et ça impose le type entier.
L'idée, c'est que même si ton code ne produit que des entiers, il vaut mieux valider avant interaction avec la DB, parce que en plus de la souplesse sur les type de variables, php en a aussi beaucoup, quoi que de moins en moins depuis php4 et 5, sur la façon d'interagir avec elles.
Avec register global activé (et on comprend que ce ne soit presque jamais le cas depuis php4), toutes les variables étaient susceptibles d'être passées à un script. Sans qu'il soit nécessaire de passer par les tableaux GET et POST.
Genre index.php?$dbname=xx&$dbuser=yy&$dbpasswd=zz
Du coup, on comprend qu'une bonne pratique soit de :
1) toujours initialiser ses variables avant la première utilisation;
2) toujours valider ses variables avant de les envoyer dans la DB.
Même si sur du code propre, c'est souvent inutile, c'est une pratique qui peut sauver dans pas mal de cas.
Pour la classe DB, c'était pour le cas ou ton script serait utilisé au sein d'une autre application, c'est pas ce qu'il fait maintenant, mais ça peut être pas mal pour dénicher d'autre critères de ban.
Pour la rewritemap, j'ai dit ça vite, c'est pas tout à fait du rewritemap l'exemple donné sur les host deny, mais tu vois intérêt d'une telle implémentassions, si on évite de manipuler directement le .htaccess, on y gagne à fond en souplesse.
| Conchise a écrit: |
La meilleure solution reste le robots.txt. Mais, est-on absolument certain que les moteurs principaux (google, yahoo, msn, ...) le respectent ? Quelqu'un voit autre chose ? |
C'est en effet un truc à prendre en compte.
Le robts.txt est un peu à double tranchant, parceque qu'il faudrait interdire tous les dossiers "sensibles", et cela reviens à donner des informations sur ces dossiers publiquement. Sans cela un hacker devrait en plus découvrir leur noms.
Par contre, tu peux ajouter un header 403 Forbidden avec ton message d'avertissement, comme ça les bots ne réessayeront pas et tu pourra bannir tranquille ceux qui insisteraient.
Pour les IP, tu as de bon exemple de RegEx ipv4 et ipv6 dans la fonction get_preg_expression de includes/functions.php de phpbb3.
ni ipv4 ni ipv6 :
| Code: | | !preg_match(get_preg_expression('ipv4'), $ip) && !preg_match(get_preg_expression('ipv6') |
| Conchise a écrit: |
Encore merci dcz pour les corrections. Ca m fait plaisir ! |
Bah, c'est réciproque, c'est un plaisir de t'aider un peu à faire un truc aussi utile
++ |
_________________
Useful links :
SEO Forum || SEO Directory || SEO phpBB || SEO phpBB3 || Search
____________________
Liens Utiles :
Forum référencement || Annuaire référencement || Référencement phpBB || Référencement phpBB3 || Recherche |
|
| Revenir en haut de page |
|
 |
|
|
Conchise
PR0
Inscrit le: 09 Jan 2008
Messages: 53
|
| Posté le: Lun Fév 04, 2008 3:46 pm Sujet du message: Re: PHP_Hack_Trap_1.0-RC1 |
|
|
Bon, après de nombreux essais, je n'ai pas réussi à mettre en place la rewritemap.
L'ajout de
| Code: | RewriteMap hosts-deny txt:/path/to/hosts.deny
RewriteCond ${hosts-deny:%{REMOTE_HOST}|NOT-FOUND} !=NOT-FOUND [OR]
RewriteCond ${hosts-deny:%{REMOTE_ADDR}|NOT-FOUND} !=NOT-FOUND
RewriteRule ^/.* - [F] |
[/code]
ou de
| Code: |
RewriteMap hosts-deny txt:/path/to/hosts.deny
RewriteRule ^/(.*)$ ${hosts-deny:%{REMOTE_HOST}|NOT-FOUND}/$1
RewriteRule !^NOT-FOUND/.* - [F]
RewriteRule ^NOT-FOUND/(.*)$ ${hosts-deny:%{REMOTE_ADDR}|NOT-FOUND}/$1
RewriteRule !^NOT-FOUND/.* - [F]
RewriteRule ^NOT-FOUND/(.*)$ /$1 |
Avec le bon chemin absolu ou relatif vers le fichier hosts.deny donne une erreur 500. Et je ne sais pas pourquoi. Est-il possible que mon hébergeur (OVH 90 plan mutualisé) interdise l'utilisation de "RewriteMap hosts-deny" ? |
|
|
| Revenir en haut de page |
|
|
dcz
Administrateur - Site Admin
Inscrit le: 28 Avr 2006
Messages: 13607
|
|
| Revenir en haut de page |
|
|
|
|
|
|
