N'étant pas très doué je n'arrive pas à modifié les 3 scripts suivants.
Il fonctionne très bien sous php4 mais rien à faire sous php5.
1) la recherche ne se fait pas
2) l'affichage dans le pop est vide
Merci à celui qui voudras bien me résoudre cet incident.
Amitiés
Début des scripts
INDEX.PHP
<?php /* echo "<?xml version=\"1.0\" encoding=\"iso-8859-1\"?".">"; */?>
<?
//INCLUSION DU FICHIER DE CONNEXION
include("connect.inc");
//CONNEXION A LA BASE
$mysql_id=mysql_connect($server,$user,$pwd);
// Sortir du script en cas de problème de connexion
//au serveur.
if(!$mysql_id){
echo "Problème de connexion à la base : ".mysql_errno().":
".mysql_error()."<br />";
exit;
}
//SELECTION DE LA BASE
mysql_select_db($base,$mysql_id);
//SELECTION DE LA TABLE
$table = 'FP_Complet';
//CONSTRUCTION DE LA CLAUSE 'WHERE'
if ($nom){ // Si un nom est inscrit dans le formulaire
$where=" WHERE nom LIKE '%".$nom. "%'";
if ($prenom){ // Si le prénom est aussi renseigné
$where=" WHERE nom='".$nom."' AND prenom LIKE '%".$prenom. "%'";
}
}
else{ // Les deux champs sont vides
$where="";
}
//CONSTRUCTION DE LA CLAUSE 'LIMIT'
//Nombre d'enregistrements souhaités par page
$nb_par_page=10;
if (!$page){
$ligne_debut=0;
}
else{
$page=$page-1;
$ligne_debut=$page*$nb_par_page;
}
$limit=" LIMIT ".$ligne_debut.", ".$nb_par_page;
//REQUETE SQL
$qry="SELECT * FROM $table".$where." ORDER BY nom " .$limit;
//echo $qry;
//EXECUTION DE LA REQUETE
$result=mysql_query($qry);
if (!$nb_pages) { // Si le nb de pages n'a encore jamais été calculé
if ($nom){
$nb_fiches_max=mysql_num_rows($result);
}
else{
$qry2="SELECT * FROM $table";
//echo $qry2;
$result2=mysql_query($qry2);
$nb_fiches_max=mysql_num_rows($result2);
}
$nb_pages=($nb_fiches_max/$nb_par_page);
$nb_pages=ceil($nb_pages);
}
// MESSAGE AU DESSUS DU TABLEAU
if ($nb_fiches_max > 0){ //S'il y a au moins un résultat
$page=$page+1;
$msg= "page ".$page." sur ".$nb_pages; //On affiche le nombre de
pages sur le total
}
else{
$msg="Désolé, aucun enregistrement trouvé !"; //Sinon, on signale
qu'il n'y a pas de résultats
}
?>
body{
background-color:#ffffff;
font-family: Trebuchet MS,Verdana,Geneva,Arial,Helvetica,sans-serif;
}
table.result{
font-family:Arial,sans-serif;
border-collapse:collapse;
border:1px solid #333333;
margin-top:10px;
width:780px;
text-align: center;
}
td.nom {
padding:5px;
width: 200px;
border:1px solid #333333;
text-align: center;
background-color:#087417;
color:#ffffff;
}
td.prenom {
padding:5px;
width: 250px;
border:1px solid #333333;
text-align: center;
background-color:#087417;
color:#ffffff;
}
td {
border:1px solid #333333;
padding:3px;
text-align: left;
}
span.page{
padding-left: 10px;
}
div.pages{
text-align: center;
padding-top: 5px;
}
</style>
</head>
<div align="center">
<body bgcolor="#E7FFB3"><h1>Les fonctionnaires dans les registres</h1>
Vous trouverez ici les données de fonctionnaires vues dans
les registres.<br>
<strong>Pourquoi cette base?</strong><br>
Le fait que les fonctionnaires soient appelés à se déplacer les rends
difficilement localisables.<br>
<br>
</div><center>
<?
##########################
# Recherche infos pour affichage des infos completes
$r=mysql_query("SELECT id FROM $table ORDER by id DESC LIMIT 1 " );
while($row =mysql_fetch_array($r))
{
echo ("<b><p>Il y a "); ?>
<font color="#006599">
<? echo (" $row[id] "); ?>
</font>
<? echo (" entrées dans la base <br> "); }
//$r=mysql_query("SELECT nom, id FROM $table ORDER by id LIMIT 1 ");
// while($row =mysql_fetch_array($r))
// {
// echo ("Pour "); ?>
<font color="#006599">
<? // echo (" $row[id] "); ?>
</font>
<?// echo (" patronymes dans la base<br></b>"); }
?>
</div>
<!-- FIN FORMULAIRE -->
<br><br>
Interrogez la base par départements<br>
<a href="FP_cartes.php">Lieux des registres</a><br>
<a href="FP_cartes_n.php">Lieux de naissances</a><br>
Lieux de décès à l'étude
<br>
<?php
echo "<br />\n"; //On passe une ligne
include ('../../Pied_page.php'); ?>
</center>
</body>
</html>
<?php /* echo "<?xml version=\"1.0\" encoding=\"iso-8859-1\"?".">"; */?>
<?php
//INCLUSION DU FICHIER DE CONNEXION
include("connect.inc");
//CONNEXION A LA BASE
$mysql_id=mysql_connect($server,$user,$pwd);
// Sortir du script en cas de problème de connexion
//au serveur.
if(!$mysql_id){
echo "Problème de connexion à la base : ".mysql_errno().":
".mysql_error()."<br />";
exit;
}
//SELECTION DE LA BASE
mysql_select_db($base,$mysql_id);
//SELECTION DE LA TABLE
$table = 'FP_Complet'; // Le nom de cette table ne passe pas chez Sivit !
//CONSTRUCTION DE LA CLAUSE 'WHERE'
if ($nom){ // Si un nom est inscrit dans le formulaire
$where=" WHERE Nom LIKE '%". $nom. "%'";
if ($prenom){ // Si le prénom est aussi renseigné
$where=" WHERE nom='". $nom."' AND prenom LIKE '%".$prenom. "%'";
}
}
else{ // Les deux champs sont vides
$where="";
}
//CONSTRUCTION DE LA CLAUSE 'LIMIT'
//Nombre d'enregistrements souhaités par page
$nb_par_page=50;
if (!$page){
$ligne_debut=0;
}
else{
$page=$page-1;
$ligne_debut=$page*$nb_par_page;
}
$limit=" LIMIT ".$ligne_debut.", ".$nb_par_page;
//REQUETE SQL
$qry="SELECT * FROM $table".$where." ORDER BY nom " .$limit;
//echo $qry;
//EXECUTION DE LA REQUETE
$result=mysql_query($qry);
if (!$nb_pages) { // Si le nb de pages n'a encore jamais été calculé
if ($nom){
$nb_fiches_max=mysql_num_rows($result);
}
else{
$qry2="SELECT * FROM $table";
//echo $qry2;
$result2=mysql_query($qry2);
$nb_fiches_max=mysql_num_rows($result2);
}
$nb_pages=($nb_fiches_max/$nb_par_page);
$nb_pages=ceil($nb_pages);
}
// MESSAGE AU DESSUS DU TABLEAU
if ($nb_fiches_max > 0){ //S'il y a au moins un résultat
$page=$page+1;
$msg= "page ".$page." sur ".$nb_pages; //On affiche le nombre de
pages sur le total
}
else{
$msg="Désolé, aucun enregistrement trouvé !"; //Sinon, on signale
qu'il n'y a pas de résultats
}
?>
<!DOCTYPE php PUBLIC "-//W3C//DTD Xphp 1.1//EN"
"http://www.w3.org/TR/xphp11/DTD/xphp11.dtd"><head>
<title>Fonctionnaires</title>
<center><h1>Les fonctionnaires dans les registres</h1></center>
<?php
echo $msg."\n"; // On écrit le message au dessus du tableau
?>
<!-- EN-TÊTES DU TABLEAU -->
<center>
Pour obtenir les informations complètes vous devez accepter les 'pop-up'
de ce site<br><br>
Cliquez sur la ligne de votre choix.
<link rel="stylesheet" href="base_resultat.css" type="text/css">
</table>
</center>
<!-- FIN REMPLISSAGE DU TABLEAU -->
</div>
<!-- LIENS VERS LES AUTRES PAGES -->
<div align="center" class="pages">
<?php
$i=0;
while ($i <= $nb_pages-1):
$j=$i+1;
if ((!$nom) AND (!$prenom)){
echo "<span class=\"page\"><a
href=\"FP_adh.php?page=".$j."&nb_pages=".$nb_pages."\">".$j."</a></span>\n";
}
else if (($nom) AND ($prenom)) {
echo "<span class=\"page\"><a
href=\"FP_adh.php?page=".$j."&nb_pages=".$nb_pages."&nom=".$nom."&prenom=".$prenom."\">".$j."</a></span>\n";
}
else{
echo "<span class=\"page\"><a
href=\"FP_adh.php?page=".$j."&nb_pages=".$nb_pages."&nom=".$nom."\">".$j."</a></span>\n";
}
$i++;
endwhile;
?>
</div>
<!-- FIN LIENS VERS LES AUTRES PAGES -->
<?php
echo "<br />\n"; //On passe une ligne
include ('../../Pied_page.php'); ?>
</body>
</html>
<?
//INCLUSION DU FICHIER DE CONNEXION
include("connect.inc");
//CONNEXION A LA BASE
$mysql_id=mysql_connect($server,$user,$pwd);
// Sortir du script en cas de problème de connexion
//au serveur.
if(!$mysql_id){
echo "Problème de connexion à la base : ".mysql_errno().":
".mysql_error()."<br />";
exit;
}
//SELECTION DE LA BASE
mysql_select_db($base,$mysql_id);
//SELECTION DE LA TABLE
$table = 'FP_Complet'; // Le nom de cette table ne passe pas chez Sivit !
//REQUETE SQL
$qry="SELECT * FROM $table WHERE id='".$id."'";
//echo $qry;
//EXECUTION DE LA REQUETE
$result=mysql_query($qry);
<hr width="50%" />
<?
//Cote
if ($cote){
echo "<div style=\"padding-left: 15px;\"><span class=\"bold\">Cote du
document: </span><span>$cote</span></div>";
}
//Titre
if ($titre){
echo "<div style=\"padding-left: 15px;\"><span class=\"bold\">Titre du
document: </span><span>$titre</span></div>";
}
?>
<hr width="50%" />
<?
//Profession
if ($profession){
echo "<div style=\"padding-left: 15px;\"><span
class=\"bold\">Profession: </span><span>$profession</span></div>";
}
//LIGNE NAISSANCE
if (($date_n) AND ($lieu_n) AND ($dpt_n)) { // Si le lieu et la date de
naissance sont présents
echo "<div style=\"padding-left: 15px;\"><span class=\"bold\">Né le
</span><span>$date_n</span><span class=\"bold\"> à
</span><span>$lieu_n</span> (<span>$dpt_n</span>)</div>";
}
else if (($date_n) AND (!$lieu_n) AND ($dpt_n)){ // Si la date de
naissance est présente mais pas le lieu
echo "<div style=\"padding-left: 15px;\"><span class=\"bold\">Né le
</span><span>$date_n</span> dans le <span>$dpt_,</span></div>";
}
else if ((!$date_n) AND ($lieu_n) AND ($dpt_n)){ // Si le lieu est
présent sans la date de naissance (si ça existe ;-))
echo "<div style=\"padding-left: 15px;\"><span class=\"bold\">Né à
</span><span>$lieu_n</span> (<span>$dpt_n</span>)</div>";
}
// Type acte
if ($acte){
echo "<div style=\"padding-left: 15px;\"><span class=\"bold\">Type
d'acte: </span><span>$acte</span></div>";
}
// Date de l'acte
if ($date_acte){
echo "<div style=\"padding-left: 15px;\"><span class=\"bold\">Date de
l'acte: </span><span>$date_acte</span></div>";
}
> Regardez ce fil et vous comprendrez ce que je DÉTESTE!
Moi il y a d'autres choses qui me défrisent, mais c'est un autre problème.
1 question pratique avec tous les éléments.
Non, avec les scripts en vrac, failles de sécurité incluses et récupérées par les bretelles par l'équipe de modération sans qui tu aurais donné l'accès à ta base à la terre entière, et débrouillez vous pour comprendre ce qui merde. J'ajouterai même que ton message d'origine est limite hors charte car incomplet.
12 messages avec 1 personne pour arriver à la solution recherchée. Je n'ai pas dit LA solution car vu les autres messages.
Non, incroyable, il y aurait plusieurs solutions pour arriver au même résultat ?
15 messages de geeks qui se battent pour dire qu'il a une meilleure solution que son voisin. Aucun pour donner une solution pratique au cas posé...
Peut-être que le cas posé ne les intéresse pas ? Peut-être qu'il y a des tétrachiées de ressources qui couvent déjà le problème, que ceci a été expliqué des centaines de fois ?
Pensez-vous décemment que vous attirez les néophites à faire des efforts? Je vous réponds que non car c'est désolant.
Est-ce le rôle d'un forum de discussion usenet ? Ce qui est désolant c'est de trouver encore des gens qui espèrent qu'on va résoudre tous leurs problèmes en deux coups de cuillère à pot. C'est sur fr.rec.oracle, qu'il faut poster dans ce cas.
Si tu avais commencé par lire la FAQ de ce forum, au hasard le point 2.7, tu aurais directement eu la bonne réponse. Pour rappel: http://faqfclphp.free.fr/
Et si tu souhaites avoir la référence de tutoriaux à propos de PHP, il y en a aussi dans cette FAQ et sur google.
a++; JG
> Regardez ce fil et vous comprendrez ce que je DÉTESTE!
Moi il y a d'autres choses qui me défrisent, mais c'est un autre problème.
1 question pratique avec tous les éléments.
Non, avec les scripts en vrac, failles de sécurité incluses et
récupérées par les bretelles par l'équipe de modération sans qui tu
aurais donné l'accès à ta base à la terre entière, et débrouillez vous
pour comprendre ce qui merde. J'ajouterai même que ton message d'origine
est limite hors charte car incomplet.
12 messages avec 1 personne pour arriver à la solution recherchée. Je
n'ai pas dit LA solution car vu les autres messages.
Non, incroyable, il y aurait plusieurs solutions pour arriver au même
résultat ?
15 messages de geeks qui se battent pour dire qu'il a une meilleure
solution que son voisin. Aucun pour donner une solution pratique au cas
posé...
Peut-être que le cas posé ne les intéresse pas ? Peut-être qu'il y a des
tétrachiées de ressources qui couvent déjà le problème, que ceci a été
expliqué des centaines de fois ?
Pensez-vous décemment que vous attirez les néophites à faire des
efforts? Je vous réponds que non car c'est désolant.
Est-ce le rôle d'un forum de discussion usenet ? Ce qui est désolant
c'est de trouver encore des gens qui espèrent qu'on va résoudre tous
leurs problèmes en deux coups de cuillère à pot. C'est sur
fr.rec.oracle, qu'il faut poster dans ce cas.
Si tu avais commencé par lire la FAQ de ce forum, au hasard le point
2.7, tu aurais directement eu la bonne réponse. Pour rappel:
http://faqfclphp.free.fr/
Et si tu souhaites avoir la référence de tutoriaux à propos de PHP, il y
en a aussi dans cette FAQ et sur google.
> Regardez ce fil et vous comprendrez ce que je DÉTESTE!
Moi il y a d'autres choses qui me défrisent, mais c'est un autre problème.
1 question pratique avec tous les éléments.
Non, avec les scripts en vrac, failles de sécurité incluses et récupérées par les bretelles par l'équipe de modération sans qui tu aurais donné l'accès à ta base à la terre entière, et débrouillez vous pour comprendre ce qui merde. J'ajouterai même que ton message d'origine est limite hors charte car incomplet.
12 messages avec 1 personne pour arriver à la solution recherchée. Je n'ai pas dit LA solution car vu les autres messages.
Non, incroyable, il y aurait plusieurs solutions pour arriver au même résultat ?
15 messages de geeks qui se battent pour dire qu'il a une meilleure solution que son voisin. Aucun pour donner une solution pratique au cas posé...
Peut-être que le cas posé ne les intéresse pas ? Peut-être qu'il y a des tétrachiées de ressources qui couvent déjà le problème, que ceci a été expliqué des centaines de fois ?
Pensez-vous décemment que vous attirez les néophites à faire des efforts? Je vous réponds que non car c'est désolant.
Est-ce le rôle d'un forum de discussion usenet ? Ce qui est désolant c'est de trouver encore des gens qui espèrent qu'on va résoudre tous leurs problèmes en deux coups de cuillère à pot. C'est sur fr.rec.oracle, qu'il faut poster dans ce cas.
Si tu avais commencé par lire la FAQ de ce forum, au hasard le point 2.7, tu aurais directement eu la bonne réponse. Pour rappel: http://faqfclphp.free.fr/
Et si tu souhaites avoir la référence de tutoriaux à propos de PHP, il y en a aussi dans cette FAQ et sur google.
a++; JG
Patrick Mevzek
Le Mon, 13 Apr 2009 13:16:26 +0000, Yannick a écrit:
Regardez ce fil et vous comprendrez ce que je DÉTESTE!
Bienvenue sur Usenet à vous :-)
-- Patrick Mevzek . . . . . . . . . . . . . . Dot and Co <http://www.dotandco.net/> <http://www.dotandco.com/> <http://www.dotandco.net/ressources/icann_registrars/prices> <http://icann-registrars-life.dotandco.net/>
Le Mon, 13 Apr 2009 13:16:26 +0000, Yannick a écrit:
Regardez ce fil et vous comprendrez ce que je DÉTESTE!
Bienvenue sur Usenet à vous :-)
--
Patrick Mevzek . . . . . . . . . . . . . . Dot and Co
<http://www.dotandco.net/> <http://www.dotandco.com/>
<http://www.dotandco.net/ressources/icann_registrars/prices>
<http://icann-registrars-life.dotandco.net/>
Le Mon, 13 Apr 2009 13:16:26 +0000, Yannick a écrit:
Regardez ce fil et vous comprendrez ce que je DÉTESTE!
Bienvenue sur Usenet à vous :-)
-- Patrick Mevzek . . . . . . . . . . . . . . Dot and Co <http://www.dotandco.net/> <http://www.dotandco.com/> <http://www.dotandco.net/ressources/icann_registrars/prices> <http://icann-registrars-life.dotandco.net/>
Mickael Wolff
Patrick Mevzek wrote:
Ah bon ce n'est pas ca le problème de register_global ? Bah je crois qu'il y a fort peu de chance qu'on soit d'accord sur quelque chose si on n'est pas d'accord sur un fait de base comme ca. C'est quoi alors selon vous le problème de register_global ?
Je pense que le vrai problème des register_global était la confusion de tout et n'importe quoi, sans maitrise et sans controle des données provenant de sources différentes.
Les variables globales ne sont accessible que depuis le scope global. Donc tant qu'on codait proprement avec des fonctions, il n'y avait pas de soucis.
Sauf que la façon dont PHP est architecturé (avec le code dans *chaque* page, par défaut), ne motive justement pas à faire des factorisations. (oui on peut évidemment, non on n'y est pas encouragé)
Ce est la racine du mal, on est d'accord.
De ce point de vue là on est d'accord, et donc vous êtes d'accord avec le fait que $_REQUEST, $_GET, et $_POST ont exactement le même niveau de sécurité (d'insécurité).
Complètement. Mais je pense que $_REQUEST ajoute un niveau de confusion, c'est ce qui gene mon caractère anxieux.
Ils sont interchangeables *du point de vue de la sécurité*. J'ai bien dit plusieurs fois, dans ce fil même, que GET et POST sont *sémantiquement* différents et non interchangeables. Mais au niveau sécurité rattachée c'est pareil et on ne peut *PAS* sécuriser une application en changeant un get en post ou le contraire.
Ce n'est pas exactement pareil. Mon propos était de dire que, si le GET pouvait ^etre déclenché involontairement par l'utilisateur de l'application, le POST ne le peut qu'avec beaucoup de difficultés (Firefox n'autorises pas les requu^etes XHR transversales, et donc neutralises la possibilité de faire des HTTP POST).
D'acord on le peut toujours techniquement. MAis la question est: cela a-t- il un sens, et cela solutionne-t-il un quelconque problème de sécurité ? Selon moi, non, car ce que vous présentez comme problème de sécurité prétendûment résolu en POST et problèmatique en GET: 1) est en fait autant un problème en POST qu'en GET 2) n'est pas un problème de sécurité à la base, mais un problème d'application mal concue, qui ne gère pas l'aspect sans états du HTTP correctement, et ne met pas en oeuvre de bonnes pratiques relatives à l'authentification, l'autorisation et les opérations délicates comme la suppression (cf ma mention de jetons uniques dans un autre message).
La technique des jetons est effectivement incontournable. Mais est-ce que ça résoud complètement le problème que j'avais exposé ?
Vous voulez dire que vous avez une application qui réagit différemment quand appelée en GET ou en POST sur la *même* URL ? C'est bien sûr possible, mais la balance entre ce que cela apporte et ce que cela peut causer comme désagréments n'est pas penchée du mauvais côté ?
On peut imaginer un formulaire d'authentification sur toutes les pages d'un site, mais qu'on ne veuille pas accéder à la ressource « page d'authentification » à chaque fois qu'on se logue, mais rester sur la page de la ressource consultée actuellement. Dans ce cas, ce n'est pas un contre-sens que de récupérer à la fois les données de consultation et celles d'altération.
Là pour le coup, je veux bien accepter cet argument... on dépend de la configuration du serveur... sauf que ca ne concerne que le cas de la page qui mélange des paramètres dans l'URL et dans le corps, ce qui
Tout à fait.
1) n'est pas forcément défini dans le standard (je n'ai pas vérifié) 2) est au moins pris en compte dans une API en jetant tout simplement la partie GET (ce qui découle peut-être du 1), je ne sais pas).
La norme de définit effectivement pas les variables qui seront accessible via PHP ^^; Cependant, on sait qu'elles sont disponibles puisque faisant partie de la Requiest-URI.
Et puis si on veut blinder 1) on se refaire son $_REQUEST à soi avec import_request_variables() avec un prefix non vide évidemment ou
Ou sa classe http_request ;)
2) on assure, dans un .htaccess ou équivalent que variables_order est positionné sainement.
Il faut pouvoir l'imposer ;) Mais il y a d'autres possiblités d'arriver au meme résultat.
Mais bon encore une fois je doute que cela soit un réel problème, sauf pour les applications qui reagissent différemment à la même url en GET/ POST. Ce qui serait d'ailleurs plutôt enclin à montrer que c'est une mauvaise idée :-)
Ben en fait, RFC2616 section 9.5 <http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.5> : « The POST method is used to request that the origin server accept the entity enclosed in the request as a new subordinate of the resource identified by the Request-URI in the Request-Line. »
Donc en fait, avec une lecture intégriste, les données concernant la désignation de la ressource devraient etre passées dans l'URI. J'avais essayé de faire ça. Mais c'est peut-etre un peu lourd gérer.
Si je dois donner mon petit cas particulier, pas forcément en PHP mais ca donne 1) je ne m'occupe pas de REQUEST_METHOD car mon API d'accès aux variables gère POST et GET de la même façon quant à la récupération des valeurs 2) je ne fais pas d'applications qui réagissent différemment à la même URL selon que c'est GET ou POST 3) si je fais un POST je ne m'amuse pas à mettre de variables dans l'URL car je me suis déjà fait piéger (genre la même variable aux deux endroits... eh eh qui gagne ?) et mon API dans ce cas précis au final ne considére pas ce qu'il y a dans le GET, histoire de trancher.
C'est une façon, mais elle ne plait pas à ma compréhension du protocole HTTP.
Pas d'expérience directe
C'est ce m'intéresserait. Sinon je sais me servir, quelque peu, d'un moteur de recherche :)
register_global n'est pas une mesure de sécurité c'est même une hénaurme mesure d'insécurité dès le départ. L'enlever permet donc just de revenir à la normale ;-)
Ah bon ce n'est pas ca le problème de register_global ?
Bah je crois qu'il y a fort peu de chance qu'on soit d'accord sur quelque
chose si on n'est pas d'accord sur un fait de base comme ca.
C'est quoi alors selon vous le problème de register_global ?
Je pense que le vrai problème des register_global était la confusion
de tout et n'importe quoi, sans maitrise et sans controle des données
provenant de sources différentes.
Les variables globales ne sont accessible que depuis le scope global.
Donc tant qu'on codait proprement avec des fonctions, il n'y avait pas
de soucis.
Sauf que la façon dont PHP est architecturé (avec le code dans *chaque*
page, par défaut), ne motive justement pas à faire des factorisations.
(oui on peut évidemment, non on n'y est pas encouragé)
Ce est la racine du mal, on est d'accord.
De ce point de vue là on est d'accord, et donc vous êtes d'accord avec le
fait que $_REQUEST, $_GET, et $_POST ont exactement le même niveau de
sécurité (d'insécurité).
Complètement. Mais je pense que $_REQUEST ajoute un niveau de
confusion, c'est ce qui gene mon caractère anxieux.
Ils sont interchangeables *du point de vue de la sécurité*. J'ai bien dit
plusieurs fois, dans ce fil même, que GET et POST sont *sémantiquement*
différents et non interchangeables. Mais au niveau sécurité rattachée
c'est pareil et on ne peut *PAS* sécuriser une application en changeant
un get en post ou le contraire.
Ce n'est pas exactement pareil. Mon propos était de dire que, si le
GET pouvait ^etre déclenché involontairement par l'utilisateur de
l'application, le POST ne le peut qu'avec beaucoup de difficultés
(Firefox n'autorises pas les requu^etes XHR transversales, et donc
neutralises la possibilité de faire des HTTP POST).
D'acord on le peut toujours techniquement. MAis la question est: cela a-t-
il un sens, et cela solutionne-t-il un quelconque problème de sécurité ?
Selon moi, non, car ce que vous présentez comme problème de sécurité
prétendûment résolu en POST et problèmatique en GET:
1) est en fait autant un problème en POST qu'en GET
2) n'est pas un problème de sécurité à la base, mais un problème
d'application mal concue, qui ne gère pas l'aspect sans états du HTTP
correctement, et ne met pas en oeuvre de bonnes pratiques relatives à
l'authentification, l'autorisation et les opérations délicates comme la
suppression (cf ma mention de jetons uniques dans un autre message).
La technique des jetons est effectivement incontournable. Mais est-ce
que ça résoud complètement le problème que j'avais exposé ?
Vous voulez dire que vous avez une application qui réagit différemment
quand appelée en GET ou en POST sur la *même* URL ?
C'est bien sûr possible, mais la balance entre ce que cela apporte et ce
que cela peut causer comme désagréments n'est pas penchée du mauvais
côté ?
On peut imaginer un formulaire d'authentification sur toutes les
pages d'un site, mais qu'on ne veuille pas accéder à la ressource « page
d'authentification » à chaque fois qu'on se logue, mais rester sur la
page de la ressource consultée actuellement. Dans ce cas, ce n'est pas
un contre-sens que de récupérer à la fois les données de consultation et
celles d'altération.
Là pour le coup, je veux bien accepter cet argument... on dépend de la
configuration du serveur... sauf que ca ne concerne que le cas de la page
qui mélange des paramètres dans l'URL et dans le corps, ce qui
Tout à fait.
1) n'est pas forcément défini dans le standard (je n'ai pas vérifié)
2) est au moins pris en compte dans une API en jetant tout simplement la
partie GET (ce qui découle peut-être du 1), je ne sais pas).
La norme de définit effectivement pas les variables qui seront
accessible via PHP ^^; Cependant, on sait qu'elles sont disponibles
puisque faisant partie de la Requiest-URI.
Et puis si on veut blinder
1) on se refaire son $_REQUEST à soi avec import_request_variables()
avec un prefix non vide évidemment
ou
Ou sa classe http_request ;)
2) on assure, dans un .htaccess ou équivalent que variables_order est
positionné sainement.
Il faut pouvoir l'imposer ;) Mais il y a d'autres possiblités
d'arriver au meme résultat.
Mais bon encore une fois je doute que cela soit un réel problème, sauf
pour les applications qui reagissent différemment à la même url en GET/
POST. Ce qui serait d'ailleurs plutôt enclin à montrer que c'est une
mauvaise idée :-)
Ben en fait, RFC2616 section 9.5
<http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.5> :
« The POST method is used to request that the origin server accept the
entity enclosed in the request as a new subordinate of the resource
identified by the Request-URI in the Request-Line. »
Donc en fait, avec une lecture intégriste, les données concernant la
désignation de la ressource devraient etre passées dans l'URI. J'avais
essayé de faire ça. Mais c'est peut-etre un peu lourd gérer.
Si je dois donner mon petit cas particulier, pas forcément en PHP mais ca
donne
1) je ne m'occupe pas de REQUEST_METHOD car mon API d'accès aux variables
gère POST et GET de la même façon quant à la récupération des valeurs
2) je ne fais pas d'applications qui réagissent différemment à la même
URL selon que c'est GET ou POST
3) si je fais un POST je ne m'amuse pas à mettre de variables dans l'URL
car je me suis déjà fait piéger (genre la même variable aux deux
endroits... eh eh qui gagne ?) et mon API dans ce cas précis au final ne
considére pas ce qu'il y a dans le GET, histoire de trancher.
C'est une façon, mais elle ne plait pas à ma compréhension du
protocole HTTP.
Pas d'expérience directe
C'est ce m'intéresserait. Sinon je sais me servir, quelque peu, d'un
moteur de recherche :)
register_global n'est pas une mesure de sécurité c'est même une hénaurme
mesure d'insécurité dès le départ. L'enlever permet donc just de revenir
à la normale ;-)
Ah bon ce n'est pas ca le problème de register_global ? Bah je crois qu'il y a fort peu de chance qu'on soit d'accord sur quelque chose si on n'est pas d'accord sur un fait de base comme ca. C'est quoi alors selon vous le problème de register_global ?
Je pense que le vrai problème des register_global était la confusion de tout et n'importe quoi, sans maitrise et sans controle des données provenant de sources différentes.
Les variables globales ne sont accessible que depuis le scope global. Donc tant qu'on codait proprement avec des fonctions, il n'y avait pas de soucis.
Sauf que la façon dont PHP est architecturé (avec le code dans *chaque* page, par défaut), ne motive justement pas à faire des factorisations. (oui on peut évidemment, non on n'y est pas encouragé)
Ce est la racine du mal, on est d'accord.
De ce point de vue là on est d'accord, et donc vous êtes d'accord avec le fait que $_REQUEST, $_GET, et $_POST ont exactement le même niveau de sécurité (d'insécurité).
Complètement. Mais je pense que $_REQUEST ajoute un niveau de confusion, c'est ce qui gene mon caractère anxieux.
Ils sont interchangeables *du point de vue de la sécurité*. J'ai bien dit plusieurs fois, dans ce fil même, que GET et POST sont *sémantiquement* différents et non interchangeables. Mais au niveau sécurité rattachée c'est pareil et on ne peut *PAS* sécuriser une application en changeant un get en post ou le contraire.
Ce n'est pas exactement pareil. Mon propos était de dire que, si le GET pouvait ^etre déclenché involontairement par l'utilisateur de l'application, le POST ne le peut qu'avec beaucoup de difficultés (Firefox n'autorises pas les requu^etes XHR transversales, et donc neutralises la possibilité de faire des HTTP POST).
D'acord on le peut toujours techniquement. MAis la question est: cela a-t- il un sens, et cela solutionne-t-il un quelconque problème de sécurité ? Selon moi, non, car ce que vous présentez comme problème de sécurité prétendûment résolu en POST et problèmatique en GET: 1) est en fait autant un problème en POST qu'en GET 2) n'est pas un problème de sécurité à la base, mais un problème d'application mal concue, qui ne gère pas l'aspect sans états du HTTP correctement, et ne met pas en oeuvre de bonnes pratiques relatives à l'authentification, l'autorisation et les opérations délicates comme la suppression (cf ma mention de jetons uniques dans un autre message).
La technique des jetons est effectivement incontournable. Mais est-ce que ça résoud complètement le problème que j'avais exposé ?
Vous voulez dire que vous avez une application qui réagit différemment quand appelée en GET ou en POST sur la *même* URL ? C'est bien sûr possible, mais la balance entre ce que cela apporte et ce que cela peut causer comme désagréments n'est pas penchée du mauvais côté ?
On peut imaginer un formulaire d'authentification sur toutes les pages d'un site, mais qu'on ne veuille pas accéder à la ressource « page d'authentification » à chaque fois qu'on se logue, mais rester sur la page de la ressource consultée actuellement. Dans ce cas, ce n'est pas un contre-sens que de récupérer à la fois les données de consultation et celles d'altération.
Là pour le coup, je veux bien accepter cet argument... on dépend de la configuration du serveur... sauf que ca ne concerne que le cas de la page qui mélange des paramètres dans l'URL et dans le corps, ce qui
Tout à fait.
1) n'est pas forcément défini dans le standard (je n'ai pas vérifié) 2) est au moins pris en compte dans une API en jetant tout simplement la partie GET (ce qui découle peut-être du 1), je ne sais pas).
La norme de définit effectivement pas les variables qui seront accessible via PHP ^^; Cependant, on sait qu'elles sont disponibles puisque faisant partie de la Requiest-URI.
Et puis si on veut blinder 1) on se refaire son $_REQUEST à soi avec import_request_variables() avec un prefix non vide évidemment ou
Ou sa classe http_request ;)
2) on assure, dans un .htaccess ou équivalent que variables_order est positionné sainement.
Il faut pouvoir l'imposer ;) Mais il y a d'autres possiblités d'arriver au meme résultat.
Mais bon encore une fois je doute que cela soit un réel problème, sauf pour les applications qui reagissent différemment à la même url en GET/ POST. Ce qui serait d'ailleurs plutôt enclin à montrer que c'est une mauvaise idée :-)
Ben en fait, RFC2616 section 9.5 <http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.5> : « The POST method is used to request that the origin server accept the entity enclosed in the request as a new subordinate of the resource identified by the Request-URI in the Request-Line. »
Donc en fait, avec une lecture intégriste, les données concernant la désignation de la ressource devraient etre passées dans l'URI. J'avais essayé de faire ça. Mais c'est peut-etre un peu lourd gérer.
Si je dois donner mon petit cas particulier, pas forcément en PHP mais ca donne 1) je ne m'occupe pas de REQUEST_METHOD car mon API d'accès aux variables gère POST et GET de la même façon quant à la récupération des valeurs 2) je ne fais pas d'applications qui réagissent différemment à la même URL selon que c'est GET ou POST 3) si je fais un POST je ne m'amuse pas à mettre de variables dans l'URL car je me suis déjà fait piéger (genre la même variable aux deux endroits... eh eh qui gagne ?) et mon API dans ce cas précis au final ne considére pas ce qu'il y a dans le GET, histoire de trancher.
C'est une façon, mais elle ne plait pas à ma compréhension du protocole HTTP.
Pas d'expérience directe
C'est ce m'intéresserait. Sinon je sais me servir, quelque peu, d'un moteur de recherche :)
register_global n'est pas une mesure de sécurité c'est même une hénaurme mesure d'insécurité dès le départ. L'enlever permet donc just de revenir à la normale ;-)
Attention cependant à ne pas confondre la requête GET avec les valeurs de $_GET ni la requête POST avec les valeurs de $_POST. Même s'il est vrai qu'une requête GET ne transmet pas de valeurs dans $_POST, l'inverse peut être faux (quelque mal que l'on puisse penser d'un POST transmettant des données dans $_GET).
Bon, question stupide dans mon précédent message, je viens de comprendre. Il s'agissait de requêtes comme
POST /foo.php?var=value HTTP/1.1
Mes doigts ont été plus rapides que mes neurones, désolé pour le bruit.
-- Manuel Pégourié-Gonnard Institut de mathématiques de Jussieu http://weblog.elzevir.fr/ http://people.math.jussieu.fr/~mpg/
Olivier Miakinen scripsit:
Attention cependant à ne pas confondre la requête GET avec les valeurs
de $_GET ni la requête POST avec les valeurs de $_POST. Même s'il est
vrai qu'une requête GET ne transmet pas de valeurs dans $_POST,
l'inverse peut être faux (quelque mal que l'on puisse penser d'un
POST transmettant des données dans $_GET).
Bon, question stupide dans mon précédent message, je viens de comprendre.
Il s'agissait de requêtes comme
POST /foo.php?var=value HTTP/1.1
Mes doigts ont été plus rapides que mes neurones, désolé pour le bruit.
--
Manuel Pégourié-Gonnard Institut de mathématiques de Jussieu
http://weblog.elzevir.fr/ http://people.math.jussieu.fr/~mpg/
Attention cependant à ne pas confondre la requête GET avec les valeurs de $_GET ni la requête POST avec les valeurs de $_POST. Même s'il est vrai qu'une requête GET ne transmet pas de valeurs dans $_POST, l'inverse peut être faux (quelque mal que l'on puisse penser d'un POST transmettant des données dans $_GET).
Bon, question stupide dans mon précédent message, je viens de comprendre. Il s'agissait de requêtes comme
POST /foo.php?var=value HTTP/1.1
Mes doigts ont été plus rapides que mes neurones, désolé pour le bruit.
-- Manuel Pégourié-Gonnard Institut de mathématiques de Jussieu http://weblog.elzevir.fr/ http://people.math.jussieu.fr/~mpg/
Mickael Wolff
Paul a écrit :
Bien sûr, qu'il peut, et peut être même va t il le faire....
Ouaip. Mais d'abord je m'occupe des insultes.
Mais pour dire quoi ? qu'il s'agit d'une pratique sodomite des hyménoptéres courants ?
Non, pour dire que pour freiner en urgence on utilises le frein arrière, et pas le frein avant, sinon on fait un soleil.
Attention cependant à ne pas confondre la requête GET avec les valeurs de $_GET ni la requête POST avec les valeurs de $_POST. Même s'il est vrai qu'une requête GET ne transmet pas de valeurs dans $_POST, l'inverse peut être faux (quelque mal que l'on puisse penser d'un POST transmettant des données dans $_GET).
Hum, j'avoue que je suis perdu. Je viens de relire les pages du manuel PHP concernant $_GET et $_POST sans y trouver d'indice concernant la possibilité de passer des données dans $_GET avec une requête POST.
Quelqu'un peut-il m'expliquer (ou m'indiquer la partie de la doc PHP ou de la RFC adéquate que j'ai manquée) ?
Merci,
-- Manuel Pégourié-Gonnard Institut de mathématiques de Jussieu http://weblog.elzevir.fr/ http://people.math.jussieu.fr/~mpg/
Olivier Miakinen scripsit:
Attention cependant à ne pas confondre la requête GET avec les valeurs
de $_GET ni la requête POST avec les valeurs de $_POST. Même s'il est
vrai qu'une requête GET ne transmet pas de valeurs dans $_POST,
l'inverse peut être faux (quelque mal que l'on puisse penser d'un
POST transmettant des données dans $_GET).
Hum, j'avoue que je suis perdu. Je viens de relire les pages du manuel
PHP concernant $_GET et $_POST sans y trouver d'indice concernant la
possibilité de passer des données dans $_GET avec une requête POST.
Quelqu'un peut-il m'expliquer (ou m'indiquer la partie de la doc PHP ou
de la RFC adéquate que j'ai manquée) ?
Merci,
--
Manuel Pégourié-Gonnard Institut de mathématiques de Jussieu
http://weblog.elzevir.fr/ http://people.math.jussieu.fr/~mpg/
Attention cependant à ne pas confondre la requête GET avec les valeurs de $_GET ni la requête POST avec les valeurs de $_POST. Même s'il est vrai qu'une requête GET ne transmet pas de valeurs dans $_POST, l'inverse peut être faux (quelque mal que l'on puisse penser d'un POST transmettant des données dans $_GET).
Hum, j'avoue que je suis perdu. Je viens de relire les pages du manuel PHP concernant $_GET et $_POST sans y trouver d'indice concernant la possibilité de passer des données dans $_GET avec une requête POST.
Quelqu'un peut-il m'expliquer (ou m'indiquer la partie de la doc PHP ou de la RFC adéquate que j'ai manquée) ?
Merci,
-- Manuel Pégourié-Gonnard Institut de mathématiques de Jussieu http://weblog.elzevir.fr/ http://people.math.jussieu.fr/~mpg/
John GALLET
Bonjour,
Bon, question stupide dans mon précédent message, je viens de comprendre.
Non, pas stupide du tout. C'est tellement tordu à la fois comme syntaxe et comme comportement serveur que si on l'a pas vu une fois dans sa vie ça fait quand même drôle quand on y est confronté la première fois.
On aura alors var dans $_GET et varpost dans $_POST
Mes doigts ont été plus rapides que mes neurones, désolé pour le bruit.
Ce n'est pas du bruit. Moult contributeurs de ce forum n'ont jamais rencontré le cas qui nécessite à la fois du code html d'une syntaxe discutable et la connaissance du fonctionnement interne de php au lieu de croire (faussement) que method="post" implique nécessairement toutes variables dans $_POST.
On est bien d'accord, c'est un cas "tordu".
a++; JG
Bonjour,
Bon, question stupide dans mon précédent message, je viens de comprendre.
Non, pas stupide du tout. C'est tellement tordu à la fois comme syntaxe
et comme comportement serveur que si on l'a pas vu une fois dans sa vie
ça fait quand même drôle quand on y est confronté la première fois.
On aura alors var dans $_GET et varpost dans $_POST
Mes doigts ont été plus rapides que mes neurones, désolé pour le bruit.
Ce n'est pas du bruit. Moult contributeurs de ce forum n'ont jamais
rencontré le cas qui nécessite à la fois du code html d'une syntaxe
discutable et la connaissance du fonctionnement interne de php au lieu
de croire (faussement) que method="post" implique nécessairement toutes
variables dans $_POST.
Bon, question stupide dans mon précédent message, je viens de comprendre.
Non, pas stupide du tout. C'est tellement tordu à la fois comme syntaxe et comme comportement serveur que si on l'a pas vu une fois dans sa vie ça fait quand même drôle quand on y est confronté la première fois.
On aura alors var dans $_GET et varpost dans $_POST
Mes doigts ont été plus rapides que mes neurones, désolé pour le bruit.
Ce n'est pas du bruit. Moult contributeurs de ce forum n'ont jamais rencontré le cas qui nécessite à la fois du code html d'une syntaxe discutable et la connaissance du fonctionnement interne de php au lieu de croire (faussement) que method="post" implique nécessairement toutes variables dans $_POST.
On est bien d'accord, c'est un cas "tordu".
a++; JG
John GALLET
Bonjour,
C'est quoi alors selon vous le problème de register_global ?
Je pense que le vrai problème des register_global était la confusion de tout et n'importe quoi, sans maitrise et sans controle des données provenant de sources différentes.
A mon sens, le *vrai* problème est (comme souvent) lié à l'interface chaise-clavier: comme les développeurs ne savent pas initialiser une variable, on peut injecter des variables depuis l'extérieur. Avoir register_globals à off ou le retirer, c'est exclusivement encourager les gens à porc-grammer(1) sans initialiser leur contexte. Mais nous revenons là des années en arrière, ce qui est fait (contre l'avis de Rasmus lui même) est fait.
(1) non, pas de faute de frappe.
Les variables globales ne sont accessible que depuis le scope global. Donc tant qu'on codait proprement avec des fonctions, il n'y avait pas de soucis.
Même pas besoin de fonctions (même si bien évidemment la factorisation du code est souhaitable), il suffit d'initialiser ses variables. Ensuite l'attaquant peut injecter ce qu'il veut, on s'en fout vu qu'on écrase sa valeur. C'est quand même pas bien compliqué, surtout dans ce Brave New World des frameworks et autres gadgets qui font tout même le café.
Complètement. Mais je pense que $_REQUEST ajoute un niveau de confusion, c'est ce qui gene mon caractère anxieux.
Je ne vois pas où est la confusion, *au contraire*: TOUT ce qui vient du monde extérieur sur la requête courante (et donc *par définition dangereux*) est CENTRALISE dans ce tableau qui est une zone tampon des choses dangereuses. Un guignol a eut l'idée géniale d'en retirer $_FILES au bout d'un certain temps (j'avoue ne pas avoir suivi la raison invoquée) alors que ça en fait partie, mais c'est bien à ça que ça sert.
Et soyons réalistes: combien de développeurs de web-app connaissent aujourd'hui la vraie différence de protocole entre un get et un post et ce que ça implique ? Il a fallu que je la rappelle pas plus tard qu'hier vu les énormités proférées. Donc on ferait mieux de dire aux débutants: côté serveur, vous vous posez pas la question de savoir COMMENT ça arrive car votre problème c'est *d'où* ça arrive (i.e. de l'extérieur donc dangereux). Ce qui n'empêche en rien de mettre dans la couche de présentation la bonne méthode appropriée au besoin.
Ce n'est pas exactement pareil. Mon propos était de dire que, si le GET pouvait ^etre déclenché involontairement par l'utilisateur de l'application, le POST ne le peut qu'avec beaucoup de difficultés
Ah ? un coup de submit() en js ça le fait pas immédiatement en une ligne de code ? (vraie question sans malice, j'avoue ne pas avoir fait de tests)
register_global n'est pas une mesure de sécurité c'est même une hénaurme mesure d'insécurité dès le départ. L'enlever permet donc just de revenir à la normale ;-)
Un peu comme request :p (oui, lynchez moi !)
J'ai pas particulièrement le temps ni l'envie et de toutes façons ça a peu d'importance. Il n'y a aucun trou de sécurité à utiliser register_globals=On si le code est écrit proprement (il SUFFIT d'initialiser ses variables, y compris les tableaux) et dans tous les cas AUCUN trou de sécurité à taper directement côté serveur dans _REQUEST au lieu de séparer _GET et _POST (c'est le contenu qui est dangereux, pas la méthode de transmission).
L'essentiel c'est de filtrer le *contenu* des variables et de vérifier la légitimité de la requête, pas de savoir si la variable a été transmise par méthode get, post ou pigeon voyageur. Ou livreur de machine à laver (private joke pour autre marronier en floraison perpétuelle qui peut d'ailleurs se relier à celui-ci vu que header location force un get).
a++; JG
Bonjour,
C'est quoi alors selon vous le problème de register_global ?
Je pense que le vrai problème des register_global était la confusion
de tout et n'importe quoi, sans maitrise et sans controle des données
provenant de sources différentes.
A mon sens, le *vrai* problème est (comme souvent) lié à l'interface
chaise-clavier: comme les développeurs ne savent pas initialiser une
variable, on peut injecter des variables depuis l'extérieur. Avoir
register_globals à off ou le retirer, c'est exclusivement encourager les
gens à porc-grammer(1) sans initialiser leur contexte. Mais nous
revenons là des années en arrière, ce qui est fait (contre l'avis de
Rasmus lui même) est fait.
(1) non, pas de faute de frappe.
Les variables globales ne sont accessible que depuis le scope global.
Donc tant qu'on codait proprement avec des fonctions, il n'y avait pas
de soucis.
Même pas besoin de fonctions (même si bien évidemment la factorisation
du code est souhaitable), il suffit d'initialiser ses variables. Ensuite
l'attaquant peut injecter ce qu'il veut, on s'en fout vu qu'on écrase sa
valeur. C'est quand même pas bien compliqué, surtout dans ce Brave New
World des frameworks et autres gadgets qui font tout même le café.
Complètement. Mais je pense que $_REQUEST ajoute un niveau de
confusion, c'est ce qui gene mon caractère anxieux.
Je ne vois pas où est la confusion, *au contraire*: TOUT ce qui vient du
monde extérieur sur la requête courante (et donc *par définition
dangereux*) est CENTRALISE dans ce tableau qui est une zone tampon des
choses dangereuses. Un guignol a eut l'idée géniale d'en retirer $_FILES
au bout d'un certain temps (j'avoue ne pas avoir suivi la raison
invoquée) alors que ça en fait partie, mais c'est bien à ça que ça sert.
Et soyons réalistes: combien de développeurs de web-app connaissent
aujourd'hui la vraie différence de protocole entre un get et un post et
ce que ça implique ? Il a fallu que je la rappelle pas plus tard qu'hier
vu les énormités proférées. Donc on ferait mieux de dire aux débutants:
côté serveur, vous vous posez pas la question de savoir COMMENT ça
arrive car votre problème c'est *d'où* ça arrive (i.e. de l'extérieur
donc dangereux). Ce qui n'empêche en rien de mettre dans la couche de
présentation la bonne méthode appropriée au besoin.
Ce n'est pas exactement pareil. Mon propos était de dire que, si le
GET pouvait ^etre déclenché involontairement par l'utilisateur de
l'application, le POST ne le peut qu'avec beaucoup de difficultés
Ah ? un coup de submit() en js ça le fait pas immédiatement en une ligne
de code ? (vraie question sans malice, j'avoue ne pas avoir fait de tests)
register_global n'est pas une mesure de sécurité c'est même une
hénaurme mesure d'insécurité dès le départ. L'enlever permet donc just
de revenir à la normale ;-)
Un peu comme request :p (oui, lynchez moi !)
J'ai pas particulièrement le temps ni l'envie et de toutes façons ça a
peu d'importance. Il n'y a aucun trou de sécurité à utiliser
register_globals=On si le code est écrit proprement (il SUFFIT
d'initialiser ses variables, y compris les tableaux) et dans tous les
cas AUCUN trou de sécurité à taper directement côté serveur dans
_REQUEST au lieu de séparer _GET et _POST (c'est le contenu qui est
dangereux, pas la méthode de transmission).
L'essentiel c'est de filtrer le *contenu* des variables et de vérifier
la légitimité de la requête, pas de savoir si la variable a été
transmise par méthode get, post ou pigeon voyageur. Ou livreur de
machine à laver (private joke pour autre marronier en floraison
perpétuelle qui peut d'ailleurs se relier à celui-ci vu que header
location force un get).
C'est quoi alors selon vous le problème de register_global ?
Je pense que le vrai problème des register_global était la confusion de tout et n'importe quoi, sans maitrise et sans controle des données provenant de sources différentes.
A mon sens, le *vrai* problème est (comme souvent) lié à l'interface chaise-clavier: comme les développeurs ne savent pas initialiser une variable, on peut injecter des variables depuis l'extérieur. Avoir register_globals à off ou le retirer, c'est exclusivement encourager les gens à porc-grammer(1) sans initialiser leur contexte. Mais nous revenons là des années en arrière, ce qui est fait (contre l'avis de Rasmus lui même) est fait.
(1) non, pas de faute de frappe.
Les variables globales ne sont accessible que depuis le scope global. Donc tant qu'on codait proprement avec des fonctions, il n'y avait pas de soucis.
Même pas besoin de fonctions (même si bien évidemment la factorisation du code est souhaitable), il suffit d'initialiser ses variables. Ensuite l'attaquant peut injecter ce qu'il veut, on s'en fout vu qu'on écrase sa valeur. C'est quand même pas bien compliqué, surtout dans ce Brave New World des frameworks et autres gadgets qui font tout même le café.
Complètement. Mais je pense que $_REQUEST ajoute un niveau de confusion, c'est ce qui gene mon caractère anxieux.
Je ne vois pas où est la confusion, *au contraire*: TOUT ce qui vient du monde extérieur sur la requête courante (et donc *par définition dangereux*) est CENTRALISE dans ce tableau qui est une zone tampon des choses dangereuses. Un guignol a eut l'idée géniale d'en retirer $_FILES au bout d'un certain temps (j'avoue ne pas avoir suivi la raison invoquée) alors que ça en fait partie, mais c'est bien à ça que ça sert.
Et soyons réalistes: combien de développeurs de web-app connaissent aujourd'hui la vraie différence de protocole entre un get et un post et ce que ça implique ? Il a fallu que je la rappelle pas plus tard qu'hier vu les énormités proférées. Donc on ferait mieux de dire aux débutants: côté serveur, vous vous posez pas la question de savoir COMMENT ça arrive car votre problème c'est *d'où* ça arrive (i.e. de l'extérieur donc dangereux). Ce qui n'empêche en rien de mettre dans la couche de présentation la bonne méthode appropriée au besoin.
Ce n'est pas exactement pareil. Mon propos était de dire que, si le GET pouvait ^etre déclenché involontairement par l'utilisateur de l'application, le POST ne le peut qu'avec beaucoup de difficultés
Ah ? un coup de submit() en js ça le fait pas immédiatement en une ligne de code ? (vraie question sans malice, j'avoue ne pas avoir fait de tests)
register_global n'est pas une mesure de sécurité c'est même une hénaurme mesure d'insécurité dès le départ. L'enlever permet donc just de revenir à la normale ;-)
Un peu comme request :p (oui, lynchez moi !)
J'ai pas particulièrement le temps ni l'envie et de toutes façons ça a peu d'importance. Il n'y a aucun trou de sécurité à utiliser register_globals=On si le code est écrit proprement (il SUFFIT d'initialiser ses variables, y compris les tableaux) et dans tous les cas AUCUN trou de sécurité à taper directement côté serveur dans _REQUEST au lieu de séparer _GET et _POST (c'est le contenu qui est dangereux, pas la méthode de transmission).
L'essentiel c'est de filtrer le *contenu* des variables et de vérifier la légitimité de la requête, pas de savoir si la variable a été transmise par méthode get, post ou pigeon voyageur. Ou livreur de machine à laver (private joke pour autre marronier en floraison perpétuelle qui peut d'ailleurs se relier à celui-ci vu que header location force un get).
a++; JG
Eric Demeester
dans (in) fr.comp.lang.php, Yannick ecrivait (wrote) :
Bonjour Yannick,
Regardez ce fil et vous comprendrez ce que je DÉTESTE!
Comme le dit Patrick, bienvenue sur Usenet :)
Plus sérieusement, dans la mesure où le sujet/question/commentaire abordé est en thème, ce forum accueille tout le monde, du débutant qui pose une question jugée triviale par les plus chevronnés, aux gourous (si si, il y en a ici) qui sont capable de générer des fils de dizaines d'articles pour discuter par exemple de la pertinence de tel ou tel point obscur de telle ou telle norme.
Pensez-vous décemment que vous attirez les néophites à faire des efforts? Je vous réponds que non car c'est désolant.
Je conçois que cela soit déroutant au début, voire frustrant, mais il faut faire la part des choses et ne pas te décourager, à mon avis.
Fais le tri de ce qui t'est utile (on a apporté la solution à ton problème il me semble ?) et laisse les informaticiens barbus se chamailler entre eux :)
Au fil du temps, tu trouveras peut-être comme moi que leurs échanges sont passionnants, même si pour l'instant leurs discussions te semblent bien ésotériques et éloignées de tes préoccupations.
Amicalement,
-- Eric
dans (in) fr.comp.lang.php, Yannick <76@voyeaud.org> ecrivait (wrote) :
Bonjour Yannick,
Regardez ce fil et vous comprendrez ce que je DÉTESTE!
Comme le dit Patrick, bienvenue sur Usenet :)
Plus sérieusement, dans la mesure où le sujet/question/commentaire
abordé est en thème, ce forum accueille tout le monde, du débutant qui
pose une question jugée triviale par les plus chevronnés, aux gourous
(si si, il y en a ici) qui sont capable de générer des fils de dizaines
d'articles pour discuter par exemple de la pertinence de tel ou tel
point obscur de telle ou telle norme.
Pensez-vous décemment que vous attirez les néophites à faire des
efforts? Je vous réponds que non car c'est désolant.
Je conçois que cela soit déroutant au début, voire frustrant, mais il
faut faire la part des choses et ne pas te décourager, à mon avis.
Fais le tri de ce qui t'est utile (on a apporté la solution à ton
problème il me semble ?) et laisse les informaticiens barbus se
chamailler entre eux :)
Au fil du temps, tu trouveras peut-être comme moi que leurs échanges
sont passionnants, même si pour l'instant leurs discussions te semblent
bien ésotériques et éloignées de tes préoccupations.
dans (in) fr.comp.lang.php, Yannick ecrivait (wrote) :
Bonjour Yannick,
Regardez ce fil et vous comprendrez ce que je DÉTESTE!
Comme le dit Patrick, bienvenue sur Usenet :)
Plus sérieusement, dans la mesure où le sujet/question/commentaire abordé est en thème, ce forum accueille tout le monde, du débutant qui pose une question jugée triviale par les plus chevronnés, aux gourous (si si, il y en a ici) qui sont capable de générer des fils de dizaines d'articles pour discuter par exemple de la pertinence de tel ou tel point obscur de telle ou telle norme.
Pensez-vous décemment que vous attirez les néophites à faire des efforts? Je vous réponds que non car c'est désolant.
Je conçois que cela soit déroutant au début, voire frustrant, mais il faut faire la part des choses et ne pas te décourager, à mon avis.
Fais le tri de ce qui t'est utile (on a apporté la solution à ton problème il me semble ?) et laisse les informaticiens barbus se chamailler entre eux :)
Au fil du temps, tu trouveras peut-être comme moi que leurs échanges sont passionnants, même si pour l'instant leurs discussions te semblent bien ésotériques et éloignées de tes préoccupations.
Amicalement,
-- Eric
mpg
John GALLET scripsit:
L'essentiel c'est de filtrer le *contenu* des variables et de vérifier la légitimité de la requête, pas de savoir si la variable a été transmise par méthode get, post ou pigeon voyageur.
La RFC 1149 a réellement été implémentée ? ;-)
À part ça, même si ça tourne parfois un peu à la querelle de clocher, je suis très content de lire cette discussion dans laquelle j'apprends des choses, sérieusement.
-- Manuel Pégourié-Gonnard Institut de mathématiques de Jussieu http://weblog.elzevir.fr/ http://people.math.jussieu.fr/~mpg/
John GALLET scripsit:
L'essentiel c'est de filtrer le *contenu* des variables et de vérifier
la légitimité de la requête, pas de savoir si la variable a été
transmise par méthode get, post ou pigeon voyageur.
La RFC 1149 a réellement été implémentée ? ;-)
À part ça, même si ça tourne parfois un peu à la querelle de clocher, je
suis très content de lire cette discussion dans laquelle j'apprends des
choses, sérieusement.
--
Manuel Pégourié-Gonnard Institut de mathématiques de Jussieu
http://weblog.elzevir.fr/ http://people.math.jussieu.fr/~mpg/
L'essentiel c'est de filtrer le *contenu* des variables et de vérifier la légitimité de la requête, pas de savoir si la variable a été transmise par méthode get, post ou pigeon voyageur.
La RFC 1149 a réellement été implémentée ? ;-)
À part ça, même si ça tourne parfois un peu à la querelle de clocher, je suis très content de lire cette discussion dans laquelle j'apprends des choses, sérieusement.
-- Manuel Pégourié-Gonnard Institut de mathématiques de Jussieu http://weblog.elzevir.fr/ http://people.math.jussieu.fr/~mpg/
