Logo GNT
Actualités Tests & Guides Bons Plans
Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11
Entraide Développement Développement Langage Java Applet/JWS Sécurité

Applet/JWS Sécurité

8 réponses
Avatar
1 connu
Bonjour à tous,

J'ai une appli que je peux déployer comme applet ou lancé par JWS

Cette appli lit un flux généré sur le même serveur avec le code standard :
URL oracle = new URL("http://www.monserveur.com/");
URLConnection yc = oracle.openConnection();
BufferedReader in = new BufferedReader(
new InputStreamReader(
yc.getInputStream()));
String inputLine;

while ((inputLine = in.readLine()) != null)
System.out.println(inputLine);
in.close();

L'applet n'a pas de probleme mais lancé par JWS, la sécurité paranoiaque bloque :

java.lang.SecurityException: denied access outside a permitted URL subpath
at sun.net.www.protocol.http.HttpURLConnection.checkURLFile(Unknown Source)
at sun.net.www.protocol.http.HttpURLConnection.writeRequests(Unknown Source)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown Source)


Est ce un bug ou vraiment la sécurité est plus sévére avec JWS ?

Merci
Signaler un problème avec ce contenu

8 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Avatar
1 connu
même en signant le jar, on a la même erreur. Pas de moyen de déployer avec JWS ?

"1 connu" a écrit dans le message de news: adb2$4e1c464d$55da232e$
Bonjour à tous,

J'ai une appli que je peux déployer comme applet ou lancé par JWS

Cette appli lit un flux généré sur le même serveur avec le code standard :
URL oracle = new URL("http://www.monserveur.com/");
URLConnection yc = oracle.openConnection();
BufferedReader in = new BufferedReader(
new InputStreamReader(
yc.getInputStream()));
String inputLine;

while ((inputLine = in.readLine()) != null)
System.out.println(inputLine);
in.close();

L'applet n'a pas de probleme mais lancé par JWS, la sécurité paranoiaque bloque :

java.lang.SecurityException: denied access outside a permitted URL subpath
at sun.net.www.protocol.http.HttpURLConnection.checkURLFile(Unknown Source)
at sun.net.www.protocol.http.HttpURLConnection.writeRequests(Unknown Source)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown Source)


Est ce un bug ou vraiment la sécurité est plus sévére avec JWS ?

Merci

Avatar
Jocelyn
Le 12/07/2011 16:36, 1 connu a écrit :
même en signant le jar, on a la même erreur. Pas de moyen de déployer avec JWS ?

"1 connu" a écrit dans le message de news: adb2$4e1c464d$55da232e$
Bonjour à tous,

J'ai une appli que je peux déployer comme applet ou lancé par JWS

Cette appli lit un flux généré sur le même serveur avec le code standard :
URL oracle = new URL("http://www.monserveur.com/");
URLConnection yc = oracle.openConnection();
BufferedReader in = new BufferedReader(
new InputStreamReader(
yc.getInputStream()));
String inputLine;

while ((inputLine = in.readLine()) != null)
System.out.println(inputLine);
in.close();

L'applet n'a pas de probleme mais lancé par JWS, la sécurité paranoiaque bloque :

java.lang.SecurityException: denied access outside a permitted URL subpath
at sun.net.www.protocol.http.HttpURLConnection.checkURLFile(Unknown Source)
at sun.net.www.protocol.http.HttpURLConnection.writeRequests(Unknown Source)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown Source)


Est ce un bug ou vraiment la sécurité est plus sévére avec JWS ?

Merci







Quelle version exacte de Java est-utilisée ? Avez-vous le cas échéant
essayé une version plus à jour ?

--
Jocelyn LECOMTE
http://www.torrefacteurjava.fr/
Avatar
1 connu
"Jocelyn" a écrit dans le message de news: 4e22dd8c$0$7843$
Le 12/07/2011 16:36, 1 connu a écrit :
même en signant le jar, on a la même erreur. Pas de moyen de déployer avec JWS ?

"1 connu" a écrit dans le message de news: adb2$4e1c464d$55da232e$
Bonjour à tous,

J'ai une appli que je peux déployer comme applet ou lancé par JWS

Cette appli lit un flux généré sur le même serveur avec le code standard :
URL oracle = new URL("http://www.monserveur.com/");
URLConnection yc = oracle.openConnection();
BufferedReader in = new BufferedReader(
new InputStreamReader(
yc.getInputStream()));
String inputLine;

while ((inputLine = in.readLine()) != null)
System.out.println(inputLine);
in.close();

L'applet n'a pas de probleme mais lancé par JWS, la sécurité paranoiaque bloque :

