- Statut : non résolu
- Ce sujet contient 12 réponses, 5 participants et a été mis à jour pour la dernière fois par
, le il y a 13 années et 6 mois.
-
Messages
-
Bonjour,
Ma configuration WP actuelle
– Version de WordPress :
– Version de PHP/MySQL :
– Thème utilisé :
– Extensions en place :
– Nom de l’hebergeur :
– Adresse du site :Problème(s) rencontré(s) :
Bonjour,
Afin d’améliorer la sécurité de mon plugin StatPress Visitors, je voudrais protéger contre le deuxième type d’attaque décrites dans la vidéo donnée en lien par xknow: les attaques XSS (Cross Site Scripting) :
http://wordpress.tv/2011/01/29/mark-jaquith-theme-plugin-security/Il faut utiliser les fonctions esc_html(), esc_attr(), esc_url(), esc_url_raw(), esc_js(), esc_js(), esc_texarea(), mais où dois-je m’en servir ?
Est-ce au moment de l’insertion dans la base de données ? au moment de la lecture des données dans la BDD insérées avec $wpdb->insert ?
Bref, j’ai cherché sur le net une méthodologie pour ces attaques, et tout ce que j’ai trouvé, c’est l’usage de la fonction PHP strip_tags.
Or, mon plugin a copié sur le Statpress original l’analyse des données et il utilise déjà cette fonction strip_tag, pourtant le StatPress original a été victime d’une attaque XSS.
http://wordpress.org/support/topic/plugin-statpress-open-xss-vulnerabilityBref, comment je dois m’y prendre ?
Merci de votre éclairage !
Pour prévenir ce genre d’attaque, il le mieux est de contrôler/nettoyer les données entrées par l’utilisateur le plus tôt possible avant toute insertion dans la base de données.
Merci de la réponse, mais dans mon plugin, les visiteurs n’entrent aucune données, elles sont lues sur l’agent fourni par le client.
L’agent ressemble à ça :
Mozilla/5.0 (Windows NT 6.1) AppleWebKit/534.30 (KHTML, like Gecko) Chrome/12.0.742.122 Safari/534.30les autres données sont lues dans la variable globale $_SERVER
Et sur le site de WordPress, ils disent de ne protéger les données que le plus tard possible, soit au moment de l’enregistrement, alors qu’est-ce que je fais et surtout comment ?
« Tip: It’s best to do the output validation as late as possible, ideally as it’s being outputted, as opposed to further up in your script.«
http://codex.wordpress.org/Data_ValidationQuelle est la fonction WordPress qui remplace strip_tags ?
Quelles fonctions WordPress utiliser pour éviter les attaques XSS, comment choisir celle qui est adéquate ?
Merci.
Ce n’est pas suffisant nettoyer juste au moment de la sauvegarde, il faut le faire aussi au moment l’affichage des données.
Luciole135, avant de commencer à protéger votre plugin, vous devriez d’abord savoir quels sont les vulnerabilités les plus communes dans les applications web, la manière de les « exploiter », etc. Il existe beaucoup d’articles qui les expliquent. Ce serait trop long de tout expliquer dans ce forum.
Vous pouvez commencer dans le site owasp.org, qui est assez complet.xknown wrote:Luciole135, avant de commencer à protéger votre plugin, vous devriez d’abord savoir quels sont les vulnerabilités les plus communes dans les applications web, la manière de les « exploiter », etc. Il existe beaucoup d’articles qui les expliquent.Ben justement, je cherche sur le net sans arrêt et je ne trouve rien du tout !
Je ne dois pas faire la recherche avec les bons mots clefs.xknown wrote:Vous pouvez commencer dans le site owasp.org, qui est assez complet.Merci du lien, bon, bien sûr toute la doc intéressante est en anglais, cela va allonger mon temps de compréhension, mais bon si vous n’avez aucun lien en français à me proposer, je vais faire l’effort (surhumain…) de décrypter l’anglais et son jargon informatique…
Il y a des traductions pour certains articles, par exemple cela pourrait être un bon début http://owasptop10.googlecode.com/files/OWASP%20Top%2010%20-%202010%20French.pdf
Je ne vous envoie pas de liens en francais car je ne lis malheureusement pas de sites francophones.
Ah oui, ça c’est géant 22 pages rien qu’en français, je vais pouvoir me concentrer sur le sens et pas la syntaxe, je vais aller bien plus vite.
Jusqu’aujourd’hui la sécurisation, les risques, les URL et les fonctions spécifiques de WordPress, c’est le grand brouillard, je n’y pige rien du tout. Pourtant, j’ai appris SQL en 1 mois et j’ai réussi, ce dont je suis assez content à diviser par 20 jusqu’à 50 le nombre de requêtes SQL du plugin en utilisant la théorie des ensembles ou l’index naturel de la table. Mais, là, je suis en plein brouillard.
Enfin, une lumière !
Merci 🙂
En gros les principes de base de la sécurisation c’est
1- je n’enregistre que le type de données que je veux enregistrer, donc je vérifie avant que tout correspond à ce qui est attendu, ce qui va plus loin que les htmlentities et autres nettoyages de base
2- quand on cherche à afficher quelque chose qui correspond à un enregistrement de la base, je vérifie que cet enregistrement existe bien dans la base, et si il n’existe pas je renvoie le message d’erreur que je décide
3- faire en sorte qu’il ne soit pas possible d’ajouter à une url une adresse php ou javascriptIl y a donc tout un travail qui consiste à réfléchir à ce qu’on veut accepter comme données, et à tout bloquer ensuite.
Donc par exemple, dans ton cas, faire une liste des agents acceptables, etc…
wasicu wrote:Un ti coup d’œil indiscret sur le code de cform2 et tu vois qu’il met du htmlspecialchars partout.Merci,
Mais, c’est justement ce que je veux éviter, car htmlspecialchar est une fonction PHP. Je veux utiliser au maximum les fonctions natives de WordPress donc trouver l’équivalent WordPress de htmlspecialchar.Bref, utiliser toutes les ressources de WordPress et s’il n’y en a pas pour résoudre le problème, alors oui, utiliser PHP.
Je pense qu’un plugin WordPress doit en premier lieu s’écrire avec les fonctions WordPress, cela facilite sa maintenance et la compréhension de son code.
Lumière de Lune wrote:En gros les principes de base de la sécurisation c’est
1- je n’enregistre que le type de données que je veux enregistrer, donc je vérifie avant que tout correspond à ce qui est attendu, ce qui va plus loin que les htmlentities et autres nettoyages de base
2- quand on cherche à afficher quelque chose qui correspond à un enregistrement de la base, je vérifie que cet enregistrement existe bien dans la base, et si il n’existe pas je renvoie le message d’erreur que je décide
3- faire en sorte qu’il ne soit pas possible d’ajouter à une url une adresse php ou javascriptIl y a donc tout un travail qui consiste à réfléchir à ce qu’on veut accepter comme données, et à tout bloquer ensuite.
Donc par exemple, dans ton cas, faire une liste des agents acceptables, etc…
Merci,
Je commence à comprendre le problème : les pirates s’amusent à ajouter du code un peu partout (notamment dans les URL) et on doit vérifier que les URL fournies n’en contiennent pas, donc sont vraiment des URL et pas autre chose.Pour les agents acceptables, il y a des listes impressionnantes d’agents existants (plusieurs milliers) sur les sites web spécialisés et tous sont différents, alors, je dois donc trouver le point commun, le minimum commun que chacun doit vérifier. Il va falloir que je travaille cela.
Y a du boulot.
🙂
luciole135 wrote:Mais, c’est justement ce que je veux éviter, car htmlspecialchar est une fonction PHP. Je veux utiliser au maximum les fonctions natives de WordPress donc trouver l’équivalent WordPress de htmlspecialchar.Bref, utiliser toutes les ressources de WordPress et s’il n’y en a pas pour résoudre le problème, alors oui, utiliser PHP.
Je pense qu’un plugin WordPress doit en premier lieu s’écrire avec les fonctions WordPress, cela facilite sa maintenance et la compréhension de son code.
Je sais que tu ne causes pas volontiers l’anglois, ce que je comprends, après tout ils ont brulé notre Jeanne d’Arc à Rouen. 😆 mais parfois, on a pas le choix ou alors il faut utiliser dotclear. (Olivier Meunier et ou Xavier Plantefève sentent bon le terroir, c’est pas comme Matthew Mullenweg….)
Ici le codex sur esc_html() http://codex.wordpress.org/Function_Reference/esc_html
et ici http://core.trac.wordpress.org/ticket/10874 où tu peux lire : Use esc_html() instead of htmlspecialchars() when appropriate
Mes connaissance php étant ce qu’elles sont. (À l’heure actuelle, je me suis promis de m’y mettre), je ne peux t’aider à juger quand est-ce que c’est approprié.
- Vous devez être connecté pour répondre à ce sujet.