You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by Paul Lindner <li...@inuus.com> on 2002/01/22 18:25:15 UTC

Cross-site Scripting prevention with Apache::TaintRequest

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.  


-- 
Paul Lindner    lindner@inuus.com   ||||| | | | |  |  |  |   |   |

    mod_perl Developer's Cookbook   http://www.modperlcookbook.org
         Human Rights Declaration   http://www.unhchr.ch/udhr/index.htm

Re: Cross-site Scripting prevention with Apache::TaintRequest

Posted by Maarten Stolte <da...@crash.nu>.
> 
> BTW, if you don't html-escape and just search for tags you should make
> sure to HTML::Entities::decode() the text before processing it.
> 
> I've seen cases where people disguised scripting code with numeric
> entities.. jav&...;script etc...
> 
This is in fact very much what the hotmail and other widely published 
css bugs have been about. Stripping out simple tags seems to be about
what the average level web progammer does, and going a step further
takes you to the pro level it seems..

just my 2 eurocents,

Maarten Stolte


Re: Cross-site Scripting prevention with Apache::TaintRequest

Posted by Paul Lindner <li...@inuus.com>.
On Tue, Jan 22, 2002 at 07:11:28PM +0100, Robin Berjon wrote:
> 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.

BTW, if you don't html-escape and just search for tags you should make
sure to HTML::Entities::decode() the text before processing it.

I've seen cases where people disguised scripting code with numeric
entities.. jav&...;script etc...

-- 
Paul Lindner    lindner@inuus.com   ||||| | | | |  |  |  |   |   |

    mod_perl Developer's Cookbook   http://www.modperlcookbook.org
         Human Rights Declaration   http://www.unhchr.ch/udhr/index.htm

Re: Cross-site Scripting prevention with Apache::TaintRequest

Posted by Robin Berjon <ro...@knowscape.com>.
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.

-- 
_______________________________________________________________________
Robin Berjon <ro...@knowscape.com> -- CTO
k n o w s c a p e : // venture knowledge agency www.knowscape.com
-----------------------------------------------------------------------
I don't suffer from insanity. I enjoy every minute of it. 


Re: Cross-site Scripting prevention with Apache::TaintRequest

Posted by João Pedro Gonçalves <jo...@co.sapo.pt>.
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



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. 
> 
> Arnold van Kampen
> 
> 
> On Tue, 22 Jan 2002, Perrin Harkins wrote:
> 
> > > 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.
> > 
> > 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?
> > 
> > - Perrin
> > 
> 
-- 
João Pedro Gonçalves
'I have never let my schooling interfere with my education.'
- Mark Twain


Re: Cross-site Scripting prevention with Apache::TaintRequest

Posted by Arnold van Kampen <te...@blackhole.acon.nl>.

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. 

Arnold van Kampen


On Tue, 22 Jan 2002, Perrin Harkins wrote:

> > 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.
> 
> 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?
> 
> - Perrin
> 


Re: Cross-site Scripting prevention with Apache::TaintRequest

Posted by Perrin Harkins <pe...@elem.com>.
> 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.

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?

- Perrin


Re: Cross-site Scripting prevention with Apache::TaintRequest

Posted by Robin Berjon <ro...@knowscape.com>.
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.

-- 
_______________________________________________________________________
Robin Berjon <ro...@knowscape.com> -- CTO
k n o w s c a p e : // venture knowledge agency www.knowscape.com
-----------------------------------------------------------------------
Critic, n.: A person who boasts himself hard to please because nobody
tries to please him.


Re: Cross-site Scripting prevention with Apache::TaintRequest

Posted by Perrin Harkins <pe...@elem.com>.
> 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.

- Perrin


Re: Cross-site Scripting prevention with Apache::TaintRequest

Posted by Tatsuhiko Miyagawa <mi...@edge.co.jp>.
On Tue, 22 Jan 2002 09:25:15 -0800
Paul Lindner <li...@inuus.com> wrote:

> 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

Techniques I use depends on HTML::Template's 
<TMPL_VAR escape="HTML"> stuff. But your idea to detect output
from Untainted data for protection against CSS, is very neat. 

Nice.

--
Tatsuhiko Miyagawa <mi...@bulknews.net>


Re: Cross-site Scripting prevention with Apache::TaintRequest

Posted by Tatsuhiko Miyagawa <mi...@edge.co.jp>.
On Tue, 22 Jan 2002 19:01:48 +0100
Thomas Eibner <th...@stderr.net> wrote:

> my $fields = {
> 	      id => ['\d+', \&validation_sub ],
> 	      text => ['(?:\w\s)+']
> 	      };
> 
> And I feed this along with the request or cgi object to a function
> that checks each key for first the simple regexp to see if it's worth
> trying the real validation function.

see also CGI::Untaint by Tony Bowden, on CPAN.


--
Tatsuhiko Miyagawa <mi...@bulknews.net>


Re: Cross-site Scripting prevention with Apache::TaintRequest

Posted by Thomas Eibner <th...@stderr.net>.
On Tue, Jan 22, 2002 at 09:25:15AM -0800, Paul Lindner wrote:
> 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?

I've been pondering a lot about this lately, since I find creating
form validation routines very repetitive. So what I've come up with
so far is (not yet finished):

my $fields = {
	      id => ['\d+', \&validation_sub ],
	      text => ['(?:\w\s)+']
	      };

And I feed this along with the request or cgi object to a function
that checks each key for first the simple regexp to see if it's worth
trying the real validation function.
My little system for doing this isn't 

All the variables that are passed through form fields into other pages
goes through HTML::Entities' encode_entites function right before it's
inserted in a template.

-- 
  Thomas Eibner <http://thomas.eibner.dk/> DnsZone <http://dnszone.org/>
  mod_pointer <http://stderr.net/mod_pointer>