Ces deux fonctions sont-elles exagérées pour la désinfection ?

Pour être honnête, je pense que l'auteur de ces fonctions n'a aucune idée de ce que sont les injections XSS et SQL ou de ce que fait exactement la fonction utilisée.

Pour ne citer que deux bizarreries :

Utiliser stripslashes après mysql_real_escape_string supprime les barres obliques ajoutées par mysql_real_escape_string .
htmlentities remplace les caractères < et > qui sont utilisés dans strip_tags afin d'identifier les balises.

De plus :En général, les fonctions qui protègent contre XSS ne sont pas adaptées pour protéger contre les injections SQL et vice versa. Parce que chaque langue et contexte a ses propres caractères spéciaux dont il faut prendre soin.

Mon conseil est d'apprendre pourquoi et comment l'injection de code est possible et comment s'en protéger. Apprenez les langues avec lesquelles vous travaillez, en particulier les caractères spéciaux et comment les échapper.

Modifier Voici un exemple (probablement étrange) :imaginez que vous autorisez vos utilisateurs à saisir une valeur qui doit être utilisée comme segment de chemin dans un URI que vous utilisez dans du code JavaScript dans un onclick valeur d'attribut. Ainsi, le contexte linguistique ressemble à ceci :

Valeur d'attribut HTML
- Chaîne JavaScript
  - Segment de chemin d'URI

Et pour le rendre plus amusant :vous stockez cette valeur d'entrée dans une base de données.

Maintenant, pour stocker correctement cette valeur d'entrée dans votre base de données, il vous suffit d'utiliser un encodage approprié pour le contexte dans lequel vous êtes sur le point d'insérer cette valeur dans le langage de votre base de données (c'est-à-dire SQL); le reste n'a pas (encore) d'importance. Puisque vous voulez l'insérer dans une déclaration de chaîne SQL, les caractères spéciaux contextuels sont les caractères qui vous permettent de changer ce contexte. Comme pour les déclarations de chaîne, ces caractères sont (surtout) le " , ' , et \ caractères qui doivent être échappés. Mais comme déjà indiqué, les instructions préparées font tout ce travail pour vous, alors utilisez-les.

Maintenant que vous avez la valeur dans votre base de données, nous voulons les sortir correctement. Ici, nous procédons du contexte le plus interne au contexte le plus externe et appliquons le codage approprié dans chaque contexte :

Pour le segment de chemin URI contexte dont nous avons besoin pour échapper (au moins) à tous ces caractères qui nous permettent de changer ce contexte ; dans ce cas / (quitter le segment de chemin actuel), ? , et # (les deux quittent le contexte du chemin d'URI). Nous pouvons utiliser rawurlencode pour cela.
Pour la chaîne JavaScript contexte dont nous devons prendre soin " , ' , et \ . Nous pouvons utiliser json_encode pour cela (si disponible).
Pour la valeur d'attribut HTML nous devons nous occuper de & , " , ' , et < . Nous pouvons utiliser htmlspecialchars pour cela.

Maintenant tout ensemble :

'… onclick="'.htmlspecialchars('window.open("http://example.com/'.json_encode(rawurlencode($row['user-input'])).'")').'" …'

Maintenant, si $row['user-input'] est "bar/baz" la sortie est :

… onclick="window.open(&quot;http://example.com/&quot;%22bar%2Fbaz%22&quot;&quot;)" …

Mais utiliser toutes ces fonctions dans ces contextes n'est pas exagéré. Parce que même si les contextes peuvent avoir des caractères spéciaux similaires, ils ont des séquences d'échappement différentes. L'URI a ce qu'on appelle l'encodage en pourcentage, JavaScript a des séquences d'échappement comme \" et HTML a des références de caractères comme " . Et ne pas utiliser une seule de ces fonctions permettra de casser le contexte.