Est-ce que htmlspcialchars($user_data) en PHP ou h(user_data) dans Ruby on Rails est assez bon pour défendre tous les cas d'attaques XSS (Cross-site scripting)? Qu'en est-il de l'encodage utilisé ou d'autres considérations possibles?est htmlspecialchars() en PHP ou h() dans Ruby on Rails assez bon pour défendre tous les cas d'attaques XSS (Cross-site scripting)?
Tous les caractères et h échappent à tous les caractères qui peuvent avoir une signification spéciale en HTML, il n'y a aucun moyen que HTML littéral puisse être injecté dans la page cible.
Cependant, il existe des moyens d'exécuter Javascript (dangereux) qui ne nécessitent pas d'injection HTML. Par exemple, si vous avez une application qui convertit [img http://example.com/img.jpg] en <img src="http://example.com/img.jpg/>, imaginez ce qui peut se produire si un utilisateur entre [img javascript:alert(document.cookies);]. L'échappement des caractères HTML ne vous sauvera pas ici, vous devez nettoyer les URLs donnés. This is a fairly comprehensive list of possible XSS vulnerability examples.
Si vous utilisez toujours htmlspecialchars/het vous désinfectez toujours complètement l'entrée d'utilisateur qui est utilisé en tant que valeurs d'attribut dans les éléments HTML, alors vous avez une défense adéquate XSS.
En général il y a three different types of XSS: le DOM basé, le non persistant et persistante.
que le premier ne se déroule sur le côté clientmaintenant les langages côté serveur ne peut empêcher les deux derniers (non persistant et persistante).
Vous pouvez également essayer d'utiliser strip_tags si vous n'autorisez pas les balises HTML dans les publications. En outre, consultez html purifier
Je ne recommanderais pas strip_tags du tout. L'utilisateur pourrait simplement taper quelque chose comme ipt> et avoir le "script" du milieu dépouillé et avoir le "script" extérieur laissé intacte. Il est préférable d'utiliser html purifier ou htmlentities avec ENT_QUOTES. –