Discussion :

[redah75]

Bonsoir tout le monde, j'espère être dans la bonne rubrique!

Je suis un utilisateur Mac & Safari. Safari propose "l'inspection du Code" et modification du code source, un peu du genre de Firebug...
je flippe depuis quelques heures en remarquant que je peux modifier le code source et que ça peut être prix en compte par le serveur.
Ex.:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

<input type="hidden" name="prix" value="20.25">

je peux modifier le prix à ma guise et soumettre le formulaire!!

que pourrais je faire pour contourner ce problème???

Je vous remercie infiniment
Reda

[transgohan]

Tu ne peux pas modifier le code sur le serveur encore heureusement...
Par contre oui il est possible de modifier le code client.
C'est pour ça qu'il faut toujours vérifier les valeurs renvoyées depuis l'application cliente.
Un prix ne devrait pas être donné par l'application cliente mais plutôt extrait d'une base de données qui elle ne peut être modifiée par le client.

[redah75]

Merci pour ta réponse.
Oui je sais qu'on ne peut modifier le code sur le serveur, et fort heureusement comme tu dis...

OK, je vais revoir mon code afin d'éviter de transmettre des données importantes telles que le prix et autres...

Merci encore une fois

[redah75]

une petite précision STP

Est ce conseillé d'utiliser les sessions afin d'éviter trop de requêtes SQL??

[transgohan]

Si ce sont des données qui doivent être affichées constamment et qui se trouvent dans ta BDD il peut en effet être judicieux de les serialiser et de les faire transiter via session.

[SucreGlace]

Le problème que tu évoques (la possibilité pour l'utilisateur de modifier le contenu d'un formulaire pré-rempli) n'est pas limité qu'à ce cas particulier.
De manière générale, toutes les données en provenance de l'utilisateur peuvent avoir fait l'objet d'une manipulation que tu n'avais pas prévue.

Si tu construis ton site de manière à ce que la page www.example.com/user?id=3 ne s'affiche qu'après que l'utilisateur n°3 se soit identifié, cela n'empêchera pas les petits malins d'essayer de voir le profil d'un autre utilisateur en accédant directement à l'adresse www.example.com/user?id=5.
Il faut vérifier que l'utilisateur a bien le droit de voir les données en question avant de les lui fournir.

Si tu construis un formulaire utilisant un champ <input type="hidden" name="id" value="3"/> afin de permettre à l'utilisateur n°3 de modifier son profil, cela n'empêchera pas les petits malins d'essayer de modifier le profil de l'utilisateur n°5 en modifiant la valeur envoyée pour le paramètre id.
Il faut vérifier que l'utilisateur a bien le droit d'effectuer cette modification avant de l'enregistrer.

Si tu te bases sur un cookie du type id=3 pour identifier un utilisateur, cela n'empêchera pas les petits malins d'essayer de se faire passer pour un autre utilisateur en modifiant la valeur du cookie à id=5.
Il ne faut jamais "identifier" un utilisateur en se basant sur un bête paramètre id qu'il a fourni lui-même !

Tu peux mettre en place des contrôles en javascript sur la page afin de faciliter l'utilisation d'un formulaire (remplissage automatique de certains champs, contrôle du format avant même de soumettre le formulaire, etc...) mais tu dois garder à l'esprit que l'utilisateur peut contourner tous les contrôles qui ont lieu sur son navigateur.
Il faut toujours répéter les contrôles côté serveur - le seul côté que sur lequel tu as réellement le contrôle.

Lorsque ton serveur web reçoit une requête HTTP, celle-ci se compose basiquement d'un URL, de différents headers, et de paramètres clé-valeur (paramètres GET et POST, cookies...).
Toutes ces valeurs peuvent avoir été manipulées par l'utilisateur et contenir ce qu'il veut, quels que soit les URL "cachés" pour lesquels tu n'avais pas fourni de lien, les valeurs avec lesquelles tu avais pré-rempli les paramètres, ou les mécanismes de contrôle que tu avais placés côté navigateur.


Tout ceci n'est pas une incitation à la paranoïa mais un rappel du fonctionnement du web :
Le client émet une requête qui peut contenir littéralement n'importe quoi.
Le serveur doit effectuer toutes les vérifications nécessaires afin de décider de la façon dont il va traiter cette requête : vérification de la cohérence de la requête, vérification de l'identité de son émetteur et de ses autorisations à effectuer telle ou telle action, etc...

Dans ton exemple :
Laisser l'utilisateur définir le nombre d'articles qu'il veut mettre dans son panier, c'est normal.
Laisser l'utilisateur définir le prix des articles qu'il veut mettre dans son panier... c'est problématique

[redah75]

Un grand merci a transgohan ainsi qu'a SucreGlace pour ta réponse bien détaillée

generalement, je ne garde jamais l'identifiant d'un utilisateur dans un cookie ou meme le faire passer comme paramètre dans l'URL, j'utilise toujours les session pour stocker des info telles que l'identifiant du client ou l'identifiant de la commande...