Réalisation d'un petit tchat

[Xenos]

\r\n est le saut de ligne de windows (et non \n\r). L'astuce (merci StackOverflow!): c'est dans le même ordre que "\r-etur\n"

Ah làlà, si seulement les injections n'existaient pas... Je sens qu'un pseudo comme "chose&message=xxx" ou qu'un message comme "je suis spécial&pseudo=admin" devrait faire des merveilles :roll:
Il existe des fonctions pour construire proprement les URIs ou sérialiser des paramètres, creuse dans cette direction.

Et donc oui, c'est bien ce que je pensais: ton append() ajoute du code HTML (hyper-injectable là aussi, c'est pour ce genre de problème que les services tiers & autres FW ou codes existants sont bien pl adaptés) puis ton sélecteur va le récupérer et le placer au bon endroit.
Un simple $('.conteneur_tchat').prepend($('<div...>')) sera plus efficace (au sens où tu ne feras qu'une création de noeud suivie d'une insertion, au lieu d'une création de noeud, d'une insertion, d'une sélection puis d'un déplacement).

PS: si j'effectue une requête POST avec des paramètres comme "pseudo=admin&message=vous êtes tous virés!" sur l'URI du tchat, sans être connecté, cela enverra un message au nom de l'admin? Et si je suis connecté, de même, je peux envoyer un message au nom de quelqu'un d'autre?

[Ter Rowan]

je suis d accord avec Xenos sur la partie ajax, et de toute façon sur le sujet "prend un truc qui marche déjà, pas un truc qui permet d apprendre"

par contre on ne peut pas conclure sur le code montré qu'il y aura injection html : ce qu'on voit c'est que la page html vu par l'utilisateur reçoit du html produit par l'utilisateur, on ne sait pas si les autres utilisateurs recevront ce code html ou si le serveur contrôle corrige protège le code html (laissons le bénéfice du doute)

après j'aime pas trop le système du .after tel que tu l'as fait  :

ton système semble marché car ton ajax est pour le moment rapide : considère un temps de latence forte ou l'utilisateur envoie msg 1 puis msg 2 avant qu'ajax ne réactualise tu auras cela :


utilisateur voit : [anciens messages]

utilisateur saisit msg 1

utilisateur voit : [anciens messages][msg 1]

utilisateur saisit msg 2

utilisateur voit : [anciens messages][msg 2][msg 1]


pour moi tu devrais plutôt avoir pour chaque message une classe "msg" qu'il soit ancien ou nouveau

<span class="msg">ancien 1</span>

<span class="msg">ancien 2</span>

<span class="msg">ancien 3</span>



$( ".msg" ).last().after( "<span class="msg">nouveau 1</span>");



<span class="msg">ancien 1</span>

<span class="msg">ancien 2</span>

<span class="msg">ancien 3</span>

<span class="msg">nouveau 1</span>





$( ".msg" ).last().after( "<span class="msg">nouveau 2</span>");



<span class="msg">ancien 1</span>

<span class="msg">ancien 2</span>

<span class="msg">ancien 3</span>

<span class="msg">nouveau 1</span>

<span class="msg">nouveau 2</span>

attention ce n est pas du vrai code mais du concept

[Xenos]

Ce n'est de toute façon pas au serveur de faire l'échappement HTML en prévision de l'emplacement où sera peut-être inséré le résultat dans le JS coté client.

[xanthius]

Bonjour,
pour le pseudo il utilise celui de la session en cours. L'utilisateur n'a aucun accès pour entrer un pseudo. Le système affiche le nom de l'auteur mais c'est tout. On ne peut donc pas utiliser le pseudo d'un autre.
Je fais aussi un traitement dans la partie php, je re vérifie que le nom est bien celui de la personne connecté.

Par contre, je n'y connais rien en injection pour le js. Vue que l'utilisateur n'a accès qu'au textarea, que peut il faire qui pourrait nuire au script ?

[Xenos]

Ben, apparemment, non puisque tu envoies "pseudo" en paramètre POST à ton URI, donc ce n'est pas le pseudo de la session que cette URI récupère.

Le principe général est simple: n'importe quelle entrée peut contenir n'importe quoi.

Donc, dans ton cas, ton $('#pseudo').val() peut renvoyer n'importe quoi, et pseudo est donc une chaîne de texte quelconque. Si tu la concatène à une URI ou à des paramètres d'URI (comme ton 'pseudo=' + pseudo + '&message=...'), alors la machine n'aura aucun moyen de savoir que tu veux faire "pseudo={la valeur de pseudo}&message={la valeur du message}". Elle verra seulement 'pseudo=gnagna&message=lalala' et elle l'interprètera ensuite comme une URI. Si le pseudo du joueur est "&pseudo=", alors ta chaîne concaténée sera pseudo=&pseudo=&message=lala. Le serveur interprétera donc cela comme un message venant d'un joueur sans pseudo...

