[3985] in WWW Security List Archive
Re: Javascript and Security
daemon@ATHENA.MIT.EDU (Fred Donck)
Wed Jan 15 12:22:27 1997
Date: Wed, 15 Jan 1997 15:13:13 +0100
From: Fred Donck <f.c.w.donck@siep.shell.com>
To: ocean5@ix.netcom.com
Cc: www-security@ns2.rutgers.edu
Errors-To: owner-www-security@ns2.rutgers.edu
We in Shell are also looking at the problem of enabling/disabling
Java(script) at the firewall.
Currently our internal service-provider which holds the actual Internet
connection has configured the firewall in such a way that Java(script)
is disabled from coming into our internal (Shell) world-wide network.
One of my collegues has found a product on the net that resides on the
FW and examines the Java(script) bytestream for malicious code.
See below.
Later,
Fred
http://www.data.com:80/hot_products/software_security/finjan.html
Safe Internet Surfing
The Surfingate firewall from
Finjan
keeps rogue applets
out
With Surfingate from Finjan, 'Net surfers get the best of both worlds:
Java applications and top-notch security. This Java firewall is the
first product to detect rogue applets that steal critical files or
undermine e-mail security.
In fact, Surfingate is the only firewall that understands Java code.
This allows it to find embedded hacker attacks that would slip through
other firewalls.
Right now, the biggest problem facing Surfingate is maturity--or the
lack of it. The product hasn't yet been field-tested, so actual
performance is a question mark.
Poison Applets
Net managers downloading applets from the 'Net are courting disaster.
Despite a Security Manager found in each Java Web browser, users remain
vulnerable to attacks. One such attack is denial of service, in which
applets execute legitimate commands continuously until a system
crashes, according to Nachshon Gal, director of research and
development at Finjan Ltd. (Netanya South, Israel).
Finjan's software blocks these attacks by examining the code of
incoming applets. The software consists of two components: the
Surfingate Server and the Surfin Management Console. The server, which
sits behind the corporate firewall, gives each incoming applet a
signature ID so that it's easily identified in the future. The server
then runs the applet's code through its database to determine the
applet's security risk or ASP (Applet Security Policy). The ASP is a
list of common attributes of rogue applets.
Next, Surfingate Server retrieves the end-user's security policy and
compares it to the applet's ASP. Client security policies are set up
via the Surfin Management Console and define what kinds of operations a
Java applet may execute on an end-user's machine. Applets that square
with the security policy are sent to the client. Rogue applets are
blocked and replacement applets are sent instead, with a message saying
that the requested applet was determined to be dangerous.
Other firewall products, like Firewall-1 from Checkpoint Software
Technologies (Lexington, Mass.), also come with Java security. But
these firewalls don't understand Java and can't differentiate between
benign and harmful applets. The only option that net managers have is
to choose between permitting or rejecting all applets written in Java.
Both the Surfingate Server and the Surfin Management Console run under
any operating system that supports Java, but so far they've only been
tested on Windows NT and 95 and Unix. The price is $1,250 for 10
clients; $7,950 for 100 clients; and $18,950 for unlimited users.--By
David Greenfield
Finjan; 972-9-659-440, http://www.finjan.com
Ocean5 wrote:
>
> >| WEB SPOOFING IS NO JOKE
> >| Researchers at Princeton University have released a paper documenting ways
> >| that nefarious crackers could dupe unwitting Web browsers into divulging
> >| personal information,
>
> <<< SNIP>>>
>
> >| The researchers suggest that Web surfers take the following
> >| precautions: disabling JavaScript in their Web browsing software; keeping
> >| an eye on the software's location line, to ensure they know where they are;
> >| and paying close attention to the addresses they visit. (Chronicle of
> >| Higher Education 10 Jan 97 A25)
> >| < http://www.cs.princeton.edu/sip/pub/spoofing.html >
>
> The clip above speaks about disabling JavaScript. This is hyped allot
> as being the "thing" to do if you're worried about security while on the
> web. I wonder though if the security holes that can be "closed" on a
> browser by disabling JavaScript on the client, can be reopened if the
> Script is run on the server? Like on a Netscape Server using the
> Livewire environment...?
>
> Disable JavaScript if you will, but its a pretty helpful bit of
> technology at times. It seems a big trade, to loose the functionality
> of this Scripting language for the sake of "security". Esp. when
> there's so many other ways to get my info, if a hacker really wants it.
> My $.02...
>
> Any help with the Server side scripting question is appreciated.
>
> Tim Chandler
>
> SurfCheck
> World Internet Surf Reports
> http://www.surfcheck.com
> http://www.surfcams.com
--
Fred Donck Tel: +31 70 311 2374
Unix System Engineer Mobile: +31 654 666 488
Internet/Intranet infrastructure Fax: +31 70 311 2166
E-mail: f.c.w.donck@siep.shell.com / fred@patriots.net
