I have a local hosting provider who has mod_perl installed
on the server, but will not enable it for security reasons. After doing
some digging on the mod_perl site and thinking about how many ways a
renegade mod_perl program could bring down a site (large modules using
a lot of memory means
mod_perl
installed
on the server, but will not enable it for security
reasons. After doing
some digging on the mod_perl site and thinking about how
many ways a
renegade mod_perl program could bring down a site (large
modules using
a lot of memory means larger httpd process, consumes
memory
)
-Sidharth.
-Original Message-
From: Mike Zelina [mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 11, 2003 12:59 PM
To: [EMAIL PROTECTED]
Subject: security with mod_perl
I have a local hosting provider who has mod_perl installed
on the server, but will not enable it for security reasons. After
On Wed, 2003-06-11 at 18:09, Sidharth Malhotra wrote:
Not quite a manual, but read some of these discussions on PerlMonks:
http://www.perlmonks.org/index.pl?node=mod+perl+isp+hostgo_button=Search
mod_perl shared hosting
ISPs supporting mod_perl
mod_perl: the bane of share webhosting
Hope
On Wed, 2003-06-11 at 12:58, Mike Zelina wrote:
I couldn't find any documentation on how a host *could* provide mod_perl
and do it in a way that would be safe for his server and usable for a
client.
I was just talking about this with my co-workers. Here's one way:
Set up a front-end apache
Perrin Harkins wrote:
On Wed, 2003-06-11 at 12:58, Mike Zelina wrote:
I couldn't find any documentation on how a host *could* provide mod_perl
and do it in a way that would be safe for his server and usable for a
client.
I was just talking about this with my co-workers. Here's one way:
Set up
Aaron Trevena wrote:
[...]
http://www.bytemark-hosting.co.uk do some good deals and discounts for
free software author and seem nice people.
Please submit ISPs that support mod_perl and/or virtual servers. so we can add
them to:
http://perl.apache.org/help/isps.html
I've added the one
I, rather blindly, put a reference to a hash of the HTTP headers and hash of
the CGI params in pnotes for most requests.
Technically, a poorly formed loop might DOS a child if the number of params
or headers is evilly large.
For instance, someone silly could write
my $params =
On Fri, 15 Nov 2002, [iso-8859-1] Faßhauer, Wolfgang, FCI3 wrote:
one database user because of resource limits. The problem I see is that the
password for connecting to the database is clear readable in the perl
script.
Does anybody know how to hide that password?
Have you thought of running
On Fri, 15 Nov 2002, Rafiq Ismail (ADMIN) wrote:
On Fri, 15 Nov 2002, [iso-8859-1] Faßhauer, Wolfgang, FCI3 wrote:
one database user because of resource limits. The problem I see is that the
password for connecting to the database is clear readable in the perl
script.
Does anybody know
Hi,
I want to build a database application based on mod_perl and Apache::DBI.
The goal of Apache::DBI is to get persistent database connections using
only
one database user because of resource limits. The problem I see is that
the
password for connecting to the database is clear readable in the
On Fri, 15 Nov 2002, [iso-8859-1] Faßhauer, Wolfgang, FCI3 wrote:
Have you thought of running your webserver as some 'www' user? You can
then make your scripts readonly by a 'dev' group which the www user and
the developes are members of.
CORRECT:
'readonly' should be 'only readable' by
Yes, that's our plan, too. But the risk still remains that someone
will get a look to the script. I think, there is a golden rule: Never put
clear text passwords in files. Those files are stored in archives by backup
for example. There maybe a lot of people (sysadmin, developer, ...)
On Fri, 15 Nov 2002, [iso-8859-1] Faßhauer, Wolfgang, FCI3 wrote:
Hmm. I think that the guy who wrote Blowfish_PP would cut my
danglies off
for that one.
This is an interesting idea.
Cutting my danglies off? hmm. Sounds painful.
Many thanks to you, Rafiq!
s'ok, although I wouldn't implement
danglies off
for that one.
Which is why you copied him in the first place? :-) In general, though, there
isn't a good way to get any security from any system that has to be able to
access sensitive data in an automatic way.
MBM
--
Matthew Byng-Maddick [EMAIL PROTECTED] http
=?iso-8859-1?Q?=22Fa=DFhauer=2C_Wolfgang=2C_FCI3=22?= [EMAIL PROTECTED]
ads.net wrote:
Hi,
I want to build a database application based on mod_perl and Apache::DBI.
The goal of Apache::DBI is to get persistent database connections using
only
one database user because of resource limits. The
I'm developing an online survey system under mod_perl (with a homemade
perlhandler, not under Apache::Registry). Since I've had as a goal to
avoid as many dependencies as possible, I store results in local plaintext
files. By nature, these files has (?) to be writable by the uid apache
runs as.
[...]
So, question is: How do I protect my data files from being accessed by
anything else than my own perlhandler? Can I set another uid for all that
has to do with my specific perlhandler? Hints are most welcome.
You can't. The only solution is run a dedicated server for each user.
So, question is: How do I protect my data files from being accessed by
anything else than my own perlhandler? Can I set another uid for all that
has to do with my specific perlhandler? Hints are most welcome.
// Joel
Maybe you are facing the same problem, that I asked earlier in this
!
-klm.
-Original Message-
From: Ask Bjoern Hansen [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, June 05, 2002 4:18 PM
To: Ken Miller
Cc: Modperl
Subject: Re: Doing security for backend applications
On Tue, 4 Jun 2002, Ken Miller wrote:
[...]
So, php application requests would
Let's say I have the following configuration:
1. Front end proxy server (no mod_perl)
2. Back end application server (mod_perl)
3. Back end application server (php)
Now, *all* application requests are passed to the mod_perl server (yes,
including the php requests). Performing security checks
server forward authentication requests
to the mod_perl server; but support the same cookie format would be
relatively simple.
This is all related to a single sign-on environment - once the user has
signed on an encrypted cookie will contain the application security
information used to authorize
Hi,
I am in front of a security issue. We are running several site using
modperl. Last days, a hacker used a script to call some script of our sites
for bad purpose. He needed to be authenticated, but we are only using
session cookies. Then, once he was loged in, he could retrieve this id
I've had people run password guessing scripts and stuff.
I've handled it on a case by case basis, ie, limit the number
of wrong guesses.
There are a bunch of modules that can set limits as well which
can come in handy against very brutish sorts of misuses of your site,.
I used mod_throttle.c,
Try this.
http://www.snert.com/Software/mod_throttle/
Tor.
fred wrote:
Hi,
I am in front of a security issue. We are running several site using
modperl. Last days, a hacker used a script to call some script of our sites
for bad purpose. He needed to be authenticated, but we are only
I am in front of a security issue. We are running several site using
modperl. Last days, a hacker used a script to call some script of our
sites
for bad purpose. He needed to be authenticated, but we are only using
session cookies. Then, once he was loged in, he could retrieve this id
Recently, I've been using Apache::ASP to program a new version of an
existing website that gets over 5 million page views per month. This
website will have to fit on a RaQ4i (450MHz) server, so I'm pretty
conscious about performance. Security is also important due to the
popularity of the site
Philip Mak:
This website runs off a MySQL database. Although all the webpages
are generated dynamically, they don't change often (unless the
webmaster explicitly updates them).
Do you generate reliable Last-Modified and Expires headers? This could
help bandwidth usage for you and your users.
Philip Mak wrote:
Recently, I've been using Apache::ASP to program a new version of an
existing website that gets over 5 million page views per month. This
website will have to fit on a RaQ4i (450MHz) server, so I'm pretty
conscious about performance. Security is also important due
darren chamberlain wrote:
Be sure to check that $line is defined:
Even better:
perl
use IO::File;
my $input = IO::File-new("/tmp/tmppswd") || die "Couldn't open /tmp/foo.pl";
my $line = $input-getline() || 'some safe default value, like
""';
die "\$line is
Hi all,
On Mon, 16 Apr 2001, darren chamberlain wrote:
Thomas K. Burkholder ([EMAIL PROTECTED]) said
[snip]
my $input = IO::File-new("/tmp/tmppswd") || die "Couldn't open /tmp/foo.pl";
Probably doesn't matter in this case, but I'd try to get used to using
the "or" operator instead of the
set MaxRequestsPerChild to 1 and just have one
parent process spawning children with different uid/gids, instead of having
to start up an entire server for each uid/gid pair... Of course, there's
the security problem of everything that happens in the child until it gets
to the setuid AND it's very
would seem slightly better then the
below alternative as you can set MaxRequestsPerChild to 1 and just have one
parent process spawning children with different uid/gids, instead of having
to start up an entire server for each uid/gid pair... Of course, there's
the security problem of eve
Be sure to check that $line is defined:
Thomas K. Burkholder ([EMAIL PROTECTED]) said something to this effect on
04/16/2001:
Note, /tmp/tmppswd is read-only by the installer of the product, but I should
be root in access.conf (right?) so I should be able to read it anyway.
perl
use
It's defined all right, it gets printed to STDERR.
The problem was that the file I was actually using was a perl file '/tmp/foo.pl', just
because it didn't matter what was in the file while I tried to make it work. But,
wait, it
does matter, because the first thing in the file was "use
Thanks again for the help - I have another one-
My application consists of perl modules with file permissions set only
to a particular user 'burkhold'. The database password is kept in
plaintext in one of those modules. I use the User: and Group:
directives in access.conf to cause the uid of
On Sun, 15 Apr 2001, Thomas K. Burkholder wrote:
Thanks again for the help - I have another one-
My application consists of perl modules with file permissions set only
to a particular user 'burkhold'. The database password is kept in
plaintext in one of those modules. I use the User: and
anyone know of a way around this? i have a site that depends heavily on
anchors for delivering reports. exploder chops off the uri at the
arguments,
which is not what mod_auth_digest (nor RFC 2617) expect.
anyone know of a way to force exploder to use the full uri for the
digest
On Thu, 1 Mar 2001, [EMAIL PROTECTED] wrote:
I used to believe that too, but now that I've developed
applications that make rather extensive use of the Apache API, I would
actually love to have an environment similar to CGI but
providing the full
Apache API, including logging,
/pnotes, etc. I realise a lot of this would be tricky and would
require RPC (thus opening up a security hole in its own right) but
I think it would be worthwhile.
This is off-topic, pretty much, but interesting nonetheless.
I just stumbled across Apache DSSI URL:http://apache_dssi.tripod.com/,
which
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
At 9:44 AM +0800 3/1/01, Stas Bekman wrote:
At this moment anybody who has an access to mod_perl server can read any
data which is accessible by the same server. suexec is not an option
because of process persistance.
I suspect this is why it is
mod_perl 2.0
At 10:33 PM 2/28/2001 -1000, Kee Hinckley wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
At 9:44 AM +0800 3/1/01, Stas Bekman wrote:
At this moment anybody who has an access to mod_perl server can read any
data which is accessible by the same server. suexec is not an option
On Thu, 1 Mar 2001, Gunther Birznieks wrote:
mod_perl 2.0
At 10:33 PM 2/28/2001 -1000, Kee Hinckley wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
At 9:44 AM +0800 3/1/01, Stas Bekman wrote:
At this moment anybody who has an access to mod_perl server can read any
data which is
security facilities, like: if the file owner id !=
the file the script is trying to open = fails.
My problem is with perl: how to solve such a problem in a perl
environment?
Does mod perl allows any kind of security, to prevent ones writing
script to read others files?
PS: All cgi runs
suexec
mechanism, is it currently done this way? Why not?
May some here confirm me that if i am a security concious admin, i
should not make modperl+embperl available to my user?
Take a look at http://www.freevsd.org. I haven't used it personally, but
it looks like something that you need..
This system is a based on making a chroot environment for each user with
his own apache and everything.
Gustavo Vieira Goncalves Coelho Rios wrote about "security!":
Vladimir Ivaschenko wrote:
Take a look at http://www.freevsd.org. I haven't used it personally, but
it looks like something that you need..
This system is a based on making a chroot environment for each user with
his own apache and everything.
i can vouch for this approach to development
Stas Bekman wrote:
On Wed, 28 Feb 2001, Gustavo Vieira Goncalves Coelho
Rios wrote:
the key user\password are kept inside this file, so
anyone can uses an
editor to retrieve the user mysql account. I resolve
this problem
running php on secure mode and chgrping the php file
the same
GRmechanism, is it currently done this way? Why not?
This could help sidestep the issue. It is not done this way by default,
because even using suexec doesn't automatically make your scripts secure,
and in fact it can make the situation worse.
GRMay some here confirm me that if i am a security
This is a general Unix webserver issue and not specific to
mod_perl, so I've marked your message [OT] for off-topic.
Well, workarounds are available for specific webserver environments, so I
don't believe it's an inappropriate question.
With CGI, you use the suexec mechanism to start
a security hole in
its own right) but I think it would be worthwhile.
I certainly don't like the way we're all assuming mod_perl 2.0 is going to
solve all our problems. It won't. It will just give us some fresh ones
(like making all modules thread safe).
--
Matt/
/||** Founder and CTO
This is a general Unix webserver issue and not specific to
mod_perl, so I've marked your message [OT] for off-topic.
Well, workarounds are available for specific webserver environments, so I
don't believe it's an inappropriate question.
With CGI, you use the suexec mechanism
And forking a new process under mod_perl
really defeats the purpose.
Does it?
Well I confess I just assumed.
I used to believe that too, but now that I've developed
applications that make rather extensive use of the Apache API, I would
actually love to have an environment similar
php have some security facilities, like: if the file owner id !=
the file the script is trying to open = fails.
My problem is with perl: how to solve such a problem in a perl
environment?
Does mod perl allows any kind of security, to prevent ones writing
script to read others files?
PS: All cgi
besides the owner of the file (or the http process) will be able to read
it.
since php have some security facilities, like: if the file owner id !=
the file the script is trying to open = fails.
My problem is with perl: how to solve such a problem in a perl
environment?
Does mod perl allows any
Hi folks!
I have just seted mod_perl with apache and i am using embperl too.
I am worried about security concerns for mod_perl.
How can i limit, for instance, the amount of memory used for embperl?
the ammount of time allowed for a perl code to spend. With php is easy,
there is directives like
On Fri, 17 Nov 2000, mgraham wrote:
Maybe another approach would be to explicitly list the handlers that
are allowed to be used in any given context. Kind of
like 'Options', but for perl handlers. Something like 'PerlOptions',
perhaps?
Location /users
PerlOptions
In the context of what you are talking about, I think giving ExecCGI
permissions should not allow them to change mod_perl handlers or do
anything to adjust mod_perl either. ExecCGI is a lot less problematic than
exposing access to mod_perl from a shared web server security standpoint
), so I'm not sure we get
better
security or control by having a separate ExecModPerl option.
NB: If we re-use ExecCGI for mod_perl, people will feel as though they're
on familiar turf. Sysadmins will understand the implications of turning it
on (i.e., they'll know that turning it on means
commandeer the most important
part of the request cycle (the response phase), so I'm not sure we get
better
security or control by having a separate ExecModPerl option.
I don't think that this is the case if you configure apache to use suexec
option. With suexec, the CGI script a user invokes cannot
important
part of the request cycle (the response phase), so I'm not sure we get
better
security or control by having a separate ExecModPerl option.
NB: If we re-use ExecCGI for mod_perl, people will feel as though they're
on familiar turf. Sysadmins will understand the implications
_perl from a shared web server security standpoint
especially if CGI's are suexec'ed.
So I would advocate an ExecModPerl option or something like that so that
user's could not arbitrarily install their own Perl Handlers.
[snip]
1) users can only use specific modules (or modules in specific
responsibility (if I allow access to a module) to make sure that
module will behave itself.
Those more versed in security issues will perhaps want to think this
through.
I've been receiving a steady trickle of off-list mail, by the way, from
ISPs and webmasters/sysadmins working in organizations where
I think Randal was making a similar point I was making last night (SG
time). That as long as you execute Perl code, you can manipualte the memory
space of Perl (and hance change the behavior of Apache::Registry).
But you explained it in your reply to me. Basically you want explicit
handlers
I think these are good points.
However, to some degree, if this is an attempt to allow an ISP protection,
it's not because most ISPs offer CGI access to their customers.
In addition, the moment you give mod_perl access to a developer they have
the rights to do a LOT of stuff that goes beyond
Gunther Birznieks wrote:
It seems to me that mod_perl wasn't really designed for safety against your
own developers
I accept this point. But it's really beside _my_ point, which was that
mod_perl modules can offer critical added functionality to run-of-the-mill
web publishers (whether it
, all they can do is call your interfaces
using the mini-Toolkit language embedded in their files.
And they get a slick templating system for free!
Best of both worlds.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
[EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/
with its internals to be able to
think and speak creatively about the security possibilities.
--
Richard Goerwitz[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
I'd have no problem if mod_perl was set up to turn off
PerlSetEnv, lit-
eral 'sub { ... }' handlers, Perl sections, and the use of
Perl modules
in non-system paths (except where ExecCGI is turned on).
Maybe another approach would be to explicitly list the handlers that
are allowed to be
mgraham wrote:
Maybe another approach would be to explicitly list the handlers that
are allowed to be used in any given context. Kind of
like 'Options', but for perl handlers. Something like 'PerlOptions',
perhaps?
Location /users
PerlOptions "My::AuthHandler My::ContentHandler
you don't, you might as well invent a meta-API,
like the one I suggested with Template Toolkit. You can't use the
generic tools... they're too powerful.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
[EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/
Perl/Unix
"Randal L. Schwartz" wrote:
I think y'all are missing it. As soon as I have any Perl code access
via Apache::Registry or anything like that, I can do this:
*Apache::Registry::handler = \my_trojan_horse;
Can you explain in what server-configuration context the above directive
would
Following up on the security suggestion (I'm actually responding to
private mail, so I'll just quote the person who wrote to me without
giving a name) -
Of course you can do this in an .htaccess file, too:
Perl
arbitrary perl code...
/Perl
I'd argue that people shouldn't be able to do
-Original Message-
From: Richard L. Goerwitz [mailto:[EMAIL PROTECTED]]
Sent: Thursday, November 16, 2000 10:11 AM
To: [EMAIL PROTECTED]
Cc: Geoffrey Young
Subject: Re: security suggestion
Following up on the security suggestion (I'm actually responding to
private mail, so
Perhaps you ought to gfind a way to use Safe; then?
-Original Message-
From: Richard L. Goerwitz [mailto:[EMAIL PROTECTED]]
Sent: Thursday, November 16, 2000 9:09 AM
To: mod_perl list
Subject: security suggestion
At Doug's suggestion I'm moving a brief conversation we've had
Maybe it's just me, but it seems that the responses richard has gotten
haven't really touched on the core of the problem. That mod_perl isn't
exactly friendly to sysadmin's who want to run apache on a (i'm guessing),
student accessed server, with user dir's and all that other stuff. I'm
pretty
The thing is, though, that as a web administrator I don't want those
same developers (or at least all of them) to be able to create and in-
stall _arbitrary_ handlers or arbitrary perl code. Sometimes the de-
velopers just don't know enough. And sometimes I just don't trust
them enough to
ent process...
as long as the server is running as an unpriveledged nobody-user or SetUID as the
~/user who is owns it, the security concerns should be minimal. if a mod_perl process
can attain root priveledges that would, uh, be a bad thing :-)
Of course, in such a restricted environment, many of m
noticed that perl security (along with shell security)
is one of the worst seucirty/privacy treat in almost all web hosting
companies... and I intend to solve this. :)
I don't see any security-wise differences between #1 and #2. These are
performance issues, where #1 wins in most cases, while #2
sites to monitor, wich will
happen quickly :)
Any other tips and tricks to improve the security of mod_perl is greatly
appreciated as well.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Félix C.Courtemanche . Head Designer
Co-Administrator . Can-Host Networks
http://www.can
noticed that perl security (along with shell security)
is one of the worst seucirty/privacy treat in almost all web hosting
companies... and I intend to solve this. :)
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Félix C.Courtemanche . Head Designer
Co-Administrator . Can-Host Networks
On Wed, 6 Sep 2000, Félix C.Courtemanche wrote:
Hello,
I couldn't find any occurance of this question in the archives, but if it
does exists, please forward me to it.
I have been working on a set of Administration Tools for commercial web
hosting companies for quite some times. Lately
scripts, since that is almost
impossible to do when you have more than 10 sites to monitor, wich will
happen quickly :)
Any other tips and tricks to improve the security of mod_perl is greatly
appreciated as well.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Félix
that is completed and working well.
Please keep in mind that security and optimization are the top 2 priorities
in this adventure :)
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Félix C.Courtemanche . Head Designer
Co-Administrator . Can-Host Networks
http://www.can-host.com
[EMAIL
Felix,
There's not much available that is efficient and does per-resource
throttling based upon CPU, RAM, and time of which I know. I looked around
for such things about 8 months ago.
I instead decided that, for my needs, limiting simultaneous client access
to resource hogs was good enough. I
it as effective as possible, it would be really
usefull for me and others.
Please don't tell me to monitor the user's scripts, since that is almost
impossible to do when you have more than 10 sites to monitor, wich will
happen quickly :)
Any other tips and tricks to improve the security of mod_perl
On Thu, 3 Aug 2000, Ken Williams wrote:
[EMAIL PROTECTED] (Rob Giseburt) wrote:
Are .htaccess files secure? I don't want users to be able to use
perl.../perl sections or any other mod_perl constructs (setting scripts
to run via the Registry, for example) in .htaccess files. However, I
Are .htaccess files secure? I don't want users to be able to use
perl.../perl sections or any other mod_perl constructs (setting scripts
to run via the Registry, for example) in .htaccess files. However, I need
.htaccess files turned on so users can password protect directories
site-wide (so I
On 8/3/2000 9:54 AM, Erich L. Markert at [EMAIL PROTECTED] wrote:
Damn good question...
I know the default apache config has a rule that prevents .htaccess
files from being accessed via a URL but not from within an embedded.
One way around this would be to use a database to handle
[EMAIL PROTECTED] (Rob Giseburt) wrote:
Are .htaccess files secure? I don't want users to be able to use
perl.../perl sections or any other mod_perl constructs (setting scripts
to run via the Registry, for example) in .htaccess files. However, I need
..htaccess files turned on so users can
ANNOUNCE Apache::ASP v1.95 - Security Hole Fixed
Apache::ASP http://www.nodeworks.com/asp/ had a security
hole in its ./site/eg/source.asp distribution examples file,
allowing a malicious hacker to potentially write to files in
the directory local to the source.asp example script.
The next
Hi all,
I thought this might be of interest to Apache users running Linux.
A vulnerability in some versions of Linux has recently been
identified.
SYSTEMS AFFECTED
Linux kernel versions 2.2.x before 2.2.16
(2.0.x are safe; 2.2.16 is safe)
IMPACT
Any local user can gain root
On Sat, 10 Jun 2000, Ged Haywood wrote:
Hi all,
I thought this might be of interest to Apache users running Linux.
[snip]
Note that this is not a vulnerability that Apache/Linux suffers from
particularly, except in the case of a mod_perl or CGI exploit that allows
the user to get a local
Matt Sergeant writes:
Unfortunately there's also a browser bug to contend with. They treat \x8b
(I think that's the right code) as and there's a similar code for
. Since most web developers are just doing s//lt;/g; they are open to
attacks based on character sets like this. Sad, but
Jeremy Howard wrote:
I'm interested in providing 'HTML email' support for my users
(like HotMail, Outlook Express, Eudora 4.0, etc provide), but
I'm very nervous about security. Essentially, providing HTML
email involves letting any arbitrary HTML get displayed by Apache...
I've been
Matt Sergeant writes:
Unfortunately there's also a browser bug to contend with. They treat \x8b
(I think that's the right code) as and there's a similar code for
. Since most web developers are just doing s//lt;/g; they are open to
attacks based on character sets like this. Sad, but
Gerald, what about Embperl, does it escape \x8b?
No, there is no html escape for \x8b (and I guess the other one Matt
mentioned is \0x8d for ) I know, so Embperl will not escape it, but this
could be simply change by an entry in epchar.c. Any suggestion to what this
should be escaped? Then I
On Fri, 28 Apr 2000, Gerald Richter wrote:
Gerald, what about Embperl, does it escape \x8b?
No, there is no html escape for \x8b (and I guess the other one Matt
mentioned is \0x8d for ) I know, so Embperl will not escape it, but this
could be simply change by an entry in epchar.c. Any
On Thu, 27 Apr 2000, Matt Sergeant wrote:
Unfortunately there's also a browser bug to contend with. They treat \x8b
(I think that's the right code) as and there's a similar code for
. Since most web developers are just doing s//lt;/g; they are open to
attacks based on character sets like
On Fri, 28 Apr 2000, Marc Slemko wrote:
On Thu, 27 Apr 2000, Matt Sergeant wrote:
Unfortunately there's also a browser bug to contend with. They treat \x8b
(I think that's the right code) as and there's a similar code for
. Since most web developers are just doing s//lt;/g; they are
1 - 100 of 139 matches
Mail list logo
