cacher du code javascript grace a PHP, possible ?

cacher du code javascript grace a PHP, possible ? - PHP - Programmation

Marsh Posté le 29-05-2006 à 15:37:36    

salut, je voudrais cacher du code javascript , comme les controle validators de ASP.NET
le truc c'est que j'emploie des expressions regulieres directement extraites de mes objets PHP, et que les laisser a vue des internautes pourrait constituer une faille.
 
J'avais fait un truc du genre :
 

Code :
  1. <script language="javascript" type="text/javascript" src="../JS/javascript.php"></script>


le principe etait de créer une variable de session qui serait détectée dans le fichier javascript.php puis détruit a la fin de son execution de sorte qu'un tentative sans variable de session se hurte a un die();
 
mais ca ne marche pas avec notre cher mozilla qui reparcours la page pour afficher les sources.. Avez vous des idées ?

Reply

Marsh Posté le 29-05-2006 à 15:37:36   

Reply

Marsh Posté le 29-05-2006 à 15:53:33    

euh...
 
ta page "principale" crée une session avec "dtc.com" en valeur.
ta page de script regarde si y'a "dtc.com" en valeur.
si oui, elle affiche, et shoot la valeur de session.
comme ça, si on réaffiche que le JS, proutch.
 
ensuite, dans les header HTTP, tu forces pragma: no-cache et tout le tralala pour obliger le nav ou tout recharger etne pas utiliser une valeur en cache.
 
ceci dit...
 
tu ouvres le temp files de IE, tu trouveras dans tous les cas le fichier tel qu'il a été utilisé par IE... même si tu interdits la mise en cache...

Reply

Marsh Posté le 29-05-2006 à 15:56:24    

ok, c'est le header qu'il me manquait :) mais avec firefox, je doute que ca marche, car il semble recharger toute la page...

Reply

Marsh Posté le 29-05-2006 à 15:59:14    

je sais pas, je vois pas comment tu fais pour voir la source du JS avec Moz depuis la page appelante. moi je vais copy-paste de l'url du js dans moz... y'a un autre moyen ?

Reply

Marsh Posté le 29-05-2006 à 15:59:31    

mais ton fichier js il va quand même se retrouver dans les "tempory files" et donc être récupérable par celui "qui veut vraiment" non?
edit: over-over-over burned ... j'ai un peu trainé :o


Message édité par anapajari le 29-05-2006 à 16:00:28
Reply

Marsh Posté le 30-05-2006 à 09:20:01    

nan => no-cache :o

Reply

Marsh Posté le 30-05-2006 à 09:45:30    

the_bigboo a écrit :

le truc c'est que j'emploie des expressions regulieres directement extraites de mes objets PHP, et que les laisser a vue des internautes pourrait constituer une faille.


Si on pousse le raisonnement plus loin, ton développement est problématique : à partir du moment où tu sers le fichier en HTTP, le client le verra (et pourra en afficher le contenu), quelle que soit la protection que tu mets en place (cache ou pas cache, variable de session ou pas variable de session, temporary files ou pas). Donc la faille est déjà présente.
Si ton information est critique pour la sécurité de ton site, elle ne doit pas être affichée en HTTP (HTTPS ne résoud pas le problème), et ne doit pas sortir de ton serveur.
 
Si tu dois valider l'entrée de tes formulaires, cela doit être fait sur le serveur de toutes façons (la validation en JS est complémentaire, et ne doit être vue que comme une aide à l'internaute).
 
(Pour ceux que ça intéresse, voici deux outils qui permettent de sniffer le traffic HTTP : TraceWeb, Ethereal. Il y en a d'autres)


Message édité par jfbus le 30-05-2006 à 09:46:26

---------------
ipersec - Optimisation et sécurisation de sites internet
Reply

Marsh Posté le 30-05-2006 à 09:49:50    

la validation d'un formulaire doit toujours se faire coté serveur  
 
en effet , dans le cas de verification js, que se passe t il si l'utilisateur a desactivé js, ou si il a une vielle version bugguée ?  


---------------

Reply

Marsh Posté le 30-05-2006 à 09:55:09    

Il y a une possibilité de + ou - cacher le code mais bon. C'est de placer le code js dans un fichier php et lors de l'appelle de ce fichier.
<script language="javascript" type="text/javascript" src="js.php?dtc=<?  echo time() ?>">
 
Dans le fichier dtc.php tu places une condition.  
if($_GET['dtc'] = time()) //Attention il faut placer une plage de tolérance de 5 secondes environs.
 
Mais bon ça reste une technique de chien malade qui n'est pas fiable ça va peut etre bluser un blaireau :/ .
Mais pour le principale je suis daccord avec FLO850 . Les test se font du coté serveur. Ne jamais faire confiance au entré entrant.

Reply

Marsh Posté le 30-05-2006 à 10:15:37    

je parle d'experience
sur un de mes sites , jai fait confiance au js ( demande du client ) et il y a eu pas mal de soucis avec un petit malin qui à désactivé js  
donc maintenant, dans cette situation ,je fais une double validation : une en JS ( si le client le veut ) et une en php (pas besoin de présentation, de mise en page, juste un message d'avertissement 'erreur sur la saisie' )


---------------

Reply

Marsh Posté le 30-05-2006 à 10:15:37   

Reply

Marsh Posté le 30-05-2006 à 10:25:14    

the_bigboo a écrit :

nan => no-cache :o


ça n'empêche pas que les navigateurs copient le fichier sur le disque. no-cache indique juste qu'ils ne doivent pas le réutiliser ensuite.

Reply

Marsh Posté le 30-05-2006 à 10:27:29    

flo850 a écrit :

je parle d'experience
sur un de mes sites , jai fait confiance au js ( demande du client ) et il y a eu pas mal de soucis avec un petit malin qui à désactivé js  
donc maintenant, dans cette situation ,je fais une double validation : une en JS ( si le client le veut ) et une en php (pas besoin de présentation, de mise en page, juste un message d'avertissement 'erreur sur la saisie' )


généralement, ce qu'on fait c'est :
-> js : contrôles basiques, genre vérification de la syntaxe de saisie
-> serveur : contrôles avancés (vérification de l'intégrité des données, validations, etc.)
-> js (back) : mise en forme du message d'erreur en fonction du contrôle JS ou du contrôle serveur

Reply

Marsh Posté le 30-05-2006 à 10:36:27    

Arjuna a écrit :

généralement, ce qu'on fait c'est :
-> js : contrôles basiques, genre vérification de la syntaxe de saisie
-> serveur : contrôles avancés (vérification de l'intégrité des données, validations, etc.)
-> js (back) : mise en forme du message d'erreur en fonction du contrôle JS ou du contrôle serveur


Je suis assez daccord avec toi, il ne faut pas complétement banire le JS dans la gestion des contrôles afin d'éviter de saouler l'internaute avec les recharges de page, par exemple, mais toujours faire un contrôle coté serveur poussé.
Et flo à fait la cruel expérience (indépendante de sa volonté) de ce que ça peut coûte de faire les contrôles coté client.
Personnellement, je fais les contrôles à la demande du javascript coté client via AJAX et lorsque c'est posté il fait appelle au même fonction utilisé par ajax pour faire les contrôles.


Message édité par Berceker United le 30-05-2006 à 10:38:52
Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed