OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
NFR Wizards Archives: Re: Active-content filtering (was RE: Buf

Re: Active-content filtering (was RE: Buffer Overruns)

Subject: Re: Active-content filtering (was RE: Buffer Overruns)
From: David Lang (dlangdiginsite.com)
Date: Wed Dec 22 1999 - 20:10:27 CST

Crispin, One thing i have seen javascript used for is in e-commerce
situations to make sure that you can only click a submit button once (even
if the server takes a while to respond). how would you do this with your
plans? I suppose you could try and do something with unique cookies for
each user, changing them each request so that when the person on a fast
connection goes through two more scrrens and back to the same submit
button it can tell that this really is a different request (while the
person on a slow link may still be waiting for the server so timeouts
cannot work) but this seems like a much more difficult way of doing
this. If you see an easy way to implement this please let me know.

By the way this does not mean that I disagree with you about the other 99%
of java/javascript useage, it just meas that as far as I know there are a
few places where javascript really is legit

 David Lang

 
On Tue, 21 Dec 1999, Crispin Cowan wrote:

> Date: Tue, 21 Dec 1999 20:31:24 +0000
> From: Crispin Cowan <crispincse.ogi.edu>
> To: fernando_montenegrohp.com
> Cc: firewall-wizardslists.nfr.net
> Subject: Re: Active-content filtering (was RE: Buffer Overruns)
>
> fernando_montenegrohp.com wrote:
>
> > One or two messages in this thread mentioned some firewalls' ability to filter
> > out Java[script]|ActiveX from the HTTP stream.
> >
> > Considering the current scenario, where lots and lots of sites with valid,
> > business-need content, will use client-side scripting|code as fundamental for
> > functionality (news/stock tickers, client-side input validation, etc...),
>
> I VEHEMENTLY dispute that any of these scripting technologies are *legitimate*
> business-need content. On the contrary, they are symptoms of "lazy web developer
> who doesn't understand the technology." I have never, ever encountered a web site
> that used Javascript in a way that was actually necessary to perform the business
> function. On the other hand, I have encountered many web sites that failed to
> function properly without Javascript, but only used Javascript for "glitz", i.e.
> every single Javascript function could just as easily been replaced with a normal
> URL linking to a page of HTML.
>
> The current trend towards *requiring* Javascript to be able to access a web site
> horrifies me. I don't mind if the glitz is there, but the entire site SHOULD work
> properly without Javascript. Cute little pages that tell the user to upgrade
> their browser are wrong: it is the web site that is broken, not the browser.
> Using Javascript for cutsiness is fine, but *requiring* Javascript for
> functionality is not fine.
>
> So much for "busienss need". Now what about the risks? MOST of the browser
> vulnerabilites that have been discovered this year have concerned Javascript
> specifically. The number two culpret has been Java and JVMs. To me, these to
> factors together make an EXCELLENT case for filtering Javascript.
>
> They also make an excellent case for spanking majorly broken major web sites like
> United Airlines ( http://www.ual.com ) and Continental Airlines (
> http://www.continental.com/dash/build_dash.asp?vs_1999_11_22_00 ) because they are
> a hazard to Internet security. Not that they contain hazardous Javascript, but
> just because they require Javascript they essentially force firewall admins to
> admint Javascript in general to the site, exposing thousands of businesses to
> major risks just for the convenience of some lame web developers.
>
> Context: I run with Javascript disabled in my web browser most of the time. When
> I encounter a Javascript site, I mostly just leave immediately and never return.
> When I have a business need to use the site anyway, I grudgingly do so, but it
> produces a *very* negative impression of that business in my mind. Requiring
> Javascript tells me that the business cares more about their convenience than my
> security.
>
> Crispin
> -----
> Crispin Cowan, CTO, WireX Communications, Inc. http://wirex.com
> Free Hardened Linux Distribution: http://immunix.org
>

This archive was generated by hypermail 2b27 : Thu Dec 23 1999 - 15:26:41 CST