Reprise du message précédent :

 
le problème c'ets qu'on peu pas  controler tout le net et savoir qui a pris mon site

 
non !!
loin de la !!mdr!!

Hum je ne dirais qu'un chose, il est urgent pour certains de revoir le fonctionnement de PHP  

bah c'est pareil pour tous les autres médias, ca n'a rien d'étonnant ni de catastrophique.

Mhaggar a écrit a écrit : Hum je ne dirais qu'un chose, il est urgent pour certains de revoir le fonctionnement de PHP

 
c'ets a dire ? ;o)

 
Tu veux savoir comment détourner ce script : Quand le popup apparait tu fais très rapidement entrée + click droit et hop comme par magie ça fait sauter le script ... (le entrée ferme le popup et le click droit agit pendant la fermeture, bilan l'appel au script ne se fait pas ...)

Affirmer éhontément que PHP empêche la récupération des pages

J'ai lu pas mal de réponses et force est de constater que beaucoup parmis vous pense qu'il est impossible de protéger un site contre les aspirateurs.
 
 
Et bien mois je dis que c'est tout à fais possible d'empêcher un aspirateur de pomper un site (même le plus performant).
 
 
Il existe des métodes très simples comme ici
 
 
ou des méthodes beaucoup plus radicales mais bon .... j'peux pas montrer  

 
attention tu lances un défi; je vais appeler Zion

 
pourquoi tu n'est pas d'accord ds le fait que l'on ne peu pas récuperer lmes pages PHP? et que l'on ne peu récuperer que les pages traiter et qui ne sont plus que des pages HTML?
et ceci biensur sans passer par des ftp ou je ne sais quoi d'autres  ;o)

php ce sont pas des pages, ce sont des scripts
quand on dit "pages" c'est "pages web" c'est-à-dire du html ou équivalent

y'a un moyen lui aussi contournable c'est de tester la méthode d'accès et l'identité du navigateur, et du coup virer les teleport pro & co

enfin bon moi j'aimerai bien qu'on m'explique comment on peu récuperer les "script" php ?
car ceux qui dienst que c possible  , bin ils en disent pas plus    
faut des preuves et des explications la  

krapaud a écrit a écrit : y'a un moyen lui aussi contournable c'est de tester la méthode d'accès et l'identité du navigateur, et du coup virer les teleport pro & co

 
oauis mais tu ne feras que repousser el pb , tu ne peu pas tt controler comme ca  non?

sax->en php il y a eu la même erreur qu'en asp.
 
en asp quand tu ajoutais +.htr à la fin de l'url tu pouvais récuperer du code asp non interprété.
 
En php je ne me rapelle plus la manip'.
 
Mais bon tout les serveurs web sont patchés

 
bah le problème c'est que les aspirateurs permettent de changer leur identification et de se faire passer pour un ie

saxgard a écrit a écrit : enfin bon moi j'aimerai bien qu'on m'explique comment on peu récuperer les "script" php ? car ceux qui dienst que c possible  , bin ils en disent pas plus     faut des preuves et des explications la

 
 
 
Quoi y a quelqu'un qui demandé si on pouvait récupérer le script Serveur    !!?

krapaud a écrit a écrit : sax->en php il y a eu la même erreur qu'en asp.   en asp quand tu ajoutais +.htr à la fin de l'url tu pouvais récuperer du code asp non interprété.   En php je ne me rapelle plus la manip'.   Mais bon tout les serveurs web sont patchés

 
ah voila ca ca me fais plaisir car c'ets au moin une explication valable ;o)
merci
 
mais sinon mnt que c'ets patché? il ya d'autres moyens  encore? faut-il d'autres patch?  

Le fichier php est traité par le serveur
 
Après traitement il est envoyé au client
 
Donc, prenons l'exemple du fichier index.php
 
Sur le serveur :
 

 
Chez le client :
 

 
Donc, contenus différents

saxgard a écrit a écrit : enfin bon moi j'aimerai bien qu'on m'explique comment on peu récuperer les "script" php ? car ceux qui dienst que c possible  , bin ils en disent pas plus     faut des preuves et des explications la

 
y a personne qui a dit que c'était possible il me semble

antp a écrit a écrit :     y a personne qui a dit que c'était possible il me semble

 
désolé petite reuuer de lecture  ;o)  
mais je pensé que mhaggard pensé ca  ;o)

