Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Adresse IP d'une applet Java
Bonjour à tous
j'ai intégré une applet java dans mon site web qui sert de client SSH.
La question que je me pose est la suivante (je n'y connais pas grand chose en java) : quelle adresse IP va prendre mon applet ? l'adresse IP du serveur qui l'héberge ou celle de la personne qui se connecte sur le site ?
Dans le deuxieme cas, existerait-il un moyen de repasser au premier cas ?
(je voudrais pouvoir utiliser "localhost" pour me connecter à ce serveur via l'applet...)
merci
Nicolas
si ton travail est difficile et tes résultats sont minces
n’oublie pas qu’un jour, le grand chêne a été un gland comme toi.
Bonjour,
L'applet s’exécute coté client, donc ton serveur verra un client SSH avec l'ip du poste client qui essai de se connecter.
Ca n'a pas de sens, pourquoi tu veux faire ça ?(je voudrais pouvoir utiliser "localhost" pour me connecter à ce serveur via l'applet...)
En fait mon idée initiale était d'utiliser une page du type AjaxtermEnvoyé par Jimmy_
pour ne pas avoir à ouvrir de port SSH vers l'exterieur étant donné que dans ce cas, l'adresse serait drectement celle du serveur où est hébergée la page web... mais devant quelques problèmes techniques rencontrés, je me suis rabattu sur l'applet java du client SSH MindTerm.
si ton travail est difficile et tes résultats sont minces
n’oublie pas qu’un jour, le grand chêne a été un gland comme toi.
n'oubliez pas qu'un applet s'exécute coté client, donc tout utilisateur de votre site a maintenant une accès ssh sur votre serveur puisque les user/pass sont dans l'applet, êtes vous sûr que c'est ce que vous voulez?
Négatif (enfin si j'en crois les specs...) car il ne s'agit pas d'une interface spécifique à mon serveur, mais d'un client SSH2 classique... sous JAVA.n'oubliez pas qu'un applet s'exécute coté client, donc tout utilisateur de votre site a maintenant une accès ssh sur votre serveur puisque les user/pass sont dans l'applet, êtes vous sûr que c'est ce que vous voulez?
Ainsi [en principe] rien n'est marqué en dur dans le code de l'applet, car rien ne m'empeche de me connecter à un autre serveur, ou encore avec d'autres identifiants. Si quelqu'un récupère le .jar (d'ailleurs c'est peut-etre une autre extension, je ne sais plus...l'applet quoi...) la personne aura normalement juste un client SSH à dispo, en aucun cas (j'espère réellement encore une fois) un identifiant ou password.
De plus, le formulaire de ma page web étant transmis en HTTPS/SSL et les données via SSH2, et la page elle-même étant protégée par mot de passe (utilisant le SDK du serveur SYNOLOGY, donc pas de bidouillage...), j'espère avoir minimisé les risques...
Reste à savoir comment ne pas mettre en cache du tout l'applet, mais pour ca, j'attends vos suggestions :o)
Néanmoins, je pense (et je croise les doigts) avoir sécurisé un max mon installation.
Bye
Nico
si ton travail est difficile et tes résultats sont minces
n’oublie pas qu’un jour, le grand chêne a été un gland comme toi.
Ce que je veux dire c'est que votre utilisateur à accès au user/pass que vous utilisez pour votre ssh. Puisque ca s'exécute coté client. Maintenant si chaque user à ses propres identifiants sur votre serveur ssh et qu'il est normal qu'il les connaisse, pas de soucis évidement
euh... je ne comprends pas...Maintenant si chaque user à ses propres identifiants sur votre serveur ssh et qu'il est normal qu'il les connaisse, pas de soucis évidement
Dans le cas présent, chaque utilisateur, pour se connecter à la page web elle-même doit etre enregistré dans le serveur; C'est avec ces memes credentials qu'il peut se connecter au SSH avec ses propres droits, donc normal ou pas... ?
si ton travail est difficile et tes résultats sont minces
n’oublie pas qu’un jour, le grand chêne a été un gland comme toi.
Ben a priori oui alors
Ce qu'il faut éviter c'est que N users différent partagent via l'applet le même crédential
pour cela (hormis un problème d'usurpation de session), ce cas ne se produirait que si les personnes passaient sur le même poste physique, n'est-ce pas ?
si ton travail est difficile et tes résultats sont minces
n’oublie pas qu’un jour, le grand chêne a été un gland comme toi.
Dans votre cas je ne sais pas si c'est possible. C'est juste que certains devs ont parfois tendance à oublier que l'applet est exécutée coté client et d'envoyer un mot de passe à l'applet sans penser que du coup l'utilisateur peut le lire, alors que ce mot de passe est supposé secret et le même pour tout le monde. Donc je voulais vous éviter cette erreur
Je ne compte plus le nombre de fois sur ce forum où les gens envoient directement le mot de passe d'accès root à la base de donnée dans une applet, histoire que n'importe quel utilisateur puisse foutre le bordel dans les tables
La principale faille de sécurité de ce type de connexion.
Outre le keylogger, c'est la fameuse 'canne à pêche'.
Il est assez simple de créer une applet semblable de récupérer le mot de passe et de connecter l'utilisateur ni vu ni connu.
Le seul moyen est de passer à l'authentification forte avec un token comme SecureID par exemple.
dans mon cas, le shéma est le suivant
CLIENT <- HTTPS -> page PHP (protégée par sessions & identifiants stockés sur le serveur en utilisant SDK de synology) avec applet JAVA MindTerm <-> SSH2 <-> SERVEUR
so... qu'en pensez vous ?
Nico
si ton travail est difficile et tes résultats sont minces
n’oublie pas qu’un jour, le grand chêne a été un gland comme toi.
en faisant du phishing ? l'accès à ma page ne se fait qu'après authentification par le serveur... donc si l'utilisateur arrive sur la page (celle qui contient l'applet), elle ne verra celle ci que s'il est identifié; sinon, il verra la formulaire de login. Donc s'il s'agit de cette faille de sécu, je peux accepter le risque; de plus, je suis censé etre le seul utilisateur...
pas possible ici, je n'ai pas de serveur RSA chez moi
oui
si ton travail est difficile et tes résultats sont minces
n’oublie pas qu’un jour, le grand chêne a été un gland comme toi.
Créer l'applet semblable est facile, d'autant plus qu'il utilise une applet fortement distribué. Par contre, arriver à l'afficher au milieu d'un page SSL négociée avec son serveur est impossible sans avoir au préalable foutu en l'air le SSL, auquel cas, de toutes façons, on a déjà pu récupérer le login/pass et on va pas en plus s'emmerder avec l'applet.
De toutes façons, le client peut aussi utiliser directement son propre client ssh (openssh sous linux, putty sous windows)
ce qui voudrait dire avoir cracké SSL + écouté l'info circulant en SSH2...
ca fait pas un peu beaucoup de complications pour un pirate qui voudrait juste un accès sur un serveur perso ?
Nico
si ton travail est difficile et tes résultats sont minces
n’oublie pas qu’un jour, le grand chêne a été un gland comme toi.
Non, je parle du client qui a le droit de faire le ssh (celui qui recois l'applet qui lui est destinée), il a rien a cracker toute est dans l'applet et ses paramètres
eh eh, à priori même pas..Non, je parle du client qui a le droit de faire le ssh (celui qui recois l'applet qui lui est destinée), il a rien a cracker toute est dans l'applet et ses paramètres
En réalité les parametres ne sont passées à l'applet que s'il passe par la page web sur laquelle il s'est authentifié.
Si l'utilisateur ne récupère que le .jar (ou la partie java quoi), il s'agira alors d'un client SSH tout ce qu'il y a de plus simple... pas de crédential en dur
En revanche, s'il s'authentifie sur la page, il peut effectivement regarder le code source... qui contiendra ce qu'il connait déjà puisqu'il s'est authentifié pour y accéder
Après, évidemment s'il marque ses identifiants sur un post-it...
Nico
si ton travail est difficile et tes résultats sont minces
n’oublie pas qu’un jour, le grand chêne a été un gland comme toi.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager