Logo GNT
Actualités Tests & Guides Bons Plans
GTA 6 iPhone 17 Copilot Switch 2 Temu ChatGPT Tesla
OVH Cloud OVH Cloud
Entraide Développement Développement Langage PHP Aide pour affichage disponibilites

Aide pour affichage disponibilites

40 réponses
Avatar
MIMATA
Bonjour à tous,

Voilà, je cherche de l'aide pour m'aider à mettre en place un système très
simple d'affichage de disponibilités pour des gites.
Vous pouvez voir ce que je cherche à faire là :
http://www.mimata6.free.fr/admin_dispo.php
Le principe est de faire en sorte que quand on clique sur un jour, dans l'un
des tableaux, on change son état : un clic, le jour est réservé donc la
cellule s'affiche en rouge (par exemple, c'est la classe occupe), un autre
clic sur la même case remet la cellule à son état d'origine, c'est à dire
libre. Pour cela, il faut que, à l'affichage de la page, on teste l'état de
chaque case pour savoir s'il faut l'afficher occupée ou libre, puis, sur
chaque numéro de jour, si on clique on change son état.

J'ai donc :
- 2 pages : dispo.php et admin_dispo (mais on ne va s'occuper que de la page
admin_dispo.php pour le moment)
- Une base de donnée avec une table dispo_gite_ecuries contenant 2 champs :
date et dispo. Voici sa structure :
`date` date NOT NULL default '0000-00-00',
`dispo` int(1) NOT NULL default '0',
PRIMARY KEY (`date`)
Cette table est vide par défaut. Sur un clic, on ajoute un item dans la base
avec la date correspondante et 1 dans dispo, sur le clic suivant sur la même
case, on efface l'item s'il existe, sinon on ajoute.

Les tableaux de chaque mois sont générés en php. Voici le code :

<?php
$m_loc = array(
1=>'Janvier',
2=>'Février',
3=>'Mars',
4=>'Avril',
5=>'Mai',
6=>'Juin',
7=>'Juillet',
8=>'Août',
9=>'Septembre',
10=>'Octobre',
11=>'Novembre',
12=>'Décembre'
);

// numéro de l'année
$a = date("Y");

