8721 sujets

Développement web côté serveur, CMS

[Résolu] Passage de données $_POST

Bonjour les développeurs !

J'utilise le genre de code ci dessous dans une page1, pour envoyer une donnée $_POST à une page2 :


<FORM name="formulaire" method="POST" action="page2.php">
     <input type="hidden" name="<?php echo $param ?>" value="<?php echo $valeur ?>"/>
</FORM>
<!-- et pour forcer le submit -->
<script type="text/javascript"> 
     document.forms['formulaire'].submit();
</script>


page1 est en quelquesorte un "sésame ouvres toi" : Si JS est actif, le mot de passe est transmis à la transaction page2.php

Hélas, quand on désactive JS (le formulaire n'étant plus envoyé), le clic droit sur page1 dévoilera inévitablement les contenus "name" et "value", bien qu'ils contiennent du code php. En d'autres termes le mot de passe sera dévoilé.

Ma réflexion est la suivante : puisque page2 attend une donnée POST, je pense qu'un "petit malin" pourrait très bien créer une page html (en utilisant lui aussi un formulaire), et ainsi accéder à page2 pour y faire ce qu'il veut.

Par "paranoïa" j'utilise donc $_SESSION, pour passer ce "sésame", mais je trouve que c'est mettre en branle une usine à gaz pour très peu de données...

Auriez-vous une autre idée ?
Il ne faut jamais passer ce genre de données via get ou post.
Si tu as un mot de passe à faire passer, personnellement je le stockerais dans une base de données (encrypté au préalable avec md5, sha1 ou autre hein), et je le récupèrerais grâce à un cookie installé plus tôt.

En effet ce que tu fais là n'est pas sécurisé.
Bonjour,
Bcp d'alsanautes ont lu mon "billet" mais pour l'instant, je n'ai eu que votre suggestion, au demeurant ultra sécurisée, dont je vous remercie.
La donnée que je souhaitais protéger est en réalité un moyen de vérifier que l'internaute respecte bien le chemin balisé par le site.
Il ne s'agit pas d'une donnée confidentielle, juste un "sésame" pour passer d'une page1 à un formulaire2.
Page1 est en fait un aiguillage : Si JS est activé j'irai à page2 et les données saisies seront alors être traitées par mes routines JS, sinon j'affiche un texte explicatif accompagné d'un lien permettant à l'utilisateur d'activer JS
La faille de cette façon de faire, est justement de désactiver volontairement JS, et d'obtenir ainsi le "sesame" pour l'utiliser ensuite à des fins de nuisance : Créer une page avec un formulaire en POST et l'utiliser hors JS pour shunter tous les contrôles prévus dans ma page2.
Voilà. C'est pourquoi je passe par $_SESSION bien que je trouve cela un peu lourd...
Encore merci pour votre solution.
Cdlt
Bonsoir,
pour ceux qui s'intéressaient au sujet : voici le code de cet "aiguillage" :
<?php
     session_start() ;
     $_SESSION['psswrd']="ske-tu-veux" ;
?>
<html>
<head>
     <meta name="robots" content="noindex">    
     <script type="text/javascript">
          window.location.href="formulaire.php" ;
     </script>     
     <meta http-equiv="refresh" content="0; URL=warning.php">          
</head>
<body/>
</html>

Explications : si JS est actif chez le client, il aura accès au formulaire de contact, sinon il est redirigé vers une page d'avertissement, sollicitant l'activation de JS.
Dans les deux cas je tue $_SESSION après traitement dans ces deux pages.

Cette solution est meilleure que le <noscript><meta http-equiv="refresh"........></noscript> qui ne respecte pas la norme W3C. En effet <noscript> est une balise du "body" alors que <meta> doit se trouver dans le "head"...

Voilà
Modérateur
En fait je comprends pas du tout ce que tu veux faire, ni même pourquoi il y a du javascript ou du rafraîchissement de page.

D'un côté tu souhaites que l'utilisateur respecte scrupuleusement un chemin de navigation en évitant tout moyen d'y échapper. D'un autre côté tu dis qu'il n'y rien d'important en terme de sécurité. C'est contradictoire. S'il n'y a rien d'important alors ne met pas en place un système ultra-complexe, peu importe que des malins puissent filouter, et si c'est important fais-ça proprement…
Bonsoir,

Oui bien sûr, il y a toujours des petits malins qui s'amusent à percer des trous, mais j'essaie de sécuriser à minima.

Il va sans dire mais c'est mieux en le disant, que ce "password" est vérifié (tests php avant d'afficher le HTML FORM) : en d'autres termes, pas de mot de passe, pas de formulaire.

