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
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
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
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
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
/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
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
: 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
: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
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
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
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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,
32 matches
Mail list logo