for($ind=1; $ind<=12;$ind++){
// numéro du mois
$m = $ind;
// timestamp du 1er du mois à minuit une
$t = mktime(0, 0, 1, $m, 1, $a);
// nombre de jours dans ce mois
$nj = date('t', $t);

// n° du premier jour du mois: on décale le résultat anglais
(premier=0=dimanche) pour obtenir premier=1=lundi
$j = date('w', $t);
if ($j==0) $j = 7; // dimanche=7
else $j = $j; // lundi=1 ... samedi=6

// nombre d'espaces à laisser vides avant le premier jour du mois = numéro
du jour - 1
$sb = $j - 1;

// nombre de lignes au total dans la table
// sachant qu'il faut placer AU MOINS $nj+$sb cases, et qu'on a 7 colonnes
// $nl = ceil(($nj+$sb)/7);

$nl = 6;

// pré-remplissage de la table avec des cases vides (0) partout
$tb = array_fill(0, $nl, array_fill(1,7,0));

// remplissage avec les n° de jours, en sautant les $sb premières cases
for ($i=1; $i<=$nj; $i++) {
$ligne = floor(($i+$sb-1)/7);
$colonne = ($i+$sb-1)%7 + 1;
$tb[$ligne][$colonne] = $i;
}


?>
<table border="1" bordercolorlight="#666666" bordercolordark="#FFFFFF"
cellpadding="2" cellspacing="2">
<tr>
<th class="mois" colspan="7" align="center" valign="middle">
<?php echo $m_loc[$m]; ?>
</th>
</tr>
<tr>
<th class="jours">Lun</th>
<th class="jours">Mar</th>
<th class="jours">Mer</th>
<th class="jours">Jeu</th>
<th class="jours">Ven</th>
<th class="jours">Sam</th>
<th class="jours">Dim</th>
</tr>
<?php foreach ($tb as $l) { ?>
<tr>
<?php foreach ($l as $numjour) { ?>

// A PARTIR DE LA CA DELIRE CAR JE NE SAIS PAS LE FAIRE

<?php
// concaténation pour céer la date complète au format mysql 0000-00-00
$date = $a.'-'.$m.'-'.$numjour;
// connexion à la base
include ('config.inc.php');
$req = "SELECT * FROM dispo_gite_ecuries WHERE date='$date'";
$res = mysql_query($req) or die(mysql_error());
if (mysql_num_rows($res) == 0){ // si la recherche ne renvoie rien, on cré
l'enregistrement
// lancement de la requette d'injection
$req = "INSERT INTO dispo_gite_ecuries(date,dispo) VALUES('$date','1')";
mysql_query($req) or die(mysql_error());
}else{ // sinon (l'enregistrement existe deja...)
$req = "DELETE FROM dispo_gite_ecuries WHERE date='$date' AND
dispo='1'";
$res = mysql_query($req) or die(mysql_error());
}

if ($numjour!=0){
if ($dispo == 0){
echo '<td class="libre"><a
href="admin_dispo.php?date='.$date.'">'.$numjour.'</a>'; }
else {
echo '<td class="occupe"><a
href="admin_dispo.php?date='.$date.'">'.$numjour.'</a>'; }
}
else { echo '<td class="pasdebordure">.'; }
?>
</td>
<?php } ?>
</tr>
<?php } ?>
</table>


Merci du coup de main.

MIMATA
Signaler un problème avec ce contenu

10 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
1 2 3 4
Avatar
MIMATA
"John GALLET" a écrit dans le message de news:
43e30d12$0$282$
On a aussi supprimé quelques bouts de code qui semblaient poser problème
pour je ne sais quelle raison et la variable global $_REQUEST s'est
changée en $_GET car le gars qui m'a aidé ne savait pas bien ce que cette
variable fesait...et moi encore moins.
Dans tous les cas c'est mauvais de l'utiliser directement si ce n'est pas

en intranet/accès protégé avec des gens en qui tu peux avoir confiance.


Bonjour John,

J'aurai une question à te poser par rapport à l'utilisation de $_REQUEST à
la place de $_GET.
Il ne faut pas croire, ça me travaille encore un peu cette histoire. Tu dis
que $_GET peut poser des problèmes de sécurité contrairement à $_REQUEST.
Pourrais-tu être plus précis sur ce point ? Je me suis un peu renseigné de
mon côté et je trouve systématiquement des personnes qui déconseille
l'utilisation de $_REQUEST. J'ai aussi chercher dans les cours PHP que tu
recommandes sur ton site http://www.saphirtech.com/cours.html mais je n'ai
pas vu de plaidoyer en faveur de $_REQUEST (ou j'ai pas compris...).

Merci

MIMATA


Avatar
John GALLET
Bonjour,

Il ne faut pas croire, ça me travaille encore un peu cette histoire. Tu dis
que $_GET peut poser des problèmes de sécurité contrairement à $_REQUEST.
Non : les deux posent les mêmes problèmes. Rigoureusement.


et je trouve systématiquement des personnes qui déconseille
l'utilisation de $_REQUEST.
S'ils disent qu'il faut vérifier que ce qui doit être en get est bien

dans $_GET et ce qui est censé arriver en post dans $_POST, ils n'ont
pas compris à quel point il est simpliste de contourner cette
vérification (qui, donc, n'apporte RIEN en termes de sécurité).

Ou alors ils en sont conscients et partent du principe (juste) que tout
ce qui emm... l'attaquant est toujours ça de gagné, même si ça se
contourne en quelques secondes.

J'ai aussi chercher dans les cours PHP que tu recommandes
Recommande, je ne sais pas, en tous cas je les ai écrits ;-)


pas vu de plaidoyer en faveur de $_REQUEST (ou j'ai pas compris...).
C'est plutôt le document

http://www.saphirtech.fr/securite_web_dynamique.pdf qu'il faut lire à ce
sujet. Extrait du paragraphe "la fausse sécurité" :
<CITE>
"Je suis sûr que c'est arrivé en POST"
So what ?
Fausse pratique de sécurité : "je vérifie que la donnée m'arrive bien en
POST" (variante : "en GET", "dans un cookie").
Règle : il est inutile de vérifier qu'une donnée vous est bien fournie
par POST et non par GET (ou l'inverse) ou par un cookie.
Pourquoi : c'est l'enfance de l'art que de vous envoyer des données.
Vous voulez du GET ? Par GET, il suffit de faire un telnet www.cible.tld
80 ou plus simplement de taper les variables dans la barre de navigation
d'un navigateur. Vous voulez du POST ? Par POST, il suffit de
sauvegarder la page html de votre formulaire sur le disque dur, de
modifier le code, de relire le fichier local, et cliquer sur "submit".
Vous voulez un cookie ? Un cookie, ce n'est qu'un fichier texte à écrire
au bon endroit sur le disque dur. Il est également possible d'utiliser
wget ou curl pour envoyer les mêmes données en boucle infinie 10 ou 50
fois par seconde pendant 1h...
Corollaire : c'est le contenu de la donnée qui est important, son mode
de transmission n'a strictement aucune importance.
En PHP : utilisez donc le tableau $_REQUEST au lieu de compliquer le
code en utilisant tantôt $_GET et tantôt $_POST.
</CITE>

Ce que je dis donc c'est :
1) il faut faire attention au contenu des variables qu'on reçoit (tout
un tas de raisons sont indiquées dans le document cité ci-dessus,
injections sql ou xss par exemple, ou injection dans les headers de la
fonction mail, comme en a été victime "svs" dans son article "victime
d'un hack de type relai" hier matin)
2) à part à compliquer le code, aller taper un coup dans $_GET, un coup
dans $_POST, n'a strictement aucun intérêt. Inutile de se fatiguer, donc
autant utiliser $_REQUEST partout.
3) il faut en revanche bien faire attention à envoyer les données
sensibles (login/pass par exemple) en POST, car sinon ces données
sensibles sont écrites en clair dans les logs http. Ce qui n'empêche aps
de les récupérer, comme les autres, dans $_REQUEST, peu importe.

Si ce n'est toujours pas clair, redemander des éclaircissements :-)
JG

Avatar
Olivier Miakinen

Bonjour John,


Bonjour MIMATA.

J'aurai une question à te poser par rapport à l'utilisation de $_REQUEST à
la place de $_GET.


Je ne suis pas John. Je peux répondre quand même ?

Il ne faut pas croire, ça me travaille encore un peu cette histoire. Tu dis
que $_GET peut poser des problèmes de sécurité contrairement à $_REQUEST.


En lui-même, $_GET ne posera aucun problème de sécurité supplémentaire
par rapport à $_REQUEST. La seule chose qui pourrait poser des problèmes
de sécurité, ce serait de se dire qu'utiliser $_GET ou $_POST est mieux
sécurisé que $_REQUEST, et donc ne pas faire les contrôles aussi bien
qu'on le devrait.

Pourrais-tu être plus précis sur ce point ? Je me suis un peu renseigné de
mon côté et je trouve systématiquement des personnes qui déconseillent
l'utilisation de $_REQUEST.


Eh bien ce sont ces personnes qui posent des problèmes de sécurité ! ;-)

Il faut savoir qu'il est aussi facile à un attaquant de remplir $_GET
que $_POST ou n'importe quoi de ce qui est transmis au script par
l'extérieur. La règle d'or est donc de toujours contrôler les valeurs
qui sont transmises, quel que soit le tuyau par lequel elles arrivent.

Donc :
- utiliser $_REQUEST au lieu de $_GET ou $_POST ou $_COOKIE, en ne
donnant pas une fausse impression de sécurité, incite peut-être à
être un poil plus vigilant ;
- comme en plus cela permet de changer ses requêtes de GET en POST
sans changer son script, il serait bête de s'en priver.

Conclusion :
Le $_REQUEST (avec contrôle), c'est bon, mangez-en !

--
Olivier Miakinen
Troll du plus sage chez les conviviaux : le nouveau venu, avec
son clan, s'infiltre dans les groupes de nouvelles. (3 c.)

Avatar
MIMATA
"John GALLET" a écrit dans le message de news:
43f5f1cb$0$17375$
et je trouve systématiquement des personnes qui déconseille
l'utilisation de $_REQUEST.
S'ils disent qu'il faut vérifier que ce qui doit être en get est bien dans

$_GET et ce qui est censé arriver en post dans $_POST, ils n'ont pas
compris à quel point il est simpliste de contourner cette vérification
(qui, donc, n'apporte RIEN en termes de sécurité).

Ou alors ils en sont conscients et partent du principe (juste) que tout ce
qui emm... l'attaquant est toujours ça de gagné, même si ça se contourne
en quelques secondes.
D'accord, ce genre de "protection" est du même niveau que les anti clics

droits en javascript 8-/

J'ai aussi chercher dans les cours PHP que tu recommandes
Recommande, je ne sais pas, en tous cas je les ai écrits ;-)

Oui, c'est ce que j'ai constaté, quelle modestie ;-) mais tu m'a bien

recommandé de les lire et j'y ai recours parfois...mais mon niveau n'est pas
encore suffisant pour bien comprendre toutes les subtilités de toutes les
recommandations.

pas vu de plaidoyer en faveur de $_REQUEST (ou j'ai pas compris...).
C'est plutôt le document

http://www.saphirtech.fr/securite_web_dynamique.pdf qu'il faut lire à ce
sujet. Extrait du paragraphe "la fausse sécurité" :
<CITE>
"Je suis sûr que c'est arrivé en POST"
So what ?
Fausse pratique de sécurité : "je vérifie que la donnée m'arrive bien en
POST" (variante : "en GET", "dans un cookie").
Règle : il est inutile de vérifier qu'une donnée vous est bien fournie par
POST et non par GET (ou l'inverse) ou par un cookie.
Pourquoi : c'est l'enfance de l'art que de vous envoyer des données. [...]
En PHP : utilisez donc le tableau $_REQUEST au lieu de compliquer le code
en utilisant tantôt $_GET et tantôt $_POST.
</CITE>
J'ai vu ce paragraphe et c'est d'ailleurs là que tu préconises l'utilisation

de REQUEST pour simplifier le code mais les commentaires que j'ai vu sur le
net critiquent REQUEST car pour eux c'est une source de bug. Au risque de
mal paraphraser, je préfère citer : "[...] il y un inconvénient : si il y a
une variable qui porte le meme nom dans les cookies, en get et en post, une
seule des trois sera pris en compte dans $_REQUEST dépendant du parametre
variable_order (gpc = get, post, cookies) dans php.ini" (source :
http://www.developpez.net/forums/viewtopic.php?p%23699)

Ce que je dis donc c'est :
1) il faut faire attention au contenu des variables qu'on reçoit
D'où l'intérêt de privilégier l'utilisation de swich par rapport à if / else

dans le cas d'un passage de paramettre via l'url.

2) à part à compliquer le code, aller taper un coup dans $_GET, un coup
dans $_POST, n'a strictement aucun intérêt. Inutile de se fatiguer, donc
autant utiliser $_REQUEST partout.
Certains disent que justement, ça leur complique un peu la tâche parce que

du coup ils ne savent plus si les données proviennet de l'url ou d'un
formulaire...mais est-ce vraiment important de le savoir...?...je ne suis
pas sûr.
Donc, si j'ai bien compris, il faut bien nommer ses variables et faire
attention à ce que chacune soit unique et à partir de là, on peut préférer
REQUEST car c'est effectivement plus simple car plus souple.

3) il faut en revanche bien faire attention à envoyer les données
sensibles (login/pass par exemple) en POST, car sinon ces données
sensibles sont écrites en clair dans les logs http. Ce qui n'empêche aps
de les récupérer, comme les autres, dans $_REQUEST, peu importe.
Donc ce que je dois retenir, c'est qu'il faut systématiquement utiliser POST

