Protection de repertoire - Version imprimable +- JeuWeb - Crée ton jeu par navigateur (https://jeuweb.org) +-- Forum : Discussions, Aide, Ressources... (https://jeuweb.org/forumdisplay.php?fid=38) +--- Forum : Programmation, infrastructure (https://jeuweb.org/forumdisplay.php?fid=51) +--- Sujet : Protection de repertoire (/showthread.php?tid=4550) Pages :
1
2
|
RE: Protection de repertoire - Allwise - 09-02-2010 Tu peux utiliser les diverses solutions proposées ici : générer le code js par le serveur, obfusquer ( quel sale mot ) le code... Mais si un "escroc" veut trouver une faille et l'exploiter, je pense que tout ce que tu vas mettre en place lui fera perdre au plus une dizaine de minutes, et que ce sera le cadet de ses soucis que le code soit obfusqué. Ton interface a beau être en Ajax, les failles c'est côté serveur qu'elles se trouvent, donc au lieu de passer du temps sur ton code js, je te conseillerais de le passer à renforcer la sécurité côté serveur. Roworll a écrit :En général, le JS ne devrait servir qu'à rendre l'interface plus conviviale (redirections, effets, etc). A partir du moment ou tu as respecté la règle d'or dans ton code PHP (ne jamais faire confiance aux données venant du client), exposer ton JS ne devrait poser aucun problème.+2 ! RE: Protection de repertoire - Roworll - 10-02-2010 Code PHP :
Ce genre de protection, ça ne tient pas 30 secondes. Il suffit de prendre le code, de remplacer le eval par un javascript : alert, de coller le tout dans la barre d'adresse et d'envoyer. Résultat, un beau message d'alerte avec le code décompacté. Évidemment, on peut virer les sauts de ligne, simplifier le nom des variables à l'extrême pour rendre le code moins accessible mais au final, ce sera peine perdue. L'interface ne devrait pas poser de problème si le code serveur est sécurisé correctement. Si ce n'est pas le cas, c'est que tu es carrément parti de travers. Bonne chance alors pour rattraper tout ça. RE: Protection de repertoire - Wells - 10-02-2010 Après dans la même optique, il y a aussi les images que l'on veut pouvoir protéger. C'est plus une méthode générale de protection de fichier que purement pour le JS en fait RE: Protection de repertoire - My Hotel - 10-02-2010 Ben les images c'est pareil, si le client les charge pour les visualiser, rien en peut l'empêcher de les copier (et surtout pas les scripts du style anti clic droit...). Après, normalement y'a un droit d'auteur donc si tu as peur que les gens te piquent tes images/codes, ben ils ne devraient pas pouvoir légalement en faire grand chose. Au niveau sécurité, là, c'est à toi de tout vérifier en PHP, même si tu as déjà vérifié en JS. Bye RE: Protection de repertoire - Roworll - 10-02-2010 A partir du moment ou l'image apparait sur l'écran du PC client, elle est facilement récupérable. Par exemple, sur FF, il suffit de faire outils->Informations sur la page, de cliquer sur Medias et on a la liste de tous les composants graphiques affichés sur la page avec en prime un petit bouton "Enregistrer sous". Il est impossible de lutter contre ça. Au mieux, tu peux interdire de parcourir certains dossiers mais ça n'ira pas plus loin. Même si par soucis de protection tu passes tout en flash par exemple, il existe de très bon décompilateurs qui permettent de retrouver les éléments de base du fichier swf. Il faut bien te dire que dans un environnement Web, tout ce qui se charge sur le poste client (des images au code HTML généré en passant par le JS, les cookies etc) ne peut être protégé. Il faut accepter de prendre le risque de se faire plagier lorsque l'on met des ressources sur le net. La seule chose qui est à l'abri est le code qui génère tes pages sur ton serveur. RE: Protection de repertoire - Allwise - 10-02-2010 Par contre on peut protéger ses images et ses autres medias contre le hotlink, même si les protections sont là encore limitées ( c'est une problématique à laquelle j'ai dû faire face dernièrement ). C'est d'ailleurs en ce sens que tendaient les quelques directives de ton premier post. C'est une pratique qui, selon le contexte, peut revenir cher en bande passante, et donc en argent. On peut aussi vouloir réserver des ressources pour une partie de ses internautes, et les protéger du reste, avec une identification obligatoire pour y accéder. RE: Protection de repertoire - NicoMSEvent - 11-02-2010 une solution simple pour le hotlink, mais ça inclu un cron qui tourne toutes les heures (très léger, le cron) tu as un répertoire avec toutes tes images, et tu crée un "hard-link" vers ce répertoire avec l'heure et la date (par exemple /2010-02-10-09h ) et le lien dans ta page pointera vers ce répertoire (une simple fonction que tu applique sur tous les href des liens te permettra de faire ça sans soucis). Pour éviter que tes hotlinker fassent la même chose, tu peux passer ta date + un mot que tu choisis au md5 et chaque heure tu crée un nouveau "hard-link", et tu supprimes celui de 2h avant (histoire qu'au passage a l'heure suivante, tu n'ai pas d'erreur 404) Le "hard link" prend 1k (donc quasi rien), et est créé en quelques millième de seconde, peu importe le contenu du répertoire @Roworll : j'avais pas pensé a "craquer" un eval avec un "alert", c'est pas bete et tellement simple que je me demande comment je n'y ai pas pensé avant ^^ RE: Protection de repertoire - DragonMaster - 11-02-2010 Pour les images il y a a toujours la solution des "slicer" automatiques, l'image est toujours disponible mais plus chiante à aller chercher (tu peux diviser ton image en 15 morceaux de différente forme avec sa). Par contre, il y a un gros mais, sa alourdir énormément le nombre de requête HTTP pour un site complet, mais après le reste va selon ton jugement. RE: Protection de repertoire - NicoMSEvent - 11-02-2010 le but n'est pas de s'ennuyer soi même avec une charge plus importante du serveur + découpage de toutes les images, le but est de sauver de la bande passante Si c'est juste pour empecher qu'on te pique tes images, il suffit de mettre un gros "watermark" dessus avec ton adresse web qui montre que tu en es le propriétaire ^^ |