This is part of The Pile, a partial archive of some open source mailing lists and newsgroups.
To: modperl@apache.org
From: Paul Lindner <lindner@inuus.com>
Subject: Cross-site Scripting prevention with
Date: Tue, 22 Jan 2002 09:25:15 -0800
Hi,
I thought it might be interesting to start a thread on cross-site
scripting attacks, since it seems that many people are not aware of
the risks involved. Has anyone noticed attacks on their applications?
Do you religiously check all input you get from form-submissions?
What techniques do you use to insure that your application is not
vulnerable?
One technique that I've used is 'Tainting' input data (with
PerlTaintCheck) and using a subclass of the Apache module to insure
that tainted data is html-escaped.
As part of the CPANification of the code in the mod_perl Developer's
cookbook, I present Apache::TaintRequest, a module that helps prevent
cross-site scripting attacks by automatically html-escaping 'tainted'
text sent to a web browser.. Get it at
http://www.modperlcookbook.org/code.html
I'd be interested in hearing how others have dealt with the problem,
suggestions on how this module could be used further are most welcome.
===
To: <lindner@inuus.com>, <modperl@apache.org>
From: "Perrin Harkins" <perrin@elem.com>
Subject: Re: Cross-site Scripting prevention with
Date: Tue, 22 Jan 2002 12:48:40 -0500
> What techniques do you use to insure that your application is not
> vulnerable?
Usually I write application so that they do some processing, package up a
chunk of data, and hand it to a template. With this structure, all you need
to do is HTML-escape the data structure before handing it off, or use a
templating tool that defaults to HTML-escaping all printed variables. If
you're doing this, nothing the user sends in will pose a CSS threat.
===
To: modperl@apache.org
From: Robin Berjon <robin@knowscape.com>
Subject: Re: Cross-site Scripting prevention with
Date: Tue, 22 Jan 2002 18:57:13 +0100
On Tuesday 22 January 2002 18:48, Perrin Harkins wrote:
> > What techniques do you use to insure that your application is not
> > vulnerable?
>
> Usually I write application so that they do some processing, package up a
> chunk of data, and hand it to a template. With this structure, all you
> need to do is HTML-escape the data structure before handing it off, or use
> a templating tool that defaults to HTML-escaping all printed variables. If
> you're doing this, nothing the user sends in will pose a CSS threat.
Yes and no. XSS attacks are possible on old browsers, when the charset is not
set (something which is often the case with modperl apps) and when the
HTML-escaping bit does not match what certain browsers accept as markup. See
http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2000-03/msg00750.html
for a discussion of this. I think CGI.pm is safe now, and most modern
browsers appear to have fixed that behaviour, but quite a few still remain in
circulation and I'm not sure that all templating systems are handling the
escaping properly.
===
To: modperl@apache.org
From: Robin Berjon <robin@knowscape.com>
Subject: Re: Cross-site Scripting prevention with
Date: Tue, 22 Jan 2002 19:11:28 +0100
On Tuesday 22 January 2002 19:04, Perrin Harkins wrote:
> Of course I set the charset, but I didn't know that might not be enough.
> Does anyone know if Apache::Util::escape_html() and
> HTML::Entities::encode() are safe?
A quick look (I could be wrong) at HTML::Entities seems to imply that it
should be safe, as it uses numeric encoding for characters that it doesn't
recognize. I don't know about Apache::Util.
===
To: modperl@apache.org
From: Robin Berjon <robin@knowscape.com>
Subject: Cross-site scripting vulnerability in Apache::Util
Date: Wed, 23 Jan 2002 17:41:05 +0100
Hi,
picking up on the recent discussion about XSS vulnerabilities Geoff prompted
me to check that Apache::Util did indeed do the right thing. Taking the
example from
http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2000-03/msg00750.html
I made a simple handler that compares the output of Apache::Util::escape_html
and of HTML::Entities::encode_entities. I hope I didn't get it wrong, I'm by
no means a security expert ;-) However it is clear that the outputs differ in
that Apache::Util does not encode potentially dangerous characters.
Here is the module:
package XSSEntities;
use strict;
use vars qw($VERSION $XSS);
use Apache::Constants qw(OK);
use Apache::Util qw();
use HTML::Entities qw();
$VERSION = '0.01';
$XSS = "\x8b" . "h1>This should *not* be a big large header" . "\x8b" .
"/h1>";
sub handler {
my $r = shift;
$r->send_http_header('text/html;charset=iso-8859-1');
$r->print(<<' EOTOP');
<html>
<head>
<title>XSSEntities</title>
</head>
<body>
EOTOP
my $htEnt = HTML::Entities::encode_entities($XSS);
my $apUtl = Apache::Util::escape_html($XSS);
$r->print("HTML::Entities: $htEnt <br />\n");
$r->print("Apache::Util: $apUtl <br />\n");
$r->print(<<' EOBOT');
</body>
</html>
EOBOT
return OK;
}
1;
HTML::Entities correctly turns \x8b into ‹ while Apache::Util leaves it
untouched. That character is treated by certain buggy browsers as < and can
thus be used to fake tags. Note that just because your browser isn't
vulnerable (ie it doesn't buy the fakes h1) doesn't mean that the problem
isn't there :-) The source makes it explicit.
This is with 1.25 but I don't think it has changed since. The solution is to
do what HTML::Entities does, which is basically sprintf "&#x%X;", ord($char)
control and high bit chars. I'd submit a patch but I'm not too fluent with
C/XS.
Hope this helps,
===
To: Arnold van Kampen <test@blackhole.acon.nl>
From: =?ISO-8859-1?Q?Jo=E3o?= Pedro=?ISO-8859-1?Q?Gon=E7alves?=
Subject: Re: Cross-site Scripting prevention with
Date: 24 Jan 2002 11:55:09 +0000
On Thu, 2002-01-24 at 07:50, Arnold van Kampen wrote:
>
>
> Does anybody have an example(s) of how this kind of abuse is actually
> working?
>
> All the time I have just been lucky then I guess.
The most common way to abuse is through cookie hijacking,
If an attacker sends an email to a user's webmail account, that
is vulnerable to cross side scripting and the users
opens the message, the attacker would get the user's
session cookies and read the user's email.
There are several attacks already reported in bugtraq,
go check
http://www.securityfocus.com/
JP
===
To: robin@knowscape.com
From: Geoffrey Young <geoff@modperlcookbook.org>
Subject: Re: Cross-site scripting vulnerability in
Date: Thu, 24 Jan 2002 09:34:25 -0500
> HTML::Entities correctly turns \x8b into ‹ while
> Apache::Util leaves it untouched. That character is
> treated by certain buggy browsers as < and can thus be
> used to fake tags. Note that just because your browser
> isn't vulnerable (ie it doesn't buy the fakes h1) doesn't
> mean that the problem isn't there :-) The source makes it
> explicit.
> This is with 1.25 but I don't think it has changed
> since. The solution is to do what HTML::Entities does,
> which is basically sprintf "&#x%X;", ord($char) control
> and high bit chars. I'd submit a patch but I'm not too
> fluent with C/XS.
I'm probably worse with C than Robin, but here's a patch
that seems to fix the problem (as I understand it, that is).
the solution is different that HTML::Entities in that it
always uses the ¸ for characters between 126 and 255,
whereas HTML::Entities uses stuff like ¸
anyway, with the usual caveats of myself not being a C guy,
input on a better way to do this is not only welcomed, but
encouraged :)
===
From: Robin Berjon <robin@knowscape.com>
To: modperl@apache.org
Subject: Re: Cross-site scripting vulnerability in Apache::Util
Date: Thu, 24 Jan 2002 15:49:56 +0100
On Thursday 24 January 2002 15:34, Geoffrey Young wrote:
> > HTML::Entities correctly turns \x8b into ‹ while Apache::Util leaves
> > it untouched. That character is treated by certain buggy browsers as <
> > and can thus be used to fake tags. Note that just because your browser
> > isn't vulnerable (ie it doesn't buy the fakes h1) doesn't mean that the
> > problem isn't there :-) The source makes it explicit.
> > This is with 1.25 but I don't think it has changed
> > since. The solution is to do what HTML::Entities does,
> > which is basically sprintf "&#x%X;", ord($char) control
> > and high bit chars. I'd submit a patch but I'm not too
> > fluent with C/XS.
> I'm probably worse with C than Robin, but here's a patch
> that seems to fix the problem (as I understand it, that
> is).
> the solution is different that HTML::Entities in that it
> always uses the ¸ for characters between 126 and 255,
> whereas HTML::Entities uses stuff like ¸
The latter part doesn't matter as browsers now recognize
numeric entities a vast majority of the time (and when they
don't they also don't recognize the very extended entities
that HTML::Entities has).
However I'm not sure your patch does the right thing re
UTF-8, unless there's some magic involved that I'm not
seeing :-/ I'm no expert on how to deal with UTF-8 in C (or
even in Perl) but it looks like you're only addressing 8bit
encodings.
===
Date: Thu, 24 Jan 2002 12:59:28 -0500
From: Geoffrey Young <geoff@modperlcookbook.org>
To: robin@knowscape.com
Subject: Re: Cross-site scripting vulnerability in Apache::Util
> However I'm not sure your patch does the right thing re UTF-8, unless there's
> some magic involved that I'm not seeing :-/ I'm no expert on how to deal with
> UTF-8 in C (or even in Perl) but it looks like you're only addressing 8bit
> encodings.
ok, after some to and fro with robin over on #modperl it
looks like we discovered a few things...
first, Apache::Util is not UTF-8 compliant, since it
currently mangles C strings byte-by-byte, which introduces
the possibility that all or part of a 2-byte character could
be mangled.
second, the patch follows suit and expands the range of
1-byte characters it mangles, which makes it more non-UTF-8
friendly.
so, basically what we're thinking is that the new
Apache::Util is more secure for non-UTF-8 encodings, while
more broken for UTF-8. but UTF-8 is unusable with
Apache::Util in either case, so the patch is probably a good
thing.
other ideas/eyeballs are welcome here, since we've just been going over the spec and
making some conjectures - neither of us is an expert here by any means.
once other people chime in, we can whip up a doc patch for Apache::Util as well.
thanks
===
Date: Fri, 25 Jan 2002 02:54:28 +0800
From: Stas Bekman <stas@stason.org>
To: Geoffrey Young <geoff@modperlcookbook.org>
Cc: modperl@apache.org, dev@perl.apache.org
Subject: Re: Cross-site scripting vulnerability in Apache::Util
Geoffrey Young wrote:
>>However I'm not sure your patch does the right thing re UTF-8, unless there's
>>some magic involved that I'm not seeing :-/ I'm no expert on how to deal with
>>UTF-8 in C (or even in Perl) but it looks like you're only addressing 8bit
>>encodings.
>>
>
> ok, after some to and fro with robin over on #modperl it
> looks like we discovered a few things...
> first, Apache::Util is not UTF-8 compliant, since it
> currently mangles C strings byte-by-byte, which introduces
> the possibility that all or part of a 2-byte character
> could be mangled.
> second, the patch follows suit and expands the range of
> 1-byte characters it mangles, which makes it more
> non-UTF-8 friendly.
> so, basically what we're thinking is that the new
> Apache::Util is more secure for non-UTF-8 encodings, while
> more broken for UTF-8. but UTF-8 is unusable with
> Apache::Util in either case, so the patch is probably a
> good thing.
> other ideas/eyeballs are welcome here, since we've just
> been going over the spec and making some conjectures -
> neither of us is an expert here by any means.
> once other people chime in, we can whip up a doc patch for
> Apache::Util as well.
Since Apache::Util wasn't ported to mod_perl 2.0 and I was
thinking to do that at some point. So we can work on the
Apache::Util for 2.0 and then backport it to 1.x. Sounds
like a more promising scenario.
So what spec are you working with?
Can we just reap the functionality from some Perl core
module in bleadperl that does it right?
===
Date: Thu, 24 Jan 2002 14:01:44 -0500
From: Geoffrey Young <geoff@modperlcookbook.org>
To: Stas Bekman <stas@stason.org>
Subject: Re: Cross-site scripting vulnerability in Apache::Util
Stas Bekman wrote:
> Geoffrey Young wrote:
> >>However I'm not sure your patch does the right thing re
> >>UTF-8, unless there's some magic involved that I'm not
> >>seeing :-/ I'm no expert on how to deal with UTF-8 in C
> >>(or even in Perl) but it looks like you're only
> >>addressing 8bit encodings.
> > ok, after some to and fro with robin over on #modperl it
> > looks like we discovered a few things...
> > first, Apache::Util is not UTF-8 compliant, since it
> > currently mangles C strings byte-by-byte, which
> > introduces the possibility that all or part of a 2-byte
> > character could be mangled.
> > second, the patch follows suit and expands the range of
> > 1-byte characters it mangles, which makes it more
> > non-UTF-8 friendly.
> > so, basically what we're thinking is that the new
> > Apache::Util is more secure for non-UTF-8 encodings,
> > while more broken for UTF-8. but UTF-8 is unusable with
> > Apache::Util in either case, so the patch is probably a
> > good thing.
> > other ideas/eyeballs are welcome here, since we've just
> > been going over the spec and making some conjectures -
> > neither of us is an expert here by any means.
> > once other people chime in, we can whip up a doc patch
> > for Apache::Util as well.
> Since Apache::Util wasn't ported to mod_perl 2.0 and I was thinking to
> do that at some point. So we can work on the Apache::Util for 2.0 and
> then backport it to 1.x. Sounds like a more promising scenario.
however it comes about is fine, I guess. however, if
Apache::Util in 1.3 is left un-patched then we're kinda
giving a false impression that calling
Apache::Util::escape_html() is sufficient to thwart CSS
attacks when it really only keeps all but the most clever
away.
>
> So what spec are you working with?
robin and I were reading
http://www.cl.cam.ac.uk/~mgk25/unicode.html
but there may be others.
>
> Can we just reap the functionality from some Perl core module in
> bleadperl that does it right?
well, the problem that robin and I were contemplating is
that Apache::Util is supposed to be fast because it uses XS.
if we went to a pure perl implementation we would loose the
speed and duplicate something like HTML::Entities (although
it would be easier to solve the problem).
that said, perhaps there is C code in utf8.c (or wherever)
that we can steal to make life easier. we probably need to
get someone involved who understands the issues better than
I do :)
===
Date: Fri, 25 Jan 2002 03:25:58 +0800
From: Stas Bekman <stas@stason.org>
To: Geoffrey Young <geoff@modperlcookbook.org>
Cc: modperl@apache.org, dev@perl.apache.org
Subject: Re: Cross-site scripting vulnerability in Apache::Util
> however it comes about is fine, I guess. however, if
> Apache::Util in 1.3 is left un-patched then we're kinda
> giving a false impression that calling
> Apache::Util::escape_html() is sufficient to thwart CSS
> attacks when it really only keeps all but the most clever
> away.
I guess we should document this first of all, till it gets fixed. So
there will be no surprises.
>>So what spec are you working with?
>>
>
> robin and I were reading
>
> http://www.cl.cam.ac.uk/~mgk25/unicode.html
>
> but there may be others.
thanks!
>>Can we just reap the functionality from some Perl core module in
>>bleadperl that does it right?
> well, the problem that robin and I were contemplating is
> that Apache::Util is supposed to be fast because it uses
> XS. if we went to a pure perl implementation we would
> loose the speed and duplicate something like
> HTML::Entities (although it would be easier to solve the
> problem).
> that said, perhaps there is C code in utf8.c (or wherever)
> that we can steal to make life easier. we probably need
> to get someone involved who understands the issues better
> than I do :)
Well I suggested to reap from bleadperl, which is mostly written in C :)
But having a nicely implemented code in Perl is a good start. It's much
easier to rewrite in C than starting from scratch.
===
To: "mod_perl" <modperl@apache.org>
From: "Ron Savage" <ron@savage.net.au>
Subject: Re: Cross-site scripting vulnerability in
Date: Fri, 25 Jan 2002 10:10:23 +1100
Folks
Unicode refs:
Unicode|HTML|Weaving the Multilingual Web|http://www.w3.org/Talks/1999/0830-tutorial-unicode-mjd/Overview.html
Unicode|Unicode|http://www-4.ibm.com/software/developer/library/globalsoft.html
Unicode|UTF-8 and Unicode FAQ for Unix/Linux|http://www.cl.cam.ac.uk/~mgk25/unicode.html
Unicode|Zvon Character Reference|http://www.zvon.org/xxl/characterReference/Output/index.html
===