en fait je crois qu'on est tous sur la meme longueur d'onde alors  

saxgard a écrit a écrit :     ah voila ca ca me fais plaisir car c'ets au moin une explication valable ;o) merci   mais sinon mnt que c'ets patché? il ya d'autres moyens  encore? faut-il d'autres patch?

 
le seul moyen en fait de récuperer le code c'est de faire croire au serveur qu'il n'a pas de code à interpréter et que tout se passe au niveau client, c'était le principe d'une erreur dans le global asa et du .htr.
 
Maintenant c'est résolu, et je dirais qu'il faut employer des moyens plus bourrins, comme la saturation de la pile et donc le traitement aléatoire des scripts serveurs etc...

 
aouis bin alors la tu me noie , ca sors de mes comptétences  ;o)
mais je me demande si par cette solution on arriverai a un résultat correct

Le jour où il sera possible de récupérer du code PHP sur un serveur APACHE ou de l'ASP sur IIS/5.0 , les poules auront des dents !
 

 
non, parce que même si tu provoque un dépassement de pile, tu auras avant tout un plantage complet du service web, et non pas un traitement incorrect des paquets

 
sur iis4 on pouvait

krapaud a écrit a écrit :     sur iis4 on pouvait

 
 
 
C pour cela que g mis IIS/5.0 en gras    

 
bin te est possible  , il ne faut jamais dire jamais  ;o)
enfin se qui est sur c que pour jusqu'a present j'avais jamais enetendu dire que c'était possible  
 
mais avce se que je veint d'apprendre par krapaud , on se rend coiompte que tt est vraiment possible  
 
c'ets pas pour rien que les hackers et autres personnes en tt genres arrive a faire des trucs impressionat des fois  

Krapaud tu as des liens concernant la faille du source que tu évoque stp ? Ca m interesse
 
Sinon, si l'auteur a prévu l'accès aux sources PHP, il crée en général des copies ss la forme PHPS. On a donc accès au source avec la coloration syntaxique qui va bien

Ultra Bestial a écrit a écrit :         C pour cela que g mis IIS/5.0 en gras

 
jusqu'au jour ou t'apprendras que IIS 5 a un gros bug et que  l'ont peu recuperer les script asp en tapant /prout$!!!  

 
 
De toutes façon les sites commerciaux comme Amazon.com utilisent des DB en Back-end dont les transactions passent par des objets (i.e: COM ) sécurisés eux-mêmes extrêment complexes à attaqués depuis le Net ...
 
 

zion a écrit a écrit : Pour ceux que ca intéresse, on a déjà eu cette discussion ailleurs   http://forum.hardware.fr/forum2.php3?post=24349&cat=10   Et y a des solutions anti-aspirateurs faciles à mettre en place, mais pas 100% efficace

 
cool ;o)

pour IIS5->
http://online.securityfocus.com/bid/4525
 
pour IIS4->
http://online.securityfocus.com/bid/2909
 
 
et puis j'm'étais trompé c'est pas .htr pour le source c'est translate:f/ , le htr c'est pour obtenir l'arborescence par ex.
 
http://online.securityfocus.com/bid/1578

prenons l'exemple de www.hebus.com
 
Vous affirmez qu'il est possible de recupérer le contenu entier de ce site?

oui, ça déjà été fait d'ailleurs

  Krapaud
 
Je parlais de PHP moi, ASP  

antp a écrit a écrit : oui, ça déjà été fait d'ailleurs

 
donc c'est tres emmerdant....et ya auncun risque???
 
Me gave car je voulais faire un site de galerie d'images donc je suis un peu daqns la merde...

risques pour qui/quoi ?

zion a écrit a écrit :     Aucun problème, c'est d'ailleurs le record de taille de projet pour Kapere pour le moment, plus de 5gb si je me rapelle bien

mais c'est enorme!!! et ils gueule pas les admin de hebus??? et tu ne risque rien?

Mhaggar a écrit a écrit :     Krapaud   Je parlais de PHP moi, ASP

 
http://online.securityfocus.com/bid/3737
 
pas exactement ce que je voulais mais bon...