Cross Site Scripting
On Tue, 2003-03-11 at 06:03, Stas Bekman wrote: Changes since 0.7 * prevent cross-site scripting, now HTML-escaping the request field In Stas' Apache::VMonitor announcement, he mentions changes to prevent cross site scripting. This is a concern for me at the moment, because I'm building a site which will allow people to submit copy (to be displayed to other users) and I would like them to be able to use HTML and include links to other sites (much like slashdot). Do any of you have any ideas about good techniques to prevent CSS (and I don't mean those div elements) in this scenario? I've read the articles on cert.org (http://www.cert.org/tech_tips/malicious_code_mitigation.html) and apache.org (http://httpd.apache.org/info/css-security/encoding_examples.html) thanks Clinton Gormley
Re: Cross Site Scripting
On Tue, 11 Mar 2003, Clinton Gormley wrote: On Tue, 2003-03-11 at 06:03, Stas Bekman wrote: Changes since 0.7 * prevent cross-site scripting, now HTML-escaping the request field In Stas' Apache::VMonitor announcement, he mentions changes to prevent cross site scripting. This is a concern for me at the moment, because I'm building a site which will allow people to submit copy (to be displayed to other users) and I would like them to be able to use HTML and include links to other sites (much like slashdot). Do any of you have any ideas about good techniques to prevent CSS (and I don't mean those div elements) in this scenario? I hate to blatantly advertise, but using AxKit mostly mitigates XSS (don't use the term CSS to mean cross site scripting - its confusing) bugs, with the exception of javascript in URLs and blank lines inserted into headers from a user submission. So you vastly limit the things you have to check for. -- !-- Matt -- :-get a SMart net/:- Spam trap - do not mail: [EMAIL PROTECTED]
Re: Cross Site Scripting
On Tue, 2003-03-11 at 02:58, Clinton Gormley wrote: On Tue, 2003-03-11 at 06:03, Stas Bekman wrote: Changes since 0.7 * prevent cross-site scripting, now HTML-escaping the request field In Stas' Apache::VMonitor announcement, he mentions changes to prevent cross site scripting. This is a concern for me at the moment, because I'm building a site which will allow people to submit copy (to be displayed to other users) and I would like them to be able to use HTML and include links to other sites (much like slashdot). Do any of you have any ideas about good techniques to prevent CSS (and I don't mean those div elements) in this scenario? I've read the articles on cert.org (http://www.cert.org/tech_tips/malicious_code_mitigation.html) and apache.org (http://httpd.apache.org/info/css-security/encoding_examples.html) There is also a great article by Paul Lindner, titled Preventing Cross-site Scripting Attacks which I found very helpful, available at: http://www.perl.com/pub/a/2002/02/20/css.html Thanks, -- Nathan Byrd [EMAIL PROTECTED]
Re: Cross Site Scripting
On 11 Mar 2003 10:58:01 +0200, Clinton Gormley [EMAIL PROTECTED] said: CG On Tue, 2003-03-11 at 06:03, Stas Bekman wrote: CG Changes since 0.7 CG * prevent cross-site scripting, now HTML-escaping the request field CG In Stas' Apache::VMonitor announcement, he mentions changes to CG prevent cross site scripting. CG This is a concern for me at the moment, because I'm building a CG site which will allow people to submit copy (to be displayed to CG other users) and I would like them to be able to use HTML and CG include links to other sites (much like slashdot). CG Do any of you have any ideas about good techniques to prevent CSS CG (and I don't mean those div elements) in this scenario? Limit HTML to some safe subset and use HTML::TagFilter to enforce it. Make sure that you don't allow tag attributes which allow running javascript (like onclick, onchange, etc). The only problem with HTML::TagFilter I see is that it doesn't support restricting schemas in URIs. You definetely should not allow links like a href=javascript:something But maybe it is possible to extend HTML::TagFilter to do this too. -- Ilya Martynov, [EMAIL PROTECTED] CTO IPonWEB (UK) Ltd Quality Perl Programming and Unix Support UK managed @ offshore prices - http://www.iponweb.net Personal website - http://martynov.org
Re: Apache::Clean, Apache::Compress, mod_gzip/deflate, cross site scripting and more.
Hi Per, Web Content Compression FAQ is attached in POD format. Please, let me know if you find something formatted inappropriately. Thanks, Slava - Original Message - From: Per Einar Ellefsen [EMAIL PROTECTED] To: Slava Bizyayev [EMAIL PROTECTED] Cc: mod_perl Mailing List [EMAIL PROTECTED] Sent: Monday, October 28, 2002 1:56 AM Subject: Re: Apache::Clean, Apache::Compress, mod_gzip/deflate, cross site scripting and more. At 04:23 28.10.2002, Slava Bizyayev wrote: Hi Ged, I would be happy to reformat that FAQ to any required format if somebody is interested in it... Hello Slava, We talked about it some time ago: It would be very interesting to add that FAQ to the mod_perl website. Just convert it to POD and send it to me. -- Per Einar Ellefsen [EMAIL PROTECTED]
Fw: Apache::Clean, Apache::Compress, mod_gzip/deflate, cross site scripting and more.
Oops, Now it should be attached... :-) Slava - Original Message - From: Slava Bizyayev [EMAIL PROTECTED] To: Per Einar Ellefsen [EMAIL PROTECTED] Cc: mod_perl Mailing List [EMAIL PROTECTED] Sent: Tuesday, October 29, 2002 11:49 PM Subject: Re: Apache::Clean, Apache::Compress, mod_gzip/deflate, cross site scripting and more. Hi Per, Web Content Compression FAQ is attached in POD format. Please, let me know if you find something formatted inappropriately. Thanks, Slava - Original Message - From: Per Einar Ellefsen [EMAIL PROTECTED] To: Slava Bizyayev [EMAIL PROTECTED] Cc: mod_perl Mailing List [EMAIL PROTECTED] Sent: Monday, October 28, 2002 1:56 AM Subject: Re: Apache::Clean, Apache::Compress, mod_gzip/deflate, cross site scripting and more. At 04:23 28.10.2002, Slava Bizyayev wrote: Hi Ged, I would be happy to reformat that FAQ to any required format if somebody is interested in it... Hello Slava, We talked about it some time ago: It would be very interesting to add that FAQ to the mod_perl website. Just convert it to POD and send it to me. -- Per Einar Ellefsen [EMAIL PROTECTED] FAQ.pod Description: Binary data
Apache::Clean, Apache::Compress, mod_gzip/deflate, cross site scripting and more.
List, Before I embark on a day exploring the pros and cons of today's cleaning/compression tools, I wondered if any of you could give me some feedback about your own experiences within the context of medium/large scale web sites/applications (E-Toys etc). Is it too presumtious to expect that many users now have high speed connections and tools that clean and/or compress html are of a small benefit anymore? That is not to mention the proliferation of pretty websites with 90% graphics. Given that gzip style compressions work very well with plain text due to whitespace characters etc, is the combination of modules like Apach::Clean, Apache::Compress (and Apache::Filter) an overkill. Is there really much benefit in using Apache::Clean AND Apache::Compress (Or similar compatible modules/technologies) with consideration of performance trade offs arising from using these modules. Is there any advantage to using modules like HTML::Tree or HTML::Parser to remove information (i.e. removing autoexecuting javascript tags and any other CSS issues) from user submitted information. Will a well designed set of regular expressions perform this sanitisation more efficiently? Not forgetting that not all user input arrives via a form. e.g. web mail (Though we can thank Anomy/Spamassassin/ClamAV/MIMEDefang and others for helping out here). I realise this post doesn't relate directly to mod_perl per se, however mod_perl does a great deal to encourage a high ratio of coupling to cohesion in the way we build our applications/sites. At the same time however we can't deny the fact that the faster we can serve our webpages the happier our users will be. I have been following the discussion on the list for a few months and though threads have cropped up addressing some of these issues I haven't really seen anyone advocate a specific stance on the situation. Perhaps someone who has faced these decisions many times can offer some insight? I'm curious as to whether a lot of technologies are used outside of developement. Has much changed in the past year to make any of the above discussions especially different? Just please point me to online references if this has been discussed to death. Richard.
Re: Apache::Clean, Apache::Compress, mod_gzip/deflate, cross site scripting and more.
Hi Richard, Let me introduce to you (and to the list ;) my Content Compression FAQ (attached in M$ WORD format). It answers some of your questions... Slava - Original Message - From: Richard Clarke [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, October 27, 2002 7:21 AM Subject: Apache::Clean, Apache::Compress, mod_gzip/deflate, cross site scripting and more. List, Before I embark on a day exploring the pros and cons of today's cleaning/compression tools, I wondered if any of you could give me some feedback about your own experiences within the context of medium/large scale web sites/applications (E-Toys etc). Is it too presumtious to expect that many users now have high speed connections and tools that clean and/or compress html are of a small benefit anymore? That is not to mention the proliferation of pretty websites with 90% graphics. Given that gzip style compressions work very well with plain text due to whitespace characters etc, is the combination of modules like Apach::Clean, Apache::Compress (and Apache::Filter) an overkill. Is there really much benefit in using Apache::Clean AND Apache::Compress (Or similar compatible modules/technologies) with consideration of performance trade offs arising from using these modules. Is there any advantage to using modules like HTML::Tree or HTML::Parser to remove information (i.e. removing autoexecuting javascript tags and any other CSS issues) from user submitted information. Will a well designed set of regular expressions perform this sanitisation more efficiently? Not forgetting that not all user input arrives via a form. e.g. web mail (Though we can thank Anomy/Spamassassin/ClamAV/MIMEDefang and others for helping out here). I realise this post doesn't relate directly to mod_perl per se, however mod_perl does a great deal to encourage a high ratio of coupling to cohesion in the way we build our applications/sites. At the same time however we can't deny the fact that the faster we can serve our webpages the happier our users will be. I have been following the discussion on the list for a few months and though threads have cropped up addressing some of these issues I haven't really seen anyone advocate a specific stance on the situation. Perhaps someone who has faced these decisions many times can offer some insight? I'm curious as to whether a lot of technologies are used outside of developement. Has much changed in the past year to make any of the above discussions especially different? Just please point me to online references if this has been discussed to death. Richard. Web Content Compression FAQ-rev7.doc Description: MS-Word document
Re: Apache::Clean, Apache::Compress, mod_gzip/deflate, cross site scripting and more.
Hi Ged, I would be happy to reformat that FAQ to any required format if somebody is interested in it... Thanks, Slava - Original Message - From: Ged Haywood [EMAIL PROTECTED] To: Slava Bizyayev [EMAIL PROTECTED] Cc: mod_perl Mailing List [EMAIL PROTECTED] Sent: Sunday, October 27, 2002 1:11 PM Subject: Re: Apache::Clean, Apache::Compress, mod_gzip/deflate, cross site scripting and more. Hi there, On Sun, 27 Oct 2002, Slava Bizyayev wrote: Let me introduce to you (and to the list ;) my Content Compression FAQ (attached in M$ WORD format). Thanks, but if you're going to publish things for this List I think most people will want POD or plain text. Definitely not M$ Word format. 73, Ged.
Re: Apache::Clean, Apache::Compress, mod_gzip/deflate, cross site scripting and more.
At 04:23 28.10.2002, Slava Bizyayev wrote: Hi Ged, I would be happy to reformat that FAQ to any required format if somebody is interested in it... Hello Slava, We talked about it some time ago: It would be very interesting to add that FAQ to the mod_perl website. Just convert it to POD and send it to me. -- Per Einar Ellefsen [EMAIL PROTECTED]
Re: Cross-site Scripting prevention with Apache::TaintRequest
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 vulnerability in Apache::Util
HTML::Entities correctly turns \x8b into #139; 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 #184; for
characters between 126 and 255, whereas HTML::Entities uses stuff like cedil;
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 :)
--Geoff
Index: Util.xs
===
RCS file: /home/cvspublic/modperl/src/modules/perl/Util.xs,v
retrieving revision 1.9
diff -u -r1.9 Util.xs
--- Util.xs 4 Mar 2000 20:55:47 - 1.9
+++ Util.xs 24 Jan 2002 14:31:46 -
@@ -36,6 +36,7 @@
{
int i, j;
SV *x;
+static char highbits[6];
/* first, count the number of extra characters */
for (i = 0, j = 0; s[i] != '\0'; i++)
@@ -43,7 +44,8 @@
j += 3;
else if (s[i] == '')
j += 4;
-else if (s[i] == '')
+else if (s[i] == '' ||
+((unsigned char)s[i] 126) (unsigned char)s[i] = 255)
j += 5;
if (j == 0)
@@ -67,6 +69,11 @@
memcpy(SvPVX(x)[j], quot;, 6);
j += 5;
}
+else if ((unsigned char)s[i] 126 (unsigned char)s[i] = 255) {
+sprintf(highbits, #%i;, (unsigned char)s[i]);
+ memcpy(SvPVX(x)[j], highbits, 6);
+ j += 5;
+}
else
SvPVX(x)[j] = s[i];
Re: Cross-site scripting vulnerability in Apache::Util
On Thursday 24 January 2002 15:34, Geoffrey Young wrote: HTML::Entities correctly turns \x8b into #139; 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 #184; for characters between 126 and 255, whereas HTML::Entities uses stuff like cedil; 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. -- ___ Robin Berjon [EMAIL PROTECTED] -- CTO k n o w s c a p e : // venture knowledge agency www.knowscape.com --- Earth is a beta site.
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 --Geoff
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? _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
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 :) --Geoff
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. _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: Cross-site scripting vulnerability in Apache::Util
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 Cheers Ron Savage [EMAIL PROTECTED] http://savage.net.au/index.html
Re: Cross-site Scripting prevention with Apache::TaintRequest
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
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[EMAIL PROTECTED] | | | | | | | | | | 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
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
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 [EMAIL PROTECTED] -- 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
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
Re: Cross-site Scripting prevention with Apache::TaintRequest
On Tue, 22 Jan 2002 19:01:48 +0100
Thomas Eibner [EMAIL PROTECTED] 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 [EMAIL PROTECTED]
Re: Cross-site Scripting prevention with Apache::TaintRequest
On Tue, 22 Jan 2002 09:25:15 -0800 Paul Lindner [EMAIL PROTECTED] 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 [EMAIL PROTECTED]
Re: Cross-site Scripting prevention with Apache::TaintRequest
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
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 [EMAIL PROTECTED] -- 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
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[EMAIL PROTECTED] | | | | | | | | | | mod_perl Developer's Cookbook http://www.modperlcookbook.org Human Rights Declaration http://www.unhchr.ch/udhr/index.htm
Re: cross site scripting security issue headsup
At 05:32 PM 02/02/00 -0700, Marc Slemko wrote: I thought about not putting the mod_perl specific one in there at all (ie. just the CGI.pm one, BTW about the CGI.pm example: use CGI (); $Text = "foobbar"; $URL = "foobbar.html"; print CGI::escapeHTML($Text), "BR"; Sorry for being off topic, but FYI from Bugtraq about Oct 5, 1999 titled "Time to update those CGIs again": "Seems that at least some Unix versions of Netscape treat characters 0x8b and 0x9b (NOT the strings "0x8b" and "0x9b" but the characters with these ascii values) just like and respectively..." I never tested it, but others on Bugtraq did confirm the problem on unix versions of Netscape. Bill Moseley mailto:[EMAIL PROTECTED]
Cross Site Scripting security issue (fwd)
I'm sure that some of you didn't get this. And some of you are unaware of the security issues covered below. Enjoy the reading and run fix your scripts :) or may be :( is a better choice. -- Forwarded message -- Date: Wed, 2 Feb 2000 12:22:12 -0700 (MST) From: Marc Slemko [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Cross Site Scripting security issue -BEGIN PGP SIGNED MESSAGE- As you may already be aware, today CERT released an advisory about a security vulnerability that has been discovered associated with malicious HTML tags (especially scripting tags) being embedded in client web requests. The common name currently associated with this problem is "Cross Site Scripting", even though this name is not entirely accurate in its description of the problem. Please review the CERT advisory available at: http://www.cert.org/advisories/CA-2000-02.html for more details. Pay particular attention to their Tech Tip for Web Developers, available at: http://www.cert.org/tech_tips/malicious_code_mitigation.html There are a number of ways in which this issue impacts Apache itself, and many more ways in which it impacts sites developed using related technologies such as Apache modules, CGI scripts, mod_perl, PHP, etc. that runs on top of Apache. We have put together some information about this and it is available at: http://www.apache.org/info/css-security/ Please visit this page for more information if you think this problem impacts your site or if you don't understand if the problem impacts your site. Included on this page are patches to Apache to fix a number of related bugs and to add a number of features that may be helpful in defending against this type of attack. We expect to release a new version of Apache in the immediate future that includes these patches, but do not yet have an exact timeline planned for this release. Please note that this issue does not in any way compromise the security of your server directly. All the issues related to this involve tricking a client into doing something that is not what the user intends. We expect to update our pages with more information in the future, as more of the details of and consequences of this issue are discovered. - -- Marc Slemko | Apache Software Foundation member [EMAIL PROTECTED] | [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: PGPfreeware 5.0i for non-commercial use Charset: noconv iQCVAwUBOJiD51Qv/g4Arev1AQFp+AP+PYknXFPhcFExJvrZ2OdXhR43w2Fwuhgp UzhJFj8WLnpuaXNipQnE5/lVxNu2s7X6hshPP9GpDUkhU8u0WMXcJqydI4+/1OEV O2yRhVeIMwhE8k38SDxIiJJ+DsPQJ5p/Rfi8tZRh4GneSU5JBhY3d5hkumfsPocs NZYgV5YnhRs= =fSkT -END PGP SIGNATURE-
Re: cross site scripting security issue headsup
On Wed, 2 Feb 2000, Marc Slemko wrote:
http://www.apache.org/info/css-security/
http://www.cert.org/advisories/CA-2000-02.html
I think I have found a little typo/oversight in the mod_perl example on
http://www.apache.org/info/css-security/encoding_examples.html
It uses escape_html rather then escape_uri on the href line, here is
a tiny patch.
Cheers,
-
Sander van Zoest [EMAIL PROTECTED]
High Geek(858) 623-7442
MP3.com, Inc. http://www.mp3.com/
See you at ApacheCon 2000 - Your premiere Music Service Provider (MSP)
diff -C3 -r1.4 encoding_examples.html
*** encoding_examples.html 2000/02/02 19:26:03 1.4
--- encoding_examples.html 2000/02/03 00:23:54
***
*** 139,145
$Text = "foolt;bgt;bar";
$URL = "foolt;bgt;bar.html";
$r-gt;print(Apache::Util::escape_html($Text), "lt;BRgt;");
! $r-gt;print("lt;A HREF=\"", Apache::Util::escape_html($URL),
"\"gt;linklt;/Agt;");
/PRE
PThis uses the same functions as in the Apache Module Example, called
--- 139,145
$Text = "foolt;bgt;bar";
$URL = "foolt;bgt;bar.html";
$r-gt;print(Apache::Util::escape_html($Text), "lt;BRgt;");
! $r-gt;print("lt;A HREF=\"", Apache::Util::escape_uri($URL),
"\"gt;linklt;/Agt;");
/PRE
PThis uses the same functions as in the Apache Module Example, called
Re: cross site scripting security issue headsup
Doh, thanks, fixed. I thought about not putting the mod_perl specific one in there at all (ie. just the CGI.pm one, and I had removed it, so the error probably came about when I put it back in), but figured I should include it for some reason. Don't know what that reason is. Oh well. On Wed, 2 Feb 2000, Sander van Zoest wrote: On Wed, 2 Feb 2000, Marc Slemko wrote: http://www.apache.org/info/css-security/ http://www.cert.org/advisories/CA-2000-02.html I think I have found a little typo/oversight in the mod_perl example on http://www.apache.org/info/css-security/encoding_examples.html It uses escape_html rather then escape_uri on the href line, here is a tiny patch. Cheers, - Sander van Zoest [EMAIL PROTECTED] High Geek(858) 623-7442 MP3.com, Inc. http://www.mp3.com/ See you at ApacheCon 2000 - Your premiere Music Service Provider (MSP)