pour envoyer des données sensibles et utiliser GET ou REQUEST indifférement
pour réccupérer ces valeurs;

Si ce n'est toujours pas clair, redemander des éclaircissements :-)
Et bien à toi de me dire si j'ai bon !



Avatar
ftc
Donc :
- utiliser $_REQUEST au lieu de $_GET ou $_POST ou $_COOKIE, en ne
donnant pas une fausse impression de sécurité, incite peut-être à
être un poil plus vigilant ;
- comme en plus cela permet de changer ses requêtes de GET en POST
sans changer son script, il serait bête de s'en priver.

Conclusion :
Le $_REQUEST (avec contrôle), c'est bon, mangez-en !


Utiliser $_POST au lieu de $_REQUEST permet de s'assurer que les données
sont transmises dans des circonstances normales et pas une tentative de
CSRF.
http://shiflett.org/articles/security-corner-dec2004

De plus je ne vois pas l'intérêt de changer des requêtes GET en POST,
l'utilisation de chacune des méthodes étant bien différenciée.

Avatar
MIMATA
"Olivier Miakinen" <om+ a écrit dans le message de news:
dt4tci$h45$

Bonjour John,


Bonjour MIMATA.

Je ne suis pas John. Je peux répondre quand même ?
Hum...allez, d'accord ;-). Biensûr, je m'adressait à John parce que c'est

