protection de mes css js et image via .htaccess

Répondre


Cette question est un moyen d’empêcher des soumissions automatisées de formulaires par des robots.
Smileys
:D :) :( :o :shock: :? 8-) :lol: :x :P :oops: :cry: :evil: :twisted: :roll: :wink: :!: :?: :idea: :arrow: :| :mrgreen: =D> #-o =P~ :^o :non: :priere: 8-|
Voir plus de smileys
  Revue du sujet
 

  Étendre la vue Revue du sujet : protection de mes css js et image via .htaccess

par Hubert Roksor » 22 janv. 2008, 16:54

Pour faire perdre du poids à un script, y'a pas mieux que gzip. C'est bien plus efficace [...]
L'un n'exclut pas l'autre, le mieux est de minifier son script et s'assurer que le serveur propose une version gzippée. Quelques exemples chez YUIBlog.
(simple exemple ici, ou un gros script de 55Ko passe à 12Ko)
Attention, ce site propose une solution qui n'est pas recommandable. "prototype.js.gz" n'est pas un fichier Javascript, c'est un fichier gzip. La compression gzip telle qu'elle est implémenté par mod_deflate et autres est un processus transparent et défini dans le protocole HTTP. Sans s'étendre sur ce problème, par mod_deflate on aura les en-têtes suivants

Code : Tout sélectionner

Content-Type: text/javascript Content-Encoding: gzip Vary: Content-Encoding
...alors qu'en pointant son navigateur sur un fichier .gz on aura probablement (selon la configuration du serveur)

Code : Tout sélectionner

Content-Type: application/x-gzip
Si le navigateur interprétait un tel fichier comme un fichier Javascript ce serait une faille de sécurité qu'il faudrait corriger. Par exemple, on pourrait imaginer uploader un .js.gz chez un hébergeur de fichier (Rapidshare & co) et lorsque l'utilisateur souhaite le télécharger, il s'exécute avec les credentials de ce site. Une façon par exemple d'automatiser le vol de comptes Rapidshare.

par BeRoots » 14 janv. 2008, 19:11

Je ne pensait pas faire un topic qui passionne autant de moderateur et ViPHP :lol:

sa fait plaisir de voir que se sujet passionne les foules :)

Par contre je voulais savoir où puis je me procurer un obfuscateur de code JS de qualité?
Je voulai savoir aussi si ces obfuscateur de code sources sont specifique à un language précis à chaque fois ou si il en existe qui traite tous type de code source? :-k

merci d'avance pour vos propositions :)

par Calimero » 10 janv. 2008, 12:11