java.lang.SecurityException: denied access outside a permitted URL subpath
at sun.net.www.protocol.http.HttpURLConnection.checkURLFile(Unknown Source)
at sun.net.www.protocol.http.HttpURLConnection.writeRequests(Unknown Source)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown Source)


Est ce un bug ou vraiment la sécurité est plus sévére avec JWS ?

Merci







Quelle version exacte de Java est-utilisée ? Avez-vous le cas échéant essayé une version plus à jour ?


Plug-in Java 10.0.1.255
JRE 1.6.0_22-b04
Avatar
1 connu
"Jocelyn" a écrit dans le message de news: 4e22dd8c$0$7843$
Le 12/07/2011 16:36, 1 connu a écrit :
même en signant le jar, on a la même erreur. Pas de moyen de déployer avec JWS ?

"1 connu" a écrit dans le message de news: adb2$4e1c464d$55da232e$
Bonjour à tous,

J'ai une appli que je peux déployer comme applet ou lancé par JWS

Cette appli lit un flux généré sur le même serveur avec le code standard :
URL oracle = new URL("http://www.monserveur.com/");
URLConnection yc = oracle.openConnection();
BufferedReader in = new BufferedReader(
new InputStreamReader(
yc.getInputStream()));
String inputLine;

while ((inputLine = in.readLine()) != null)
System.out.println(inputLine);
in.close();

L'applet n'a pas de probleme mais lancé par JWS, la sécurité paranoiaque bloque :

java.lang.SecurityException: denied access outside a permitted URL subpath
at sun.net.www.protocol.http.HttpURLConnection.checkURLFile(Unknown Source)
at sun.net.www.protocol.http.HttpURLConnection.writeRequests(Unknown Source)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown Source)


Est ce un bug ou vraiment la sécurité est plus sévére avec JWS ?

Merci







Quelle version exacte de Java est-utilisée ? Avez-vous le cas échéant essayé une version plus à jour ?




Testé avec la derniere version JWS :
Java Web Start 1.5.0_14
Utilisation de la version JRE 1.6.0_26 Java HotSpot(TM) Client VM

C'est pareil !
java.lang.SecurityException: denied access outside a permitted URL subpath
at sun.net.www.protocol.http.HttpURLConnection.checkURLFile(Unknown Source)
at sun.net.www.protocol.http.HttpURLConnection.writeRequests(Unknown Source)
Avatar
Yliur
Testé avec la derniere version JWS :
Java Web Start 1.5.0_14
Utilisation de la version JRE 1.6.0_26 Java HotSpot(TM) Client VM

C'est pareil !
java.lang.SecurityException: denied access outside a permitted URL
subpath at
sun.net.www.protocol.http.HttpURLConnection.checkURLFile(Unknown
Source) at
sun.net.www.protocol.http.HttpURLConnection.writeRequests(Unknown
Source)



"outside a permitted URL *subpath*"