lui qui m'avait parlé de ça mais tu avais compris Olivier :-D (c'est le jour
où je tutoies tout le monde, j'espère n'ofusquer personne...)

Pourrais-tu être plus précis sur ce point ? Je me suis un peu renseigné
de
mon côté et je trouve systématiquement des personnes qui déconseillent
l'utilisation de $_REQUEST.
Eh bien ce sont ces personnes qui posent des problèmes de sécurité ! ;-)

Rhaaa les s***ps, ils sont partout sur les forums !



Conclusion :
Le $_REQUEST (avec contrôle), c'est bon, mangez-en !
C'est ce que j'en retiens effectivement ! Merci OLIVIER



Avatar
John GALLET
Re,

D'accord, ce genre de "protection" est du même niveau que les anti clics
droits en javascript 8-/
Grosso merdo, oui.


mal paraphraser, je préfère citer : "[...] il y un inconvénient : si il y a
une variable qui porte le meme nom dans les cookies, en get et en post, une
seule des trois sera pris en compte dans $_REQUEST dépendant du parametre
variable_order (gpc = get, post, cookies) dans php.ini"
C'est exact techniquement, mais il n'y a que DEUX cas quand un script

reçoit une requête http:

CAS 1 : c'est un utilisateur légitime qui a cliqué là où on lui a dit de
cliquer et qui donc fournit en entrée (dans $_REQUEST) ce que le
développeur de l'application a voulu fournir. Dans ce cas là, si le
charlot est pas foutu de faire gaffe à comment il nomme ses variables et
qu'il a le même nom dans un cookie et une autre(get/post) ou qu'il
joue à balancer des données à la fois en get et en post dans un
formulaire en mettant deux fois la même variable à deux valeur
différentes, **on peut plus rien faire pour lui**. Déjà les cookies,
hein, bon. Z'on qu'à pas les utiliser, ça fera pas de confusion ;-)

