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 ]