Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsWhite Papers
Discussion GroupsFirst AidDatabasesJavaBeansGUIJava 3DVirtual MachineCORBASecurityToolsGeneral
Java DirectoryOpen Source ProjectsSample Book ChaptersUser GroupsWeb Resources
Related Topics
Databases.NETMore Topics ...

Java Forum / Security / March 2004

Tip: Looking for answers? Try searching our database.

java applet security

Thread view: 
Matthijs Blaas - 26 Mar 2004 23:53 GMT
Hi all!

I have a situation that isn't fully clear to me, maybe anyone could clear
things up a bit for me, or tell me in what direction I should look for more
info about this:
I have an SSL connection to a certain website, on this secured website is an
php script issued that calls an applet with parameters. After the applet did
it's job the parameters it received from the php script are send along with
some other info it generated, to another php script (hosted on the same SSL
site).

Is this secure? I mean could one decompile the applet and have it listnen to
the data it receives from the php script, add his own info with it and send
this to the other php script? Or is it possible to 'see' if the applet is
issued from the secured domain and not local(possibly modified), or can't
one tap the parameters the php script would send as its over SSL?... Im a
little bit confused about this...

I'd greatly appreciate any help or links to more info about this issue!

-Thijs
Roedy Green - 28 Mar 2004 23:30 GMT
>Is this secure? I mean could one decompile the applet and have it listnen to
>the data it receives from the php script, add his own info with it and send
>this to the other php script? Or is it possible to 'see' if the applet is
>issued from the secured domain and not local(possibly modified), or can't
>one tap the parameters the php script would send as its over SSL?... Im a
>little bit confused about this...

that you could do in get a packet sniffer like Ethereal and just watch
the traffic to see if it is encrypted.

http://mindprod.com/jgloss/ethereal.html

--
Canadian Mind Products, Roedy Green.
Coaching, problem solving, economical contract programming.
See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.
Matthijs Blaas - 29 Mar 2004 13:19 GMT
I think the issue I have problems with is about how the caching of an applet
works:

I call my applet from the (SSL) website with parameters (the sessionid), the
applet is downloaded locally, does it's job and sends back a score along
with the sessionid it received. This id session is send back because the
receiving script will validate the incoming data with it, so that nobody
could just send their own score (they'd need a valid generated session id).

But if someone would decompile the locally downloaded applet and have the
modified applet listnen to the sessionid it receives and have the modified
applet to send his own score along with the hijacked sessionid back... is
there a way to overcome this or will there automatically be checked if the
applet really is the original applet from the website? I don't know how this
is handled...

-Thijs

> >Is this secure? I mean could one decompile the applet and have it listnen to
> >the data it receives from the php script, add his own info with it and send
[quoted text clipped - 12 lines]
> Coaching, problem solving, economical contract programming.
> See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.


Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.