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>";
}
Ce qui est important c'est de savoir ce qui se passe à tel ou tel moment dans le script. En conséquence un pro n'a pas besoin de commentaires car il sait mais un amateur en a besoin pour repérer rapidement ses commandes et les actions qu'elles sont sensées faire.
Un pro comme un amateur a besoin de commentaires. Mais chacun à besoin d'une information claire, concise, et maintenable. Si les commentaires sont illisibles et grèvent le code, il est inutile et aura beaucoup de chances de devenir dépassé. Et il n'y a rien de pire qu'une documentation erronée. n'oublions pas que les commentaires sont interprétés par le cerveau humain, et seul cet organe est capable de déterminer si le commentaire est cohérent ou non.
Un programme bien documenté et bien commenté est réutilisable par une autre personne. Un programme non commenté EST illisible donc mieux vaut trop que pas assez.
Un code bien écrit n'a pas besoin de commentaires superflus. Les commentaires doivent signaler le comportement attendu et l'usage d'un bout de code, et des points délicats du code source.
Si je m'en sort c'est bien parce que mon code, bien que pas génial pour les puristes, est commenté en abondance. Certes il y a beaucoup à dire sur le travail que j'ai fait mais pour un programmeur dilettant je crois que j'ai le droit d'être fier car j'ai été très largement largué techniquement alors que je programmais en basic puis en DbaseII en auto-formé.
Je comprends bien ton point de vue. Mais comprends aussi le mien, qui suis confronté professionnellement à du code de qualité variable.
Ce qui est important c'est de savoir ce qui se passe à tel ou tel moment
dans le script.
En conséquence un pro n'a pas besoin de commentaires car il sait mais un
amateur en a besoin pour repérer rapidement ses commandes et les actions
qu'elles sont sensées faire.
Un pro comme un amateur a besoin de commentaires. Mais chacun à
besoin d'une information claire, concise, et maintenable. Si les
commentaires sont illisibles et grèvent le code, il est inutile et aura
beaucoup de chances de devenir dépassé. Et il n'y a rien de pire qu'une
documentation erronée. n'oublions pas que les commentaires sont
interprétés par le cerveau humain, et seul cet organe est capable de
déterminer si le commentaire est cohérent ou non.
Un programme bien documenté et bien commenté est réutilisable par une
autre personne. Un programme non commenté EST illisible donc mieux vaut
trop que pas assez.
Un code bien écrit n'a pas besoin de commentaires superflus. Les
commentaires doivent signaler le comportement attendu et l'usage d'un
bout de code, et des points délicats du code source.
Si je m'en sort c'est bien parce que mon code, bien que pas génial pour
les puristes, est commenté en abondance.
Certes il y a beaucoup à dire sur le travail que j'ai fait mais pour un
programmeur dilettant je crois que j'ai le droit d'être fier car j'ai
été très largement largué techniquement alors que je programmais en
basic puis en DbaseII en auto-formé.
Je comprends bien ton point de vue. Mais comprends aussi le mien, qui
suis confronté professionnellement à du code de qualité variable.
Ce qui est important c'est de savoir ce qui se passe à tel ou tel moment dans le script. En conséquence un pro n'a pas besoin de commentaires car il sait mais un amateur en a besoin pour repérer rapidement ses commandes et les actions qu'elles sont sensées faire.
Un pro comme un amateur a besoin de commentaires. Mais chacun à besoin d'une information claire, concise, et maintenable. Si les commentaires sont illisibles et grèvent le code, il est inutile et aura beaucoup de chances de devenir dépassé. Et il n'y a rien de pire qu'une documentation erronée. n'oublions pas que les commentaires sont interprétés par le cerveau humain, et seul cet organe est capable de déterminer si le commentaire est cohérent ou non.
Un programme bien documenté et bien commenté est réutilisable par une autre personne. Un programme non commenté EST illisible donc mieux vaut trop que pas assez.
Un code bien écrit n'a pas besoin de commentaires superflus. Les commentaires doivent signaler le comportement attendu et l'usage d'un bout de code, et des points délicats du code source.
Si je m'en sort c'est bien parce que mon code, bien que pas génial pour les puristes, est commenté en abondance. Certes il y a beaucoup à dire sur le travail que j'ai fait mais pour un programmeur dilettant je crois que j'ai le droit d'être fier car j'ai été très largement largué techniquement alors que je programmais en basic puis en DbaseII en auto-formé.
Je comprends bien ton point de vue. Mais comprends aussi le mien, qui suis confronté professionnellement à du code de qualité variable.
je n'arrive pas à voir en quoi l'un représente des « données d'alteration » et l'autre « de consultation ». Peux-tu détailler ce qui se cache derrière ces deux mots ?
Bien sûr je peux détaille, et avec plaisir.
GET se traduit par « prendre » (consultation) POST peut se traduire par « soumettre » (altération)
Par consultation, je pense bien sûr à la lecture des données. Par altération, je considère l'ajout, la modification et la suppression d'une ressource (un article, un contact, etc).
Les méthodes existantes sont listées et décrites dans la RFC 2616 <http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9>. D'ailleurs, ce que je dis, y est exposé en moins extrémiste :
« In particular, the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered "safe". This allows user agents to represent other methods, such as POST, PUT and DELETE, in a special way, so that the user is made aware of the fact that a possibly unsafe action is being requested. »
La seule différence majeure entre ce que j'affirme et ce que déclare le RFC, c'est je dis MUST NOT plutôt que SHOULD NOT. Ceci signifie simplement que GET ne devrait pas être utilisé pour modifier des données.
Cependant je pense que cet usage devrait être bannit de nos habitudes pour des problèmes évidents (enfin, pas tant que ça visiblement :p ) de sécurité.
Le protocole HTTP prévoie donc que la méthode GET ne devrait être utilisée que pour requérir des données, et non les modifier. Car la méthode GET ne requiert pas d'action explicite de l'utilisateur.
je n'arrive pas à
voir en quoi l'un représente des « données d'alteration » et l'autre « de
consultation ». Peux-tu détailler ce qui se cache derrière ces deux mots ?
Bien sûr je peux détaille, et avec plaisir.
GET se traduit par « prendre » (consultation)
POST peut se traduire par « soumettre » (altération)
Par consultation, je pense bien sûr à la lecture des données. Par
altération, je considère l'ajout, la modification et la suppression
d'une ressource (un article, un contact, etc).
Les méthodes existantes sont listées et décrites dans la RFC 2616
<http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9>.
D'ailleurs, ce que je dis, y est exposé en moins extrémiste :
« In particular, the convention has been established that the GET and
HEAD methods SHOULD NOT have the significance of taking an action other
than retrieval. These methods ought to be considered "safe". This allows
user agents to represent other methods, such as POST, PUT and DELETE, in
a special way, so that the user is made aware of the fact that a
possibly unsafe action is being requested. »
La seule différence majeure entre ce que j'affirme et ce que déclare
le RFC, c'est je dis MUST NOT plutôt que SHOULD NOT. Ceci signifie
simplement que GET ne devrait pas être utilisé pour modifier des données.
Cependant je pense que cet usage devrait être bannit de nos habitudes
pour des problèmes évidents (enfin, pas tant que ça visiblement :p ) de
sécurité.
Le protocole HTTP prévoie donc que la méthode GET ne devrait être
utilisée que pour requérir des données, et non les modifier. Car la
méthode GET ne requiert pas d'action explicite de l'utilisateur.
je n'arrive pas à voir en quoi l'un représente des « données d'alteration » et l'autre « de consultation ». Peux-tu détailler ce qui se cache derrière ces deux mots ?
Bien sûr je peux détaille, et avec plaisir.
GET se traduit par « prendre » (consultation) POST peut se traduire par « soumettre » (altération)
Par consultation, je pense bien sûr à la lecture des données. Par altération, je considère l'ajout, la modification et la suppression d'une ressource (un article, un contact, etc).
Les méthodes existantes sont listées et décrites dans la RFC 2616 <http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9>. D'ailleurs, ce que je dis, y est exposé en moins extrémiste :
« In particular, the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered "safe". This allows user agents to represent other methods, such as POST, PUT and DELETE, in a special way, so that the user is made aware of the fact that a possibly unsafe action is being requested. »
La seule différence majeure entre ce que j'affirme et ce que déclare le RFC, c'est je dis MUST NOT plutôt que SHOULD NOT. Ceci signifie simplement que GET ne devrait pas être utilisé pour modifier des données.
Cependant je pense que cet usage devrait être bannit de nos habitudes pour des problèmes évidents (enfin, pas tant que ça visiblement :p ) de sécurité.
Le protocole HTTP prévoie donc que la méthode GET ne devrait être utilisée que pour requérir des données, et non les modifier. Car la méthode GET ne requiert pas d'action explicite de l'utilisateur.
Le 10/04/2009 23:43, Mickael Wolff répondait à mpg :
je n'arrive pas à voir en quoi l'un représente des « données d'alteration » et l'autre « de consultation ». Peux-tu détailler ce qui se cache derrière ces deux mots ?
GET se traduit par « prendre » (consultation) POST peut se traduire par « soumettre » (altération)
Par consultation, je pense bien sûr à la lecture des données. Par altération, je considère l'ajout, la modification et la suppression d'une ressource (un article, un contact, etc).
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).
Les méthodes existantes sont listées et décrites dans la RFC 2616 <http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9>. D'ailleurs, ce que je dis, y est exposé en moins extrémiste :
« In particular, the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered "safe". This allows user agents to represent other methods, such as POST, PUT and DELETE, in a special way, so that the user is made aware of the fact that a possibly unsafe action is being requested. »
Ici, il s'agit des types de requêtes (GET, HEAD, POST, PUT et DELETE), pas des types de transmission de données (ceux que PHP appelle $_GET et $_POST).
La seule différence majeure entre ce que j'affirme et ce que déclare le RFC, c'est je dis MUST NOT plutôt que SHOULD NOT. Ceci signifie simplement que GET ne devrait pas être utilisé pour modifier des données.
Àmha, la différence majeure est surtout que la discussion était sur le canal de transmission des données, absolument pas sur le type de requête.
Cependant je pense que cet usage devrait être bannit de nos habitudes pour des problèmes évidents (enfin, pas tant que ça visiblement :p ) de sécurité.
Tu as raison : visiblement il n'est pas si évident de distinguer le type de requête du type de transmission des données. Tu es bien excusable, cela dit, tant il est vrai que $_GET/$_POST font penser à GET/POST.
Le protocole HTTP prévoie donc que la méthode GET ne devrait être utilisée que pour requérir des données, et non les modifier. Car la méthode GET ne requiert pas d'action explicite de l'utilisateur.
Nous sommes d'accord. Un bon concepteur programmera donc une méthode GET pour requérir des données et une méthode POST pour les modifier. Mieux : il prévoiera de transmettre les données dans $_GET quand il programme une requête GET (paramètres dans l'URL), et dans $_POST quand il prévoit une requête POST (par un formulaire).
*MAIS* il ne doit pas avoir besoin de vérifier par quel canal l'informa- tion a été transmise pour assurer sa sécurité. La sécurité doit être assurée par les valeurs elles-mêmes et non par le mode de transmission. Si vérifier le canal de transmission est nécessaire pour assurer la sécurité, alors c'est que la sécurité est intrinsèquement mauvaise et qu'il faut faire autrement (cas du delete que tu me donnais en exemple dans un autre article).
En effet, si un attaquant est capable d'amener une victime à faire un GET donné, ou un POST donné avec variables dans $_GET, alors il pourrait tout aussi bien amener une victime (la même ou une autre) à faire un POST avec toutes ces données dans $_POST. Et si l'attaquant sait quelles valeurs mettre pour faire une opération non voulue (comme un delete dans une base de données), c'est que la sécurité est mauvaise au départ.
Bonjour
Le 10/04/2009 23:43, Mickael Wolff répondait à mpg :
je n'arrive pas à
voir en quoi l'un représente des « données d'alteration » et l'autre « de
consultation ». Peux-tu détailler ce qui se cache derrière ces deux mots ?
GET se traduit par « prendre » (consultation)
POST peut se traduire par « soumettre » (altération)
Par consultation, je pense bien sûr à la lecture des données. Par
altération, je considère l'ajout, la modification et la suppression
d'une ressource (un article, un contact, etc).
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).
Les méthodes existantes sont listées et décrites dans la RFC 2616
<http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9>.
D'ailleurs, ce que je dis, y est exposé en moins extrémiste :
« In particular, the convention has been established that the GET and
HEAD methods SHOULD NOT have the significance of taking an action other
than retrieval. These methods ought to be considered "safe". This allows
user agents to represent other methods, such as POST, PUT and DELETE, in
a special way, so that the user is made aware of the fact that a
possibly unsafe action is being requested. »
Ici, il s'agit des types de requêtes (GET, HEAD, POST, PUT et DELETE),
pas des types de transmission de données (ceux que PHP appelle $_GET et
$_POST).
La seule différence majeure entre ce que j'affirme et ce que déclare
le RFC, c'est je dis MUST NOT plutôt que SHOULD NOT. Ceci signifie
simplement que GET ne devrait pas être utilisé pour modifier des données.
Àmha, la différence majeure est surtout que la discussion était sur
le canal de transmission des données, absolument pas sur le type de requête.
Cependant je pense que cet usage devrait être bannit de nos habitudes
pour des problèmes évidents (enfin, pas tant que ça visiblement :p ) de
sécurité.
Tu as raison : visiblement il n'est pas si évident de distinguer le type
de requête du type de transmission des données. Tu es bien excusable,
cela dit, tant il est vrai que $_GET/$_POST font penser à GET/POST.
Le protocole HTTP prévoie donc que la méthode GET ne devrait être
utilisée que pour requérir des données, et non les modifier. Car la
méthode GET ne requiert pas d'action explicite de l'utilisateur.
Nous sommes d'accord. Un bon concepteur programmera donc une méthode GET
pour requérir des données et une méthode POST pour les modifier. Mieux :
il prévoiera de transmettre les données dans $_GET quand il programme
une requête GET (paramètres dans l'URL), et dans $_POST quand il prévoit
une requête POST (par un formulaire).
*MAIS* il ne doit pas avoir besoin de vérifier par quel canal l'informa-
tion a été transmise pour assurer sa sécurité. La sécurité doit être
assurée par les valeurs elles-mêmes et non par le mode de transmission.
Si vérifier le canal de transmission est nécessaire pour assurer la
sécurité, alors c'est que la sécurité est intrinsèquement mauvaise et
qu'il faut faire autrement (cas du delete que tu me donnais en exemple
dans un autre article).
En effet, si un attaquant est capable d'amener une victime à faire un
GET donné, ou un POST donné avec variables dans $_GET, alors il pourrait
tout aussi bien amener une victime (la même ou une autre) à faire un
POST avec toutes ces données dans $_POST. Et si l'attaquant sait quelles
valeurs mettre pour faire une opération non voulue (comme un delete dans
une base de données), c'est que la sécurité est mauvaise au départ.
Le 10/04/2009 23:43, Mickael Wolff répondait à mpg :
je n'arrive pas à voir en quoi l'un représente des « données d'alteration » et l'autre « de consultation ». Peux-tu détailler ce qui se cache derrière ces deux mots ?
GET se traduit par « prendre » (consultation) POST peut se traduire par « soumettre » (altération)
Par consultation, je pense bien sûr à la lecture des données. Par altération, je considère l'ajout, la modification et la suppression d'une ressource (un article, un contact, etc).
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).
Les méthodes existantes sont listées et décrites dans la RFC 2616 <http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9>. D'ailleurs, ce que je dis, y est exposé en moins extrémiste :
« In particular, the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered "safe". This allows user agents to represent other methods, such as POST, PUT and DELETE, in a special way, so that the user is made aware of the fact that a possibly unsafe action is being requested. »
Ici, il s'agit des types de requêtes (GET, HEAD, POST, PUT et DELETE), pas des types de transmission de données (ceux que PHP appelle $_GET et $_POST).
La seule différence majeure entre ce que j'affirme et ce que déclare le RFC, c'est je dis MUST NOT plutôt que SHOULD NOT. Ceci signifie simplement que GET ne devrait pas être utilisé pour modifier des données.
Àmha, la différence majeure est surtout que la discussion était sur le canal de transmission des données, absolument pas sur le type de requête.
Cependant je pense que cet usage devrait être bannit de nos habitudes pour des problèmes évidents (enfin, pas tant que ça visiblement :p ) de sécurité.
Tu as raison : visiblement il n'est pas si évident de distinguer le type de requête du type de transmission des données. Tu es bien excusable, cela dit, tant il est vrai que $_GET/$_POST font penser à GET/POST.
Le protocole HTTP prévoie donc que la méthode GET ne devrait être utilisée que pour requérir des données, et non les modifier. Car la méthode GET ne requiert pas d'action explicite de l'utilisateur.
Nous sommes d'accord. Un bon concepteur programmera donc une méthode GET pour requérir des données et une méthode POST pour les modifier. Mieux : il prévoiera de transmettre les données dans $_GET quand il programme une requête GET (paramètres dans l'URL), et dans $_POST quand il prévoit une requête POST (par un formulaire).
*MAIS* il ne doit pas avoir besoin de vérifier par quel canal l'informa- tion a été transmise pour assurer sa sécurité. La sécurité doit être assurée par les valeurs elles-mêmes et non par le mode de transmission. Si vérifier le canal de transmission est nécessaire pour assurer la sécurité, alors c'est que la sécurité est intrinsèquement mauvaise et qu'il faut faire autrement (cas du delete que tu me donnais en exemple dans un autre article).
En effet, si un attaquant est capable d'amener une victime à faire un GET donné, ou un POST donné avec variables dans $_GET, alors il pourrait tout aussi bien amener une victime (la même ou une autre) à faire un POST avec toutes ces données dans $_POST. Et si l'attaquant sait quelles valeurs mettre pour faire une opération non voulue (comme un delete dans une base de données), c'est que la sécurité est mauvaise au départ.
Sylvain SF
Mickael Wolff a écrit :
Les méthodes existantes sont listées et décrites dans la RFC 2616
les méthodes, quelles méthodes ?? celles de la construction d'une URL (au niveau applicatif) ou celles du fonctionnement du serveur ?
si cette RFC répondait au problème débattu ici, tu aurais utilisé une commande DELETE pour effacer ta fiche 42.
« In particular, the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered "safe". This allows user agents to represent other methods, such as POST, PUT and DELETE, in a special way, so that the user is made aware of the fact that a possibly unsafe action is being requested. »
donc après avoir affirmé que rien n'est sur ("Je pars du principe qu'aucune donnée n'est fiable." - pas même tes propres variables $_SESSION), tu t'appuies sur une prétendue "safety" pour défendre le point ?! j'ai du mal à suivre.
toute requête GET comme POST pour être forgée à fin d'attaque, l'argument est non recevable.
une différence évidente entre les protocoles GET et POST est simplement la taille maximale des données transmises.
la taille de la seule URI (donc la taille des params GET) est limité par le browser (de 2Ko (IE) à 64Ko (FireFox) ou plus) et par le serveur (+/- 4Ko pour Apache); la taille des params POST est (virtuellement illimité).
donc oui, il fait sens de "demander" (GET) la fiche 42 via un GET, et il fait sens de transmettre le contenu de cette fiche (pour stockage sur serveur) via un POST (les exemples du § 9.5 de RFC 2616 ne montrent rien d'autre que des opérations "volumineuses").
le choix du protocole GET ou POST n'est donc que motivé par les tailles d'échanges supportées, en aucun cas par de pseudo-sécurités, en aucun cas par des traductions opportunistes.
Le protocole HTTP prévoie donc que la méthode GET ne devrait être utilisée que pour requérir des données, et non les modifier.
du fait de la taille des arguments transmis. et pratiquement, du fait que les arguments POST peuvent être lus par bloc, spoolés, etc, alors que l'URL GET doit être entièrement reçue pour invoquer le bon script, accéder au bon fichier.
Car la méthode GET ne requiert pas d'action explicite de l'utilisateur.
de quelle action parles-tu ? cliquer sur un lien (GET) est aussi explicite que de cliquer sur un bouton (d'un FORM POST).
Sylvain.
Mickael Wolff a écrit :
Les méthodes existantes sont listées et décrites dans la RFC 2616
les méthodes, quelles méthodes ?? celles de la construction d'une URL
(au niveau applicatif) ou celles du fonctionnement du serveur ?
si cette RFC répondait au problème débattu ici, tu aurais utilisé une
commande DELETE pour effacer ta fiche 42.
« In particular, the convention has been established that the GET and
HEAD methods SHOULD NOT have the significance of taking an action other
than retrieval. These methods ought to be considered "safe". This allows
user agents to represent other methods, such as POST, PUT and DELETE, in
a special way, so that the user is made aware of the fact that a
possibly unsafe action is being requested. »
donc après avoir affirmé que rien n'est sur ("Je pars du principe
qu'aucune donnée n'est fiable." - pas même tes propres variables
$_SESSION), tu t'appuies sur une prétendue "safety" pour défendre
le point ?! j'ai du mal à suivre.
toute requête GET comme POST pour être forgée à fin d'attaque,
l'argument est non recevable.
une différence évidente entre les protocoles GET et POST est simplement
la taille maximale des données transmises.
la taille de la seule URI (donc la taille des params GET) est limité
par le browser (de 2Ko (IE) à 64Ko (FireFox) ou plus) et par le serveur
(+/- 4Ko pour Apache); la taille des params POST est (virtuellement
illimité).
donc oui, il fait sens de "demander" (GET) la fiche 42 via un GET, et
il fait sens de transmettre le contenu de cette fiche (pour stockage
sur serveur) via un POST (les exemples du § 9.5 de RFC 2616 ne montrent
rien d'autre que des opérations "volumineuses").
le choix du protocole GET ou POST n'est donc que motivé par les tailles
d'échanges supportées, en aucun cas par de pseudo-sécurités, en aucun
cas par des traductions opportunistes.
Le protocole HTTP prévoie donc que la méthode GET ne devrait être
utilisée que pour requérir des données, et non les modifier.
du fait de la taille des arguments transmis.
et pratiquement, du fait que les arguments POST peuvent être lus
par bloc, spoolés, etc, alors que l'URL GET doit être entièrement
reçue pour invoquer le bon script, accéder au bon fichier.
Car la méthode GET ne requiert pas d'action explicite de l'utilisateur.
de quelle action parles-tu ? cliquer sur un lien (GET) est aussi
explicite que de cliquer sur un bouton (d'un FORM POST).
Les méthodes existantes sont listées et décrites dans la RFC 2616
les méthodes, quelles méthodes ?? celles de la construction d'une URL (au niveau applicatif) ou celles du fonctionnement du serveur ?
si cette RFC répondait au problème débattu ici, tu aurais utilisé une commande DELETE pour effacer ta fiche 42.
« In particular, the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered "safe". This allows user agents to represent other methods, such as POST, PUT and DELETE, in a special way, so that the user is made aware of the fact that a possibly unsafe action is being requested. »
donc après avoir affirmé que rien n'est sur ("Je pars du principe qu'aucune donnée n'est fiable." - pas même tes propres variables $_SESSION), tu t'appuies sur une prétendue "safety" pour défendre le point ?! j'ai du mal à suivre.
toute requête GET comme POST pour être forgée à fin d'attaque, l'argument est non recevable.
une différence évidente entre les protocoles GET et POST est simplement la taille maximale des données transmises.
la taille de la seule URI (donc la taille des params GET) est limité par le browser (de 2Ko (IE) à 64Ko (FireFox) ou plus) et par le serveur (+/- 4Ko pour Apache); la taille des params POST est (virtuellement illimité).
donc oui, il fait sens de "demander" (GET) la fiche 42 via un GET, et il fait sens de transmettre le contenu de cette fiche (pour stockage sur serveur) via un POST (les exemples du § 9.5 de RFC 2616 ne montrent rien d'autre que des opérations "volumineuses").
le choix du protocole GET ou POST n'est donc que motivé par les tailles d'échanges supportées, en aucun cas par de pseudo-sécurités, en aucun cas par des traductions opportunistes.
Le protocole HTTP prévoie donc que la méthode GET ne devrait être utilisée que pour requérir des données, et non les modifier.
du fait de la taille des arguments transmis. et pratiquement, du fait que les arguments POST peuvent être lus par bloc, spoolés, etc, alors que l'URL GET doit être entièrement reçue pour invoquer le bon script, accéder au bon fichier.
Car la méthode GET ne requiert pas d'action explicite de l'utilisateur.
de quelle action parles-tu ? cliquer sur un lien (GET) est aussi explicite que de cliquer sur un bouton (d'un FORM POST).
Sylvain.
Olivier Miakinen
Le 10/04/2009 23:43, Mickael Wolff répondait à Patrick Mevzek :
Le problème du register_global est de fusionner deux contextes qui n'ont rien à voir : celui de l'environnement Web (les échanges avec le client) et celui de l'intérieur du programme (les variables)
Le jet des variables HTTP dans le scope global n'était pas le problème. Personnelement, hormis dans les script simples d'apprentissage, je ne vois pas comment on peut sérieusement utiliser les variables globales dans ces fonctions. Dans les cursus de formation des développeurs, les variables globales sont toujours présentées comme l'une des plaies de la programmation, au côté de goto.
Euh... quoique vous ayez (à mon avis) raison tous les deux, tu parles d'une chose qui n'a rien à voir avec ce dont parle Patrick. En effet, Patrick parle des variables globales dans le *programme* alors que toi tu parles des variables globales dans les *fonctions*.
(Au passage, $_POST, $_GET et $_REQUEST sont « superglobales », et elles sont donc visibles aussi bien dans les fonctions qu'en dehors, mais c'est encore un troisième point qui n'a que peu à voir avec les deux premiers.)
$_REQUEST fusionne $_GET et $_POST (entre autres) mais ils sont par essence dans le *même* contexte (celui du web, c'est à dire contenu non sûr provenant de l'utilisateur), donc leur fusion ne créé pas de problème supplémentaire de sécurité.
Je pars du principe qu'aucune donnée n'est fiable. Quelle que soit ça provenance, même si les données provenant de sources considérées comme sûres doivent être considérées comme compromises :D Mais c'est un point de vu paranoïaque.
Vous êtes encore d'accord tous les deux. Mais justement tu apportes de l'eau à notre moulin : puisque aucune donnée n'est fiable, il faut toujours vérifier la valeur de chacune d'entre elles, quelle que soit sa provenance. Vérifier un jeton à usage unique de 128 bits, par exemple, est ainsi beaucoup plus utile que de vérifier si le jeton a été mis dans $_GET ou $_POST.
Maintenant je regrète : les contextes POST, GET et COOKIE sont différents. Qu'ils proviennent de la même source ne permettent pas de les considérer comme équivalent.
Pourquoi cela ? Ils proviennent de la même source, et sont donc aussi peu fiables en passant par $_POST que par $_GET. Si tu considères que vérifier le passage par $_POST est nécessaire pour la sécurité, c'est que tu n'as pas un bon moyen pour vérifier la sécurité par ailleurs (par exemple un jeton à usage unique).
[...]
Oui, mais pas pour la raison que vous évoquez.
J'évoque deux raisons. La sémantique et la sécurité. Elles sont liées, certes, mais importantes.
La sémantique, c'est ce qui fait qu'un programmeur choisira tantôt une URL (et donc un GET avec données passant par $_GET) tantôt un formulaire (en POST avec données passant par $_POST).
La sécurité, c'est vérifier les valeurs reçues, celles-ci permettant d'avoir une assurance raisonnable (proportionnée aux dommages possibles) qu'un attaquant n'a pas forgé une requête à la place de l'utilisateur.
Alors certes, l'utilisateur honnête enverra bien un GET si tu as prévu un GET et un POST si tu as prévu un POST. Mais l'attaquant, s'il peut forger un GET là où tu attends un POST, pourrait aussi bien forger un POST avec les mêmes données. Du coup, tu peux bien vérifier ce point particulier si ça te chante, mais il ne faut pas l'ériger en principe de sécurité car ce n'en est pas un.
[...] j'utilises tout de même $_POST et $_GET pour distinguer la provenance des instructions. Simplement parce qu'une application complexe peut requérir l'accès à une ressource ne même temps que la modification d'une autre.
... et donc avoir besoin à la fois de $_POST['truc'] et $_GET['truc'] ? Je ne donnerai pas d'avis sur cette méthode, juste que si vraiment le programmeur veut faire ça il *peut* utiliser à la fois $_GET et $_POST mais que ça n'a strictement rien à voir avec la sécurité.
Mais aussi parce que l'ordre d'importation des contextes est configurable, il n'y a aucune garantie de fonctionnement alors.
Idem. Personnellement je sais que j'éviterais à tout prix d'avoir deux valeurs de même nom parmi $_GET['truc'], $_POST['truc'] et $_COOKIE['truc'] car ce serait vraiment casse-gueule et une grosse source possible de bugs.
[...]
D'ailleurs, j'espère que $_REQUEST disparaîtra un jour !
C'est le genre de paravent de mesure de sécurité. Supprimer $_REQUEST n'augmentera en rien la sécurité des applications. Au contraire, un "faux" sentiment de sécurité est bien pire selon moi que pas de sécurité du tout, mais clairement avouée.
C'est vrai que de supprimer register_global est un paravent ;)
Ahem... merci de reconnaître que cet argument est de la pure mauvaise foi ! Utiliser $_REQUEST au lieu de $_GET et $_POST ne permet pas à des variables de se glisser dans le contexte global à l'insu du programmeur.
Le 10/04/2009 23:43, Mickael Wolff répondait à Patrick Mevzek :
Le problème du register_global est de fusionner deux contextes qui n'ont
rien à voir : celui de l'environnement Web (les échanges avec le client)
et celui de l'intérieur du programme (les variables)
Le jet des variables HTTP dans le scope global n'était pas le
problème. Personnelement, hormis dans les script simples
d'apprentissage, je ne vois pas comment on peut sérieusement utiliser
les variables globales dans ces fonctions. Dans les cursus de formation
des développeurs, les variables globales sont toujours présentées comme
l'une des plaies de la programmation, au côté de goto.
Euh... quoique vous ayez (à mon avis) raison tous les deux, tu parles
d'une chose qui n'a rien à voir avec ce dont parle Patrick. En effet,
Patrick parle des variables globales dans le *programme* alors que toi
tu parles des variables globales dans les *fonctions*.
(Au passage, $_POST, $_GET et $_REQUEST sont « superglobales », et elles
sont donc visibles aussi bien dans les fonctions qu'en dehors, mais
c'est encore un troisième point qui n'a que peu à voir avec les deux
premiers.)
$_REQUEST fusionne $_GET et $_POST (entre autres) mais ils sont par
essence dans le *même* contexte (celui du web, c'est à dire contenu non
sûr provenant de l'utilisateur), donc leur fusion ne créé pas de problème
supplémentaire de sécurité.
Je pars du principe qu'aucune donnée n'est fiable. Quelle que soit ça
provenance, même si les données provenant de sources considérées comme
sûres doivent être considérées comme compromises :D Mais c'est un point
de vu paranoïaque.
Vous êtes encore d'accord tous les deux. Mais justement tu apportes de
l'eau à notre moulin : puisque aucune donnée n'est fiable, il faut
toujours vérifier la valeur de chacune d'entre elles, quelle que soit sa
provenance. Vérifier un jeton à usage unique de 128 bits, par exemple,
est ainsi beaucoup plus utile que de vérifier si le jeton a été mis dans
$_GET ou $_POST.
Maintenant je regrète : les contextes POST, GET et COOKIE sont
différents. Qu'ils proviennent de la même source ne permettent pas de
les considérer comme équivalent.
Pourquoi cela ? Ils proviennent de la même source, et sont donc aussi
peu fiables en passant par $_POST que par $_GET. Si tu considères que
vérifier le passage par $_POST est nécessaire pour la sécurité, c'est
que tu n'as pas un bon moyen pour vérifier la sécurité par ailleurs (par
exemple un jeton à usage unique).
[...]
Oui, mais pas pour la raison que vous évoquez.
J'évoque deux raisons. La sémantique et la sécurité. Elles sont
liées, certes, mais importantes.
La sémantique, c'est ce qui fait qu'un programmeur choisira tantôt une
URL (et donc un GET avec données passant par $_GET) tantôt un formulaire
(en POST avec données passant par $_POST).
La sécurité, c'est vérifier les valeurs reçues, celles-ci permettant
d'avoir une assurance raisonnable (proportionnée aux dommages possibles)
qu'un attaquant n'a pas forgé une requête à la place de l'utilisateur.
Alors certes, l'utilisateur honnête enverra bien un GET si tu as prévu
un GET et un POST si tu as prévu un POST. Mais l'attaquant, s'il peut
forger un GET là où tu attends un POST, pourrait aussi bien forger un
POST avec les mêmes données. Du coup, tu peux bien vérifier ce point
particulier si ça te chante, mais il ne faut pas l'ériger en principe
de sécurité car ce n'en est pas un.
[...] j'utilises tout de même $_POST et $_GET pour distinguer
la provenance des instructions. Simplement parce qu'une application
complexe peut requérir l'accès à une ressource ne même temps que la
modification d'une autre.
... et donc avoir besoin à la fois de $_POST['truc'] et $_GET['truc'] ?
Je ne donnerai pas d'avis sur cette méthode, juste que si vraiment le
programmeur veut faire ça il *peut* utiliser à la fois $_GET et $_POST
mais que ça n'a strictement rien à voir avec la sécurité.
Mais aussi parce que l'ordre d'importation des
contextes est configurable, il n'y a aucune garantie de fonctionnement
alors.
Idem. Personnellement je sais que j'éviterais à tout prix d'avoir
deux valeurs de même nom parmi $_GET['truc'], $_POST['truc'] et
$_COOKIE['truc'] car ce serait vraiment casse-gueule et une grosse
source possible de bugs.
[...]
D'ailleurs, j'espère que $_REQUEST disparaîtra un jour !
C'est le genre de paravent de mesure de sécurité. Supprimer $_REQUEST
n'augmentera en rien la sécurité des applications. Au contraire, un
"faux" sentiment de sécurité est bien pire selon moi que pas de sécurité
du tout, mais clairement avouée.
C'est vrai que de supprimer register_global est un paravent ;)
Ahem... merci de reconnaître que cet argument est de la pure mauvaise
foi ! Utiliser $_REQUEST au lieu de $_GET et $_POST ne permet pas à des
variables de se glisser dans le contexte global à l'insu du programmeur.
Le 10/04/2009 23:43, Mickael Wolff répondait à Patrick Mevzek :
Le problème du register_global est de fusionner deux contextes qui n'ont rien à voir : celui de l'environnement Web (les échanges avec le client) et celui de l'intérieur du programme (les variables)
Le jet des variables HTTP dans le scope global n'était pas le problème. Personnelement, hormis dans les script simples d'apprentissage, je ne vois pas comment on peut sérieusement utiliser les variables globales dans ces fonctions. Dans les cursus de formation des développeurs, les variables globales sont toujours présentées comme l'une des plaies de la programmation, au côté de goto.
Euh... quoique vous ayez (à mon avis) raison tous les deux, tu parles d'une chose qui n'a rien à voir avec ce dont parle Patrick. En effet, Patrick parle des variables globales dans le *programme* alors que toi tu parles des variables globales dans les *fonctions*.
(Au passage, $_POST, $_GET et $_REQUEST sont « superglobales », et elles sont donc visibles aussi bien dans les fonctions qu'en dehors, mais c'est encore un troisième point qui n'a que peu à voir avec les deux premiers.)
$_REQUEST fusionne $_GET et $_POST (entre autres) mais ils sont par essence dans le *même* contexte (celui du web, c'est à dire contenu non sûr provenant de l'utilisateur), donc leur fusion ne créé pas de problème supplémentaire de sécurité.
Je pars du principe qu'aucune donnée n'est fiable. Quelle que soit ça provenance, même si les données provenant de sources considérées comme sûres doivent être considérées comme compromises :D Mais c'est un point de vu paranoïaque.
Vous êtes encore d'accord tous les deux. Mais justement tu apportes de l'eau à notre moulin : puisque aucune donnée n'est fiable, il faut toujours vérifier la valeur de chacune d'entre elles, quelle que soit sa provenance. Vérifier un jeton à usage unique de 128 bits, par exemple, est ainsi beaucoup plus utile que de vérifier si le jeton a été mis dans $_GET ou $_POST.
Maintenant je regrète : les contextes POST, GET et COOKIE sont différents. Qu'ils proviennent de la même source ne permettent pas de les considérer comme équivalent.
Pourquoi cela ? Ils proviennent de la même source, et sont donc aussi peu fiables en passant par $_POST que par $_GET. Si tu considères que vérifier le passage par $_POST est nécessaire pour la sécurité, c'est que tu n'as pas un bon moyen pour vérifier la sécurité par ailleurs (par exemple un jeton à usage unique).
[...]
Oui, mais pas pour la raison que vous évoquez.
J'évoque deux raisons. La sémantique et la sécurité. Elles sont liées, certes, mais importantes.
La sémantique, c'est ce qui fait qu'un programmeur choisira tantôt une URL (et donc un GET avec données passant par $_GET) tantôt un formulaire (en POST avec données passant par $_POST).
La sécurité, c'est vérifier les valeurs reçues, celles-ci permettant d'avoir une assurance raisonnable (proportionnée aux dommages possibles) qu'un attaquant n'a pas forgé une requête à la place de l'utilisateur.
Alors certes, l'utilisateur honnête enverra bien un GET si tu as prévu un GET et un POST si tu as prévu un POST. Mais l'attaquant, s'il peut forger un GET là où tu attends un POST, pourrait aussi bien forger un POST avec les mêmes données. Du coup, tu peux bien vérifier ce point particulier si ça te chante, mais il ne faut pas l'ériger en principe de sécurité car ce n'en est pas un.
[...] j'utilises tout de même $_POST et $_GET pour distinguer la provenance des instructions. Simplement parce qu'une application complexe peut requérir l'accès à une ressource ne même temps que la modification d'une autre.
... et donc avoir besoin à la fois de $_POST['truc'] et $_GET['truc'] ? Je ne donnerai pas d'avis sur cette méthode, juste que si vraiment le programmeur veut faire ça il *peut* utiliser à la fois $_GET et $_POST mais que ça n'a strictement rien à voir avec la sécurité.
Mais aussi parce que l'ordre d'importation des contextes est configurable, il n'y a aucune garantie de fonctionnement alors.
Idem. Personnellement je sais que j'éviterais à tout prix d'avoir deux valeurs de même nom parmi $_GET['truc'], $_POST['truc'] et $_COOKIE['truc'] car ce serait vraiment casse-gueule et une grosse source possible de bugs.
[...]
D'ailleurs, j'espère que $_REQUEST disparaîtra un jour !
C'est le genre de paravent de mesure de sécurité. Supprimer $_REQUEST n'augmentera en rien la sécurité des applications. Au contraire, un "faux" sentiment de sécurité est bien pire selon moi que pas de sécurité du tout, mais clairement avouée.
C'est vrai que de supprimer register_global est un paravent ;)
Ahem... merci de reconnaître que cet argument est de la pure mauvaise foi ! Utiliser $_REQUEST au lieu de $_GET et $_POST ne permet pas à des variables de se glisser dans le contexte global à l'insu du programmeur.
Patrick Mevzek
Le Fri, 10 Apr 2009 21:43:56 +0000, Mickael Wolff a écrit:
Le problème du register_global est de fusionner deux contextes qui n'ont rien à voir : celui de l'environnement Web (les échanges avec le client) et celui de l'intérieur du programme (les variables)
Le jet des variables HTTP dans le scope global n'était pas le problème.
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 ?
Personnelement, hormis dans les script simples d'apprentissage, je ne vois pas comment on peut sérieusement utiliser les variables globales dans ces fonctions. Dans les cursus de formation des développeurs, les variables globales sont toujours présentées comme l'une des plaies de la programmation, au côté de goto.
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é)
$_REQUEST fusionne $_GET et $_POST (entre autres) mais ils sont par essence dans le *même* contexte (celui du web, c'est à dire contenu non sûr provenant de l'utilisateur), donc leur fusion ne créé pas de problème supplémentaire de sécurité.
Je pars du principe qu'aucune donnée n'est fiable. Quelle que soit ça provenance, même si les données provenant de sources considérées comme sûres doivent être considérées comme compromises :D Mais c'est un point de vu paranoïaque.
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é).
Maintenant je regrète : les contextes POST, GET et COOKIE sont différents. Qu'ils proviennent de la même source ne permettent pas de les considérer comme équivalent. Pourtant tu devrais le savoir, tu n'es pas un abruti, mais je pense que tu n'as jamais observé la gueule d'une requête. Si ces trois contextes étaient interchangeables, pourquoi sont-ils séparés, et pourquoi leur sémantique (et donc leur comportement) est-il si différent ?
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.
Parce que le simple fait de changer un GET en POST ou le contraire faisait 'planter' l'application ? Bah alors là le problème est ailleurs et il me semble qu'on a discuté de cela récemment.
Mais alors où est-il ? Si on ne peut plus distinguer les données saisies en POST et en GET ?
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).
Alors certes, pour vérifier que j'ai reçu une requête POST je vérifie la clé 'REQUEST_METHOD' de la superglobale $_SERVER, mais j'utilises tout de même $_POST et $_GET pour distinguer la provenance des instructions. Simplement parce qu'une application complexe peut requérir l'accès à une ressource ne même temps que la modification d'une autre.
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é ?
Mais aussi parce que l'ordre d'importation des contextes est configurable, il n'y a aucune garantie de fonctionnement alors.
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 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).
Et puis si on veut blinder 1) on se refaire son $_REQUEST à soi avec import_request_variables() avec un prefix non vide évidemment ou 2) on assure, dans un .htaccess ou équivalent que variables_order est positionné sainement.
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 :-)
En fait, avant d'utiliser $_REQUEST, tu vérifie la valeur de la variable $_SERVER['REQUEST_METHOD'] ? Et finalement, lorsque tu es en 'POST' tu ignores les paramètres GET (donc en partie l'URL) ?
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.
Par exemple OsCommerce, Wordpress, Dotclear, etc. C'est pourquoi je considère inconcevable qu'on puisse conseiller l'usage de $_REQUEST à un débutant.
C'est tout à fait concevable et c'est même la bonne façon de faire. Toutes les bonnes APIs de tous les langages de programmation offrent une interface identique que l'on soit en GET en POST (tout en étant capable de discriminer bien sûr quand on en a besoin), ce qui illustre bien que le problème n'est pas là.
Tu as des noms d'API ? Ça m'intéresse en C++ ;)
Pas d'expérience directe, mais après une recherche je tombe sur http://rudeserver.com/cgiparser/usage.html et manifestement j'infère de cgi["color"] que ca sera toujours ca quelle que soit la méthode (mais je peux me tromper, je n'ai pas lu toute la documentation).
Après je ne connais pas toutes les API C++, certaines font peut-être comme PHP en séparant, d'autres non.
D'ailleurs, j'espère que $_REQUEST dispara^itra un jour !
C'est le genre de paravent de mesure de sécurité. Supprimer $_REQUEST n'augmentera en rien la sécurité des applications. Au contraire, un "faux" sentiment de sécurité est bien pire selon moi que pas de sécurité du tout, mais clairement avouée.
C'est vrai que de supprimer register_global est un paravent ;)
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 ;-)
-- 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 Fri, 10 Apr 2009 21:43:56 +0000, Mickael Wolff a écrit:
Le problème du register_global est de fusionner deux contextes qui
n'ont rien à voir : celui de l'environnement Web (les échanges avec le
client) et celui de l'intérieur du programme (les variables)
Le jet des variables HTTP dans le scope global n'était pas le
problème.
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 ?
Personnelement, hormis dans les script simples
d'apprentissage, je ne vois pas comment on peut sérieusement utiliser
les variables globales dans ces fonctions. Dans les cursus de formation
des développeurs, les variables globales sont toujours présentées comme
l'une des plaies de la programmation, au côté de goto.
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é)
$_REQUEST fusionne $_GET et $_POST (entre autres) mais ils sont par
essence dans le *même* contexte (celui du web, c'est à dire contenu non
sûr provenant de l'utilisateur), donc leur fusion ne créé pas de
problème supplémentaire de sécurité.
Je pars du principe qu'aucune donnée n'est fiable. Quelle que soit ça
provenance, même si les données provenant de sources considérées comme
sûres doivent être considérées comme compromises :D Mais c'est un point
de vu paranoïaque.
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é).
Maintenant je regrète : les contextes POST, GET et COOKIE sont
différents. Qu'ils proviennent de la même source ne permettent pas de
les considérer comme équivalent. Pourtant tu devrais le savoir, tu n'es
pas un abruti, mais je pense que tu n'as jamais observé la gueule d'une
requête. Si ces trois contextes étaient interchangeables, pourquoi
sont-ils séparés, et pourquoi leur sémantique (et donc leur
comportement) est-il si différent ?
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.
Parce que le simple fait de changer un GET en POST ou le contraire
faisait 'planter' l'application ? Bah alors là le problème est ailleurs
et il me semble qu'on a discuté de cela récemment.
Mais alors où est-il ? Si on ne peut plus distinguer les données
saisies en POST et en GET ?
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).
Alors certes, pour vérifier que j'ai reçu
une requête POST je vérifie la clé 'REQUEST_METHOD' de la superglobale
$_SERVER, mais j'utilises tout de même $_POST et $_GET pour distinguer
la provenance des instructions. Simplement parce qu'une application
complexe peut requérir l'accès à une ressource ne même temps que la
modification d'une autre.
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é ?
Mais aussi parce que l'ordre d'importation des
contextes est configurable, il n'y a aucune garantie de fonctionnement
alors.
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
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).
Et puis si on veut blinder
1) on se refaire son $_REQUEST à soi avec import_request_variables()
avec un prefix non vide évidemment
ou
2) on assure, dans un .htaccess ou équivalent que variables_order est
positionné sainement.
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 :-)
En fait, avant d'utiliser $_REQUEST, tu vérifie la valeur de la
variable $_SERVER['REQUEST_METHOD'] ? Et finalement, lorsque tu es en
'POST' tu ignores les paramètres GET (donc en partie l'URL) ?
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.
Par exemple OsCommerce,
Wordpress, Dotclear, etc. C'est pourquoi je considère inconcevable
qu'on puisse conseiller l'usage de $_REQUEST à un débutant.
C'est tout à fait concevable et c'est même la bonne façon de faire.
Toutes les bonnes APIs de tous les langages de programmation offrent
une interface identique que l'on soit en GET en POST (tout en étant
capable de discriminer bien sûr quand on en a besoin), ce qui illustre
bien que le problème n'est pas là.
Tu as des noms d'API ? Ça m'intéresse en C++ ;)
Pas d'expérience directe, mais après une recherche je tombe sur
http://rudeserver.com/cgiparser/usage.html
et manifestement j'infère de
cgi["color"]
que ca sera toujours ca quelle que soit la méthode
(mais je peux me tromper, je n'ai pas lu toute la documentation).
Après je ne connais pas toutes les API C++, certaines font peut-être
comme PHP en séparant, d'autres non.
D'ailleurs, j'espère que $_REQUEST dispara^itra un jour !
C'est le genre de paravent de mesure de sécurité. Supprimer $_REQUEST
n'augmentera en rien la sécurité des applications. Au contraire, un
"faux" sentiment de sécurité est bien pire selon moi que pas de
sécurité du tout, mais clairement avouée.
C'est vrai que de supprimer register_global est un paravent ;)
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 ;-)
--
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 Fri, 10 Apr 2009 21:43:56 +0000, Mickael Wolff a écrit:
Le problème du register_global est de fusionner deux contextes qui n'ont rien à voir : celui de l'environnement Web (les échanges avec le client) et celui de l'intérieur du programme (les variables)
Le jet des variables HTTP dans le scope global n'était pas le problème.
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 ?
Personnelement, hormis dans les script simples d'apprentissage, je ne vois pas comment on peut sérieusement utiliser les variables globales dans ces fonctions. Dans les cursus de formation des développeurs, les variables globales sont toujours présentées comme l'une des plaies de la programmation, au côté de goto.
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é)
$_REQUEST fusionne $_GET et $_POST (entre autres) mais ils sont par essence dans le *même* contexte (celui du web, c'est à dire contenu non sûr provenant de l'utilisateur), donc leur fusion ne créé pas de problème supplémentaire de sécurité.
Je pars du principe qu'aucune donnée n'est fiable. Quelle que soit ça provenance, même si les données provenant de sources considérées comme sûres doivent être considérées comme compromises :D Mais c'est un point de vu paranoïaque.
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é).
Maintenant je regrète : les contextes POST, GET et COOKIE sont différents. Qu'ils proviennent de la même source ne permettent pas de les considérer comme équivalent. Pourtant tu devrais le savoir, tu n'es pas un abruti, mais je pense que tu n'as jamais observé la gueule d'une requête. Si ces trois contextes étaient interchangeables, pourquoi sont-ils séparés, et pourquoi leur sémantique (et donc leur comportement) est-il si différent ?
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.
Parce que le simple fait de changer un GET en POST ou le contraire faisait 'planter' l'application ? Bah alors là le problème est ailleurs et il me semble qu'on a discuté de cela récemment.
Mais alors où est-il ? Si on ne peut plus distinguer les données saisies en POST et en GET ?
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).
Alors certes, pour vérifier que j'ai reçu une requête POST je vérifie la clé 'REQUEST_METHOD' de la superglobale $_SERVER, mais j'utilises tout de même $_POST et $_GET pour distinguer la provenance des instructions. Simplement parce qu'une application complexe peut requérir l'accès à une ressource ne même temps que la modification d'une autre.
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é ?
Mais aussi parce que l'ordre d'importation des contextes est configurable, il n'y a aucune garantie de fonctionnement alors.
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 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).
Et puis si on veut blinder 1) on se refaire son $_REQUEST à soi avec import_request_variables() avec un prefix non vide évidemment ou 2) on assure, dans un .htaccess ou équivalent que variables_order est positionné sainement.
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 :-)
En fait, avant d'utiliser $_REQUEST, tu vérifie la valeur de la variable $_SERVER['REQUEST_METHOD'] ? Et finalement, lorsque tu es en 'POST' tu ignores les paramètres GET (donc en partie l'URL) ?
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.
Par exemple OsCommerce, Wordpress, Dotclear, etc. C'est pourquoi je considère inconcevable qu'on puisse conseiller l'usage de $_REQUEST à un débutant.
C'est tout à fait concevable et c'est même la bonne façon de faire. Toutes les bonnes APIs de tous les langages de programmation offrent une interface identique que l'on soit en GET en POST (tout en étant capable de discriminer bien sûr quand on en a besoin), ce qui illustre bien que le problème n'est pas là.
Tu as des noms d'API ? Ça m'intéresse en C++ ;)
Pas d'expérience directe, mais après une recherche je tombe sur http://rudeserver.com/cgiparser/usage.html et manifestement j'infère de cgi["color"] que ca sera toujours ca quelle que soit la méthode (mais je peux me tromper, je n'ai pas lu toute la documentation).
Après je ne connais pas toutes les API C++, certaines font peut-être comme PHP en séparant, d'autres non.
D'ailleurs, j'espère que $_REQUEST dispara^itra un jour !
C'est le genre de paravent de mesure de sécurité. Supprimer $_REQUEST n'augmentera en rien la sécurité des applications. Au contraire, un "faux" sentiment de sécurité est bien pire selon moi que pas de sécurité du tout, mais clairement avouée.
C'est vrai que de supprimer register_global est un paravent ;)
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 ;-)
-- 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/>
Sylvain SF
Mickael Wolff a écrit :
Sylvain SF wrote:
tu peux expliciter ce qui te parait manquer ?
Ben la distinction entre les méthodes. Utiliser $_REQUEST revient à reproduire le comportement stupide de register_global, qui a entra^iné tant de désillusions en compromettant la sécurité des données en raison d'une erreur grave de conception.
ah ! c'est '$_REQUEST' qui t'embête !... il est nuisible et inutile (en prod.) c'est une évidence.
toutefois lorsque que tu écrivais "Il faut traiter $_GET et $_POST", je lisais $_GET *et* $_POST, or ma compréhension du protocole Internet et que cela ne peut pas être les 2 simultanément pour une même requête.
en complément du point d'Olivier, je dirais que traiter $_COOKIE, en plus des paramètres postés (en POST ou GET) n'est pas tordu, une appli web classique définira couramment son contexte global via $_COOKIE (pour des préférences globales), via $_SESSION (pour l'état logique, dont authentification, historique des étapes, etc) et $_POST *ou* $_GET (pour une requête particulière).
Sylvain.
Mickael Wolff a écrit :
Sylvain SF wrote:
tu peux expliciter ce qui te parait manquer ?
Ben la distinction entre les méthodes. Utiliser $_REQUEST revient à
reproduire le comportement stupide de register_global, qui a entra^iné
tant de désillusions en compromettant la sécurité des données en raison
d'une erreur grave de conception.
ah ! c'est '$_REQUEST' qui t'embête !... il est nuisible et inutile
(en prod.) c'est une évidence.
toutefois lorsque que tu écrivais "Il faut traiter $_GET et $_POST",
je lisais $_GET *et* $_POST, or ma compréhension du protocole Internet
et que cela ne peut pas être les 2 simultanément pour une même requête.
en complément du point d'Olivier, je dirais que traiter $_COOKIE,
en plus des paramètres postés (en POST ou GET) n'est pas tordu,
une appli web classique définira couramment son contexte global
via $_COOKIE (pour des préférences globales), via $_SESSION (pour
l'état logique, dont authentification, historique des étapes, etc)
et $_POST *ou* $_GET (pour une requête particulière).
Ben la distinction entre les méthodes. Utiliser $_REQUEST revient à reproduire le comportement stupide de register_global, qui a entra^iné tant de désillusions en compromettant la sécurité des données en raison d'une erreur grave de conception.
ah ! c'est '$_REQUEST' qui t'embête !... il est nuisible et inutile (en prod.) c'est une évidence.
toutefois lorsque que tu écrivais "Il faut traiter $_GET et $_POST", je lisais $_GET *et* $_POST, or ma compréhension du protocole Internet et que cela ne peut pas être les 2 simultanément pour une même requête.
en complément du point d'Olivier, je dirais que traiter $_COOKIE, en plus des paramètres postés (en POST ou GET) n'est pas tordu, une appli web classique définira couramment son contexte global via $_COOKIE (pour des préférences globales), via $_SESSION (pour l'état logique, dont authentification, historique des étapes, etc) et $_POST *ou* $_GET (pour une requête particulière).
Sylvain.
John GALLET
Bonjour/soir,
Etant historiquement un des premiers casse-c***lles à avoir mis les pieds dans le plat il y a bien des années, je me marre quand même de voir qu'on a toujours pas avancé d'un iota sur ce genre de querelles de clocher.
La seule différence majeure entre ce que j'affirme et ce que déclare le RFC, c'est je dis MUST NOT plutôt que SHOULD NOT. Ceci signifie simplement que GET ne devrait pas être utilisé pour modifier des données.
Ne serait-ce qu'à cause des robots qui foutent le bordel partout, je suis grosso merdo d'accord. Mais je trouve quand même franchement bourrin de refuser un get juste pour les changements de "contexte de navigation" (par exemple pour un site multilangue passer du français à l'anglais en cliquant sur un drapeau, on va faire un JS pour forcer la méthode post ? Mouarf !!).
En revanche, je sépare bien là aussi le SHOULD (côté html) du MUST (re-vérifié côté serveur).
Cependant je pense que cet usage devrait être bannit de nos habitudes pour des problèmes évidents (enfin, pas tant que ça visiblement :p ) de sécurité.
Je ne vois vraiment pas où se trouve le problème. Dans la couche de présentation, on met la bonne méthode (get/post) en la générant. Et côté serveur on s'en branle complètement de savoir si les données ont effectivement été envoyées de la "bonne" manière parce que de toutes façons c'est trop tard, elles sont reçues donc le problème c'est de savoir si elles sont légitimes ou pas, et la méthode de transmission n'est pas, loin de là, le facteur déterminant. Si ton propos est de dire qu'il faut aussi revérifier côté serveur que ce qui devait être envoyé en post l'a effectivement été, je pense que c'est plus que superflu et que ça génère plus d'emmerdements que ça n'apporte quoi que ce soit (i.e: rien) mais après tout c'est légitime.
Je ne parlerai même pas de tous les compteurs de visites et trucs à la noix où un img src appelle (en post ?! arf !) un script php qui modifie des données côté serveur avant de faire un bon vieux readfile sur pouet.jpg
Car la méthode GET ne requiert pas d'action explicite de l'utilisateur.
Pas toujours en tous cas. Quand toto clique sur un href c'est bien du get (sauf JS de wrapping) et c'est bien une action explicite. Et ça "peut" légitimement changer des données côté serveur, en particulier tout ce que j'appellerais "contextuelles" (i.e. qui meurent avec la session/fin de navigation).
a++; JG
Bonjour/soir,
Etant historiquement un des premiers casse-c***lles à avoir mis les pieds
dans le plat il y a bien des années, je me marre quand même de voir qu'on
a toujours pas avancé d'un iota sur ce genre de querelles de clocher.
La seule différence majeure entre ce que j'affirme et ce que déclare le
RFC, c'est je dis MUST NOT plutôt que SHOULD NOT. Ceci signifie simplement
que GET ne devrait pas être utilisé pour modifier des données.
Ne serait-ce qu'à cause des robots qui foutent le bordel partout, je suis
grosso merdo d'accord. Mais je trouve quand même franchement bourrin de
refuser un get juste pour les changements de "contexte de navigation" (par
exemple pour un site multilangue passer du français à l'anglais en
cliquant sur un drapeau, on va faire un JS pour forcer la méthode post ?
Mouarf !!).
En revanche, je sépare bien là aussi le SHOULD (côté html) du MUST
(re-vérifié côté serveur).
Cependant je pense que cet usage devrait être bannit de nos habitudes pour
des problèmes évidents (enfin, pas tant que ça visiblement :p ) de sécurité.
Je ne vois vraiment pas où se trouve le problème. Dans la couche de
présentation, on met la bonne méthode (get/post) en la générant. Et côté
serveur on s'en branle complètement de savoir si les données ont
effectivement été envoyées de la "bonne" manière parce que de toutes
façons c'est trop tard, elles sont reçues donc le problème c'est de savoir
si elles sont légitimes ou pas, et la méthode de transmission n'est pas,
loin de là, le facteur déterminant. Si ton propos est de dire qu'il faut
aussi revérifier côté serveur que ce qui devait être envoyé en post l'a
effectivement été, je pense que c'est plus que superflu et que ça génère
plus d'emmerdements que ça n'apporte quoi que ce soit (i.e: rien) mais
après tout c'est légitime.
Je ne parlerai même pas de tous les compteurs de visites et trucs à la
noix où un img src appelle (en post ?! arf !) un script php qui modifie
des données côté serveur avant de faire un bon vieux readfile sur
pouet.jpg
Car la méthode GET ne requiert pas d'action explicite de l'utilisateur.
Pas toujours en tous cas. Quand toto clique sur un href c'est bien du get
(sauf JS de wrapping) et c'est bien une action explicite. Et ça "peut"
légitimement changer des données côté serveur, en particulier tout ce que
j'appellerais "contextuelles" (i.e. qui meurent avec la session/fin de
navigation).
Etant historiquement un des premiers casse-c***lles à avoir mis les pieds dans le plat il y a bien des années, je me marre quand même de voir qu'on a toujours pas avancé d'un iota sur ce genre de querelles de clocher.
La seule différence majeure entre ce que j'affirme et ce que déclare le RFC, c'est je dis MUST NOT plutôt que SHOULD NOT. Ceci signifie simplement que GET ne devrait pas être utilisé pour modifier des données.
Ne serait-ce qu'à cause des robots qui foutent le bordel partout, je suis grosso merdo d'accord. Mais je trouve quand même franchement bourrin de refuser un get juste pour les changements de "contexte de navigation" (par exemple pour un site multilangue passer du français à l'anglais en cliquant sur un drapeau, on va faire un JS pour forcer la méthode post ? Mouarf !!).
En revanche, je sépare bien là aussi le SHOULD (côté html) du MUST (re-vérifié côté serveur).
Cependant je pense que cet usage devrait être bannit de nos habitudes pour des problèmes évidents (enfin, pas tant que ça visiblement :p ) de sécurité.
Je ne vois vraiment pas où se trouve le problème. Dans la couche de présentation, on met la bonne méthode (get/post) en la générant. Et côté serveur on s'en branle complètement de savoir si les données ont effectivement été envoyées de la "bonne" manière parce que de toutes façons c'est trop tard, elles sont reçues donc le problème c'est de savoir si elles sont légitimes ou pas, et la méthode de transmission n'est pas, loin de là, le facteur déterminant. Si ton propos est de dire qu'il faut aussi revérifier côté serveur que ce qui devait être envoyé en post l'a effectivement été, je pense que c'est plus que superflu et que ça génère plus d'emmerdements que ça n'apporte quoi que ce soit (i.e: rien) mais après tout c'est légitime.
Je ne parlerai même pas de tous les compteurs de visites et trucs à la noix où un img src appelle (en post ?! arf !) un script php qui modifie des données côté serveur avant de faire un bon vieux readfile sur pouet.jpg
Car la méthode GET ne requiert pas d'action explicite de l'utilisateur.
Pas toujours en tous cas. Quand toto clique sur un href c'est bien du get (sauf JS de wrapping) et c'est bien une action explicite. Et ça "peut" légitimement changer des données côté serveur, en particulier tout ce que j'appellerais "contextuelles" (i.e. qui meurent avec la session/fin de navigation).
a++; JG
Yannick
Bonjour,
Regardez ce fil et vous comprendrez ce que je DÉTESTE! 1 question pratique avec tous les éléments. 12 messages avec 1 personne pour arriver à la solution recherchée. Je n'ai pas dit LA solution car vu les autres messages. 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é... Je ne parle pas des messages reçus en privé pour ne rien faire avancé. De ces derniers 1 seul a eu un effet constructif qui sera repris.
Pensez-vous décemment que vous attirez les néophites à faire des efforts? Je vous réponds que non car c'est désolant.
Un grand merci à Olivier et Éric
Amitiés
-- Yannick VOYEAUD
Bonjour,
Regardez ce fil et vous comprendrez ce que je DÉTESTE!
1 question pratique avec tous les éléments.
12 messages avec 1 personne pour arriver à la solution recherchée. Je
n'ai pas dit LA solution car vu les autres messages.
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é...
Je ne parle pas des messages reçus en privé pour ne rien faire avancé.
De ces derniers 1 seul a eu un effet constructif qui sera repris.
Pensez-vous décemment que vous attirez les néophites à faire des
efforts? Je vous réponds que non car c'est désolant.
Regardez ce fil et vous comprendrez ce que je DÉTESTE! 1 question pratique avec tous les éléments. 12 messages avec 1 personne pour arriver à la solution recherchée. Je n'ai pas dit LA solution car vu les autres messages. 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é... Je ne parle pas des messages reçus en privé pour ne rien faire avancé. De ces derniers 1 seul a eu un effet constructif qui sera repris.
Pensez-vous décemment que vous attirez les néophites à faire des efforts? Je vous réponds que non car c'est désolant.
Un grand merci à Olivier et Éric
Amitiés
-- Yannick VOYEAUD
John GALLET
> une différence évidente entre les protocoles GET et POST est simplement la taille maximale des données transmises.
Tellement évidente que c'est une conséquence et non une cause: c'est la méthode d'encodage qui est différente, et seulement celle-ci en ce qui concerne le dialogue tcp/ip. Ceci a pour effet de bord accessoire qu'en général, selon le navigateur et le serveur, la méthode get est effectivement plus limitée en taille, mais ce n'est pas toujours le cas, selon le navigateur et le serveur il y a aussi des restrictions de taille sur le post.
le choix du protocole GET ou POST n'est donc que motivé par les tailles d'échanges supportées, en aucun cas par de pseudo-sécurités, en aucun cas par des traductions opportunistes.
Non, autant je suis le premier à dire depuis des années qu'on se tamponne de le re-vérifier côté serveur, autant là c'est abuser en simplification pour le choix de la méthode à indiquer dans la couche de présentation.
Une des autres différences majeures entre les deux méthodes est son traitement côté serveur dans les logs et côté client dans le referrer.
Donc il est évident (?) qu'on va transmettre les paramètres sensibles (données de carte bancaire si on doit malheureusement les gèrer, login et mot de passe) en POST pour qu'il ne soient pas connement stockés en clair dans les logs http (qui ne sont que très rarement considérés comme contenant des données confidentielles donc improprement peu protégés et ne devraient JAMAIS en contenir en DMZ), et qu'il faut faire un minimum attention aux XSS involontaires par referer.
On voit ci-dessous la différence d'encodage en envoyant les mêmes données (variable id_client valant 12345 et mode valant full, exemple bateau sur un entier et une string pour montrer qu'on s'en fout), en particulier le content-type pour le post. La requête est faite depuis le client 192.168.0.1 qui envoie les données à .2 après avoir demandé la page une première fois (cf referer).
On remarquera au passage que pour des faibles volumes de données, ce qui bouffe le plus la BP ce sont toutes les conneries ajoutées par le navigateur, mais c'est une autre histoire...
a++; JG
Exemples en capture de trame IP par tcpdump (après décodage) et log apache:
> une différence évidente entre les protocoles GET et POST est simplement
la taille maximale des données transmises.
Tellement évidente que c'est une conséquence et non une cause: c'est la
méthode d'encodage qui est différente, et seulement celle-ci en ce qui
concerne le dialogue tcp/ip. Ceci a pour effet de bord accessoire qu'en
général, selon le navigateur et le serveur, la méthode get est
effectivement plus limitée en taille, mais ce n'est pas toujours le cas,
selon le navigateur et le serveur il y a aussi des restrictions de
taille sur le post.
le choix du protocole GET ou POST n'est donc que motivé par les tailles
d'échanges supportées, en aucun cas par de pseudo-sécurités, en aucun
cas par des traductions opportunistes.
Non, autant je suis le premier à dire depuis des années qu'on se
tamponne de le re-vérifier côté serveur, autant là c'est abuser en
simplification pour le choix de la méthode à indiquer dans la couche de
présentation.
Une des autres différences majeures entre les deux méthodes est son
traitement côté serveur dans les logs et côté client dans le referrer.
Donc il est évident (?) qu'on va transmettre les paramètres sensibles
(données de carte bancaire si on doit malheureusement les gèrer, login
et mot de passe) en POST pour qu'il ne soient pas connement stockés en
clair dans les logs http (qui ne sont que très rarement considérés comme
contenant des données confidentielles donc improprement peu protégés et
ne devraient JAMAIS en contenir en DMZ), et qu'il faut faire un minimum
attention aux XSS involontaires par referer.
On voit ci-dessous la différence d'encodage en envoyant les mêmes
données (variable id_client valant 12345 et mode valant full, exemple
bateau sur un entier et une string pour montrer qu'on s'en fout), en
particulier le content-type pour le post. La requête est faite depuis le
client 192.168.0.1 qui envoie les données à .2 après avoir demandé la
page une première fois (cf referer).
On remarquera au passage que pour des faibles volumes de données, ce qui
bouffe le plus la BP ce sont toutes les conneries ajoutées par le
navigateur, mais c'est une autre histoire...
a++;
JG
Exemples en capture de trame IP par tcpdump (après décodage) et log apache:
> une différence évidente entre les protocoles GET et POST est simplement la taille maximale des données transmises.
Tellement évidente que c'est une conséquence et non une cause: c'est la méthode d'encodage qui est différente, et seulement celle-ci en ce qui concerne le dialogue tcp/ip. Ceci a pour effet de bord accessoire qu'en général, selon le navigateur et le serveur, la méthode get est effectivement plus limitée en taille, mais ce n'est pas toujours le cas, selon le navigateur et le serveur il y a aussi des restrictions de taille sur le post.
le choix du protocole GET ou POST n'est donc que motivé par les tailles d'échanges supportées, en aucun cas par de pseudo-sécurités, en aucun cas par des traductions opportunistes.
Non, autant je suis le premier à dire depuis des années qu'on se tamponne de le re-vérifier côté serveur, autant là c'est abuser en simplification pour le choix de la méthode à indiquer dans la couche de présentation.
Une des autres différences majeures entre les deux méthodes est son traitement côté serveur dans les logs et côté client dans le referrer.
Donc il est évident (?) qu'on va transmettre les paramètres sensibles (données de carte bancaire si on doit malheureusement les gèrer, login et mot de passe) en POST pour qu'il ne soient pas connement stockés en clair dans les logs http (qui ne sont que très rarement considérés comme contenant des données confidentielles donc improprement peu protégés et ne devraient JAMAIS en contenir en DMZ), et qu'il faut faire un minimum attention aux XSS involontaires par referer.
On voit ci-dessous la différence d'encodage en envoyant les mêmes données (variable id_client valant 12345 et mode valant full, exemple bateau sur un entier et une string pour montrer qu'on s'en fout), en particulier le content-type pour le post. La requête est faite depuis le client 192.168.0.1 qui envoie les données à .2 après avoir demandé la page une première fois (cf referer).
On remarquera au passage que pour des faibles volumes de données, ce qui bouffe le plus la BP ce sont toutes les conneries ajoutées par le navigateur, mais c'est une autre histoire...
a++; JG
Exemples en capture de trame IP par tcpdump (après décodage) et log apache:
