Hmm, that's a huge effort to go to. I would be interested to know what sort
of applications people consider it important to hide the html for. For
normal web pages I cannot see any reason why you would bother. After all,
the important thing is the content not the html. And in reality, html is
just content plus tags so why worry about whether someone can see them ? 


Regards,
Derek Clarkson
Global Applications
Lonely Planet Publications
ph: (03) 8379-8000 x8041
"It's not a bug - it's an undocumented feature!"

-----Original Message-----
From: Frank W. Zammetti [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, 9 November 2004 2:35 PM
To: Tomcat Users List
Subject: Re: hide source of a page

I had such a requirement at work one time, although fortunately I talked
some sense into the higher-ups and they forgot about it, but not before I
worked up an entire proof-of-concept document.  IN THEORY, this could make
it very difficult for would-be hackers, although I wouldn't say fullproof.

The idea was to set up a frameset with one invisible frame and one
full-screen frame.  Into the invisible frame would go an ActiveX control
that was encrypted with a custom binary encrypter program (could be an
applet too, but obfuscation isn't as good as encoding a binary). 
Basically, every form submission to the server would go through the control,
and every response from the server would go through it, both encrypted.  On
the response from the server, HTML is generated out of the control and
placed into the frame in an obfuscated form.  Javascript it used to guard
against right-clicks and keyboard shortcuts, and since the app starts up in
it's own chromless window, it's relatively secure from most clientside
exploits.  There is a handshake between the control and the server at
startup that basically sets up a temporary public/private key pair, the
point being to make it impossible to just issue commands via Telnet.  You'd
have to fake considerably more than just some URLs or header variables.

So, the idea is that you could probably still get at the source, but it
wouldn't be in cache so you'd probably have to use a memory scanner, but
even if you did that it would be in an obfuscated form.  Not impossible to
decypher, but probably hard enough that most people wouldn't both. 
Getting at the server is going to be difficult.  You could still decompile
the control, but that's not going to be at all easy either considering the
obfuscation and encryption (think a PE compactor approach).

I think making it tough is about as good as you can hope to do, but as
Steven said, it's ALWAYS going to be defeatable one way or another.

--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com

Steven J. Owens wrote:
> On Mon, Nov 08, 2004 at 09:37:09PM -0500, Dov Rosenberg wrote:
> 
>>The only thing I can think of to hide the source of the page is to 
>>create your own private label browser or perhaps load the source of 
>>the page in a hidden frame and use some javascript to display the text 
>>you want. Not sure why you would want to go thru the hassle - there 
>>are lots of ways to defeat any measure.
> 
> 
>      You're right, this is futile, because it's trivial to get the 
> source of the page, no matter what you do at the browser level.  The 
> browser has to see the source to render it, therefore the server is 
> providing the source, upon request, to anything that knocks at port 80 
> and asks for it.  Getting the source is as simple as telnetting to the 
> webserver on port 80 and faking the commands.  Or run a packet sniffer 
> in the network you're browsing from.  Or run a logging http proxy on 
> your own machine and point your browser at it.
> 
>      You can't show something to people and keep it secret at the same 
> time.
>  
> 




---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


______________________________________________________________________
This email, including attachments, is intended only for the addressee
and may be confidential, privileged and subject to copyright.  If you
have received this email in error, please advise the sender and delete
it.  If you are not the intended recipient of this email, you must not
use, copy or disclose its content to anyone.  You must not copy or 
communicate to others content that is confidential or subject to 
copyright, unless you have the consent of the content owner.

Reply via email to