Tant qu'à aller dans le troll, j'ajouterais que plus un code est protégé, plus il donne envie aux bidouilleurs compétents de le cracker (même simplement par défi, car c'est comme ça que ça fonctionne dans cet univers-là ;-) ). Quelquefois la meilleure des protections consiste à ne pas protéger du tout...

par Nagol » 10 janv. 2008, 12:04

**troll detected***

une entreprise qui cherche à cacher ses sources se fera toujours voler son travail, du fait que les bidouilleurs sont souvent plus performant que les employés. l'open source a non seulement l'avantage de jouer sur la concurence (des testeurs gratos, des codeurs parfois voire même souvent) mais aussi de permettre aux moins avancé d'apprendre.

personellement je trouve que le close source est une erreur, les grandes entreprise de close sourcing microsoft en tête se feront bouffer à ce jeu la alors je ne comprend pas trop "mais ça ne signifie pas pour autant que ce soit valable pour tout le monde.". Non seulement c'est valable pour tout le monde mais en plus c'est la voix à suivre pour survivre dans le paysage informatique moderne (voyez sun qui va dans ce sens, même microsoft)

</troll>

par Cyrano » 10 janv. 2008, 11:57

Obfusquer son js, c'est un peu comme lire un article wikipedia et l'effacer pour que d'autres ne puissent profiter de son enseignement.
Pas forcément. Pour une entreprise de développement commerciale, ce n'est pas forcément intéressant de laisser ses codes tout ouverts et laisser n'importe quel bidouilleur le récupérer... et le revendre dans ses propres développements sans pour autant payer le moindre centime. Une entreprise commerciale n'est pas là pour faire de la philanthropie. Et faire de l'open-source, ça peut être tout à fait valable, il y a même des modèles économiques basés dessus, mais ça ne signifie pas pour autant que ce soit valable pour tout le monde.

par Berzemus » 10 janv. 2008, 11:12

Pour faire perdre du poids à un script, y'a pas mieux que gzip. C'est bien plus efficace (simple exemple ici, ou un gros script de 55Ko passe à 12Ko), voilà pour le gain de poids.
Le seul objectif de l'obfuscation est de rendre illisible un code source (...)
(...)ça rends le rétro-engineering très complexe.
C'est bien ça qui me gène (et c'est ce que je voulais dire, je sais bien que l'obfuscation sert à obfusquer). Pourquoi vouloir rendre son code illisible ?
:arrow: Pour ne pas que d'autres le copient ? Ma foi, c'est le risque de toute publication.
:arrow: Pour masquer certaines données sensibles ? C'est du JS. Donner des données sensibles au client, c'est suicidaire.
:arrow: Pour pas que d'autres s'en inspirent ? Mais c'est justement ce qui rend le JS si connu, si largement utilisé, si facile d'accès.. (suffit de savoir regarder une source).

Obfusquer son js, c'est un peu comme lire un article wikipedia et l'effacer pour que d'autres ne puissent profiter de son enseignement.

par @rthur » 10 janv. 2008, 01:21

Par ailleurs, je pense qu'on a un problème de définition... :-k
Pour réduire la taille d'un code informatique on fait de la compression (en retirant les espaces inutiles ou en diminuant la taille des noms de fonctions/variables) ou de la factorisation de code... même si ça peut y ressembler, ça n'a rien à voir avec l'obfuscation.

L'obfuscation de code n'a pas pour objectif de réduire sa taille. C'est d'ailleurs même souvent l'inverse où l'obfuscateur va ressortir un code plus verbeux en rajoutant des fonctions qui ne servent à rien, juste pour embrouiller les pistes...

:arrow: Le seul objectif de l'obfuscation est de rendre illisible un code source afin qu'il ne puisse pas être réutilisé par d'autres facilement...

Si vous n'en êtes pas convaincu, je vous renvoie à la définition Wikipédia: :idea:
http://en.wikipedia.org/wiki/Obfuscated_code


Enfin, comme un exemple est toujours plus parlant, voici un code javascript (850 caractères; 648 sans les commentaires):

Code : Tout sélectionner

// Cette fonction permet de retourner le nom de l'objet en paramètre function OBJNAME(n) { return n; } // Cette fonction affiche dans la page le paramètre str function dw(str) { document.write(str); } // Fonction affichant un objet dans une table HTML function dumptbl(obj,row_callback_str,cell_callback_str) { dw('<table border=1>'); for(var i=0;i<obj.length;++i) { var tr = '<tr>'; eval(row_callback_str); dw(tr); for(var j=0;j<obj[i].length;++j) { var td_s = '<td>', td_e = '</td>'; eval(cell_callback_str); dw(td_s); dw(obj[i][j]); dw(td_e); } } dw('</table>'); } dumptbl([[1,2,3],[4,5,6],[7,8,9],[10,11,12],[13,14,15],[16,17,18]], OBJNAME('tr') + "= '<tr style=\"background: ' + ( " + OBJNAME('i') + '%2 ? "red" : "yellow") + \'">\';', "");
Et voici après obfuscation exactement le même code (c'est à dire qu'il aura le même comportement dans le navigateur web):

Code : Tout sélectionner

function z8c231aa888(z14851c4b0f){return z14851c4b0f;}function z0ab1f0a49e( z0721975593){document.write(z0721975593);}function zcd8c17c79d(z4716861143, z500f443098,z9bc82e0042){z0ab1f0a49e( "\x3c\x74\x61\x62\x6c\x65\x20\x62\x6f\x72\x64\x65\x72\x3d\x31\x3e");for(var zd1ea46315e=(0x8e9+2039-0x10e0);zd1ea46315e<z4716861143.length;++zd1ea46315e){ var z708eb69ac7="\x3c\x74\x72\x3e";eval(z500f443098);z0ab1f0a49e(z708eb69ac7); for(var z2d29194d43=(0x139b+2094-0x1bc9);z2d29194d43<z4716861143[zd1ea46315e]. length;++z2d29194d43){var z23b8891aeb="\x3c\x74\x64\x3e",z7f5411ee29= "\x3c\x2f\x74\x64\x3e";eval(z9bc82e0042);z0ab1f0a49e(z23b8891aeb);z0ab1f0a49e( z4716861143[zd1ea46315e][z2d29194d43]);z0ab1f0a49e(z7f5411ee29);}}z0ab1f0a49e( "\x3c\x2f\x74\x61\x62\x6c\x65\x3e");}zcd8c17c79d([[(0x2d7+5314-0x1798), (0xf7c+295-0x10a1),(0x900+1599-0xf3c)],[(0x1e8+1063-0x60b),(0xfc1+580-0x1200), (0x1cf5+1843-0x2422)],[(0x9f9+4410-0x1b2c),(0x1c6+8452-0x22c2), (0x28a+2774-0xd57)],[(0xcc0+2614-0x16ec),(0x7ee+1483-0xdae),(0xab2+6657-0x24a7)] ,[(0xa14+2966-0x159d),(0x63c+7549-0x23ab),(0x7e2+5079-0x1baa)],[ (0x14bc+296-0x15d4),(0x720+6090-0x1ed9),(0xfba+3045-0x1b8d)]], "\x7a\x37\x30\x38\x65\x62\x36\x39\x61\x63\x37"+ "\x3d\x20\x27\x3c\x74\x72\x20\x73\x74\x79\x6c\x65\x3d\x22\x62\x61\x63\x6b\x67\x72\x6f\x75\x6e\x64\x3a\x20\x27\x20\x2b\x20\x28\x20" +"\x7a\x64\x31\x65\x61\x34\x36\x33\x31\x35\x65"+ "\x25\x32\x20\x3f\x20\x22\x72\x65\x64\x22\x20\x3a\x20\x22\x79\x65\x6c\x6c\x6f\x77\x22\x29\x20\x2b\x20\x27\x22\x3e\x27\x3b" ,"");
Le code obfusqué fait alors 1533 caractères...


Alors effectivement, il existe des softs de dé-obfuscation mais le résultat n'est jamais très probant (expérience inside). Rien que le fait de perdre tous les commentaires, les noms de fonctions et les noms de variables, ça rends le rétro-engineering très complexe... :twisted:

par @rthur » 10 janv. 2008, 00:47

Mais je continue de maintenir que l'obfuscation de code est HS pour la question de base ;)
Tu as interprété la demande de base par la phrase suivante: "[comment] empecher les internautes à avoir un acces à mes dossier..."

A ce moment là, ta réponse sur l'interdiction de listage des répertoires est correcte, mais incomplète car ta technique masque juste le nom des fichiers contenus dans un répertoire sans en empêcher l'accès.


Or personnellement, je pense que la question initiale était contenu dans sa première phrase:
je voulais savoir si il existait une methode pour securiser les feuille css (ou autre .js...) :-k
et la deuxième phrase que tu as retenu était une reformulation pas forcément heureuse. ;)