Ainsi il n'est pas possible d' accéder au formulaire sans respecter le chemin du site. (par exemple en tapant directement dans la barre d'adresse du navigateur.

Si l'utilidateur a activé JS, et qu'il suit les liens du site, il aura donc accès à mon formulaire. Ses entrées seront alors soumises aux routines JS de vérification (Pour qu'il ne tape pas n'importe quoi, et comme je suis bon prince, je remets même en forme la textarea, qui sera soumise à son approbation)

Certes, il n'est pas de forteresse imprenable, mais elles ont au moins : une muraille, des fossés en eau et un pont-levis...

Cordialement.

PS : Si vous avez des solutions encore plus sûres, je suis à l'écoute.
Bonsoir KUSTO,

Le code que j'ai donné est un simple aiguiillage (a switchPoint). Si le client a JS actif, il aura accès au formulaire, sinon il aura un carton d'invitation pour l'activer.
C'est une page sans body qui va juste tester si le client a activé JS, ce n'est rien d'autre que cela.

Si JS est actif, formulaire.php sera chargé. Dans le cas contraire, le JS étant ignoré, warning.php (le carton d'invitation) sera appelé en séquence. Et puis c'est tout, comme disait Philippe Lucas l'entraineur de l'indisciplinée Manaudou....

Quant à la donnée $_SESSION, elle sert à vérifier que le chemin a bien été respecté, ainsi il ne sera pas possible d'accéder directement au formulaire par la barre d'adresse, ni même par l'historique !

Cordialement
Modérateur
Dans ce cas là c'est donc un vrai faux problème.

La validation serveur n'est jamais optionnelle sur un formulaire, la validation JS ou HTML5 n'est toujours qu'un confort supplémentaire pour l'utilisateur.

Surtout qu'il y a moults façon de contourner cela. Le plus simple étant de désactiver javascript après être arrivé sur le formulaire… En plus, il suffit que js s'arrête à cause d'une erreur pour que toute la validation disparaisse (que ce soit un bug du navigateur, un bug de ton code, un module qui fiche la galère, ou tout simplement le fichier js qui ne se charge pas).

De plus, forcer l'utilisateur (qui n'a rien à se reprocher) à se manger une redirection à cause d'un défaut de conception du site, c'est plutôt moyen.
Bonjour KUSTO !

En avant-propos je signale que j'estimais le sujet résolu, et j'en avais informé ceux qui avaient suivi ce "post". Je n'imaginais pas un tel retour de flamme !...

D'abord, au départ vous ne compreniez pas, et maintenant que vous entrevoyez une lueur vous vous empressez de l'éteindre. Voici donc ma réponse à vos remarques :

1° Quand JS est désactivé par la boîte à outils, il faut quitter le navigateur pour que cela devienne effectif. Par conséquent l'accès au formulaire sans JS sera interdit à la prochaine tentative (c'est le sujet même de ce post s'il faut encore le rappeler).

2° Les routines JS de vérification du FORM, sont là pour vérifier que l'utilisateur ne tape n'importe quoi, ou s'amuse à nuire. Or vous invoquez curieusement un bug de mon code, alors que ces routines ont été écrites pour justement éviter cela...
En revanche, vous avez raison, un bug dans un script JS entrainera la neutralisation de celui-ci. Mais encore faut-il arriver à le planter !...
En d'autres termes vous sous-entendez que les scripts JS sont inévitablement mal-écrits. Désolé de le souligner mais ccette remela sent fortement l'intolérance...

3° Enfin il reste, les erreurs système (ça je ne peux pas le tester) mais si "ça plante" comment êtes vous si sûr que mon application restera accessible ???

Je terminerais enfin par une réflexion d'ordre général. Mozilla Firefox a récemment oté de sa boîte à outils la possibilité de désactiver JS. C'est un choix radical certes, mais qui démontre bien l'importance qu'accorde ce constructeur à javascript, qui de fait est devenu incontournable...

Cdlt
iakou a écrit :

Je terminerais enfin par une réflexion d'ordre général. Mozilla Firefox a récemment oté de sa boîte à outils la possibilité de désactiver JS. C'est un choix radical certes, mais qui démontre bien l'importance qu'accorde ce constructeur à javascript, qui de fait est devenu incontournable...


C'est faux. Ils ont juste modifié la manière d'accéder à cette fonctionnalité. On peut toujours désactiver JavaScript dans les dernières versions de Firefox.

De toute manière Kusto a raison, même si tu fais une vérification en JS il faut obligatoirement vérifier et valider tes données côté serveur. Le JS n'offre aucune forme de sécurité. Dans ton cas il est tout simple de laisser JavaScript activé, entrer des donner valides, soumettre le formulaire puis modifier les données POST à la volée avant qu'elle soient envoyées au serveur. Techniquement ça ne présente aucune difficulté.
Bonjour,

Ouh la la !... 2 contradicteurs maintenant !

D'abord si vous savez comment désactiver JS sur firefox, faites en profiter tout le monde plutôt que de procéder par simple affirmation...

Par ailleurs, si vous pouviez indiquer comment modifier les $_POST à la volée, on pourrait se pencher sur cette faille. J'ai déjà mon idée, mais si vous aviez un lien sur cette problématique cela intéresserait les lecteurs. D'avance merci.

Enfin, où vous ai-je dit que je n'ai pas de contrôle côté serveur ?

Cdlt
iakou a écrit :

D'abord si vous savez comment désactiver JS sur firefox, faites en profiter tout le monde plutôt que de procéder par simple affirmation...


about:config -> javascript.enabled

Ou bien simplement avec une extension populaire comme NoScript ou plus spécialisée comment Webdevelopper Toolbar.

iakou a écrit :

Par ailleurs, si vous pouviez indiquer comment modifier les $_POST à la volée, on pourrait se pencher sur cette faille. J'ai déjà mon idée, mais si vous aviez un lien sur cette problématique cela intéresserait les lecteurs. D'avance merci.


Il y a bien 50 techniques possible pour faire ça. Si tu ne sais pas comment le faire manuellement tu peux utiliser un outil qui propose ce genre de choses comme une extension pour Firefox comme Tamper Data.
Modifié par jb_gfx (21 Nov 2013 - 14:45)
a écrit :
2° Les routines JS de vérification du FORM, sont là pour vérifier que l'utilisateur ne tape n'importe quoi, ou s'amuse à nuire. Or vous invoquez curieusement un bug de mon code, alors que ces routines ont été écrites pour justement éviter cela...

Si j'ai vraiment envie de te nuire, je fais un script CURL et je te spam ou je tente une injection quand je veux. Javascript ou pas, c'est pareil. Les vérifications coté client, ça se contourne facilement, ça n'apporte aucune protection. Elles sont juste là pour le confort du client, c'est tout !


a écrit :
En revanche, vous avez raison, un bug dans un script JS entrainera la neutralisation de celui-ci. Mais encore faut-il arriver à le planter !...

Plus simple que d'essayer de le planter, on peut simplement le désactiver. Plusieurs moyens de désactiver javascript très facilement ont été données dans les interventions précédentes. ET puis il y a telnet, CURL et n'importe quel autre client alternatif que tu pourras programmer.

a écrit :
En d'autres termes vous sous-entendez que les scripts JS sont inévitablement mal-écrits.

En mode mauvaise langue, je dirais que oui, 99% des codes javascript qui circulent sur le web ont été mal écrits ou n'ont pas lieu d'être, pour tout un tas de raisons variées. Mais ce serait dénigrer ceux qui font du bon travail.


N'oublie jamais que le client peut, à n'importe quel moment et arbitrairement, décider de zapper totalement tous les traitements que tu lui demandes de faire, ou faire complètement autre chose à la place. Tu contrôles ce que fait le serveur, mais jamais ce que fait le client.

Si tu as besoin de t'assurer que javascript est disponible et activé, par exemple parce qu'une page ne peut pas fonctionner sans js, le mieux c'est de générer une valeur en javascript dans un champ hidden et de la vérifier côté serveur ensuite. Et puis, bien sûr, prévenir l'utilisateur que la page suivante nécéssite javascript.

Mais ne fais ça que si ta page a un besoin obligatoire et pleinement justifié de js, et s'il n'est vraiment pas possible d'y échapper: un jeu, un chat, une application de manipulation audio/images/vidéo, etc. Si c'est juste pour un contrôle de sécurité ou une petite animation fondamentalement facultative, c'est idiot et ça ne sert à rien.

Note: le coup de la valeur générée par javascript peut éventuellement être un bon CAPTCHA, les robots spammeurs n'ont pas de temps à perdre avec javascript.
Bonjour !

D'abord, merci de toutes ces précisions, bien que je constate qu'on procède toujours par affirmation et non par démonstration :

En ce qui me concerne, la désactivation de JS (par la boite à outils) ne sera effective que quand on quitte le navigateur (cela a été testé), par conséquent mon application ne permettra pas une tentative d'accès au formulaire si JS est désactivé.

En revanche jb_gfx a raison, 'Tamper Data' permet de modifier les $_POST malgré les routines JS que le développeur ait pu mettre en place. Cela est une réelle faille et c'est bien cela qui m'embête !

Dès lors, on comprend mieux la position de Mozilla qui a oté la désactivation JS de sa boîte à outils : En effet, à quoi bon laisser la possibilité de désactiver javascript, puisque de toute façon on peut neutraliser les contrôle (Tamper Data n'est-il pas un plug-in Mozilla ?...)

http://korben.info/mozilla-retire-loption-qui-permet-de-desactiver-le-javascript-dans-firefox-et-cest-une-bonne-idee.html

Cdlt
iakou a écrit :
1° Quand JS est désactivé par la boîte à outils, il faut quitter le navigateur pour que cela devienne effectif. Par conséquent l'accès au formulaire sans JS sera interdit à la prochaine tentative (c'est le sujet même de ce post s'il faut encore le rappeler).

opera, F12, décocher la case "activer le javascript"

Aucun besoin de quitter le navigateur ou de faire quoique ce soit, ça prend 3 secondes, je le désactive et le réactive à volonté, une fois sur la page. (je dois l'utiliser assez souvent, à cause de programmeurs qui font justement des javascripts imbuvables ^^)
a écrit :
En ce qui me concerne, la désactivation de JS (par la boite à outils) ne sera effective que quand on quitte le navigateur (cela a été testé), par conséquent mon application ne permettra pas une tentative d'accès au formulaire si JS est désactivé.

IL me semble pourtant que jb_gfx t'a donné une façon très simple de le faire sans redémarrer le navigateur.

Remarque, je peux aussi mettre en place un proxy local qui, comme par hasard, supprime le script de la deuxième page après avoir passé ta « vérification ». Et voilà, plus de js !

a écrit :
bien que je constate qu'on procède toujours par affirmation et non par démonstration :

Il faut te dire quoi pour t'expliquer que la sécurité de ton truc est complètement pourrie ?
Revois les bases, never trust user input, tout ça tout ça.
Cher QuentinC

Si vous ne savez pas expliquer sans être "hautain", cela vous jouera un jour un mauvais tour !... Si ce n'est déjà fait....

Cela aussi est une affirmation !... Suivie d'une quasi-certitude...

Bref, j'ai testé le about:config (j'ai dû un peu chercher, car je n'avais pas le mode d'emploi) et effectivement on peut désactiver et revenir par l'historique sur la page à "neutraliser".

C'est même pire que Tamper Data dont on pouvait encore s'accommoder.

Si on l'avait expliqué calmement...

Il ne me reste plus qu'à bétonner les contrôles côté serveur, et compte tenu de l'aggressivité ambiante je considère ce post définitivement clos.
ou alors, il suffit d'avoir un navigateur comme opera et y a moyen de désactiver le javascript n'importe quand en une touche et un clic, sur n'importe quel page, sans changer de page et c'est effectif directement.

Après, oui, en sécurité, la règle primaire est de ne jamais faire confiance en une donnée venant de l'utilisateur. Ne jamais oublier que le javascript (dans son utilisation classique) est coté client et donc peut être adapté/modifié/trifouillé/sauté,...
Bonjour,

Pour ceux qui s'intéressaient à ce débat, je précise que ma sécurité côté serveur est assurée voire blindée...

En revanche, côté client je n'ai pas abandonné mon petit aiguillage, que j'ai toutefois corrigé car il perturbait le fonctionnement de l'historique sous IE. Je vous donne ma dernière "mouture" :
<html>
<head>
<meta name="robots" content="noindex">    
<script type="text/javascript">
     var nav = navigator.appName;
     if (nav == "Microsoft Internet Explorer") document.location.[b]replace[/b]= "contact.php";    
     document.location.[b]href[/b]= "contact.php";
</script>     
<meta http-equiv="refresh" content="0; URL=warning.html">          
</head>
<body/>
</html>
Explications :
Je rappelle le fonctionnement : Si le client a JS il accède au formulaire (contact.php) sinon il est redirigé vers une page d'invitation (warning.html)...
S'agissant d'un simple aiguillage (donc sans affichage) tous les navigateurs ignoraient cette page dans leur historique. Mais IE au contraire la repertoriait, ce qui empêchait de remonter dans l'historique, une fois qu'elle était atteinte.
Il m'a donc fallu isoler ce comportement, en utilisant 'replace' plutôt que 'href'...

Par ailleurs j'ai constaté une curiosité sur OPERA, et je contacte Lothindil en privé à cet égard.

Cdlt
Sujet clos
Aller à