Est-ce qu'il ne ferait pas la tête parce que l'applet se trouve dans
www.monserveur.com/truc/machin/applet/* et que tu tentes d'accéder à
www.monserveur.com/ ?
Avatar
Yliur
"1 connu" a écrit :

> "outside a permitted URL *subpath*"
>
> Est-ce qu'il ne ferait pas la tête parce que l'applet se trouve dans
> www.monserveur.com/truc/machin/applet/* et que tu tentes d'accéder à
> www.monserveur.com/ ?
>
ha oui, merci.
En fait,l'applet est dans www.monserveur.com/applet servie par le
serveur web statique. Mais elle attaque une appli qui génére du
contenu dynamique donc l'url est du type :
www.monserveur.com/cgi-bin/MonAppli/...

Un idée pour rendre ca possible ?



Ce n'est pas possible de faire ça au niveau du serveur web ? Par
exemple créer un lien symbolique du répertoire de l'applet vers les
données de l'autre appli (pas sûr que le serveur accepte de suivre le
lien, par sécurité) ? Ou de faire une redirection au niveau du
serveur : lui indiquer que les URL de la forme /applet/donnees/ doivent
être réécrites en /cgi-bin/MonAppli/ ?
Avatar
Yliur
Le Mon, 25 Jul 2011 17:14:15 +0200
"1 connu" a écrit :


"Yliur" a écrit dans le message de news:

> "1 connu" a écrit :
>
>> > "outside a permitted URL *subpath*"
>> >
>> > Est-ce qu'il ne ferait pas la tête parce que l'applet se trouve
>> > dans www.monserveur.com/truc/machin/applet/* et que tu tentes
>> > d'accéder à www.monserveur.com/ ?
>> >
>> ha oui, merci.
>> En fait,l'applet est dans www.monserveur.com/applet servie par le
>> serveur web statique. Mais elle attaque une appli qui génére du
>> contenu dynamique donc l'url est du type :
>> www.monserveur.com/cgi-bin/MonAppli/...
>>
>> Un idée pour rendre ca possible ?
>
> Ce n'est pas possible de faire ça au niveau du serveur web ? Par
> exemple créer un lien symbolique du répertoire de l'applet vers les
> données de l'autre appli (pas sûr que le serveur accepte de suivre
> le lien, par sécurité) ? Ou de faire une redirection au niveau du
> serveur : lui indiquer que les URL de la forme /applet/donnees/
> doivent être réécrites en /cgi-bin/MonAppli/ ?
>
Merci pour ces suggestions. Pas mal galéré pour peu de resultat ...

Puis, j'ai essayé dans le jnlp :
<security>
<j2ee-application-client-permissions/>
</security>

et là ca passe nickel !
Il faut signer le jar mais il n'y a pas d'avertissement de sécurité.



L'inconvénient de cette solution c'est qu'il faut un jar signé, donc
quand même une demande d'autorisation à l'utilisateur, non ? Si c'est
pour un site public, il se peut qu'il se méfie et change d'avis. Alors
que rester dans le cadre de sécurité standard des applets ne nécessite
pas d'autorisation de l'utilisateur. Après je ne suis pas sûr de
comment ça se passe exactement et ça dépend de qui est l'utilisateur du
site.
Avatar
Yliur
Le Wed, 27 Jul 2011 09:21:06 +0200
"1 connu" a écrit :


"Yliur" a écrit dans le message de news:

> Le Mon, 25 Jul 2011 17:14:15 +0200
> "1 connu" a écrit :
>
>>
>> "Yliur" a écrit dans le message de news:
>>
>> > "1 connu" a écrit :
>> >
>> >> > "outside a permitted URL *subpath*"
>> >> >
>> >> > Est-ce qu'il ne ferait pas la tête parce que l'applet se
>> >> > trouve dans www.monserveur.com/truc/machin/applet/* et que tu
>> >> > tentes d'accéder à www.monserveur.com/ ?
>> >> >
>> >> ha oui, merci.
>> >> En fait,l'applet est dans www.monserveur.com/applet servie par
>> >> le serveur web statique. Mais elle attaque une appli qui génére
>> >> du contenu dynamique donc l'url est du type :
>> >> www.monserveur.com/cgi-bin/MonAppli/...
>> >>
>> >> Un idée pour rendre ca possible ?
>> >
>> > Ce n'est pas possible de faire ça au niveau du serveur web ? Par
>> > exemple créer un lien symbolique du répertoire de l'applet vers
>> > les données de l'autre appli (pas sûr que le serveur accepte de
>> > suivre le lien, par sécurité) ? Ou de faire une redirection au
>> > niveau du serveur : lui indiquer que les URL de la
>> > forme /applet/donnees/ doivent être réécrites
>> > en /cgi-bin/MonAppli/ ?
>> >
>> Merci pour ces suggestions. Pas mal galéré pour peu de resultat ...
>>
>> Puis, j'ai essayé dans le jnlp :
>> <security>
>> <j2ee-application-client-permissions/>
>> </security>
>>
>> et là ca passe nickel !
>> Il faut signer le jar mais il n'y a pas d'avertissement de
>> sécurité.
>
> L'inconvénient de cette solution c'est qu'il faut un jar signé, donc
> quand même une demande d'autorisation à l'utilisateur, non ? Si
> c'est pour un site public, il se peut qu'il se méfie et change
> d'avis. Alors que rester dans le cadre de sécurité standard des
> applets ne nécessite pas d'autorisation de l'utilisateur. Après je
> ne suis pas sûr de comment ça se passe exactement et ça dépend de
> qui est l'utilisateur du site.
>
effectivement, il y a aussi un avertissement comme pour
<all-permissions/>. Donc, je ne vois pas l'interet vu que la punition
est la même. C'est quand même débile de demander une autorisation
pour juste faire une bête requete http sur un site public qu'on peut
faire avec n'importe quel browser. Bug ou paranoia ?



Ce n'est pas débile : le programme fait la requête sans te demander,
contrairement à si tu fais une requête avec ton navigateur. Et la JVM
(ou son système de sécurité) ne peut pas évaluer les informations qui
sont envoyées au serveur par l'applet (y a-t-il vol d'information ?).
Il s'agit quand même d'exécuter un programme sorti d'on ne sait où sur
ta machine, c'est normal que les possibilités soient limitées. On
suppose que là où tu exécute l'applet tu fais confiance au site, mais
l'applet ne peut pas demander des instructions à un autre site, ni
aller chercher du code ailleurs, ...

Le but est d'avoir un environnement et des possibilités plus ou moins
contrôlés, pour exécuter une appli étrangère sans trop de danger.