Je remercie également pour les liens, je n'en ai lu aucun pour le moment mais je réserves ma pause de midi à une lecture attentive !

EDIT :
Lecture terminée...
C'est assez impressionnant voir même flippant ce qu'il est possible de faire avec une "simple" XSS 

Encore merci pour ces documentations !

Pour le XSS ce n'est théoriquement pas possible de refermer la balise iframe ou d'injecter quoi que ce soit comme balise dans le paramètre de l'url car je lui ai fait mettre en place le strict minimum quand même
Un petit truc ressemblant de mémoire à du htmlentitites...

Donc on reste sur le phishing comme seul possibilité ?

Merci pour les réponses !

Par contre si the_lsd pouvait un peu détailler les risques par ce pour moi une faille XSS ça sert "simplement" à voler des session, hors dans ce cas là il s'agit de deux serveurs complètements différents l'un affichant l'autre via iframe.
Celui dans l'iframe ne devrait donc pas avoir accès à quoi que ce soit, non ?

Bonjour,

Un de mes amis a dans l'idée de créer un espèce de portail regroupant différents sites. Ceux ci seront accessibles au travers de son portail via une iframe.

Le problème c'est qu'actuellement la source de l'iframe est passée en claire dans l'url et qu'il est possible d'afficher n'importe quel page en saisissant son adresse dans les paramètres de l'URL.
Par exemple :
https://www.SITE PORTAIL.fr/contenuIframe.aspx?src=http://www.SITE DISTANT.fr
Vous l'aurez compris il est, pour l'instant, possible de spécifier n'importe quoi à la place de http://www.SITE DISTANT.fr et le site s'affiche dans son portail...

Ma question est : à part les risques de fishings y-a-t-il un réel risque à laisser tout est n'importe quoi s'afficher ?

D'avance merci !

Ok je vois mieux ce que vous voulez dire...
Je confondais les principes de protocoles en pensant que le FTP pouvait être encapsulé dans du HTTPS !

Le premier gros problème à résoudre et donc de ne plus faire de FTP via l'applet JAVA !

Et sinon qu'en est il de l'utilisation de FTPS ? Il me semble avoir lu que cela ne pouvait pas être sniffé ?

Merci pour ces éclaircissements !

Il n'y a aucune réponse satisfaisante à ton problème, car le principe même d'une applet java public faisant du FTP est bancal. Si l'applet peut le faire, quiconque se faisant passer pour l'applet le pourra également. Et empêcher la décompilation ne résout rien  : en imaginant que l'analyse statique soit impossible (ce qui est hautement improbable), il suffit de lancer l'applet dans un navigateur avec en parallèle un sniffer pour voir les flux FTP et donc les login et mot de passe utilisés.

À ce niveau là, ce n'est plus un problème de sécurisation de l'existant (ce qui, de toute façon, est une mauvaise idée), mais de conception.

Tout d'abord merci de cette réponse !
Je commençais à désespérer d'en avoir une ^^

J'avoue ne pas tout comprendre à ta réponse :
_ quiconque se faisant passer pour l'applet le pourra également : tu pourrais détailler le processus qui pourrait être utilisé stp ?
_ il suffit de lancer l'applet dans un navigateur avec en parallèle un sniffer pour voir les flux FTP et donc les login et mot de passe utilisés : je crois alors que j'ai un gros manquement dans mes connaissances de bases car il me semblait que si le site web était en HTTPS les flux sniffés n'étaient pas "compréhensibles" et donc pas utilisable ... J'aurais mal compris un truc ?

Encore merci de chercher à m'aider !

Bonjour à toute la communauté !

Je tourne vers vous car je souhaiterais avoir des éclaircissements au niveau de la sécurisation d'applets JAVA.

Pour vous situer dans le contexte je suis jeune développeur Web qui se passionne pour la sécurité, d'où ma présence sur ce site depuis quelques mois
En revanche mes connaissances en JAVA sont réellement limitées !

Je travaille depuis peu avec des gens qui prennent plaisir à coller des applets JAVA un peu partout dans leurs services web...
Cependant en suivant les tutoriels présent sur le web, et notamment ici, j'ai montré à mes collègues qu'il était aisément possible de télécharger leurs applets (fichiers *.jar) en saisissant l'url directement dans le navigateur...

Ces mêmes applets son "auto signés" (certificat auto généré) mais apparemment cela n'empêche en rien la décompilation via un petit soft comme JAD...
J'ai donc découvert en fouillant les codes sources décompilés que ces mêmes applets contenaient des accès FTP (login et mdp) !

Vous imaginez donc mon problème et celui de mes collègues : n'importe qui aurait pu télécharger les applets, les décompiler et accéder à certains FTP !

J'ai imaginé plusieurs scénarios pour tenter de pallier à ce problème :

• Protéger le répertoire contenant les applets avec un .htaccess et .htpasswd correctement construit de façon à empêcher leur téléchargement par n'importe qui.
  Mais comment faire pour que les applets continuent de fonctionner dans le site web ? A ma connaissance seul un script php peut accéder à un répertoire protéger par .htaccess, or plusieurs de nos sites web appellent ces applets en AJAX...
  Nos services étant en HTTPS le passage des paramètres par le script php pour accéder au .htaccess ne devrait pas être compromis...
  
• Laisser "libre accès" à nos applets mais modifier celle ci afin qu'elle ne contiennent par directement les comptes FTP :
  L'applet accéderais à un répertoire protéger par .htaccess et .htpasswd, ce répertoire contiendrait des fichiers (*.txt ou autres ?) qui eux mêmes contiendrait les login et mdp FTP...
  Là encore nous sommes en HTTPS, donc a priori lorsque l'applet accède au répertoire protégé le mot de passe n'est pas espionnable ?
  
• Combiner les deux ?
  Est-ce réellement utile ?
  
• Un autre moyen ?
  A ma connaissance il n'est pas possible d'empêcher de décompiler du code JAVA, la protection doit se faire donc ailleurs : empêcher de télécharger l'applet JAVA ou s'arranger pour qu'elle ne contiennent rien de compromettant me semble être les deux seules issues...
  

Bien entendu toutes les réponses et remarques concernant mon problème sont les bienvenues !

Merci Zmx, j'ai compris cette subtilité trop tard !

C'est Pixis qui m'a expliqué ça via IRC et donc après quelques essais j'ai pu valider le tout

Dans ce cas je ne comprends pas ce qui ne vas pas...

J'ai envoyé exactement la même chose que ce que j'avais déjà envoyé ailleurs pour récupérer ce qu'il faut mais rien ne se passe...

J'ai comme l'impression que je me heurte à la limite de la simulation de la faille...

Est il possible que je partage ma méthode avec quelqu'un par mail histoire qu'il me corrige si besoin ?

EDIT :
Pour Pixis : merci de chercher à m'aider, j'ai bien reçu ton MP mais je ne peux pas en envoyer moi même =/
En clair il faudrait que cette âme charitable m'envoi son adresse mail par MP car je n'ai apparemment pas assez de points pour en envoyer moi même...

Bonjour à tous,

Je penses avoir compris le principe de l'attaque mais j'aimerais avoir une précision : comment être sûr de ce que "lis" le bot ?

Je veux dire par là que je sais ce que j’envoie mais je ne sais pas comment c'est réceptionné par le bot ? Y a t il moyen de prévisualiser le message à sa réception histoire de savoir si il y a un encodage entre temps ?

Il me semble avoir lu qu'il s'agit de l'index par défaut de NB...

Donc si tu le croises c'est que tu fais fausse route

J'ai finalement mis la main sur l'un des fichiers recherchés !

Je penses que j'ai eu de la chance car je suis tombé directement sur le fichier contenant le password et non pas sur le fichier indiquant où se situe celui avec le password...

Bonjour à tous,

Désolé du dérangement, j'aimerais juste un précision :
Je parviens (comme beaucoup sans doute) au répertoire qui renvoi le fameux "Bien tenté mais non..." j'aimerais juste savoir si je suis trop loin ou si je dois fouiller à cet endroit précis ?

Merci