Follow the Cert Advisory and encode all special characters (% and ' and "
and < and > and |). Specifically, encoding just < and > in a dynamic web
application that ultilize forms will not stop JavaScript injection. You
will be limited but it is still possible and the extent of the exploit
really depends on the application. Don't just think of CSS think of other
things like SQL injection and other types of input validation attacks
(buffer overflows etc etc). This all falls under Input Validation. Never
trust client input in anyway.

Good Luck,
----- Original Message -----
From: "Elan Hasson" <elandaryl.org>
To: "The Picard" <thepicardrogers.com>; <webappsecsecurityfocus.com>
Sent: Wednesday, February 06, 2002 10:15 PM
Subject: RE: Webappsec FAQ?

> Well from what i know &lt; will show up as < TO THE USER and if you view
> source you'll see &lt; so, that *WOULD* protect you from it. %3E (url
> encoded form) should be evaluated to < a simple str_replace() would fix
it,
> just replace < and %3E with &lt; its secure.
>
> josh smith [mailto:pen_testerhotmail.com] wrote:
> >> Just encoding < and > will *NOT* protect from code injection. There
are
> >> other characters that are just as bad as < and >. Although its a start
> in
> >> protection it is not a 100% end all solution. This is why it is very
> >> important to follow Cert's recommendation.
>
> -----Original Message-----
> From: The Picard [mailto:thepicardrogers.com]
> Sent: Wednesday, February 06, 2002 10:25 PM
> To: webappsecsecurityfocus.com
> Subject: RE: Webappsec FAQ?
>
>
> Is there any practical method to do cross-site scripting in the context of
> an HTML mail _without_ < and > ?
>
>
> -----Original Message-----
> From: josh smith [mailto:pen_testerhotmail.com]
> Sent: Monday, February 04, 2002 2:50 PM
> To: webappsecsecurityfocus.com
> Subject: Re: Webappsec FAQ?
>
>
> Just encoding < and > will *NOT* protect from code injection. There are
> other characters that are just as bad as < and >. Although its a start in
> protection it is not a 100% end all solution. This is why it is very
> important to follow Cert's recommendation.
>
> ----- Original Message -----
> From: "Elan Hasson" <elandaryl.org>
> To: "Security Coordinator" <securityaptusventures.com>; "Lincoln Yeoh"
> <lyeohpop.jaring.my>; <webappsecsecurityfocus.com>
> Sent: Monday, February 04, 2002 9:12 AM
> Subject: RE: Webappsec FAQ?
>
>
> > Just replace < with &lt; and > with &gt; and <javascript> will show up
> > thwarting the user's attempt to run rouge scripts.
> >
> > -----Original Message-----
> > From: Security Coordinator [mailto:securityaptusventures.com]
> > Sent: Monday, February 04, 2002 9:20 AM
> > To: Lincoln Yeoh; webappsecsecurityfocus.com
> > Subject: Re: Webappsec FAQ?
> >
> >
> > On Sunday 03 February 2002 23:54, Lincoln Yeoh wrote:
> > > Hi,
> > >
> > > Where can I find the webappsec FAQ?
> > >
> > > I'm trying to figure out how best to filter out javascript (and other
> > > active content) on my webapps when displaying HTML from nontrusted
> sources
> > > (e.g. email, users etc). There seem to be thousands of ways to smuggle
> > > javascript in html. Is it even possible to create such a filter?
> >
> > Well, most people try to use regex type filtering, so your perl script
(or
> > whatever) filters out "bad" characters or (better approach) allows only
> > "good" characters. The problem is that with DHTML its not really
possible
> to
> > adequately analyze input that way. A better approach is to parse the
HTML
> > with a real HTML parser, and analyze the resulting DOM tree. At least
for
> > perl there are numerous packages that can do that. Unfortunately of
course
> > there could still be a problem with your parser or analysis logic, or
some
> > feature of a new browser could open it up to attack at a later time.
> >
> > The final possibility is that you substitute some simpler markup
language
> > for
> > the HTML, and let people input that instead, then convert it to HTML.
The
> > downside being its non-standard.
> >
> > Perhaps the best approach would be to "round trip" untrusted HTML.
Convert
> > it
> > to some simpler markup that expresses only what you want to allow, then
> > convert that back to HTML. At least then you know exactly what sets of
> tags
> > CAN appear in the final result unequivocally.
> > >
> > > No I don't want to resort to an exploit that will turn off javascript
> etc,
> > > on the user's browser.
> > >
> > > If only browser manufacturers would create a tag for "active content
> > > disabled from now on, renenabled by this passcode: ab412f83d921dc389".
> But
> > > I suppose they won't be able to do that properly either ;).
> > >
> > > Thanks,
> > > Link.
> >
> >
>
>

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]