Bonjour à toutes et à tous,

J'aimerai aborder ce point pour être certain d'avoir bien compris ces points et d'avoir mis en place les bonnes protections.

A - Injection SQL et faille XSS

En effet, en parcourant un site j'ai découvert cette manière de procéder :

1 - Je récupère des informations depuis l'extérieur
2 - Je me protège de cette manière la :
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7
8
9
10
11
12
 
$_GET['ext01'] $_POST['ext02']
 
$recuperation_get = striplashes($_GET['ext01']); //SQL
$recuperation_get = mysql_real_escape_string($recuperation_get); //SQL
$recuperation_get =htmlspecialchars($recuperation_get); //XSS
 
même manière de procéder pour POST
 
$recuperation_post = striplashes($_POST['ext02']); //SQL
$recuperation_post = mysql_real_escape_string($recuperation_post); //SQL
$recuperation_post =htmlspecialchars($recuperation_post); //XSS
Je me pose des questions sur la partie injection SQL.
1 - Si l'utilisation utilise
Code : Sélectionner tout - Visualiser dans une fenêtre à part
\
dans un mot de passe par exemple, automatiquement on vient dénaturer son mot de passe avec striplashes
2 - mysql_real_escape_string renvoie une erreur (fonction inconnue), l'alternative proposée est mysqli_real_escape_string qui renvoie aussi une erreur car la liste des paramètres à échapper n'est pas définie...

Ces élément sont-ils réellement nécessaires pour se protéger contre l'injection SQL ?

Dans d'autres exemples que j'ai trouvé, striplashes et mysql_real_escape_string n'ont jamais été proposés contre la faille injection SQL.
Mais on parlait plutôt de requêtes préparés, et que ces requêtes préparées permettaient de se prémunir contre l'injection SQL

Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
 
//Cas INSERT INTO
$rep=$acces_bdd->prepare('INSERT INTO maTAble ($recuperation_get, $recuperation_post) VALUES(:$recuperation_get, :$recuperation_post);
$rep->execute(array(	
'Colonne01' => $recuperation_get,
'Colonne02' => $recuperation_post
));
 
//Cas UPDATE
$rep=$acces_bdd->prepare('UPDATE maTAble SET $recuperation_get =:$recuperation_get, $recuperation_post =:$recuperation_post  WHERE id=:id');
 
$rep->execute(array(	
'Colonne01' => $recuperation_get,
'Colonne02' => $recuperation_post,
'id' => $Ma_Recherche['id']
));
Pour la faille XSS, rien de trop méchant à comprendre si ce n'est l'utilisation de htmlspecialchars.

Bref suite à ces différentes manière de procéder... me voici ici pour profiter de votre expérience car je suis un peu perdu pour le coup.

B - Jeton CSRF

J'ai bien compris que l'objectif du jeton est de vérifier que le formulaire qui a été complété vient bien de notre propre site.
Les différents exemples rencontrés placent ce jeton directement dans un champs masqué du formulaire et, lors du traitement du formulaire vérifie que $_POST['jeton'] existe et que sa valeur
concorde avec $_SESSION['jeton'].

Y'a t-il un intérêt à généraliser ce jeton pour toutes les données entrantes ?

Par exemple un lien de désinscription à une newsletter ?
La personne clique sur le lien, est redirigée vers une page de traitement où on en profite pour récupérer des données par l'intermédiaire de $_GET (a minima l'email de la personne qui ne veut plus être inscrite).
Un jeton a-t-il un intérêt ici ? (la vous vous dites surement... mince il a rien compris aux jetons le type )
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
 
Exemple :
Je reçois une demande sur mon site
www.monsite.pagetraitement?desinscription=O&email=monemail@youpi.com
 
if(isset($_GET['desinscription']) AND $_GET['desinscription']=="O")
{
     //Ouverture de la table et je supprime la ligne ou je trouve l'email
}
 
VERSUS
$jeton = $_SESSION['jeton']
if(isset($_GET['desinscription']) AND $_GET['desinscription']=="O" AND isset($jeton) AND ($jeton == $_SESSION['jeton']))
{
     //Ouverture de la table et je supprime la ligne ou je trouve l'email
}
Mon idée sous-jacente (ou mon incompréhension sous-jacente () est que si le jeton permet de nous assurer qu'une personne ne puisse faire passer un site H pour notre site,
une protection qui est fonctionnelle pour $_POST le sera aussi pour $_GET, non ?

D'avance merci pour vos retours