Newsgroup: it.comp.java
Titolo: java e sicurezza ? dove

Ma scusate si parla di sicurezza in java e ho appena letto un post dove dice
di essere riuscito a scaricare tutti i class (anche quelli che risiedono sul
server) e quindi averli fisicamente sul pc, inoltre ho provato a decompilare
e ricompilare un class e ho visto che funziona benissimo. Ma così dove stà
la sicurezza di cui tanto si parla quando si devono sviluppare programmi
client server.
Accendo questa discussione perchè ho iniziato un corso di java ma non vorrei
sprecare solo tempo se poi il mio lavoro è, con pochi semplici passaggi,
leggibile da chiunque e chiunque potrebbe trovare delle gabole per accedere
ai servizi che il programma client server offre.
Rassicuratemi vi prego !
Dani


La security by obscurity non e' mai stata (e non solo a mio avviso) una 
soluzione efficace, e questo e' stato dimostrato piu' e piu' volte nel 
tempo. Ad es: i programmi open source hanno un numero di vulnerabilita' 
pari (o addirittura, a volte, inferiori!) a quelli commerciali, closed 
source - il che dimostra che non e' quello il punto.
La sicurezza di Java (per quanto possa essere discutibile sotto questo 
aspetto quanto sia robusto il suo modello) non e' certo nel chiudere il 
sorgente, ma nell'ambiente (sicuro, per l'appunto) che offre ad un 
programma per girare ed interagire con i componenti al suo esterno.
-- 
/**
  * Mattia Belletti - Undergraduate student @ 
cs.unibo.it
  * ICQ: 33292311   - email: 
mbel...@cs.unibo.it
  * IRC: BluShine   - site(s): 
http://cs.unibo.it/~mbellett
  * Linux registered user 299762 @ Linux registered machine 213003
  */

 ha scritto nel messaggio
news:3awJb.23091$i_5....@news.edisontel.com...
CUT
hai uno strano concetto di sicurezza.
sicurezza non è impedire che leggano il tuo codice.
Linux non è sicuro, allora?
ivan
-- 
Kangaroo's Country - V.15  - Italia (Hattrick.org)
tessera #052 club dei Mille.
ID IGHer N° 13 (it.hobby.giochi)
Proud to be a ZappaFanatic!

Devo fare una precisazione dovuta a questo punto:
se scrivo un programma commerciale che svolge dei servizi su internet è
scontato che se riescono, come con un programma tramite teleport o simili, a
scaricare i miei class (praticamente i sorgenti) potrebbero, analizzandoli,
trovare buchi per utilizzare gratuitamente il servizio che ho faticosamente
e dispendiosamente progettato realizzato e manutenuto. Cioè open source è un
concetto, è una filosofia e linux è fuori dalla discussione.
Dani

 server) e quindi averli fisicamente sul pc,
Dovresti chiarire di che cosa stai parlando. Che applicazione? Che
server?
Se stai parlando di un'applicazione JSP/Servlet (che sfrutti ad
esempio Tomcat come server) la cosa mi risulta strana poiche' le
classi normalmente risiedono all'interno della directory WEB-INF che
non dovrebbe essere accessibile dall'esterno del server.
In ogni caso, come ti hanno gia' detto, la sicurezza di un programma
non deve dipendere dal fatto che i suoi sorgenti non sono conosciuti.
Andrea

 concetto, è una filosofia e linux è fuori dalla discussione.
Qui non si tratta tanto della filosofia open source, quanto del fatto
che basare la sicurezza di un protocollo o di un'applicazione sulla
mancanza di conoscenza dei sorgenti e' decisamente pericoloso.
Sicurezza in java non significa che nessuno potra' accedere ai
sorgenti del tuo programma. Significa che il linguaggio e le librerie
standard mettono a disposizione tutta una serie di strumenti per la
realizzazione di applicazioni sicure (ad esempio il supporto alla
crittografia).
Andrea Polci

 non dovrebbe essere accessibile dall'esterno del server.
Anche a me sembra molto strano riuscire a downloadare i file class da un
server J2EE.. so che con vecchie release era possibile, sfruttando bug degli
application servers, forzare i servizi esposti da file servlet built-in (di
solito utilizzate dalla console di gestione di questi a.s per l'upload di
ear o quant'altro ) per accedere ai file class, ma il problema dovrebbe
essere risolto con le ultime release...
Comunque, per maggiore sicurezza aggiungi un firewall.
Scorpio.

Ringrazio tutti dei chiarimenti e credo che anche per me sia giunto il
momento di approfondire la conoscenza di java. Ci rileggiamo con argomenti
meno provocatori.
Un Ciao a tutti !
Dani


Riguardo a quello che si è detto vorrei fare alcune considerazioni per avere
un po' di chiarezza e rispondere ad alcuni miei dubbi.
Dunque da ciò che leggo "sembrebbe" che i .class siano accessibili,
quantomeno se si ha accesso diretto al web server.
Ora chiedo :
i .class non sono bytecode??? ovvero non corrispondono ad un .exe compilato
in C/c++?
Se apro con il notepad un file .class vedo che è illeggibile (bytecode), da
ciò che ho letto sembrerebbe invece che i .class siano sorgenti utilizzabili
"tranquillamente" da chi ha accesso al web server.
Questo significa, senza entrare troppo nel merito di logiche commerciali,
che non ho nessuna tutela della mia proprietà intellettuale nè nei riguardi
del cliente (che ha accesso diretto al web server) nè nel riguardo di terzi
che accedono direttamente al server oppure visionano da client il codice
(sotto questo aspetto che si scriva in php/asp/jsp ho visto che il codice è
leggibile).
Concordate? Avete ulteriori considerazioni da fare?
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
alex wrote:
| i .class non sono bytecode??? ovvero non corrispondono ad un .exe
compilato
| in C/c++?
Sì, ma con la differenza che un compilatore C di solito "incasina" il
codice ottimizzandolo, invece "javac" evita *apposta* di ottimizzare il
codice in modo che sia più facimlente ottimizzabile a runtime dalla Hotspot.
Quindi in pratica l' "assemblato" .class è in relazione 1:1 con un
sorgente .java.
(tranne ovviamente i commenti e i nomi delle variabili nno pubbliche)
| Se apro con il notepad un file .class vedo che è illeggibile
(bytecode), da
| ciò che ho letto sembrerebbe invece che i .class siano sorgenti
utilizzabili
| "tranquillamente" da chi ha accesso al web server.
Confermo.
| Concordate?
Sì.
| Avete ulteriori considerazioni da fare?
Sì: fai programmi opensource a priori (così non te li rubano, eheh) e
usa la crittografia per avere sicurezza, non la "sicurezza per
oscurantesimo" che non funziona mai ;-)
Se ti interessa la crittografia ti rimando (anche) all'ottimo
it.comp.sicurezza.crittografia, dove ogni argomento correlato è
accettato e discusso =)
- --
L a p o   L u c h i n i
l a p o @ l a p o . i t
w w w . l a p o . i t /
http://www.megatokyo.it
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (Cygwin)
Comment: Using GnuPG with Mozilla - 
http://enigmail.mozdev.org
iEYEARECAAYFAj/9bFoACgkQaJiCLMjyUvtc1gCgn5w1e90nQNAxQOEw6VTxhSnF
AP8AoN/bK1WxU/8taPLDhLmYnl48qqe2
=QBCk
-----END PGP SIGNATURE-----

 leggibile).
... a meno che non si utilizzino dei programmi chiamati "offuscatori
del codice" che fanno in modo di rendere il risultato di una
eventuale decompilazione illeggibile. Ad esempio questi programmmi
rinomina tutti gli identificatori (nomi di variabili, metodi e classi)
in modo da renderli non significativi (ma fanno anche altre cose,
cerca "java obfuscator" con google se vuoi dettagli).
Tra l'altro uno dei risultati di questi programmi e' che i .class
da loro prodotti sono di solito piu' piccoli di quelli originali.
Andrea Polci
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 Avete ulteriori considerazioni da fare?
Stai confondendo le problematiche di sicurezza con quelle di proprieta' 
intellettuale. Le due cose non sono, a mio avviso, legate fra di loro.
- Dario