If I'm following exactly, the suggestion is that attributes populated by unfiltered input could be used for cross site scripting. Something like <div body="this_was_unfiltered_input"> wher the input would close the quotation and would continue with extra attributes like the onmousemove in your example. But in order for the evil_stuff to be used for CSS, that stuff must invoke a script, mustn't it? And because in an attribute we are not in a script context, the script must be inserted elsewhere between <script> </script>. Which moves the question to the latter injection: how does the script get there when <> are filtered?

Are the assumptions wrong? I hope to see a full example.

Thank you for your replies.

-----Original Message-----
From: Andrew.Omanpredictive.com [mailto:Andrew.Omanpredictive.com]
Sent: Thursday, February 07, 2002 10:26 PM
To: webappsecsecurityfocus.com
Cc: The Picard
Subject: RE: Webappsec FAQ?

Look at form inputs:

<input TYPE="password" NAME="password" VALUE="" maxlength=8>
This was from a google search for login.asp

Now just send login.asp?password= onmousemove=(insert_evil_stuff_here)

I don't think the server side providing the brackets is artificial.

Thanks,
Andrew

"The Picard" <thepicardrogers.com>
02/07/2002 09:33 PM

 
        To: <webappsecsecurityfocus.com>
        cc:
        Subject: RE: Webappsec FAQ?

Yes, SQL injection and b.o. are part of input validation, but my question
was specific to CSS. I'd like to see a _working_ example of a CSS attack
through HTML forms and which works without < and >. And without the rather
artificial case in which < was conveniently opened by the server code.

I'm not challenging CERT's advisory, doing more filtering than less is
better, but still, _can_ it be done? A technical curiosity, nothing more.

TP

-----Original Message-----
From: josh smith [mailto:pen_testerhotmail.com]
Sent: Thursday, February 07, 2002 10:35 AM
To: webappsecsecurityfocus.com
Subject: Re: Webappsec FAQ?

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 ]