Bonjour Monsieur
Je suis désolé de ne pas avoir répondu plus tôt, j'étais en vacances
de Noël chez mon père, dans un coin pas trop perdu du pays basque... ;)
Voir mes réponses ci-dessous.
Jean-François Ortolo
Post by John GALLETPost by Jean-Francois OrtoloLe problème étant d'empêcher un intrus extérieur de lancer ce script
avec ce paramètre de branchement vers la fonction, ( donc avec un faux
paramètre, puisque non produit par le script lui-même ),
N'oublions pas, que tout le répertoire où se trouve la partie
administration, est sécurisé par login/password dans les fichiers
.htaccess et .htpasswd
Théoriquement donc, personne ne devrait pouvoir avoir accès à ce
répertoire, directement de l'extérieur.
Cependant, le fait de suivre les appels au *même* script
d'administration par une session avec une variable complexe (
microtime() au moment de l'ouverture de la session, nous garantit même
dans ce cas ( login/password volés ), que le script d'admin ne peut
s'exécuter, que conformément à sa programmation.
Post by John GALLETPost by Jean-Francois Ortolosorte de "suivre" les accès à ce script, par une session ( par user
évidemment, mais il n'y a théoriquement que l'administrateur qui a le
login/password d'accès ). Cette session comporte simplement une variable
de session numérique ou alphabétique complexe. Par exemple: la valeur
de microtime()
Oui mais non.
1) on ne donne pas de ressource, quelle qu'elle soit, à quiconque n'a pas
à accéder à cette page. Rien, nada, bernique.
Quelle ressource ?
Si c'est le résultat de microtime(), elle peut être visible comme
cookie temporaire, si la session se fait par cookie. Evidemment, si le
visiteur n'est pas l'administrateur et a volé le login/password, il
s'aperçoit à la rigueur, qu'il y a une session, et que la variable de
session, ressemble à une valeur de microtime(). Mais que voulez-vous
qu'il en retire ultérieurement ? Il ne peut pas deviner aucune valeur
ultérieure de microtime(), qui a une résolution de une micro-seconde, et
de toute façon, il a déjà volé le login/password, alors...
En fait, je reconnais que la protection par session, ne servirait à
rien, puisque toute la sécurité du script d'admin, tient à sa protection
par login/password.
Post by John GALLETPost by Jean-Francois OrtoloDonc cette variable complexe de session est générée, mise dans la base
de données, et la fonction de branchement est la première, c'est-à-dire
celle du menu d'administration.
Mais de quel droit ?! Pourquoi aurait-on une quelconque velléité
d'exécuter du code sans savoir à qui on a affaire dans la partie ADMIN ?
L'accès au répertoire d'admin, est protégé par login/password.
Post by John GALLETPost by Jean-Francois OrtoloDeuxième possibilité: Si au début du script, après le démarrage de la
session, la variable numérique ou alphabétique complexe existe et figure
dans la base de données, c'est que cet appel à ce script, provient bien
de ce même script,
La requête est légitime. Il est ici normal d'exécuter du code.
Post by Jean-Francois Ortoloet donc il est possible de faire confiance aux
données transmises en POST lors de cet appel,
Non, ça jamais. La requête peut donner lieu à exécution de code parce
qu'elle est légitime (le token d'identification est valide) mais les
données reçues du monde extérieur ne peuvent JAMAIS êter considérées comme
dignes de confiance, ne serait-ce qu'à cause des fautes de frappe : si je
tape 1 0 (espace en trop) dans une zone de quantité parce que, comme
d'hab, j'ai pas encore enlevé les moufles et le café est trop chaud, la
requête SQL va faire une drôle de gueule.
Ce ne sont pas des données reçues de l'extérieur. En effet, le fait
que la variable de session ait authentifié l'accès au script par POST,
indique que cet appel POST, provient du script lui-même.
Donc, il est possible de faire confiance à ces données reçues en
POST, puisqu'elles viennent du script lui-même, et que chaque appels
POST précédents à ce script, aient été authentifiés par la variable de
session.
Côté verrouillage exclusif d'accès, c'est évident qu'au début de
l'ajout d'un nouveau sondage ( c'est un cas particulier ), j'incrémente
le numéro d'indice du sondage. Ce numéro d'indice, servira de paramètre
à la fonction appelant l'interface du sondage, dans le script public
servant à l'affichage du sondage.
Cependant, il me paraît nécéssaire d'authentifier l'appel POST au
deuxième script public, enregistrant les données POST du script public
d'affichage, de la façon que j'ai indiquée, par une variable de session,
qui n'est ni devinable, ni simulable.
Donc, au total: Pas de mécanisme d'authentification par session dans
le script d'administration, mais mécanisme d'authentification par
session, dans les scripts publics.
En effet, le seul script existant dans le répertoire
d'administration, est le script d'administration, et de toute façon,
l'accès à ce répertoire est protégé par un login/password.
Si le monsieur malhonnête et méchant, a mon login/password, il peut
de toute façon, faire ce qu'il veut de ma base de données.
Il me semblerait plus sécuritaire, de logguer les accès à ce
répertoire, pour être informé du vol de login/password, histoire de le
changer.
Si le méchant hacker, qui m'en veut particulièrement, a simplement
modifié ma base de données d'une façon imprévisible, il me serait à
priori dificile de m'en apercevoir, si effectivement il appelé le script
d'admin avec des variables POST trafiquées. Pour parer à cette
éventualité, il faudrait donc quand même, faire une authentification par
session, même dans le script d'admin ( en plus des scripts publics ).
A charge pour moi de faire un programme pour détecter les
incohérences dans ma bdd, suite à ce type d'intrusion ( exécution
normale du script d'admin, mais modification de la bdd. ) Dans le cas de
l'exécution normale, ce type de programme serait beaucoup plus facile à
faire.
Post by John GALLETPost by Jean-Francois OrtoloDans ce cas, le traitement des données transmises en POST est
effectué dans le début du script ( enregistrement dans la base de
données par exemple ), puis éventuellement la variable gérant le
branchement aux fonctions, est modifiée en fonction des données
transmises en POST au script. En effet, ce n'est qu'au moment où on
prend connaissance des choix précédents de l'administrateur, que l'on
saura quelle prochaine fonction appeler.
Euh... L'oeuf ou la poule ? Reprenons. Quand on appelle une
fonction/méthode il faut bien à un moment ou à un autre vérifier qu'on a
toutes nos billes pourle faire, et qu'il ne manque pas de données
obligatoires pour ce faire. Or ceci dépend de chaque traitement. Donc il
faut commencer par récupérer, d'une manière ou d'une autre, peu importe,
l'action à exécuter, et c'est elle la racine de l'arbre d'appel : selon
l'action à exécuter, on vérifie si on a bien toutes les informations
nécessaires pour le traitement (reçues directement, ou stockées ailleurs,
en session au sens large, en base, sur la lune, etc.).
C'est sûr, que je peux faire une vérification de la cohérence des
variables POST reçues, entre elles. Je ne pense pas qu'il y ait besoin
de pousser la sécurité, jusqu'à faire une concordance entre des
variables de session dédiées, et certaines vaiables POST reçues. C'est
de l'ordre du possible, mais le mécanisme de session, pour les deux
scripts publics, me paraît suffisamment sécurisé, pour ne pas avoir à
m'embarasser de proécédés supplémentaires de sécurité, que la cohérence
des variables POST, entre elles.
Pour ce qui est du script d'admin, toute sa sécurité repose sur le
secret du login/password.
Eventuellement, rien ne m'empêche, de supprimer du serveur ce script
d'admin, une fois que l'ensemble de la gestion des sondages, ait été
fait, et de le remettre quand j'en ai besoin. Je sais bien, c'est
foireux... ;)
Par ailleurs, rien ne m'empêche, pour la variable POST de switching
entre les fonctions, d'utiliser des valeurs complexes, difficiles à
deviner, et qui ne seront de toute façon pas vues du visiteur, les
données étant en mode POST.
Post by John GALLETPost by Jean-Francois OrtoloMais si l'on mémorise les adresses IP ayant voté, avec disons un
timestamp, et que l'on efface les adresses IP après un délai, les mêmes
personne vont pouvoir revoter ?
Oui, mais ça ce sera le cas de toutes façons : la majeure partie de la
population ne possède pas des IP fixes... Si je me connecte par wanamou le
matin puis l'après midi, je n'aurai pas la même IP. Et ne parlons pas des
utilisateurs derrière des proxys (le cas le plus connu est AOL) qui
changent d'IP à chaque requête (sur une page qui a 10 images, on peut voir
11 adresses IP différentes...)
Post by Jean-Francois OrtoloJe ne vois pas quel intérêt présente ce dispositif.
Uniquement empêcher quelqu'un de s'exciter sur le bouton refresh. Pas
plus, pas moins. Et encore, marchera pas pour les utilisateurs d'AOL.
Oui.
Dans ce cas, peut-être faudrait-il simplement, en plus de l'adresse
IP obsolète, supprimer la variable de session ( des scripts publics ),
de la base de données, ce qui arrête l'authentification, avec
éventuellement backlistage de l'adresse IP correspondante, sans pour
autant modifier le message par défaut, pour ne pas alerter le visiteur
malhonnête.
Merci beaucoup pour tous vos conseils.
"La connaissance s'accroît quand on la partage." ;)
Bien à vous.
Amicalement.
Jean-François Ortolo
--
Visitez mon site gratuit donnant des Statistiques
et des Historiques Graphiques sur les Courses de Chevaux:
http://www.ortolojf-courses.com