NB1 : xpost fr.comp.lang.php et fu2 fr.comp.securite (les deux sont
modérés).
Après moult tergiversations, je laisse le fu2 sur fr.comp.securite car
on dépasse le cadre du langage PHP et que les failles à débattre sont
majoritairement
humaines et non liées au langage. J'encourage plus que vivement les
habituels lecteurs/contributeurs de fclphp à suivre la discussion sur
fcs (et à le
consulter régulièrement une fois cette bonne habitude prise ;-)...)
Je me porte volontaire pour essayer de faire une synthèse de la
discussion qu'on pourra intégrer dans l'une des deux FAQs et référencer
depuis l'autre.
NB 2 : Cet article étant long et fcs étant modéré, je rappelle aux
contributeurs qui seraient tentés de le citer intégralement que leur
réponse n'a aucune chance d'être publiée. Si vous avez un doute sur la
bonne manière de répondre sur un forum usenet, usez et abusez de
http://www.giromini.org/usenet-fr/repondre.html
Suite aux divers questions/trolls sur la sécurité des applications
écrites en PHP dans une optique web, je lance un petit débat sur les
pratiques de codage en PHP apportant ou non un vrai "plus" de sécurité.
J'entends par "faille de sécurité" une erreur de codage ou de conception
qui permet de passer outre une procédure d'authentification, d'avoir
accès à des données non publiques, ou de modifier/détruire des
données/des scripts, exclusivement dans une optique web, avec php comme
langage dans mon esrit à l'origine, mais on pourra élargir à d'autres
langages/plateformes de web dynamique comme perl, jsp, asp, .net etc...
Les questions sont les suivantes :
Question 1 :
Quelles sont les principales failles existantes dans les scripts PHP que
vous avez rencontrées ? Quels risques induisaient-elles ? Comment les
avez vous corrigées ?
Question 2 :
Quelles sont les principales fausses vérifications de sécurité que vous
connaissez ? Comment peut-on les contourner (indiquer la difficulté
pour y arriver) ou pourquoi ne sont-elles pas fiables ou non applicables
sur le principe même ?
Question 3 :
Pensez vous à des failles théoriques potentielles que vous n'avez pas
encore vérifiées en pratique ?
------------
Je commence bien entendu :
Question 1 (failles existantes):
a) variables non itilialisées en register_globals=On (injection de
variables)
Risque : principalement accès non autorisés, mais tout est possible.
Correction : initialiser ses variables (Sans blague...), ou utiliser des
fonctions/des objets car ils snt insensibles à l'injection de variables.
Piège : croire qu'on est toujours en register_globals=Off et coder comme
un cochon.
Correction : idem.
b) include dynamiques (ex include($toto);)
Risque : exécution sur sa machine de n'importe quel code souhaité par
l'attaquant (installation de back-doors, défigurations, etc....
Correction : ne pas utiliser d'includes dynamiques ou vérifier que le
fichier est bien local si hébergement dédié. Renforcer les restrictions
d'include_path. Attention, depuis php5, file_exists peut éventuellement
renvoyer TRUE sur des fichiers distants (à restester, je n'ai pas poussé
plus loin que le "tip php5" du manuel).
Piège : essayer de se renforcer avec include($toto.'.php');
Contournement : $toto="[target]/script_sans_extension"; par exemple.
c) injection SQL.
Risque : accès non autorisés, corruption de données
Correction : filtrage des variables, échappement de ' et " par le
caractère ad hoc pour la base de données (\ pour mysql, ' pour sybase
etc...)
d) confiance dans les variables venant de l'extérieur. Par exemple,
recalculer une facture à payer en utilisant un prix transmis par un
champ HIDDEN ou calculé en javascript. Ne pas revalider la donnée parce
qu'elle l'a été en JavaScript.
Risque : multiples. Accès non autorisés, corruption de données, etc...
Correction : ne faire confiance qu'à des données conservées côté serveur
(refaire une requête sgbd pour obtenir le prix de l'article, les frais
de port, etc...). Faire avant tout les validations de cohérence des
données côté serveur et non en javascript.
e) uploads de fichiers.
Outre les failles du langage php lui même qui apparaissent parfois à ce
sujet, les tutoriels que j'ai vus n'insistent pas assez sur le besoin de
faire attention aux extensions autorisées par rapport aux extensions
parsées sur le serveur. Si le serveur considère comme du code php le
fichier toto.php.txt, il faut interdire tout nom de fichier contenant
.php. dans son nom. Ceci doit venir en complément d'une liste
restrictive d'extensions explicitement autorisées (.jpg, .gif, .doc
etc...). Je suis plus particulièrement intéressé sur ce point par les
vérification purement serveur permettant de vérifier le type de fichier
traité.
f) utilisation de header("Location:...)
Algo (erronné)
1. vérification de cohérence
2.1 si problème alors header("Location:bad.php"); // jusqu'ici tout va
bien
2.2 si ok alors header("Location:ok.php"); // et plouf dommage, il
suffit d'appeler directement ok.php avec n'importe quels arguments et
tout passe.
Correction :
2.1 si problème require('erreur.php'); exit();
2.2 (sinon) require('traitement.php'); // rappel : toute variable locale
est alors définie dans traitement.php
g) appels systèmes non filtrés
Dans le même genre que les includes dynamiques, passer directement la
saisie de l'utilisateur à exec() ou system(). Personnellement, j'ai
tendance à interdire tout exécution de code directe, filtrée ou par (je
remplace les actions possibles par des cases à cocher et j'exécute ce
qu'il faut). Peut-être est-ce par trop parano et que 'lon peut autoriser
certaines choses.
Risques : donner la main sur votre machine à un attaquant.
Correction : ne jamais passer quoi que ce soit qui vient de l'extérieur
en argument, mais c'est parfois trop restrictif.
Question 2 (fausses vérifications):
a) vérifier que la donnée a bien été transmise par la méthode POST sous
prétexte qu'elle vient d'un formulaire.
Contournement : il suffit d'envoyer une donnée vérolée par post, que ce
soit en modifiant du html ou en utilisant la librairie CURL par exemple
pour de l'attaque massive. C'est le contenu de la donnée qu'il faut
vérifier, pas son mode de transmission.
b) Vérifier que les données viennent bien "de mon site" en utilisant
HTTP_REFERRER.
Une idée (qui n'est pas de moi) et que je n'ai pas réussi à mettre en
oeuvre : injection SQL par des entiers ou plus généralement injection
SQL insensible aux habituelles vérifications sur les quotes.
Soit la requête : "UPDATE .... WHERE id=$i " avec id de type entier
(typiquement : autoincrement)
But de la manip : injecter dans $i une chaîne transformant la requête en
(par exemple):
"UPDATE ... WHERE id=0 OR 1=1"
(requête qui va corrompre les données en impactant tous les rangs de la
table)
Moyen sous mysql : utiliser la fonction mysql CHAR et complèter la
chaîne en hexa. Mais je n'ai pas réussi à le faire, je me prends ou du
syntax error ou une chaîne non interprêtée.
Espérant faire avancer le shimili... le shcibi... le biniou.
A mon bureau on passe par plusieurs proxy, et mon adresse IP vue par le serveur eut varier d'une page à l'autre.
Mauvaise configuration du parc de proxys.
-- ;-)
Dominique Blas
Bonsoir,
Pour faire avancer l e schmilblick et cela ne concerne pas que PHP mais tous les langages adossés à un service web : Java, pyhton, perl, C#. Je n'évoque pas ici les failles incombant aux logiciels implantant les services (serveur Web, serveur applicatif, SGBD) ou aux machines hébergeant lesdits services qu'il s'agissent de failles intrisèques ou extrinsèques (mauvaise configuration). Il ne s'agit ici que de quelques conseils généraux de développement afin d'éviter le pire pour un offreur de services.
1. les entrèes doivent être systématiquement traitées afin d'éliminer les caractères n'ayant rien à y faire ( '&', '$', ';', ',', '!', ':', '', etc) selon la nature de la zone de saisie ( alpha, alphanum, num, flottant, etc) ; ceci concerne également le contenu du POST (ou du GET) : les champs doivent être traités avant usage dans une fonction ou une méthode.
2. sauf cas de force majeure interdire l'accès direct aux pages (le module mod_rewrite d'Apache est utile pour cela) : seul l'état de l'utilisateur doit donné accès à telle ou telle page (le modèle MVC2 est très utile pour cela) : on accède systématiquement via http://www.toto.com quelle que soit la vue réellement affichée derrière. Ainsi que l'on tente www.toto.com/tartampion.html ou www.toto.com?TEST=toto&SQLREQUEST=SELECT+ ... cela n'a aucune influence étant donné que seul l'état de l'utilisateur (conservé dans un objet Session) indique quelle est la vue réellement utilisée ;
3. A l'arrière j'ajoute que les erreurs doivent être traitées correctement (le modèle des exceptions est utile pour cela) afin d'éviter d'exposer le modèle sous-jacent et donc de fournir des indications pertinentes à d'éventuels prétendants au SQL injection.
Bien entendu, un modèle objet bien fait est très utile à l'implantation de ces quelques règles en permettant le découpage des différentes étapes.
En résumé je constate qu'il reste un sacré effort à réaliser au niveau des développeurs afin qu'ils incluent dès le départ une pensée réellement orientée sécurité. Et cela ne concerne pas forcément les petits sites loin s'en faut ! De nombreux petits sites sont développés par des individuels et/ou des petites sociétés, c'est-à-dire une main d'oeuvre qui est consciente des règles du jeu.
De nombreux gros sites développés par de grosses SSII (c'est le souci justement : elles ne se remettrent pas souvent en question) sont sujets à l'injection SQL (non traitement des entrèes et des GET/POST) ou aux accès indélicats (accès direct aux vues).
db
Bonsoir,
Pour faire avancer l
e schmilblick et cela ne concerne pas que PHP mais tous les langages adossés
à un service web : Java, pyhton, perl, C#.
Je n'évoque pas ici les failles incombant aux logiciels implantant les
services (serveur Web, serveur applicatif, SGBD) ou aux machines hébergeant
lesdits services qu'il s'agissent de failles intrisèques ou extrinsèques
(mauvaise configuration). Il ne s'agit ici que de quelques conseils
généraux de développement afin d'éviter le pire pour un offreur de
services.
1. les entrèes doivent être systématiquement traitées afin d'éliminer
les caractères n'ayant rien à y faire ( '&', '$', ';', ',', '!', ':', '',
etc) selon la nature de la zone de saisie ( alpha, alphanum, num, flottant,
etc) ; ceci concerne également le contenu du POST (ou du GET) : les champs
doivent être traités avant usage dans une fonction ou une méthode.
2. sauf cas de force majeure interdire
l'accès direct aux pages (le module mod_rewrite d'Apache est utile pour
cela) :
seul l'état de l'utilisateur doit donné accès à telle ou telle page
(le modèle MVC2 est très utile pour cela) : on accède systématiquement
via http://www.toto.com quelle que soit la vue réellement affichée
derrière. Ainsi que l'on tente www.toto.com/tartampion.html ou
www.toto.com?TEST=toto&SQLREQUEST=SELECT+ ... cela n'a aucune influence
étant donné que seul l'état de l'utilisateur (conservé dans un objet
Session) indique quelle est la vue réellement utilisée ;
3. A l'arrière j'ajoute que les erreurs doivent être traitées correctement
(le modèle des exceptions est utile pour cela) afin d'éviter d'exposer
le modèle sous-jacent et donc de fournir des indications pertinentes à
d'éventuels prétendants au SQL injection.
Bien entendu, un modèle objet bien fait est très utile à l'implantation de
ces quelques règles en permettant le découpage des différentes étapes.
En résumé je constate qu'il reste un sacré effort à réaliser au niveau
des développeurs afin qu'ils incluent dès le départ une pensée réellement
orientée sécurité.
Et cela ne concerne pas forcément les petits sites loin s'en faut !
De nombreux petits sites sont développés par des individuels et/ou des
petites sociétés, c'est-à-dire une main d'oeuvre qui est consciente des
règles du jeu.
De nombreux gros sites développés par de grosses SSII (c'est le souci
justement : elles ne se remettrent pas souvent en question) sont
sujets à l'injection SQL (non traitement des entrèes et des GET/POST)
ou aux accès indélicats (accès direct aux vues).
Pour faire avancer l e schmilblick et cela ne concerne pas que PHP mais tous les langages adossés à un service web : Java, pyhton, perl, C#. Je n'évoque pas ici les failles incombant aux logiciels implantant les services (serveur Web, serveur applicatif, SGBD) ou aux machines hébergeant lesdits services qu'il s'agissent de failles intrisèques ou extrinsèques (mauvaise configuration). Il ne s'agit ici que de quelques conseils généraux de développement afin d'éviter le pire pour un offreur de services.
1. les entrèes doivent être systématiquement traitées afin d'éliminer les caractères n'ayant rien à y faire ( '&', '$', ';', ',', '!', ':', '', etc) selon la nature de la zone de saisie ( alpha, alphanum, num, flottant, etc) ; ceci concerne également le contenu du POST (ou du GET) : les champs doivent être traités avant usage dans une fonction ou une méthode.
2. sauf cas de force majeure interdire l'accès direct aux pages (le module mod_rewrite d'Apache est utile pour cela) : seul l'état de l'utilisateur doit donné accès à telle ou telle page (le modèle MVC2 est très utile pour cela) : on accède systématiquement via http://www.toto.com quelle que soit la vue réellement affichée derrière. Ainsi que l'on tente www.toto.com/tartampion.html ou www.toto.com?TEST=toto&SQLREQUEST=SELECT+ ... cela n'a aucune influence étant donné que seul l'état de l'utilisateur (conservé dans un objet Session) indique quelle est la vue réellement utilisée ;
3. A l'arrière j'ajoute que les erreurs doivent être traitées correctement (le modèle des exceptions est utile pour cela) afin d'éviter d'exposer le modèle sous-jacent et donc de fournir des indications pertinentes à d'éventuels prétendants au SQL injection.
Bien entendu, un modèle objet bien fait est très utile à l'implantation de ces quelques règles en permettant le découpage des différentes étapes.
En résumé je constate qu'il reste un sacré effort à réaliser au niveau des développeurs afin qu'ils incluent dès le départ une pensée réellement orientée sécurité. Et cela ne concerne pas forcément les petits sites loin s'en faut ! De nombreux petits sites sont développés par des individuels et/ou des petites sociétés, c'est-à-dire une main d'oeuvre qui est consciente des règles du jeu.
De nombreux gros sites développés par de grosses SSII (c'est le souci justement : elles ne se remettrent pas souvent en question) sont sujets à l'injection SQL (non traitement des entrèes et des GET/POST) ou aux accès indélicats (accès direct aux vues).
db
Fabien LE LEZ
On 28 Nov 2004 17:48:30 GMT, Dominique Blas :
De nombreux gros sites développés par de grosses SSII
...qui emploient manifestement de nombreux stagiaires. Quand je vois l'ergonomie désastreuse de la majorité des gros sites, je ne m'étonne guère des trous de sécurité...
-- ;-)
On 28 Nov 2004 17:48:30 GMT, Dominique Blas <nospam@spam.int>:
De nombreux gros sites développés par de grosses SSII
...qui emploient manifestement de nombreux stagiaires. Quand je vois
l'ergonomie désastreuse de la majorité des gros sites, je ne m'étonne
guère des trous de sécurité...
De nombreux gros sites développés par de grosses SSII
...qui emploient manifestement de nombreux stagiaires. Quand je vois l'ergonomie désastreuse de la majorité des gros sites, je ne m'étonne guère des trous de sécurité...
-- ;-)
Simon Marechal
Dominique Blas wrote:
l'accès direct aux pages (le module mod_rewrite d'Apache est utile pour cela) :
Un peu overkill :) un simple limit de get et post suffit normalement.
Et cela ne concerne pas forcément les petits sites loin s'en faut ! De nombreux petits sites sont développés par des individuels et/ou des petites sociétés, c'est-à-dire une main d'oeuvre qui est consciente des règles du jeu.
De nombreux gros sites développés par de grosses SSII (c'est le souci justement : elles ne se remettrent pas souvent en question) sont sujets à l'injection SQL (non traitement des entrèes et des GET/POST) ou aux accès indélicats (accès direct aux vues).
Il ne faut pas non plus négliger le fait que quand le site est plus gros, ça complexité augmente de manière non linéaire, ainsi que le nombre d'erreurs pouvant etre exploitées ... Mais il est vrai que les sociétés de service en dev. sont souvent peu sérieuses du coté de la sécurité.
Dominique Blas wrote:
l'accès direct aux pages (le module mod_rewrite d'Apache est utile pour
cela) :
Un peu overkill :) un simple limit de get et post suffit normalement.
Et cela ne concerne pas forcément les petits sites loin s'en faut !
De nombreux petits sites sont développés par des individuels et/ou des
petites sociétés, c'est-à-dire une main d'oeuvre qui est consciente des
règles du jeu.
De nombreux gros sites développés par de grosses SSII (c'est le souci
justement : elles ne se remettrent pas souvent en question) sont
sujets à l'injection SQL (non traitement des entrèes et des GET/POST)
ou aux accès indélicats (accès direct aux vues).
Il ne faut pas non plus négliger le fait que quand le site est plus
gros, ça complexité augmente de manière non linéaire, ainsi que le
nombre d'erreurs pouvant etre exploitées ...
Mais il est vrai que les sociétés de service en dev. sont souvent peu
sérieuses du coté de la sécurité.
l'accès direct aux pages (le module mod_rewrite d'Apache est utile pour cela) :
Un peu overkill :) un simple limit de get et post suffit normalement.
Et cela ne concerne pas forcément les petits sites loin s'en faut ! De nombreux petits sites sont développés par des individuels et/ou des petites sociétés, c'est-à-dire une main d'oeuvre qui est consciente des règles du jeu.
De nombreux gros sites développés par de grosses SSII (c'est le souci justement : elles ne se remettrent pas souvent en question) sont sujets à l'injection SQL (non traitement des entrèes et des GET/POST) ou aux accès indélicats (accès direct aux vues).
Il ne faut pas non plus négliger le fait que quand le site est plus gros, ça complexité augmente de manière non linéaire, ainsi que le nombre d'erreurs pouvant etre exploitées ... Mais il est vrai que les sociétés de service en dev. sont souvent peu sérieuses du coté de la sécurité.
John Gallet
(re) bonjour,
Et merci aux contributeurs du thread. Je vais essayer de faire une synthèse des risques et de leur contre-mesure, pour le moment, j'ai l'impression que se dégagent deux types d'acteurs :
- le développeur - le responsable du déploiement de l'application.
Par exemple, le développeur doit filtrer ses variables en entrée et coder de manière à être indépendant de la configuration de register_globals ou de magic_quotes_gpc. Le responsable du déploiement/de la livraison doit d'assurer qu'il ne traine pas de répertoires sans protections d'accès. Est-ce qu'il vous semble cohérent et pratique de faire un résumé sous la forme "tel acteur doit faire telle et telle chose afin de se prémunir de telle ou telle attaque" ?
a++ JG
(re) bonjour,
Et merci aux contributeurs du thread. Je vais essayer de faire une
synthèse des risques et de leur contre-mesure, pour le moment, j'ai
l'impression que se dégagent deux types d'acteurs :
- le développeur
- le responsable du déploiement de l'application.
Par exemple, le développeur doit filtrer ses variables en entrée et
coder de manière à être indépendant de la configuration de
register_globals ou de magic_quotes_gpc. Le responsable du
déploiement/de la livraison doit d'assurer qu'il ne traine pas de
répertoires sans protections d'accès. Est-ce qu'il vous semble cohérent
et pratique de faire un résumé sous la forme "tel acteur doit faire
telle et telle chose afin de se prémunir de telle ou telle attaque" ?
Et merci aux contributeurs du thread. Je vais essayer de faire une synthèse des risques et de leur contre-mesure, pour le moment, j'ai l'impression que se dégagent deux types d'acteurs :
- le développeur - le responsable du déploiement de l'application.
Par exemple, le développeur doit filtrer ses variables en entrée et coder de manière à être indépendant de la configuration de register_globals ou de magic_quotes_gpc. Le responsable du déploiement/de la livraison doit d'assurer qu'il ne traine pas de répertoires sans protections d'accès. Est-ce qu'il vous semble cohérent et pratique de faire un résumé sous la forme "tel acteur doit faire telle et telle chose afin de se prémunir de telle ou telle attaque" ?
a++ JG
John Gallet
Bonjour,
1. les entrèes doivent être systématiquement traitées afin d'éliminer les caractères n'ayant rien à y faire ( '&', '$', ';', ',', '!', ':', '', etc) selon la nature de la zone de saisie ( alpha, alphanum, num, flottant, etc) ; ceci concerne également le contenu du POST (ou du GET) : les champs doivent être traités avant usage dans une fonction ou une méthode.
Est-ce suffisant d'interdire explicitement certains caractères ? Pour le moment j'ai plutôt tendance à lister les caractères explicitement autorisés.
via http://www.toto.com quelle que soit la vue réellement affichée derrière. Ainsi que l'on tente www.toto.com/tartampion.html ou www.toto.com?TEST=toto&SQLREQUEST=SELECT+ ... cela n'a aucune influence étant donné que seul l'état de l'utilisateur (conservé dans un objet Session) indique quelle est la vue réellement utilisée ;
Je n'ai pas compris comment mettre ça en oeuvre. Tu stockes dans ta session les différents choix possibles de l'utilisateur par rapport à la dernière page générée ? Tu as une page avec 3 liens http, un FORM pour une recherche et un FORM de saisie de tes coordonnées, comment peux-tu prévoir à l'avance quelle "vue" il va falloir afficher ? Une sorte d'arbre de décision ?
3. A l'arrière j'ajoute que les erreurs doivent être traitées correctement Oui, sans aucun doute.
(le modèle des exceptions est utile pour cela) Mouais, enfin là on rentre dans de l'implémentation et en ce qui me
concerne, je ne cite qu'un seul exemple de gestion des exceptions : le premier vol d'ariane V (boum). Je dirais qu'au contraire, au lieu de laisser le code appelant se démm....er avec l'exception, plus vite on la gère, mieux ça vaut, mais on va arriver vite à la querelle de clochers.
Bien entendu, un modèle objet bien fait est très utile à l'implantation de ces quelques règles en permettant le découpage des différentes étapes.
Bien entendu, on peut parfaitement s'en passer et faire plus simple. Mais là encore, il s'agit de querelles de clocher.
En résumé je constate qu'il reste un sacré effort à réaliser au niveau des développeurs afin qu'ils incluent dès le départ une pensée réellement orientée sécurité. Oh que oui. C'est bien pour ça que je voudrais essayer de faire une
petite synthèse de tout ça.
a++ JG
Bonjour,
1. les entrèes doivent être systématiquement traitées afin d'éliminer
les caractères n'ayant rien à y faire ( '&', '$', ';', ',', '!', ':', '',
etc) selon la nature de la zone de saisie ( alpha, alphanum, num, flottant,
etc) ; ceci concerne également le contenu du POST (ou du GET) : les champs
doivent être traités avant usage dans une fonction ou une méthode.
Est-ce suffisant d'interdire explicitement certains caractères ? Pour le
moment j'ai plutôt tendance à lister les caractères explicitement
autorisés.
via http://www.toto.com quelle que soit la vue réellement affichée
derrière. Ainsi que l'on tente www.toto.com/tartampion.html ou
www.toto.com?TEST=toto&SQLREQUEST=SELECT+ ... cela n'a aucune influence
étant donné que seul l'état de l'utilisateur (conservé dans un objet
Session) indique quelle est la vue réellement utilisée ;
Je n'ai pas compris comment mettre ça en oeuvre. Tu stockes dans ta
session les différents choix possibles de l'utilisateur par rapport à la
dernière page générée ? Tu as une page avec 3 liens http, un FORM pour
une recherche et un FORM de saisie de tes coordonnées, comment peux-tu
prévoir à l'avance quelle "vue" il va falloir afficher ? Une sorte
d'arbre de décision ?
3. A l'arrière j'ajoute que les erreurs doivent être traitées correctement
Oui, sans aucun doute.
(le modèle des exceptions est utile pour cela)
Mouais, enfin là on rentre dans de l'implémentation et en ce qui me
concerne, je ne cite qu'un seul exemple de gestion des exceptions : le
premier vol d'ariane V (boum). Je dirais qu'au contraire, au lieu de
laisser le code appelant se démm....er avec l'exception, plus vite on la
gère, mieux ça vaut, mais on va arriver vite à la querelle de clochers.
Bien entendu, un modèle objet bien fait est très utile à l'implantation de
ces quelques règles en permettant le découpage des différentes étapes.
Bien entendu, on peut parfaitement s'en passer et faire plus simple.
Mais là encore, il s'agit de querelles de clocher.
En résumé je constate qu'il reste un sacré effort à réaliser au niveau
des développeurs afin qu'ils incluent dès le départ une pensée réellement
orientée sécurité.
Oh que oui. C'est bien pour ça que je voudrais essayer de faire une
1. les entrèes doivent être systématiquement traitées afin d'éliminer les caractères n'ayant rien à y faire ( '&', '$', ';', ',', '!', ':', '', etc) selon la nature de la zone de saisie ( alpha, alphanum, num, flottant, etc) ; ceci concerne également le contenu du POST (ou du GET) : les champs doivent être traités avant usage dans une fonction ou une méthode.
Est-ce suffisant d'interdire explicitement certains caractères ? Pour le moment j'ai plutôt tendance à lister les caractères explicitement autorisés.
via http://www.toto.com quelle que soit la vue réellement affichée derrière. Ainsi que l'on tente www.toto.com/tartampion.html ou www.toto.com?TEST=toto&SQLREQUEST=SELECT+ ... cela n'a aucune influence étant donné que seul l'état de l'utilisateur (conservé dans un objet Session) indique quelle est la vue réellement utilisée ;
Je n'ai pas compris comment mettre ça en oeuvre. Tu stockes dans ta session les différents choix possibles de l'utilisateur par rapport à la dernière page générée ? Tu as une page avec 3 liens http, un FORM pour une recherche et un FORM de saisie de tes coordonnées, comment peux-tu prévoir à l'avance quelle "vue" il va falloir afficher ? Une sorte d'arbre de décision ?
3. A l'arrière j'ajoute que les erreurs doivent être traitées correctement Oui, sans aucun doute.
(le modèle des exceptions est utile pour cela) Mouais, enfin là on rentre dans de l'implémentation et en ce qui me
concerne, je ne cite qu'un seul exemple de gestion des exceptions : le premier vol d'ariane V (boum). Je dirais qu'au contraire, au lieu de laisser le code appelant se démm....er avec l'exception, plus vite on la gère, mieux ça vaut, mais on va arriver vite à la querelle de clochers.
Bien entendu, un modèle objet bien fait est très utile à l'implantation de ces quelques règles en permettant le découpage des différentes étapes.
Bien entendu, on peut parfaitement s'en passer et faire plus simple. Mais là encore, il s'agit de querelles de clocher.
En résumé je constate qu'il reste un sacré effort à réaliser au niveau des développeurs afin qu'ils incluent dès le départ une pensée réellement orientée sécurité. Oh que oui. C'est bien pour ça que je voudrais essayer de faire une
petite synthèse de tout ça.
a++ JG
Cedric Blancher
Le Mon, 29 Nov 2004 14:39:47 +0000, John Gallet a écrit :
j'ai l'impression que se dégagent deux types d'acteurs : - le développeur - le responsable du déploiement de l'application.
J'ajouterai l'indispensable responsable réseau qui va être en charge d'assurer la connectivité correcte de l'ensemble et sa protection périphérique au moyen de pare-feu et tutti quanti.
Par exemple, le développeur doit filtrer ses variables en entrée et coder de manière à être indépendant de la configuration de register_globals ou de magic_quotes_gpc. Le responsable du déploiement/de la livraison doit d'assurer qu'il ne traine pas de répertoires sans protections d'accès.
Tout comme le développeur doit mettre en oeuvre un certain nombre (ou un nombre certain) de dispositifs de vérification pour s'affranchir, voire se protéger, de la (mauvaise) configuration de l'application sous-jacente, le responsable de l'applicatif doit mettre en place des dispositifs pour protéger son système d'un site Web vulnérable. C'est particulièrement vrai pour tout ce qui est hébergement, où il devra en outre s'assurer de la bonne séparation des sites entre eux.
Genre des mesures pour éviter qu'un directory traversal sur un site, associé à un sale upload sur un autre puisse conduire à un remote shell (grand classique). Apache et PHP par exemple offrent un certain nombre de moyens techniques pour y parvenir de manière fort honorable.
Est-ce qu'il vous semble cohérent et pratique de faire un résumé sous la forme "tel acteur doit faire telle et telle chose afin de se prémunir de telle ou telle attaque" ?
Complètement.
-- BOFH excuse #84:
Someone is standing on the ethernet cable, causing a kink in the cable
Le Mon, 29 Nov 2004 14:39:47 +0000, John Gallet a écrit :
j'ai l'impression que se dégagent deux types d'acteurs :
- le développeur
- le responsable du déploiement de l'application.
J'ajouterai l'indispensable responsable réseau qui va être en charge
d'assurer la connectivité correcte de l'ensemble et sa protection
périphérique au moyen de pare-feu et tutti quanti.
Par exemple, le développeur doit filtrer ses variables en entrée et
coder de manière à être indépendant de la configuration de
register_globals ou de magic_quotes_gpc. Le responsable du
déploiement/de la livraison doit d'assurer qu'il ne traine pas de
répertoires sans protections d'accès.
Tout comme le développeur doit mettre en oeuvre un certain nombre (ou un
nombre certain) de dispositifs de vérification pour s'affranchir, voire
se protéger, de la (mauvaise) configuration de l'application
sous-jacente, le responsable de l'applicatif doit mettre en place des
dispositifs pour protéger son système d'un site Web vulnérable. C'est
particulièrement vrai pour tout ce qui est hébergement, où il devra en
outre s'assurer de la bonne séparation des sites entre eux.
Genre des mesures pour éviter qu'un directory traversal sur un site,
associé à un sale upload sur un autre puisse conduire à un remote shell
(grand classique). Apache et PHP par exemple offrent un certain nombre de
moyens techniques pour y parvenir de manière fort honorable.
Est-ce qu'il vous semble cohérent et pratique de faire un résumé sous
la forme "tel acteur doit faire telle et telle chose afin de se
prémunir de telle ou telle attaque" ?
Complètement.
--
BOFH excuse #84:
Someone is standing on the ethernet cable, causing a kink in the cable
Le Mon, 29 Nov 2004 14:39:47 +0000, John Gallet a écrit :
j'ai l'impression que se dégagent deux types d'acteurs : - le développeur - le responsable du déploiement de l'application.
J'ajouterai l'indispensable responsable réseau qui va être en charge d'assurer la connectivité correcte de l'ensemble et sa protection périphérique au moyen de pare-feu et tutti quanti.
Par exemple, le développeur doit filtrer ses variables en entrée et coder de manière à être indépendant de la configuration de register_globals ou de magic_quotes_gpc. Le responsable du déploiement/de la livraison doit d'assurer qu'il ne traine pas de répertoires sans protections d'accès.
Tout comme le développeur doit mettre en oeuvre un certain nombre (ou un nombre certain) de dispositifs de vérification pour s'affranchir, voire se protéger, de la (mauvaise) configuration de l'application sous-jacente, le responsable de l'applicatif doit mettre en place des dispositifs pour protéger son système d'un site Web vulnérable. C'est particulièrement vrai pour tout ce qui est hébergement, où il devra en outre s'assurer de la bonne séparation des sites entre eux.
Genre des mesures pour éviter qu'un directory traversal sur un site, associé à un sale upload sur un autre puisse conduire à un remote shell (grand classique). Apache et PHP par exemple offrent un certain nombre de moyens techniques pour y parvenir de manière fort honorable.
Est-ce qu'il vous semble cohérent et pratique de faire un résumé sous la forme "tel acteur doit faire telle et telle chose afin de se prémunir de telle ou telle attaque" ?
Complètement.
-- BOFH excuse #84:
Someone is standing on the ethernet cable, causing a kink in the cable
Patrick Mevzek
1. les entrèes doivent être systématiquement traitées afin d'éliminer les caractères n'ayant rien à y faire ( '&', '$', ';', ',', '!', ':', '', etc) selon la nature de la zone de saisie ( alpha, alphanum, num, flottant, etc) ; ceci concerne également le contenu du POST (ou du GET)
Est-ce suffisant d'interdire explicitement certains caractères ? Pour le moment j'ai plutôt tendance à lister les caractères explicitement autorisés.
C'est bien entendu mieux dans ce sens.
via http://www.toto.com quelle que soit la vue réellement affichée derrière. Ainsi que l'on tente www.toto.com/tartampion.html ou www.toto.com?TEST=toto&SQLREQUEST=SELECT+ ... cela n'a aucune influence étant donné que seul l'état de l'utilisateur (conservé dans un objet Session) indique quelle est la vue réellement utilisée ;
Je n'ai pas compris comment mettre ça en oeuvre. Tu stockes dans ta session les différents choix possibles de l'utilisateur par rapport à la dernière page générée ? Tu as une page avec 3 liens http, un FORM pour une recherche et un FORM de saisie de tes coordonnées, comment peux-tu prévoir à l'avance quelle "vue" il va falloir afficher ? Une sorte d'arbre de décision ?
Je pense que c'est l'idée, mais cela a des conséquences facheuses: un même utilisateur ne peut être connecté deux fois avec la même session (et parfois, par exemple avec des cookies, il ne peut pas se connecter deux fois avec deux sessions différentes) dans deux fenêtres différentes, sans perturbations. Pour ceux qui usent des onglets, c'est très pénalisant, c'est pour ca que personnellement je ne recommande pas trop cette piste.
Cela pose un problème aussi si on souhaite laisser la possibilité aux utilisateurs de mettre en bookmark n'importe quelle page du site.
-- Patrick Mevzek . . . . . . Dot and Co (Paris, France) <http://www.dotandco.net/> <http://www.dotandco.com/> Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
1. les entrèes doivent être systématiquement traitées afin
d'éliminer les caractères n'ayant rien à y faire ( '&', '$',
';', ',', '!', ':', '', etc) selon la nature de la zone de
saisie ( alpha, alphanum, num, flottant,
etc) ; ceci concerne également le contenu du POST (ou du GET)
Est-ce suffisant d'interdire explicitement certains caractères ? Pour le
moment j'ai plutôt tendance à lister les caractères explicitement
autorisés.
C'est bien entendu mieux dans ce sens.
via http://www.toto.com quelle que soit la vue réellement
affichée derrière. Ainsi que l'on tente
www.toto.com/tartampion.html ou
www.toto.com?TEST=toto&SQLREQUEST=SELECT+ ... cela n'a aucune
influence étant donné que seul l'état de l'utilisateur
(conservé dans un objet Session) indique quelle est la vue
réellement utilisée ;
Je n'ai pas compris comment mettre ça en oeuvre. Tu stockes dans ta
session les différents choix possibles de l'utilisateur par rapport à la
dernière page générée ? Tu as une page avec 3 liens http, un FORM pour
une recherche et un FORM de saisie de tes coordonnées, comment peux-tu
prévoir à l'avance quelle "vue" il va falloir afficher ? Une sorte
d'arbre de décision ?
Je pense que c'est l'idée, mais cela a des conséquences facheuses: un
même utilisateur ne peut être connecté deux fois avec la même session (et
parfois, par exemple avec des cookies, il ne peut pas se connecter deux
fois avec deux sessions différentes) dans deux fenêtres différentes, sans
perturbations. Pour ceux qui usent des onglets, c'est très pénalisant,
c'est pour ca que personnellement je ne recommande pas trop cette piste.
Cela pose un problème aussi si on souhaite laisser la possibilité aux
utilisateurs de mettre en bookmark n'importe quelle page du site.
--
Patrick Mevzek . . . . . . Dot and Co (Paris, France)
<http://www.dotandco.net/> <http://www.dotandco.com/>
Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
1. les entrèes doivent être systématiquement traitées afin d'éliminer les caractères n'ayant rien à y faire ( '&', '$', ';', ',', '!', ':', '', etc) selon la nature de la zone de saisie ( alpha, alphanum, num, flottant, etc) ; ceci concerne également le contenu du POST (ou du GET)
Est-ce suffisant d'interdire explicitement certains caractères ? Pour le moment j'ai plutôt tendance à lister les caractères explicitement autorisés.
C'est bien entendu mieux dans ce sens.
via http://www.toto.com quelle que soit la vue réellement affichée derrière. Ainsi que l'on tente www.toto.com/tartampion.html ou www.toto.com?TEST=toto&SQLREQUEST=SELECT+ ... cela n'a aucune influence étant donné que seul l'état de l'utilisateur (conservé dans un objet Session) indique quelle est la vue réellement utilisée ;
Je n'ai pas compris comment mettre ça en oeuvre. Tu stockes dans ta session les différents choix possibles de l'utilisateur par rapport à la dernière page générée ? Tu as une page avec 3 liens http, un FORM pour une recherche et un FORM de saisie de tes coordonnées, comment peux-tu prévoir à l'avance quelle "vue" il va falloir afficher ? Une sorte d'arbre de décision ?
Je pense que c'est l'idée, mais cela a des conséquences facheuses: un même utilisateur ne peut être connecté deux fois avec la même session (et parfois, par exemple avec des cookies, il ne peut pas se connecter deux fois avec deux sessions différentes) dans deux fenêtres différentes, sans perturbations. Pour ceux qui usent des onglets, c'est très pénalisant, c'est pour ca que personnellement je ne recommande pas trop cette piste.
Cela pose un problème aussi si on souhaite laisser la possibilité aux utilisateurs de mettre en bookmark n'importe quelle page du site.
-- Patrick Mevzek . . . . . . Dot and Co (Paris, France) <http://www.dotandco.net/> <http://www.dotandco.com/> Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
Eric Razny
Je pense que c'est l'idée, mais cela a des conséquences facheuses: un même utilisateur ne peut être connecté deux fois avec la même session (et parfois, par exemple avec des cookies, il ne peut pas se connecter deux fois avec deux sessions différentes) dans deux fenêtres différentes, sans perturbations. Pour ceux qui usent des onglets, c'est très pénalisant, c'est pour ca que personnellement je ne recommande pas trop cette piste.
Je confirme, je connaissais quelques sites comme ça c'est chiant au possible. En plus je suis loin d'être sur que c'est positif pour la sécurité. Certe du côté du site un utilisateur est dans un état (au sens automate) bien défini, mais un utilisateur peut croire qu'il est en sécurité après un surf alors qu'en relancant une page bookmarkée on se retrouve connecté ; sur une autre page certes, mais "connecté" (au sens avec certaines actions qui ne doivent pas être possible sans login/passwd au minimum). Même un cookie de session est plus sur :-/ (en plus la gestion du bouzingue doit vite devenir... amusante quand le site évolue.)
Sinon aussi, à propos de sécurité en général : faire simple[1] est souvent gage de maintenance aisée et la sécu du bidule peut être plus facilement assurée.
Cela pose un problème aussi si on souhaite laisser la possibilité aux utilisateurs de mettre en bookmark n'importe quelle page du site.
Yep
Eric
[1] Au sens large. Il s'agit aussi d'employer les outils fait pour, pas de réinventer la roue à chaque fois :)
-- L'invulnérable : Je ne pense pas etre piratable, infectable par un trojen oui! Vu sur fcs un jour de mars 2004.
Je pense que c'est l'idée, mais cela a des conséquences facheuses: un
même utilisateur ne peut être connecté deux fois avec la même session (et
parfois, par exemple avec des cookies, il ne peut pas se connecter deux
fois avec deux sessions différentes) dans deux fenêtres différentes, sans
perturbations. Pour ceux qui usent des onglets, c'est très pénalisant,
c'est pour ca que personnellement je ne recommande pas trop cette piste.
Je confirme, je connaissais quelques sites comme ça c'est chiant au
possible.
En plus je suis loin d'être sur que c'est positif pour la sécurité.
Certe du côté du site un utilisateur est dans un état (au sens automate)
bien défini, mais un utilisateur peut croire qu'il est en sécurité après
un surf alors qu'en relancant une page bookmarkée on se retrouve
connecté ; sur une autre page certes, mais "connecté" (au sens avec
certaines actions qui ne doivent pas être possible sans login/passwd au
minimum). Même un cookie de session est plus sur :-/ (en plus la gestion
du bouzingue doit vite devenir... amusante quand le site évolue.)
Sinon aussi, à propos de sécurité en général : faire simple[1] est
souvent gage de maintenance aisée et la sécu du bidule peut être plus
facilement assurée.
Cela pose un problème aussi si on souhaite laisser la possibilité aux
utilisateurs de mettre en bookmark n'importe quelle page du site.
Yep
Eric
[1] Au sens large. Il s'agit aussi d'employer les outils fait pour, pas
de réinventer la roue à chaque fois :)
--
L'invulnérable :
Je ne pense pas etre piratable, infectable par un trojen oui!
Vu sur fcs un jour de mars 2004.
Je pense que c'est l'idée, mais cela a des conséquences facheuses: un même utilisateur ne peut être connecté deux fois avec la même session (et parfois, par exemple avec des cookies, il ne peut pas se connecter deux fois avec deux sessions différentes) dans deux fenêtres différentes, sans perturbations. Pour ceux qui usent des onglets, c'est très pénalisant, c'est pour ca que personnellement je ne recommande pas trop cette piste.
Je confirme, je connaissais quelques sites comme ça c'est chiant au possible. En plus je suis loin d'être sur que c'est positif pour la sécurité. Certe du côté du site un utilisateur est dans un état (au sens automate) bien défini, mais un utilisateur peut croire qu'il est en sécurité après un surf alors qu'en relancant une page bookmarkée on se retrouve connecté ; sur une autre page certes, mais "connecté" (au sens avec certaines actions qui ne doivent pas être possible sans login/passwd au minimum). Même un cookie de session est plus sur :-/ (en plus la gestion du bouzingue doit vite devenir... amusante quand le site évolue.)
Sinon aussi, à propos de sécurité en général : faire simple[1] est souvent gage de maintenance aisée et la sécu du bidule peut être plus facilement assurée.
Cela pose un problème aussi si on souhaite laisser la possibilité aux utilisateurs de mettre en bookmark n'importe quelle page du site.
Yep
Eric
[1] Au sens large. Il s'agit aussi d'employer les outils fait pour, pas de réinventer la roue à chaque fois :)
-- L'invulnérable : Je ne pense pas etre piratable, infectable par un trojen oui! Vu sur fcs un jour de mars 2004.
Dominique Blas
Fabien LE LEZ wrote:
On 28 Nov 2004 17:48:30 GMT, Dominique Blas :
De nombreux gros sites développés par de grosses SSII
...qui emploient manifestement de nombreux stagiaires. Qu'elles payent une misère alors qu'elles facturent leur prestation au-delà
de tout ce qu'on peut imaginer. Mais c'est là l'apanage des gros qui entretiennent savamment quelques relations politico-magouilleuse avec les clients/prospects. En clair, les petits rament pour gagner un marché avec quelque chose de vraiment bien tandis que les gros n'ont qu'à lever le petit doigt pour réaliser de la merde facturée au prix fort.
Quand je vois l'ergonomie désastreuse de la majorité des gros sites, je ne m'étonne guère des trous de sécurité...
Je pense qu'il va falloir dénoncer ces failles juste à mi-juillet 2005.
db
-- email : usenet blas net
Fabien LE LEZ wrote:
On 28 Nov 2004 17:48:30 GMT, Dominique Blas <nospam@spam.int>:
De nombreux gros sites développés par de grosses SSII
...qui emploient manifestement de nombreux stagiaires.
Qu'elles payent une misère alors qu'elles facturent leur prestation au-delà
de tout ce qu'on peut imaginer.
Mais c'est là l'apanage des gros qui entretiennent savamment quelques
relations politico-magouilleuse avec les clients/prospects.
En clair, les petits rament pour gagner un marché avec quelque chose de
vraiment bien tandis que les gros n'ont qu'à lever le petit doigt pour
réaliser de la merde facturée au prix fort.
Quand je vois
l'ergonomie désastreuse de la majorité des gros sites, je ne m'étonne
guère des trous de sécurité...
Je pense qu'il va falloir dénoncer ces failles juste à mi-juillet 2005.
De nombreux gros sites développés par de grosses SSII
...qui emploient manifestement de nombreux stagiaires. Qu'elles payent une misère alors qu'elles facturent leur prestation au-delà
de tout ce qu'on peut imaginer. Mais c'est là l'apanage des gros qui entretiennent savamment quelques relations politico-magouilleuse avec les clients/prospects. En clair, les petits rament pour gagner un marché avec quelque chose de vraiment bien tandis que les gros n'ont qu'à lever le petit doigt pour réaliser de la merde facturée au prix fort.
Quand je vois l'ergonomie désastreuse de la majorité des gros sites, je ne m'étonne guère des trous de sécurité...
Je pense qu'il va falloir dénoncer ces failles juste à mi-juillet 2005.