La "bonne" réponse si toutefois il y en a une est selon moi multiple:
1) On ne peut pas de façon sure sécuriser des fichiers javascript ou css.
2) On peut toutefois limiter les risques en évitant le listage des répertoires qui ne contiennent pas de fichier index
3) Pour éviter de se faire piquer du code, il faut passer par de l'obfuscation qui va rendre difficile toute récupération...

par zeus » 10 janv. 2008, 00:37

D'accord avec Sekiltoyai. L'obfuscation obscurcie le code, mais ne le rend pas inutilisable. Par contre, on gagne en poids.

Mais je continue de maintenir que l'obfuscation de code est HS pour la question de base ;)

par Sékiltoyai » 10 janv. 2008, 00:03

Bah je ne vois pas en quoi ca le rend illisible. Quelqu'un qui veut vraiment l'utiliser le pourra.
Par contre, pour l'allègement, je pense qu'on peut gagner 20 à 40% de la taille du fichier…

par @rthur » 09 janv. 2008, 23:40

L'intérêt premier étant de rendre le code "obfusqué" le plus illisible possible et donc inutilisable pour le copieur ;-)
ça ne réponds pas à ton interrogation Berzemus? :-k

par Sékiltoyai » 09 janv. 2008, 23:08

Je te plussoie…

par Berzemus » 09 janv. 2008, 20:07

je m'arreterais à "pourquoi vouloir obfusquer son js ?"
(si ce n'est pour l'alléger)

par Sékiltoyai » 09 janv. 2008, 19:59

Le problème de l'obfuscation, c'est qu'unpetit script peut sans problème reconstruire complètement le code, il n'y aurait que pour le changement des noms de variables et de fonctions qu'il ne serait pas possible de modifier.

par zeus » 09 janv. 2008, 19:12

Désolé, mais je m'inscrit en faux par rapport à ton message Zeus...
Concernant ta demande d'origine, ma méthode est incontournable, sauf à avoir un accès ssh sur le serveur et supprimer le .htaccess ...
Ta méthode permet juste d'éviter de lister les fichiers présents dans un répertoire qui ne contient pas de fichier index...
Or si quelqu'un souhaite copier un CSS ou un Javascript, c'est qu'il l'a déjà vu en application sur une page HTML et donc connait déjà le chemin précis où récupérer ce fichier (qui n'est donc pas protégé)
Non, non, nous parlons bien la même langue ;)

Pour rappel, la demande de base est
en gros je voudrai empecher les internautes à avoir un acces à mes dossier de css ,js..., mais sans pour autant que ces fichiers soit bloquer
C'est donc ce que j'ai proposé via mon .htaccess ;)