Page 1 sur 2
Stratégie de sécurité
Posté : 16 févr. 2007, 17:53
par lord.anonymous
Bonjour à tous. Je suis en train de coder un petit site qui pourra contenir des données "relativement" sensibles telles que des notes et des bulletins d'élèves.
Je conçois donc dès le début divers moyens de se protéger.
1) Toutes les entrées utilisateur sont analysées à l'aide des expressions régulières afin d'éviter toute intrusion de code malveillant.
2) Il y a divers niveaux d'utilisateurs.
3) Chaque répertoire et sous répertoire est protégé par un index.php qui renvoie directement sur la page d'accueil.
4) Chaque header("location:..."); est suivi d'un die();
5) Le code est protégé de façon à ne s'éxécuter que sur son propre serveur (avec un test de $_SERVER['SERVER_NAME']
6) J'utilise un cryptage maison rudimentaire pour toutes les variables passées en $_GET.
7) En cas de tentative de hack (identifiant qui change, navigation sans être logué, action illégale, exécution sur un autre serveur), le site bloque l'accès à l'IP de l'utilisateur pendant 1/4 d'heure.
8) Les adresses mails n'apparaissent jamais en clair dans le code source, donc un robot ne peut pas les lire et j'évite le spam.
Je pense que c'est largement suffisant, mais comme je ne suis pas professionnel de l'internet et de la conception de sites, je me demande si je n'aurais pas négligé d'autres concepts de sécurité de base?
Posté : 19 févr. 2007, 12:11
par zigz4g
Pour le 1, regarde peut etre du cote de l'extension Filter si tu es en PHP5.2.0 et superieur.
Pour le reste ca me parait tres bien, voir beaucoup trop mais bon les eleves sont peut etre de grand futes qui voudront changer leurs notes