CAS 2 : ce n'est pas un utilisateur légitime qui envoie les données.
Alros dans ce cas on en a rien à f... de savoir si $_REQUEST['coucou']
est en réalité $_POST['coucou'] ou $_COOKIES['coucou'] ce qui importe
c'est son contenu et surtout le droit d'exécuter le code associé à cette
requête http.

D'où l'intérêt de privilégier l'utilisation de swich par rapport à if / else
dans le cas d'un passage de paramettre via l'url.
Entre autres. L'avantage de switch est de forcer à se souvenir qu'il

faut remplir le cas default. Mais ce n'est que de la syntaxe et des
habitudes de chaque développeur.

Certains disent que justement, ça leur complique un peu la tâche parce que
du coup ils ne savent plus si les données proviennet de l'url ou d'un
formulaire...
Et alors ?


mais est-ce vraiment important de le savoir...?...je ne suis
pas sûr.
Moi j'en suis sûr : on s'en bat les co^W^W^Wfiche. Ou la requête est

légitime et on l'exécute, ou elle n'est pas légitime et on doit le
détecter. Peu importe le mode de transmission, c'est le contenu des
variables qui permettra de faire la différence

Donc, si j'ai bien compris, il faut bien nommer ses variables et faire
attention à ce que chacune soit unique et à partir de là, on peut préférer
REQUEST car c'est effectivement plus simple car plus souple.
Pile poil. Et même si on utilise explicitement $_POST ou $_GET ou

$_COOKIE, il ne me parait pas idiot de nommer ses variables de manière
unique.

Donc ce que je dois retenir, c'est qu'il faut systématiquement utiliser POST
pour envoyer des données sensibles
Oui.

et utiliser GET ou REQUEST indifférement pour réccupérer ces valeurs;
Non pour $_GET avec une méthode POST, il sera vide (sauf bidouille comme

ci-dessous).
Exemple :
<FORM action=toto.php?a=1 METHOD="POST">
<INPUT TYPE="HIDDEN" NAME="b" VALUE="2">
<INPUT TYPE="SUBMIT">

