séquelles de sécurisation de serveur

Répondre


Cette question est un moyen d’empêcher des soumissions automatisées de formulaires par des robots.
Smileys
:D :) :( :o :shock: :? 8-) :lol: :x :P :oops: :cry: :evil: :twisted: :roll: :wink: :!: :?: :idea: :arrow: :| :mrgreen: =D> #-o =P~ :^o :non: :priere: 8-|
Voir plus de smileys
  Revue du sujet
 

  Étendre la vue Revue du sujet : séquelles de sécurisation de serveur

par naholyr » 12 juil. 2005, 10:10

Tu peux m'envoyer le php.ini à [email protected] ?
Ce sont surtout les directives safe_* qui m'intéressent.
Pour le session_path, je ne pense pas qu'il y ait d'erreur sinon session_start() échouerait.

PhP info...

par Le retraité » 12 juil. 2005, 10:06

J'avais déjà essayé de le faire, mais je ne suis pas assez calé pour l'analyser...
Je te mets ci-dessous ce qui concerne les sessions:

Code : Tout sélectionner

Directive Local Value Master Value session.auto_start Off Off session.bug_compat_42 Off Off session.bug_compat_warn On On session.cache_expire 180 180 session.cache_limiter nocache nocache session.cookie_domain no value no value session.cookie_lifetime 0 0 session.cookie_path / / session.cookie_secure Off Off session.entropy_file no value no value session.entropy_length 0 0 session.gc_divisor 1000 1000 session.gc_maxlifetime 1440 1440 session.gc_probability 1 1 session.name PHPSESSID PHPSESSID session.referer_check no value no value session.save_handler files files session.save_path /var/lib/php/session /var/lib/php/session session.serialize_handler php php session.use_cookies On On session.use_only_cookies Off Off session.use_trans_sid Off Off
Je tente de t'envoyer en fichier attaché de message perso la totalité avec le résultat de print_r($GLOBALS);

J'ai lancé la même demande d'info sur mon prestataire de service:
tout parait identique sauf la fin du tableau après

Code : Tout sélectionner

session.gc_probability 1 1
qui est:

Code : Tout sélectionner

session.hash_bits_per_character 4 4 session.hash_function 0 0 session.name PHPSESSID PHPSESSID session.referer_check no value no value session.save_handler files files session.save_path /sessions /sessions session.serialize_handler php php session.use_cookies On On session.use_only_cookies Off Off session.use_trans_sid 0 0
voilà toutes les données du pb....

Le webmaster se serait peut-être planté dans le path des sauvegarde de session ? C'est-y possible ?

par naholyr » 12 juil. 2005, 09:11

J'avoue que je cale... J'ai regardé hier quelle pouvait être l'incidence de safe_mode sur les sessions, mais rien...

Pourrais-tu faire un
phpinfo();
et éventuellement un
print_r($GLOBALS);
pour sortir vraiment toutes les infos possibles ?

Bon, c'est bien difficile...

par Le retraité » 11 juil. 2005, 18:09

En relisant vos messages, j'ai eu l'idée de tester 2 pages "hyper simples":
page A:

Code : Tout sélectionner

<? session_start(); $_SESSION["nom_secteur"]= "toto"; header("location:page_B.php"); ?>
page B:

Code : Tout sélectionner

<? session_start(); echo "secteur= ".$_SESSION['nom_secteur']; ?>
résultat:
sur mon ordinateur, la page B affiche bien nom_secteur=toto
sur le serveur de mon prestataire de service également
sur le serveur "sécurisé" en..
- activant le mode "safe_mode"
- activant la variable magic_quotes_gpc
- mettant la variable register_globals à OFF
la variable est vide....

Mais que se passe-t-il donc sur cette machine "sécurisée"????

Aïe...

par Le retraité » 11 juil. 2005, 17:39

j'obtiens:

Code : Tout sélectionner

array(0) { }
comme retour mais comme vérification, au même endroit:

Code : Tout sélectionner

echo "n° de session : ".session_id()."<br>"; echo "secteur : ".$_SESSION['nom_secteur'];
Donne évidemment la variable vide, mais le N° de session est bien valide par rapport à celui testé en page A....

par naholyr » 11 juil. 2005, 16:59

Gni :s
Ce qui exclut donc un problème dans A.
Comme l'id de session transite bien, ce n'est pas un problème de SID.
J'ai peut-être une idée, mais je veux d'abord vérifier la page B.

Tu vas faire la même opération de débuggage sur $_SESSION dans la page B, une fois juste après session_start(), et l'autre fois juste avant la première utilisation de $_SESSION["nom_secteur"]

Les idées que j'ai - en vrac - sont les suivantes :
- un test d'égalité foireux (un == qui devient = par exemple).
- une variable globale qui parasite (mais c'est impossible si register_globals est à Off).
- et sûrement d'autres pistes une fois que j'aurai les résultats de débug ^^

pareil...

par Le retraité » 11 juil. 2005, 16:49

voilà, c'est fait...
le retour est:

Code : Tout sélectionner

array(2) { ["nom_secteur"]=> string(13) "D_Vernon Pacy" ["nom_prof"]=> string(11) "resp_groupe" }
ça contient bien les 2 variables que je veux conserver...

par naholyr » 11 juil. 2005, 16:39

Ben... Pareil avec $_SESSION au lieu de $_POST ? :D

c'est fait...

par Le retraité » 11 juil. 2005, 16:16

j'ai copié ton code à l'endroit voulu et j'obtiens:

Code : Tout sélectionner

array(5) { ["nom_prof"]=> string(11) "resp_groupe" ["m_pass"]=> string(6) "groupe" ["nom_secteur"]=> string(13) "D_Vernon Pacy" ["affiche"]=> string(0) "" ["Submit"]=> string(7) "Valider" }
Celle qui m'interesse le plus, ["nom_secteur"], contient bien la valeur voulue... à cet endroit (juste avant le "header...)

par naholyr » 11 juil. 2005, 16:06

Tu as effectivement très bien fait de vérifier les numéros de session, ça fait une base sûre à partir de laquelle travailler ;)

D'abord vérifier le contenu de $_POST. Dans A, avant l'appel à header(), un simple
var_dump($_POST);
exit(1);
Stoppera le script avant la redirection, et permettra de voir le contenu précis des variables de formulaires.

réponse à Naholyr

par Le retraité » 11 juil. 2005, 15:54

C'est bien ça...!
et session_start() est bien lancé (et reconnu puisque j'arrive à faire afficher le N° de la session dans la page B (que je te disais avoir comparé à celui de la session ouverte dans la page A...)
Merci pour ta matière grise...!

par naholyr » 11 juil. 2005, 15:46

Que je sois bien sûr de comprendre.
Dans une page A, on définit une variable de session avec $_SESSION["nom_secteur"]= $_POST["nom_secteur"], puis on fait une redirection vers la page B avec header("Location: B").
Dans la page B, on utilise la variable $_SESSION["nom_secteur"], qui est vide ?

Si c'est bien ça, il faut déjà vérifier que session_start() est bien au début des pages A et B.
Sinon il faut vérifier le contenu des différentes variables en cause le long du processus.

réponses à vous 2, gentils "tuteurs"

par Le retraité » 11 juil. 2005, 14:37

en ce qui concerne les variables $_GET et $_POST,
C'est "oui", évidemment, puisque c'est la consigne qui m'avait été donnée au départ par l'éléphant...(merci à lui)8)
Pour ce qui de se qui se passe aux endroits où j'utilise header:
La variable est "perdue".
Dans la page concernée , j'ai testé la session par "session_id()", le numéro de session est bien le même que la session ouverte au moment de l'alimentation des variables par $_SESSION["nom_secteur"]= $_POST["nom_secteur"];...
Je n'y comprends rien....

:?: :cry:

Re: encore un petit pb...

par naholyr » 11 juil. 2005, 11:18

sauf aux endroits où j'ai utilisé des redirections avec "header"....
Comment vaincre ce dernier écueil ???
Il se passe quoi à ces endroits ?

par zeus » 11 juil. 2005, 10:18

Quand tu passes les variables par l'url, il faut récupérer avec $_GET et non plus $_POST

Tu y a pensé ?