Geckozone

Salut tout le monde,

Mon problème est d'empêcher la mise en cache automatiquement sur mozilla chez les "clients".

Le contexte est le suivant :
j'ai lancé un défi pour tenter de récupérer les codes sources d'un monde 3D en VRML, par un jeu de headers en php, ce code source n'est pas enregistré dans le cache d'IE. Mais Sous Mozilla, il reste dans le cache et est donc consultable...
Pour l'instant, Mozilla est le maillon faible de mon défi.

C'est tout de même pour tenter de prouver que l'on peut protéger ce genre de source (vrml) sans avoir besoin d'acheter un licence chez blaxxun pour profiter de leur cryptographie de sécurité, qui est le seul à le faire pour le moment.

Voila ce que j'ai mis en php dans le code qui génère la page : Mais rien à faire, le fichier apparait toujours dans le cache chez le client...

Bien à vous
Alain

Pas dans le cache ne veux pas dire que la source n'est pas récupérable...

Il y as toujour moyen de récupérer un fichier si ce dernier est en libre acces...

sinon j'ai trouver cela :

http://www.webrankinfo.com/forums/viewtopic_9508.htm

Ben non, ça marche pas... Un inconvénient des fichiers wrl est que l'on ne peut envoyer les entêtes que par header en php et non en html...

Bon, je continue de chercher... Mozilla semble être un point faible dans ce genre de sécurité...

Alain

Franchement je ne vois pas en quoi c'est un probléme de sécuriter. Un fichier accessible sur internet le resteras toujours, que tu l'empeche d'être en cache ou non.

une fois que tu as l'adresse tu la copie dans un gestionaire de téléchargement et tu a le fichier en entier.

Le php est très puissant... Surtout si c'est géré avec astuce...

Même si tu as l'adresse, le php détecte d'où viens l'appel et selon la situation, il génère ou non le bon code.
Le principe de base : il faut être passer par une page intermédiaire pour avoir droit d'afficher le code. Ca utilise les variables de sessions, un accès par formulaire. Ce qui fait qu'un accès direct ne permet pas de lire le source...

Sous IE et Opera, c'est efficace : il est très difficile de lire la source.

Un aspirateur WEB n'y passe pas non plus.

Le seul maillon faible de cette méthode, c'est Mozilla qui ne se comporte pas normalement par rapport aux instructions de non mise en cache.

Pour info : dans le défi, je précise que le source reste toujours accessible avec des moyens d'investigation approprié, mais juste que la méthode présentait un sérieux coup de frein à la majorité de ceux qui tentaient de lire les sources et c'était juste un challenge pour moi de développer cette méthode.
En faisant les essais, on se rend compte que Mozilla ne se comporte pas correctement par rapport à du code qu'une page lui envoie, et c'est en soi un problème de sécurité.

Bah, c'est un défi supplémentaire pour moi de faire un code qui contourne ce problème. J'ai une solution de leurrage du cache à tester... Si vous voulez, je viendrai vous lancer le défi à vous aussi si je réussi à leurrer mozila.

Bien à vous
Alain

Il faudrait plutot regarder dans les doc de mozilla pour voir comment faire car je ne vois vraiment pas...

Mais sinon si je devait faire ce defi, à mon avie ce n'est pas dure, ce ne sont des des trame ip echanger entre le serveur et le client. En delhi en quelque minute je capte les trame et je les simule.

En delphi je fait un mini proxie, c'est à dire que je me met e relait.

Au lieu de taper la vrais adresse je met 127.0.0.1, et tout ce que je ressois de ie (pour être sur que cela ne soit pas en cache) je l'envois à ton serveur en changant 127. et inversement tout ce que je ressois du serveur je le redonne à ie... C'est un mini proxie ultra simplifier, mais la seul chose c'est que la je peux récupérer tout les fichier que je veux...

bsr jv2759

Oui, j'ai bien précisé que ça restait craquable sans problème avec des moyens d'investigations plus poussés... Mais avoues, est ce que tout le monde peut faire ce que tu suggères ?

Non, rares sont ceux à pouvoir le faire, et ceux qui peuvent le faire n'ont pas besoin de récupérer ce genre de source car ils n'y apprendraient pas grand chose qu'ils ne sachent déjà faire...

En tout les cas, je sens que je vais m'intéresser de très près à cette méthodologie que tu suggères car elle me parait intéressante à me développer pour ma culture générale... Tu aurais une idée d'un tuto disponible sur le sujet ?

Alain

aucune idée de tuto, en fait la base c'est un outil de developpement sufisament pouser, java delphi c++, eviter le genre php, non pas que l'on ne peux pas le faire mais ce n'est pas fait pour php est "limiter" à 30 second en mémoire est surtout n'est pas interactif.

Moi je te conseillerais fortement delphi. c'est ma petit cherie, en plus il existe en version gratuit pour la 6;)

Sinon des tutoriel sur ce que je tes decrie non je ne pense pas qu'il en existe, en fait ce qu'il faut c'est surtout connaitre le language utiliser et eventuelement les composant. Une fois que tu metrise cela ce n'est plus dure dutout, tu envois un requette, tu attend la réponse, et ainsi de suite...