dans toto.php :
print_r($_GET) donnera a=>1
print_r($_POST) donnera b=>2
et print_r($_REQUEST) donnera a=>1, b=>2

a++;
JG

Avatar
Olivier Miakinen
Le 17/02/2006 19:06, ftc me répondait :

Utiliser $_POST au lieu de $_REQUEST permet de s'assurer que les données
sont transmises dans des circonstances normales et pas une tentative de
CSRF.
http://shiflett.org/articles/security-corner-dec2004


Non, ça ne permet pas de s'en « assurer ». Comme le rappelle John, cela
permet juste de limiter le nombre de méthodes, mais cette protection se
contourne en quelques secondes.

Si tu peux modifier le code HTML pour y mettre une image, tu peux tout
aussi bien y mettre un formulaire avec tous les champs cachés, et validé
en JavaScript.

De plus je ne vois pas l'intérêt de changer des requêtes GET en POST,
l'utilisation de chacune des méthodes étant bien différenciée.


Je ne me battrai pas sur ce point.

--
Olivier Miakinen
Troll du plus sage chez les conviviaux : le nouveau venu, avec
son clan, s'infiltre dans les groupes de nouvelles. (3 c.)

Avatar
John GALLET
Bonsoir,

Utiliser $_POST au lieu de $_REQUEST permet de s'assurer que les données
sont transmises dans des circonstances normales
Non. Il permet de détecter *certaines tentatives de transmission

anormale*. Pas toutes, ce serait trop simple (donc s'il en reste,
pourquoi se fatiguer vu qu'il FAUDRA une AUTRE protection).

et pas une tentative de CSRF.
http://shiflett.org/articles/security-corner-dec2004
Oui et ? A part rajouter un token en plus du session_id (et puis

pourquoi pas un token2 et un token3, des fois qu'on ait deviné le
premier puis le second) qu'est-ce que cet article indique ?
<CITE>
[le code qui est envoyé par l'image]
Every user that visits this page sends a request to example.org just as
if the user clicked a link to the same URL. Because the sample
application uses $_REQUEST instead of the more specific $_POST, it
cannot distinguish between data sent in the URL from data provided in
the proper HTML form.
</CITE>
BFD ! (big furry deal). C'est surtout parce qu'on ne vérifie pas que
cette requête est valide (i.e. cette personne a le droit de l'exécuter)
que le risque est là. Ce n'est pas en vérifiant le mode de transmission
qu'on le saura, mais bien, comme il l'écrit plus loin, en validant un
jeton donnant cette autorisation, et je cite aussi :
<CITE>
POST requests can also be forged, so do not consider a strict use of
$_POST to be sufficient protection.
</CITE>
Donc C.S. fait partie des gens qui considèrent que tout ce qui permet de
mettre des batons dans les roues à l'attaquant est bon à prendre, quel
que soit le coût en maintenance et complexification du code (dont il ne
parle pas d'ailleurs). Moi je considère que quand ça m'oblige à modifier
mon code toutes les 5 minutes parce qu'on golio (cf plus bas) change
d'avis comme de chemise et qu'en plus la "protection" se contourne en 3
secondes, ça ne vaut pas le coup de s'emmerder. A chacun d'adopter la
stratégie qu'il voudra, l'essentiel c'est de comprendre ce qu'on fait et
pourquoi.

De plus je ne vois pas l'intérêt de changer des requêtes GET en POST,
l'utilisation de chacune des méthodes étant bien différenciée.
Nous sommes tout à fait d'accord : strictement aucun !! Mais va dire ça

à la @#*! d'agence graphiste qui te fournit 15 versions de la même page
en 3 semaines avec un coup l'un, un coup l'autre, et la troisième fois
du JS qui transforme le clic sur une image en POST...


a++;
JG

Avatar
ftc
Le 17/02/2006 19:06, ftc me répondait :
Utiliser $_POST au lieu de $_REQUEST permet de s'assurer que les données
sont transmises dans des circonstances normales et pas une tentative de
CSRF.
http://shiflett.org/articles/security-corner-dec2004


Non, ça ne permet pas de s'en « assurer ».


Si, car un CSRF ne peut se faire que par la méthode GET et que les
données devraient être faites en POST puisque c'est une action d'envoi
de données.


1 2 3 4