>>>>> 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' Apac
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 p
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
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
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
>
>
&g
]>
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 h
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 sen
<[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
tober 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 you
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 m
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
> 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 shoul
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
> >>en
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
>
> 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 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 vulnerab
>
> 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 pro
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
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 (somethi
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
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
s
> 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 enou
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-escap
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 firs
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 applica
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
> ne
> 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, o
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
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 = "foobar";
$URL = "foobar.html";
print CGI::escapeHTML($Text), "";
Sorry for being off topic, but FYI
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
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 th
ko <[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 (especiall
32 matches
Mail list logo
