VidaNada
dimanche 5 mars 2006 à 18:18
MS-DOS_1991
dimanche 5 mars 2006 à 19:23
Pour moi, les plus "idiotes" et pourtant tellement faciles à éviter sont les
failles includes et les
injections sql
baycris
dimanche 5 mars 2006 à 21:14
il y a aussi la GET je ne sias plus tres bien a cause de quoi mais j'essaye de rechercher le site où j'avais vu cela.
Cris
MarvinLeRouge
dimanche 5 mars 2006 à 22:57
_AT_baycris : Je pense que tu veux parler, notamment, des failles d'includes (dont parle MS-DOS 1991) utilisant des noms de fichiers passés en paramètres GET (ce qui permet à l'utilisateur de demander des includes d'un peu tout et n'importe quoi).
michel durand
lundi 6 mars 2006 à 07:26
il manque le principal : toutes les données récupérées de l'extérieur (get/post/server)doivent être filtrées contre les injections de code.
VidaNada
lundi 6 mars 2006 à 17:32
Faille include ?
CODE
$variable='../../../../etc/hosts';
include($variable);
??
Injections SQL ?
CODE
function sql($variable)
{
if (get_magic_quotes_gpc()) {
$variable = stripslashes($variable);
}
if (!is_numeric($variable)) {
$variable = "'" . mysql_real_escape_string($variable) . "'";
}
return $variable;
}
Injections de code ?
CODE
Quoi ? Comment ?
Théo B.
lundi 6 mars 2006 à 18:38
CITATION(VidaNada @ lundi 06 mars 2006, 17h32)
Injections de code ?
CODE
Quoi ? Comment ?
Par exemple, en n'utilisant que des quotes qui ne prennent pas en compte le $ comme une variable !
K-Ola
lundi 6 mars 2006 à 20:51
Un trés bon site concernant la sécurité php(une référence en la matiére)
www.phpsecure.info
Pour les failles les plus courantes :
http://www.phpsecure.info/v2/article/php-security.php
Anonymus
lundi 6 mars 2006 à 23:01
Dans le même genre, je citerais les innombrables pages de statistiques automatiques, qui montrent non seulement les pages du site, mais également les pages de l'admin...
baboon
lundi 6 mars 2006 à 23:46
Bonsoir,
Pour moi ce ne serait pas les injections d'headers ou sql (comme le souligne MS-DOS 1991) car ces failles sont largement documentés.
Elles sont plutôt la conséquence du "Copier / Coller" sans comprendre ...car on trouve de plus en plus de script, mais peu sont bien écris et documentés, et encore moins sécurisés...
Un script ou une classes sans documentation, est un travail inachevé, donc une faille potentielle...Le minimum étant d'écrire pour chaque classes, script et/ou fonction les rôles, entrées et sorties, contexte et environnement d'utilisation, plateforme de test.
Sans oublier la todo list ou l'historique des bugs corrigés qui donnent quelques indice sur la qualité du script...
L'utilisation à profusion de scripts divers et variés n'exclu pas qu'il faille comprendre ce que l'on fait;
Parfois il est intéressant de faire relire ou tester son code par une personne tierce... d'ou l'interet qu'il soit documenté....
by by
choupiz
mardi 7 mars 2006 à 15:58