mrstranger a écrit :Le seul maillon faible de cette méthode, c'est Mozilla qui ne se comporte pas normalement par rapport aux instructions de non mise en cache.

Non, le maillon faible dans ta méthode, c'est de te baser sur le comportement d'un navigateur en particulier sans comprendre le protocole.
Ton instruction n'interdit pas de mettre le fichier en cache (et ne cherche pas, il n'en n'existe pas). Elle indique juste que la page doit toujours être téléchargée et que la version en cache doit être remplacée par la nouvelle.


Se baser sur des logiciels clients pour assurer une sécurité, c'est ne rien connaitre à ce domaine...

Salut Xanthor,

Si je fais ce genre d'expérience, c'est bien justement pour en apprendre le plus possible. Si je suis un brin provocateur dans mes propos (juste envers un logiciel), c'est aussi pour avoir une réaction en face...

Sinon, ce que tu dis est vrai en général, mais est ce que cela interdit pour autant de tenter l'expérience ? Même si le projet n'aboutit pas, pour ma part, j'aurai gagner pas mal de choses de mon apprentissage et éventuellement, cela me permet de m'ouvrir de nouvelles possibilités de découvertes...

Et pour ta dernière phrase, un brin provocatrice aussi (mais plus envers ma personne, donc un peu mal placée sur un forum à mon avis ) ), j'ai l'honneur de revendiquer le fait que je n'y connaisse presque rien et que je fasse les démarches nécessaires pour combler un max de mes lacunes.
Il y a des domaines où je suis meilleur que les autres, dans ce cas, j'essaie de prendre la patience de les aider tranquillement, mais surtout à leur rythme et à leur manière.

Le net a la particularité assez pratique de pouvoir rencontrer des gens ouverts qui permettent des échanges riches et instructives...

Bien à toi
Alain

C'est juste que "lancer un défi" dans un domaine que l'on cherche encore à maitriser, ça me fait sourire

Bah, l'apprentissage peut prendre une multitude de forme pour peu qu'on y réfléchisse un tout petit peu...

Par rapport au défi, c'est un défi qui évolue au cours du temps... Au fur et à mesure que l'on lit mes fichiers, on me donne la méthode qui a été utilisée et je réfléchis ensuite comment bloquer ladite méthode avant de remettre une nouvelle version du défi... Là, j'en suis à la cinquième version et quelqu'un m'avait dit que Mozilla gardait en cache les fichiers...

Concrêtement, je ne me faisais pas d'illusions, je sais pertinement depuis le début que mon défi est toujours perdu d'avance... Et alors ?

Au point où j'en suis de ce défi, je projette de faire des essais pour doubler la mise en cache d'un fichier donné. Dans un système de deux frames A et B dont la B serait invisible, je provoque un rafraichissement des deux frames avec un léger décalage sur un même fichier. La première frame A met en cache le fichier qui va générer le bon code, ainsi que des variables d'environnements en session du php. La deuxième frame B va détecter ces variables et donc générer un autre code pour ce même fichier. Mais au niveau du navigateur, le fichier avec le mauvais code sera mis en cache, remplaçant l'ancienne version qui avait le bon code.

C'est du bidouillage à 100%, mais moi, ça m'éclate et ça me permet d'émettre des hypothèses que je teste ensuite...

En tout les cas, ce défi m'a permi par la pratique de mieux comprendre la portée des headers en php, d'aquérir un logiciel en plein développement comme Mozilla, d'avoir comrpis que les sources étaient disponibles (et donc que mon regard de bidouilleur posera pour essayer de comprendre d'autres choses)...

C'est un peu partir à la pêche : on ne sait jamais sur quoi on va tomber.

Au début de ce défi, il s'agissait juste d'une simple question de la part d'une personne qui voulait savoir comment protéger ses codes sources des fichiers WRL. Tout le monde a répondu que ce n'était pas possible à moins de prendre une solution payante. Et de là, je voulais savoir jusqu'à quelle niveau de protection des sources on est en droit d'attendre par les moyens classics et gratuit...
Et je me retrouve dans ce forum à discuter à propos de mozilla...

Alors ? Ca te fait toujours sourire cette méthodologie d'apprentissage par le défi ?

Bien à toi
Alain

Mr.Stranger a écrit :Au point où j'en suis de ce défi, je projette de faire des essais pour doubler la mise en cache d'un fichier donné. Dans un système de deux frames A et B dont la B serait invisible, je provoque un rafraichissement des deux frames avec un léger décalage sur un même fichier. La première frame A met en cache le fichier qui va générer le bon code, ainsi que des variables d'environnements en session du php. La deuxième frame B va détecter ces variables et donc générer un autre code pour ce même fichier. Mais au niveau du navigateur, le fichier avec le mauvais code sera mis en cache, remplaçant l'ancienne version qui avait le bon code.

L'inconveniant à mon avie c'est que la personne qui vas chercher à relever ton defie, si connaitra certainement un minimum en informatique et surment en html javascripte, donc il demontrat ta protection facilement à mon avie... Ou alors il faut vraiment empechais que l'on puisse télécharger en dehort de ta pages.