Posté : 19 févr. 2007, 14:49
par pascaltje
pour le 3 : Chaque répertoire et sous répertoire est protégé par un index.php qui renvoie directement sur la page d'accueil.
un fichier .htaccess avec comme contenu : deny from all
=> ça bloque tout en mode web, sauf tes scripts faisant les inclusions.
A+
Pascal
Re: Stratégie de sécurité
Posté : 19 févr. 2007, 18:58
par AB
Je pense que c'est largement suffisant, mais comme je ne suis pas professionnel de l'internet et de la conception de sites, je me demande si je n'aurais pas négligé d'autres concepts de sécurité de base?
Bonjour, tu n'as pas parlé de ce point :
si tu utilises une BDD, tes requêtes sont-elles protégées des injections sql?
Re: Stratégie de sécurité
Posté : 19 févr. 2007, 19:26
par lord.anonymous
Je pense que c'est largement suffisant, mais comme je ne suis pas professionnel de l'internet et de la conception de sites, je me demande si je n'aurais pas négligé d'autres concepts de sécurité de base?
Bonjour, tu n'as pas parlé de ce point :
si tu utilises une BDD, tes requêtes sont-elles protégées des injections sql?
Il y a 2 types de protections:
La première est configurée par le serveur, car j'ai magic_quotes_gpc = On dans le php.ini
La deuxième est une vérification faite par mes soins. Toute entrée est filtrée avec des expressions régulières, et certains caractères peuvent être refusés.
Posté : 19 févr. 2007, 19:27
par lord.anonymous
pour le 3 : Chaque répertoire et sous répertoire est protégé par un index.php qui renvoie directement sur la page d'accueil.
un fichier .htaccess avec comme contenu : deny from all
=> ça bloque tout en mode web, sauf tes scripts faisant les inclusions.
A+
Pascal
J'avais pensé à ça sans approfondir, mais puisque tu soulèves la possibilité... Puis-je renvoyer l'utilisateur sur l'index de mon site avec un .htaccess? Car c'est surtout pour cela que j'avais fait un index dans chaque répertoire et sous répertoire.
Posté : 19 févr. 2007, 19:28
par Arcanis
Ce n'est pas exactement une mesure de sécuritée, mais tu pourrais peut-être créer un fichier log qui contient l'ensemble des requêtes sql et les connections/déconnections (bref, l'ensemble des trucs utiles). Au cas où un pirate aurait réussis à te pirater, tu pourrais ainsi savoir comment (et qui c'est, avec un peu de chance) et donc réussir à sécuriser définitivement ton site.
Posté : 19 févr. 2007, 19:30
par lord.anonymous
Ce n'est pas exactement une mesure de sécuritée, mais tu pourrais peut-être créer un fichier log qui contient l'ensemble des requêtes sql et les connections/déconnections (bref, l'ensemble des trucs utiles). Au cas où un pirate aurait réussis à te pirater, tu pourrais ainsi savoir comment (et qui c'est, avec un peu de chance) et donc réussir à sécuriser définitivement ton site.
C'est également fait, toute action sur le site est enregistrée en bdd. Pour des questions de légalité, je pense garder aussi toute trace de mails échangés au travers du site.
Re: Stratégie de sécurité
Posté : 19 févr. 2007, 20:00
par AB
Bonjour, tu n'as pas parlé de ce point :
si tu utilises une BDD, tes requêtes sont-elles protégées des injections sql?
Il y a 2 types de protections:
La première est configurée par le serveur, car j'ai magic_quotes_gpc = On dans le php.ini
La deuxième est une vérification faite par mes soins. Toute entrée est filtrée avec des expressions régulières, et certains caractères peuvent être refusés.
Si c'est en complément de précaution de base comme l'utilisation de mysql_real_escape_string et de formatage de la requête avec sprintf (exemples 1529 et 1531 sur le lien
http://fr2.php.net/manual/fr/function.m ... string.php ), je ne vois rien à ajouter.
Posté : 17 avr. 2007, 10:28
par Invité
Ce n'est pas exactement une mesure de sécuritée, mais tu pourrais peut-être créer un fichier log qui contient l'ensemble des requêtes sql et les connections/déconnections (bref, l'ensemble des trucs utiles). Au cas où un pirate aurait réussis à te pirater, tu pourrais ainsi savoir comment (et qui c'est, avec un peu de chance) et donc réussir à sécuriser définitivement ton site.
Et comment fais-tu cela ? Autres que les logs du serveur MySQL.
Posté : 08 mai 2007, 13:53
par yuuzhantar
bonjour
moi aussi je suis en train de concevoir un site, et ou il y aura un système de payement par allopass
c'est pourquoi je cherche à mettre un maximum de sécurité
j'aurais quelques petites questions à propos des différents points abordés
1/ Toutes les entrées utilisateur sont analysées à l'aide des expressions régulières afin d'éviter toute intrusion de code malveillant.
qu'est ce que vous appelez "expression régulières" ? est ce que l'on peut introduire un code malveillant avec un formulaire de contact par exemple, et quelles sont les fonctions permettant de l'éviter ?
4) Chaque header("location:..."); est suivi d'un die();
pourquoi faut il mettre un die ? moi dans mes redirections je met après, un exit
5) Le code est protégé de façon à ne s'éxécuter que sur son propre serveur (avec un test de $_SERVER['SERVER_NAME']
mais à quoi celà sert-il ? si quelqu'un récupère le fichier il poura enlever ce bout de code
et pour terminer
si tu utilises une BDD, tes requêtes sont-elles protégées des injections sql?
comment fait on pour se protéger de celà ? je ne sait pas du tout comment celà marche
merci
Posté : 08 mai 2007, 17:01
par Shrell
Hello

1) Les expressions régulières sont des "masques" qui te permettent de tester des chaines de caractère.
Exemple : Je veux récupérer toutes les adresses email contenues dans un document, l'expression régulière (simplifiée) sera de la forme :
[a-z0-9_\.]*@[a-z0-9_\.]*\.[a-z]{2,3}
Forcément, vu comme ca, c'est barbare et ca fait peur. Mais une fois que tu sauras t'en servir, tu ne pourras (presque) plus t'en passer.
Je te conseille de faire des recherches sur les sujets "expressions régulières" et / ou REGEXP, ca te sera utile
4) die() = exit() : c'est la même chose, sauf que die() est dépréciée, il est donc conseillé d'utiliser exit() à la place.
5) Si quelqu'un arrive à récupérer un script PHP sur ton serveur, ne te fais plus aucun souci, ton serveur sera déjà aux mains des vilains pirates et il n'y aura plus grand chose à faire, à part arracher la prise...
L'interet de faire un test sur $_SERVER est de s'assurer que le fichier s'exécute bien là où on veut et qu'il n'a pas été
inclus par un autre fichier, sur lequel tu n'as pas forcément la main, qui est donc potentiellement non sécurisé
6) pour la base de données, l'application de mysql_real_escape_string() sur les entrées utilisateur permet de se prémunir des injections SQL
vala :p
Posté : 08 mai 2007, 17:07
par yuuzhantar
merci bien, je vais étudier tout sa
je suis aussi en train de mettre en place une nouvelle stratégie de sécurité pour mon site
en fait, il n'y a qu'une seule page : /index.php
puis on passe la page que l'on veut en ?page=inscription par exemple
puis sa va chercher dans un bdd l'adresse de la page à inclure à l'intérieur de la présentation de index.php
( les pages se trouvent dans des dossier avec un .htacces ou il y a deny from all )
et aussi la stratégie de sécurité à appliquer ( session ... )
et aussi, j'ai mis un htmlspecialchars("$page", ENT_QUOTES) pour éviter que l'on passe du code malveillant dedans
je viens de penser à aussi couper à par exemple 15 caractères le nom de la page pour éviter de passer un code ( il n'y aura pa la place )
qu'en pensez vous ? si vous avez des idées n'hésitez pas
aussi, j'ai entendu parler des magic-quotes ... des injections d'en tête ...
pourriez vous m'aider la dessus aussi
merci
Posté : 08 mai 2007, 23:39
par naholyr
Interdire par défaut, n'autoriser que ce qui est expressément permis.
Cette règle est particulièrement valable dans le système que tu mets en place (pages de la forme index.php?page=inscription).
Tu pourras faire toutes les vérifications que tu veux, si tu ne prévois pas exhaustivement l'infinité des cas possibles, tu laisses une faille potentielle. Face à l'impossibilité de la tâche, il ne reste qu'une manière correcte de faire : n'autoriser qu'un nombre limité de cas, rejeter tous les autres.
Un code de ce genre est forcément inviolable, puisqu'il n'autorise que le nombre limité de cas prévu :
// Liste des pages autorisées
$pagesOK = array('home', 'inscription', 'identification', ...);
$pageParDefaut = $pagesOK[0];
if (!isset($_GET['page'])) { // page par défaut
$page = $pageParDefaut;
}
else {
$page = $_GET['page']; // pas besoin de faire quoi que ce soit à ce niveau, qu'y gagnerait-on ?
}
// vérification que la page est bien autorisée, sinon page par défaut
if (!in_array($page,$pagesOK)) {
$page = $pageParDefaut;
}
// inclusion de la page
include 'pages/'.$page.'.php';
Dans ce type de système c'est la plus efficace des protections simples. Et toute protection plus compliquée a tendance à être moins efficace.
Posté : 10 mai 2007, 20:53
par yuuzhantar
slt
merci de ta réponse
en effet, c'est ce que j'avais prévu
1/ je ne laisse passer que des caractères "normaux" ( lettres et chiffres )
2/ si pas de page spécifiée, on met la page d'accueil
3/ possibilitées : - page sans connection
- script sans connection ( directement exécuté sans passer par une page ...)
- page avec connection ( session )
- script avec connection
et voila