De même, n'importe qui peut faire une requête à ta page "game/core/ajax/envoi_tchat.php" en envoyant un pseudo et un message quelconque (tu peux le faire avec cURL par exemple, que ce soit dans PHP ou dans cygwin/bash).


Un peu de lecture:
http://toile.reinom.com/regle-anti-injection/
http://toile.reinom.com/connaitre-lorigi...injection/
http://toile.reinom.com/tag/securite/



PS:
Ah oui, quand même... C'est volontaire?
Un autre petit guide sur les fichiers PHP privés/publics

[xanthius]

je connais ce principe, never trust user. voilà comme j'ai procédé.
j'ai inséré dans un input caché la variable de session, par la suite le js récupère cette valeur.
Cette méthode n'est pas bonne ?


Deuxièmement, merci pour ta gifle (très énorme). Heureusement que tu m'as prévenu, merci pour les articles je regarderais ça !

Edit :
J'ai jeté un coup d'oeil, du moins j'ai lu et relu et mis en place certaines mesures prescrites par le tuto. Merci pour le lien, merci pour cette baffe qui m'a fait réagir.
Il serait bien de mettre le lien de ce tuto en évidence, que les nouveaux comme les anciens puissent jeter un oeil, ça en aidera plus d'un !

[Xenos]

J'essaierai de mettre des thématiques en place sur ce blog, ce qui permettra de les mettre en avant par la suite (je pense qu'il y a maintenant assez de contenu sur ce blog pour le faire).

Et note que pour ta question, "l'input caché" ne l'est qu'aux yeux de l'utilisateur lambda: le contenu de cet input peut être altéré sans problème par un utilisateur avancé (et le JS va donc récupérer n'importe quelle valeur). Par principe, pour le JS, la valeur piochée dans l'input du DOM est une donnée extérieure au JS, donc, elle ne doit pas être considérée comme "sûre" ni comme "intègre". Ce n'est pas tant "never trust the user", ou "never trust the client", mais bien "never trust the outside" qu'il faut appliquer, et le DOM (la page HTML) est le "outside" du JS.

Pour le reste, ce JS va en faire quoi de cette valeur? Il va l'envoyer dans une requête Ajax n'est-ce pas? Cette requête va être récupérée et traitée par le serveur? Donc, là aussi, pour le serveur, le JS est "outside". On a donc deux points d'altération possible: modifier le DOM (le input caché) pour tromper le JS, ou modifier le JS pour tromper le serveur (ce qu'on peut aussi faire sans modifier le JS, en passant par cURL, c'est à dire en envoyant directement une requête HTTP au serveur; d'ailleurs, le message de 'MesGenoux' qui est probablement apparu sur ton tchat a été envoyé par cURL).

L'important, que ce soit pour la sécurité ou pour "coder propre", c'est de bien savoir délimiter les frontières de chaque composant (osef un peu des "responsabilités" en fait, ce qui compte, c'est savoir où un composant s'arrête et où il démarre). Partant de là, pour la sécurité, tout ce qui se trouvera hors de cette frontière devra être vérifié et validé avant d'être utilisé dans le composant en question.

Et je suis ravi de voir que mes articles ont pu te servir et t'aider

[xanthius]

Bonjour,
oui il faut vraiment le mettre en avant car je suis sur que je ne suis pas un cas isolé (si c'est le cas et bah c'est pas très jolie pour moi)..

Concernant le tchat, non ton message n'a pas arrivé à s'insérer. Du moins, il a réussi mais à moitié.
Je suis d'accord avec toi sur le fait que le js va pouvoir afficher le message pirate mais il ne sera pas inséré dans la BDD.
Comme dit précédemment j'utilise la variable de session en cours du joueur pour transmettre le message dans la bdd, si elle n'est pas en active et bien le traitement php et donc l'insertion n'est pas effectué, seul le js va afficher mais provisoirement (5s).

Du coup,
j'ai passé toute ma soirée d'hier soir à revoir les fichiers du jeu, à insérer les protections. Je ne dis pas là qu'il est devenu infranchissable mais il fait moins passoire qu'hier soir et ça grâce à toi ! Il reste des points à revoir, ce que je ferais mais on a franchi un cap en terme de sécurité.

[Xenos]

Ok, je verrai pour mettre tout ça en structure et en avant. Merci de ton soutien

Dans ce cas, si le pseudo est inutile, autant ne pas l'envoyer dans ta requête AJAX.
(PS: le problème restera entier si un utilisateur s'inscrit sous le pseudo "&pseudo="... Ok, ça se verra, mais un utilisateur légitimement appelé "Truc & Much" aura aussi des soucis)