En plus si tu remplace trop rapidement tu ne pouras plus utiliser ton fichier...

PS : Tu lie avec quoi ton fichier wrl.

Bonsoir Jv2759,

Je te fais une description du procédé :
Sur la page index.php, il y a la génération d'un formulaire avec un code qui change à chaque connexion, code qu'il faut bien sûr donner au formulaire pour afficher la page suivante. En même temps, une variable de session est initialisée.
La deuxième page, appelée par le formulaire va générer automatiquement deux frames et faire un appel du même fichier dans chacune des frames, avec un léger décalage. Ce procédé par le formulaire sert à contrer les aspirateurs de sites...
La premiere fois que le fichier wrl est générée par le php (par un appel d'embeding), il va controler la variable de session et lui mettre une autre valeur (pour bloquer un deuxième appel du même fichier ou un appel direct vers le fichier qui n'aura alors pas eu la variable de session initialisée), controler dans l'historique d'où viens l'appel (deuxième protection). Donc lors du premier appel de ce fichier, il sera généré noremalement.
J'en suis maintenant à bien réfléchir cette partie de l'appel avec décalage de la deuxième frame vers le même fichier. Etant donné qu'il aura déjà été appelé une première fois, la variable de session aura été changé donc, ce coup ci, il générera un mauvais code (ou un message destiné aux pirates). Ce procédé servirait uniquement à réécraser le même fichier qui aura été mis en cache avec le bon code, par du mauvais code.
Si on veut revoir la page, il faut repasser par la première page index.php et son formulaire.

Je réfléchis à un moyen de contrer la méthode que tu as suggéré à propos d'une mini-proxi, mais ça me parait tellement imparable... Peut être une pîste dans la constitution des appels urls pour essayer de remonter à la source de l'appel et détecter de adresses ip absconces ? Un champ d'étude potentiel pour essayer de trouver une solution ou des hypotheses...

Un petit descriptif :
Le VRML est un langage de programmation (présentation) par script (on écrit les mots et c'est "directement" interprété) au même titre que le HTML, mais peut être en un peu plus puissant. Il permet de faire des mondes en 3 dimensions. Comme le HTML, il peut être généré par du code php en faisant préciser le bon type mime par header.
Pour voir les mondes en 3D, il est indispensable de télécharger un plug in qui s'attachera aux navigateurs : c'est ce que l'on appel un viewer 3D. De la même manière qu'il existe plusieurs programmes pour interpréter le HTML, il existe plusieurs viewers pour le VRML (aussi bien sous windows, sous mac os, sous linux et même unix pour ce que j'ai pu voir). On peut écrire en VRML avec un simple bloc note ou un editeur VRML.
Comme le HTML, le VRML a la possibilité d'être gzipé et directement interprétable dans cet état (et oui, c'est rare, mais c'est déjà pu voir du HTML compressé directement utilisable par IE (je n'ai pas testé les autres navigateurs)).

En HTML, les codes sources sont immédiatement disponibles par affichage des sources. Pour le VRML, une lecture directe avec un programme particulier (par exemple, un éditeur VRML qui a le pouvoir de télécharger des pages tels quels (je n'ai pas trouvé de tels fonctions dans ULTRA EDIT). Mais cela j'ai trouvé la parade (cf ma description du procédé).

Pour plus de renseignement sur le VRML, il y a un site sur lequel j'ai fait mes premiers pas dans ce language : www.web3d-fr.com (c'est d'ailleurs dans le forum de ce site que je me suis lancé dans le défi de la sécurité des sources).
Sinon, pour voir une belle collection de mondes fait avec ce langage : vrml.base.com
Pour mon boulot, j'en mets sur le wmpk.fnet.fr

Excusez-moi de cet ecart, je me reconcentre sur le défi.
Dès que j'aurais mis à jour ma prochaine version du défi, j'en mettrai un lien ici si vous voulez (mais vous pourrez aussi le trouver sur le web3d-fr).

Bien à vous
Alain

Marche pas non plus, car mon proxie et sur ma machine, donc il vas initialiser une connection comme l'aurais fait le naviguateur avec la même ip... Pour utiliser mon mini proxi avec le naviguateur je change qu'une chose l'adresse cicle, xxx.yyy.fr devien 127.0.0.1, mais connaissant l'adresse de départ il me seras tres simple de modifier faire la transformation arriére...

Et la preuvent dans les entreprise on peux tres bien naviguer dériére un proxie sans probléme...

Et je dirait même il y as des proxie qui sont capable de stocker des information en cache...

Pour contourner le proxie la seul solution serais de "crypter" le vrml en entré et que seul la pages html soit capable de le décripter...

Sinon ps : Je connais quelqu'un qui réverais de pouvoir faire de la 3d sur internet. Je voulais savoir, peut-on affecter des texture au objet. Si ou qu'elle est la qualiter du rendut. Mais surtout ce qui m'interesse c'est la capaciter à interagisre avec le vrml. ajouter soustraire des objet, changer des texture, gérer les vue. Et tout cela de maniére simple et universel pour que ce soit compatible avec ie firefox, linux et mac...