things I should be doing, besides not running on Windows and IIS,
to make my application more secure? I am careful to timestamp every row in
every table in case some malicious nonsense is done and I have to clean up
the mess.
Thanks
Mary Anderson
To answer your security question;
Firstly, yo
n up the mess.
Hi Mary,
Glad you're thinking about security early. Too many folks don't.
I have a brief introduction to CGI security at
http://users.easystreet.com/ovid/cgi_course/lessons/lesson_three.html.
It's not complete, but it covers the basics (there are a lot of things
Hi,
I am writing my first Perl CGI program. I get logins through one CGI
script. When the user has loggin I use
a(href->myurl$login=mylogin&passwor=mypassword
to get to my input screen. Logins are checked by doing a trial connection
to the database. I plan to run in taint mode. I wil
latively safe way to do this is to ask people to put in their email
once, then email them a confirmation email that they must reply to or
validate using a URL that includes a security token (an MD5 hash of the
email and the timestamp and some keyword) that you can check when the user
clicks back to y
We do IDX-enabled Real Estate software for Real Estate brokerages. As
part of this, I want to be able to save searches and e-mail the results
to an e-mail address once a week.
What I'm concerned about is someone picking up the form field names and
storing whatever URL they want with hundreds o
t I gather there are security issues with this
method.
Can someone tell me what these are, or point me to explanations
of the problems?
Thanks a bunch,
-J
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
<http://learn.perl.org/> <http://learn.perl.org/first-response>
On Fri, 3 Sep 2004, Octavian Rasnita wrote:
This might be helpful for more users, because a system admin can
create automaticly a special dir where the users can put their config
files, and "insert" that file in httpd.conf.
After that, every user can create its own config file, with any
variabl
IL PROTECTED]>; "michael watson (IAH-C)"
<[EMAIL PROTECTED]>
Sent: Friday, September 03, 2004 3:56 PM
Subject: Re: CGI scripts, security and MySQL
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
<http://learn.perl.org/> <http://learn.perl.org/first-response>
On Fri, 3 Sep 2004, Octavian Rasnita wrote:
No, the environment variables are set a single time at the start (or
restart) of the web server.
Ok, that's what I thought.
So in what way does this help manage a pool of several users?
This seems to be a solution in search of some other problem...
--
Ch
- Original Message -
From: "Chris Devers" <[EMAIL PROTECTED]>
To: "Octavian Rasnita" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; "michael watson (IAH-C)"
<[EMAIL PROTECTED]>
Sent: Friday, September 03, 2004 3:31 PM
Subject: Re: CGI script
On Fri, 3 Sep 2004, Octavian Rasnita wrote:
You can put something like this, in httpd.conf file:
include ...path_to_file
And make the directory where sits that file readable only by the root user.
Then, in that file, put something like:
SetEnv usr user_name
SetEnv pass parolissima
Those 2 environme
uot; <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Friday, September 03, 2004 3:08 PM
Subject: Re: CGI scripts, security and MySQL
> On Fri, 3 Sep 2004, michael watson (IAH-C) wrote:
>
> > I need to make this secure such that only users I want can use the
> > s
On Fri, 3 Sep 2004, michael watson (IAH-C) wrote:
I need to make this secure such that only users I want can use the
system. I want to set up a username and password so that users can
log in once at the beginning of a session, carry out their work
filling in various forms and writing to the dat
Hi
I need to know what is the accepted way of handling the following. I
have a MySQL database, and a host of CGI scripts which present forms to
the users as web pages, they fill them in and then the data is written
to the database. I need to make this secure such that only users I want
can use t
On Tue, 31 Aug 2004, Dennis McFall wrote:
But Firebird, the database system, is a magnificent, fully
SQL-standard compliant, rock-solid system capable of handling millions
of records and hundreds of simultaneous users. APress has just
published a 1000-page book on it: "The Firebird Book" by Hel
At 12:43 PM 8/31/2004, you wrote:
Access is a single-user, desktop database, like FileMaker Pro or Phoenix
(the open source database that almost no one has heard of or uses, not the
open source web browser (which is now known as Firefox), which lots of
people know of and use).
This statement has
On Tue, 31 Aug 2004, Siegfried Heintze wrote:
I have explained the performance problems with Microsoft Access many
times to my customer and he does not listen. (This is because it is
not a problem with only he and I prototyping the site). What you
describe is a performance issue, not a security
ribe is a performance
> issue, not a security issue. It sounds like MSAccess is just as secure as
> those other databases, correct?
Or just as insecure depending on how you are passing data to it. At any
rate, I agree with you that it's a performance issue, not a security
issue.
> >More th
5ing a hash you seemingly have reduced
its power since it is a hash of a relatively short string which could
definitely be brute forced very quickly? I would skip MD5 completely
and go with SHA-1 (although there are recent concerns about it), and
would definitely double check hashing a hash w
nly he and I prototyping the site). What you describe is a performance
issue, not a security issue. It sounds like MSAccess is just as secure as
those other databases, correct?
>> Finally, what about using cookies for authentication and authorization?
>> Assuming his clients are ame
nation of thereof might work.
>
>
> Is this approach secure? I am suspicious because in the Microsoft .NET
> literature they suggest that cookie (or forms) security is only medium
> security appropriate for storing things like frequent flyer miles or email
> and is not appropri
database everytime the user requests an evaluation.
Is this approach secure? I am suspicious because in the Microsoft .NET
literature they suggest that cookie (or forms) security is only medium
security appropriate for storing things like frequent flyer miles or email
and is not appropriate for
call this custom module's
function which returns the password, which the scripts then use to connect
to the database.
An additional security (and maintenance) benefit to this implementation is
that the password is stored in a single location, rather than peppered
throughout my scripts. This makes r
Zedgar,
You are chasing the yourself into circles. Security is dictated by
circumstances and resources available. In our case, we had plenty of
both and developed for our needs the "best" solution. Insofar as the
storing of the password for the login that is used to get the pas
ottom of my post.
It is actually an extremely common situation: There is a CGI script written in Perl.
It is a frontend to an SQL database.
The script has to connect to the database so it has to send a password. I need that
password to be secure. I am not interested in security through obsc
[EMAIL PROTECTED] wrote:
> Thank you Joseph and Motherofperls for your tips, however I need something more than
> security through obscurity, as this database is going to store our customers
> personal information (real name and contact information) which is absolutely
> unacce
Dear Zedgar,
I'm not completely sure I understand your goals, question and setup, but, if
you are concerned about security, using a relational database is almost if
not certainly your best bet. I am working on just such a system right now
for myself, so I can appreciate your question.
R. Joseph Newton wrote:
> [EMAIL PROTECTED] wrote:
>
>>I'm basically concerned about the security of writing a simple web frontend to SQL
>>database, the most important question being: how should I store the database
>>password?
>>[...]
>>There are
On Monday, Sep 8, 2003, at 22:57 US/Pacific, Greenhalgh David wrote:
[..]
I refer you to the answer I received from Drieux to (almost) exactly
the same question.
---Drieux's code---
#!/usr/bin/perl -w
use strict;
use Fcntl qw/O_CREAT O_RDWR O_EXCL O_RDONLY/;;
my $
an do is remove write
> access unless the script is actually running. Not foolproof. If you
> use the above code to chmod to a writeable file, then the script dies
> before you get the chance to chmod it back again you are left with the
>
> original security issue until you ei
On Mon, 8 Sep 2003 18:04:44 -0800
[EMAIL PROTECTED] (Alejandro Chavarria - Cypage) wrote:
> Does anyone know
> of a way, where I can not allow ANYONE to view that text file, but
> still let the program write to it?
It appears there is a misunderstanding of what permissions mean. I
suggest that y
an do is remove write
> access unless the script is actually running. Not foolproof. If you
> use the above code to chmod to a writeable file, then the script dies
> before you get the chance to chmod it back again you are left with the
>
> original security issue until you ei
I've never done it personally, but off-hand (assuming that chmod 444
won't work) I'd suggest you may want to look into using sudo (for
*nix). With sudo you could give the www user permission to become root
only when executing that one command that writes to the file. You'd
have to use a system call
an do is remove write
> access unless the script is actually running. Not foolproof. If you
> use the above code to chmod to a writeable file, then the script dies
> before you get the chance to chmod it back again you are left with the
>
> original security issue until you ei
On Mon, 8 Sep 2003 18:04:44 -0800
[EMAIL PROTECTED] (Alejandro Chavarria - Cypage) wrote:
(my apologies if this appears twice!)
> Does anyone know
> of a way, where I can not allow ANYONE to view that text file, but
> still let the program write to it?
It appears there is a misunderstanding of
so
if you want your CDGI to be able to read from a file, then so can
everyone else. In that case, the best you can do is remove write access
unless the script is actually running. Not foolproof. If you use the
above code to chmod to a writeable file, then the script dies before
you get the chance
Hey,
I am writing a perl CGI script on a remote server that is supposed to do the
following:
1. Have the user sign in with a username and password.
2. Allow the user to add News Stories in which that input is taken and then
written to a text file (Which is as of this moment, set to chmod 777).
Skorpion wrote:
> can you give me a pice of advice of security aspects creating cgi
> scripts working with apache server on linux running 2.2.19 kernel -
> any backdoors i should be aware of ?
See the security resources on the CGI Meta-FAQ:
http://www.perl.org/CGI_MetaFAQ.html
>
can you give me a pice of advice of security aspects creating cgi scripts
working with apache server on linux running 2.2.19 kernel - any backdoors i
should be aware of ?
is there any chance to get a root password via badly writen cgi script - i
used mysql and psql dbd pure perl modules with dbi
On Thu, 31 Oct 2002 15:56:59 -0500, [EMAIL PROTECTED] (Todd W) wrote:
>
>"Jim Lundeen" <[EMAIL PROTECTED]> wrote in message
>news:3DBDA799.307DC69A@;jimmyjames.net...
>> nothing that will work on Linux box?
>
>perlcc works... see below.
Yeah, I have to say that the perlcc which comes with perl5.8.
I can't say for sure, but check your Internet Explorer settings. You should be
able to stop the browser caching documents from certain domains, and also you
might have that automatic form completion option activated. I can't give you
more precise info because I'm using Linux. And if that doesn't
"Jim Lundeen" <[EMAIL PROTECTED]> wrote in message
news:3DBDA799.307DC69A@;jimmyjames.net...
> nothing that will work on Linux box?
perlcc works... see below.
> Admin-Stress wrote:
>
> > Nice, but that will produce .exe, executable file for Windows :(
> >
> > --- David Simcik <[EMAIL PROTECTED]>
erver, meaning that the
password and username are sent from the cache of the first page.
It might be another security problem of Internet Explorer.
Teddy's Center: http://teddy.fcc.ro/
Email: [EMAIL PROTECTED]
- Original Message -
From: "Geraint Jones" <[EMAIL PROTECTED]
On Friday 25 October 2002 9:51 am, Octavian Rasnita wrote:
> Hi all,
>
> I've made a script that displays 2 forms one after another, then the result
> page.
> It works like a Wizard from Windows.
>
> In the first page, I print a form for getting the username and the
> password, and if these are goo
this reply.
> -Original Message-
> From: Abel Lucano [mailto:abel@;decode.com.ar]
> Sent: Monday, October 28, 2002 4:35 PM
> To: Jim Lundeen
> Cc: Admin-Stress; [EMAIL PROTECTED]
> Subject: Re: perl cgi security
>
> I understand instead that you want 'hide' your
On Mon, 28 Oct 2002, Jim Lundeen wrote:
> nothing that will work on Linux box?
>
> Admin-Stress wrote:
>
> > Nice, but that will produce .exe, executable file for Windows :(
> >
> > --- David Simcik <[EMAIL PROTECTED]> wrote:
> > > See perl2exe.exe for details on converting scripts into executable
nothing that will work on Linux box?
Admin-Stress wrote:
> Nice, but that will produce .exe, executable file for Windows :(
>
> --- David Simcik <[EMAIL PROTECTED]> wrote:
> > See perl2exe.exe for details on converting scripts into executables.
> >
> > -D
>
> _
Nice, but that will produce .exe, executable file for Windows :(
--- David Simcik <[EMAIL PROTECTED]> wrote:
> See perl2exe.exe for details on converting scripts into executables.
>
> -D
__
Do you Yahoo!?
Y! Web Hosting - Let the expert host your
See perl2exe.exe for details on converting scripts into executables.
-D
-Original Message-
From: Jim Lundeen [mailto:jim@;jimmyjames.net]
Sent: Monday, October 28, 2002 12:48 PM
To: fliptop
Cc: Admin-Stress; [EMAIL PROTECTED]
Subject: Re: perl cgi security
Isn't there a meth
Isn't there a method of actually making an executable (compiled) out of a perl
script? I heard/saw about is a year or so ago, but never investigated it. I'd
be interested in finding out more if anyone has info. Thanks
fliptop wrote:
> On Sun, 27 Oct 2002 at 14:10, Admin-Stress opined:
>
> A:I
can read their files. You can probably bet
money that the "government" has already looked thru your files.
Most ISP's have a "warning" that doing this may result in you
getting kicked off their server.
If you need security, then it is best that you run your own server,
On Sun, 27 Oct 2002 at 14:10, Admin-Stress opined:
A:Is it possible to VIEW the source code of a perl cgi from a website?
sure, if your httpd server is improperly configured.
A:For example, I wrote a perl cgi like this
A:http://www.myweb.com/cgi-bin/addcustomer.pl
A:
A:The purpose of that script
Hi,
I am new to perl cgi. I would like to ask (maybe a silly question) :
Is it possible to VIEW the source code of a perl cgi from a website?
For example, I wrote a perl cgi like this http://www.myweb.com/cgi-bin/addcustomer.pl
The purpose of that script is to add new customer into my MySQL dat
Hi Octavian,
I would suggest that you use session management (I like CGI::Session but
Apache::Session should also work) to store the private data about the
current user rather than writing it to the second form.
Good luck,
William
--
Lead Developer
Knowmad Services Inc. || Internet Applicat
Hi all,
I've made a script that displays 2 forms one after another, then the result
page.
It works like a Wizard from Windows.
In the first page, I print a form for getting the username and the password,
and if these are good, the script prints the second form with some private
data.
After submit
id in like 2 min. It will be cleaned up a bit more. And if there is
> a better way of checking let me know. I would rather use proven code then
> risk a security hole.
>
> Chris
>
> $valid = 'digital-drakon'
> $referer = $ENV{HTTP_REFERER};
Chris,
You do not wan
is
a better way of checking let me know. I would rather use proven code then
risk a security hole.
Chris
$valid = 'digital-drakon'
$referer = $ENV{HTTP_REFERER};
# should split by the // in
# http://www.digital-drakon.com
($http, $url) = split(/\/\//, $referer)
# whats left over s
--- John Brooking <[EMAIL PROTECTED]> wrote:
> Gang,
>
>A week or three ago, someone referred to a page
> that discussed security issues when using CGI input to
> send out to a web page. I thought I had bookmarked the
> page or saved the email, but I can't find i
John,
Thanks for that link. Good reading/advice.
Scot R.
-Original Message-
From: John Brooking [mailto:[EMAIL PROTECTED]]
Sent: Thursday, May 30, 2002 12:02 PM
To: David T-G; Beginners CGI
Subject: Re: URL for security issue?
Actually, I may have just found it. I think it was
e of them for future reference.
--- David T-G <[EMAIL PROTECTED]>
wrote:
> Actually, I'd appreciate such a thing, too. I just
> went back through my
> list mailbox looking for "cgi" and "security" in the
> body and don't see
> anything relating
d T-G [mailto:[EMAIL PROTECTED]]
Sent: Thursday, May 30, 2002 11:53 AM
To: Beginners CGI
Cc: John Brooking
Subject: Re: URL for security issue?
John, et al --
and then John Brooking said...
%
% Gang,
Hello!
%
%A week or three ago, someone referred to a page
% that discussed security
John, et al --
...and then John Brooking said...
%
% Gang,
Hello!
%
%A week or three ago, someone referred to a page
% that discussed security issues when using CGI input to
% send out to a web page. I thought I had bookmarked the
% page or saved the email, but I can't find i
Gang,
A week or three ago, someone referred to a page
that discussed security issues when using CGI input to
send out to a web page. I thought I had bookmarked the
page or saved the email, but I can't find it now.
Could whoever posted it please do so again, or maybe
just email it
Please take into account that I'm new at this...
Rather than using CGI.pm, I'm using the following library sub-routine
which was passed to me by a friend (I think from one of the O'Reilly
books). What I'm wondering is if Perl 5 has any built in functionality
to prevent buffer overruns or excessiv
--- erotomek <[EMAIL PROTECTED]> wrote:
> --- Curtis Poe <[EMAIL PROTECTED]> wrote:
> >
> > You supplied some great information, however, your
> > example of plugging the security hole has a
> > security hole itself. From the command line on any
> &g
> http:[EMAIL PROTECTED]/msg02976.html
Doh!
Please forgive my nonsensical ramblings.
Thanks!
Carl
--
>From: erotomek <[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED]
>Subject: Re: Very serious security hole in your script
>Date: Fri, Mar 1, 2002, 4:55 am
>
>
--- Carl Franks <[EMAIL PROTECTED]> wrote:
> As you've changed the subject line, and have not
> included the original
> message, could you please explain whose post this is
> regarding.
> Quite a lot of code is sent to this mailing list!
> >From: erotomek <[EMAIL PROTECTED]>
> > I've just read
--- Curtis Poe <[EMAIL PROTECTED]> wrote:
>
> You supplied some great information, however, your
> example of plugging the security hole has a
> security hole itself. From the command line on any
> *nix system, enter the following (assuming you
> are not in root):
&
Randal wrote:
> > "Rob" == Rob <[EMAIL PROTECTED]> writes:
>
> Rob> Is there a good tutorial on untainting data received via a cgi
script?
>
> Besides "perldoc perlsec"?
>
The best way to make sure that you don't pass dangerous data to the shell
is to pass no user data to the shell. There
sign.com
- Original Message -
From: "Rob" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, February 26, 2002 5:50 PM
Subject: Re: Very serious security hole in your script
> Is there a good tutorial on untainting data received via a cgi script?
>
>
ECTED]> http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
> >
> > and untaint the $file variable:
> >
> > die 'INSECURE $file !!!' if $file =~ /\.\./;
> > if ($file =~ /^([-\w./]+)$/) { $file = $1 }
> > else { die 'INSECURE $file !!!' }
> >
> > and now you can use it.
>
> You supplied some
/) { $file = $1 }
> else { die 'INSECURE $file !!!' }
>
> and now you can use it.
You supplied some great information, however, your example of plugging the security
hole has a
security hole itself. From the command line on any *nix system, enter the following
(assuming you
are not in root
<[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED]
>Subject: Very serious security hole in your script
>Date: Tue, Feb 26, 2002, 5:11 am
>
> Hi,
>
> I've just read your message on [EMAIL PROTECTED]
> mailing list archives:
> http:[EMAIL PROTECTED]/msg02976.ht
Hi,
I've just read your message on [EMAIL PROTECTED]
mailing list archives:
http:[EMAIL PROTECTED]/msg02976.html
I just thought you'd like to know that there's an
extremely serious security problem, anyone can
download every single file from your server! And
that's not all
At 02:29 AM 10/12/2001, Curtis Poe wrote:
>--- Wagner Garcia Campagner <[EMAIL PROTECTED]> wrote:
> >
> > This site doesn't need so much security so I'm not worryed if someone is
> > using a sniffer...
>
>Wagner,
>
>That is begging for trouble.
--- Wagner Garcia Campagner <[EMAIL PROTECTED]> wrote:
>
> This site doesn't need so much security so I'm not worryed if someone is
> using a sniffer...
Wagner,
That is begging for trouble. My apologies in advance for the rather serious tone
here. Here's
--- Wagner Garcia Campagner <[EMAIL PROTECTED]> wrote:
>
> This site doesn't need so much security so I'm not worryed if someone is
> using a sniffer...
Wagner,
That is begging for trouble. My apologies in advance for the rather serious tone
here. Here's
Hi,
Thanks everybody for the help...
I think I have the solution...
This site doesn't need so much security so I'm not worryed if someone is
using a sniffer...
I just don't want everyone to do "view source" and see the password in plain
text so i'm going t
Hi there,
I had the same problem...now I'm sending a random valued cookie to the user's browser
and to the user table in a database.
I compare the value of the cookie in the browser against the value in the database if
it matches voila! it's the user.
You could use a text file to store the us
Please forgive the formatting of this message, I am using Lotus Notes (nuff
said)...
First off, this is NOT a "Perl security issue". It doesn't matter what
language you do this in, the results would be the same...
Now, if you want to pass a username and password securely, you
what he needs to do.
> -Original Message-
> From: fliptop [SMTP:[EMAIL PROTECTED]]
> Sent: Thursday, October 11, 2001 1:06 PM
> To: Grierson, Garry (UK07)
> Cc: Wagner Garcia Campagner; [EMAIL PROTECTED]
> Subject: Re: security in perl
>
> "
"Grierson, Garry (UK07)" wrote:
>
> I had pretty much exactly the same problem, if you look at the 'Security
> Suggestions Please!' thread on the beginners-cgi archive at
> http://archive.develooper.com/beginners-cgi%40perl.org/ you can see what
>
>
Hi,I have three web pages, for example: login.html,
page1.pl and page2.pl...In the first page i send the username and the
password to the page1.pl through FORM POST METHOD:USER:PASSWORD:So
i get this in page1.pl as follos:$name = param('username');$pass = param('passwd');if
(($name eq 'gest'
Hey folks,
I'm trying to cobble together some form of authentication mechanism on a
website I am building for a friend. His ISP uses Perl & Apache (it's on a
linux box). I (obviously) don't have root priviledges and have limited
access to the filesystem. What are my options (if any)??? I t
If you want your usernames and passwords to look something like this.
ªaRtW¢³†Ê¬Ì~“µv$¾ïÃ
then store passwords in a mysql blob field with the encrypt() function and a
"key". I learned this technique from a very excellent tutorial by Aaron
Weiss at the following URL:
www.wdvl.com/Authoring/
geron'
-Original Message-
From: "Grierson, Garry (UK07)"<[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Date: Tue Sep 18 03:22:17 PDT 2001
Subject: Security Suggestions Please!
>I have to secure a newly developed web search service that deals with
>sensitive fiscal inform
ck" is a good thing...lets not fall into the mass-media trap of
equating computer intrusion with "hacking".
That being said, nowadays you don't need much knowledge to compromise
security on a computer network. Thousands of pre-made "script kiddie"
exploit tools are a
ecuring data. I'm assuming that you are using hidden
fields. Anyone
can "view source" and see the password. This is a very, very bad idea.
Okay, so this is for an intranet and you're not worried about sniffers. First rule of
CGI
security: never, never, never trust an
om: "Grierson, Garry (UK07)" <[EMAIL PROTECTED]>
To: "Roger C Haslock" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Tuesday, September 18, 2001 3:20 PM
Subject: RE: Security Suggestions Please!
> 1) Ok point taken.
>
> 2) Mabey a little unclear here:
K07); [EMAIL PROTECTED]
> Subject: Re: Security Suggestions Please!
>
> At 12:22 PM 9/18/2001 +0200, Grierson, Garry (UK07) wrote:
> >I have to secure a newly developed web search service that deals with
> >sensitive fiscal information, this originally consisted of Perl sc
Tuesday, September 18, 2001 2:42 PM
> To: Grierson, Garry (UK07)
> Subject: Re: Security Suggestions Please!
>
> (This is not a perl/cgi question)
>
> 1)
> It is easier to manage changes if data is held in a database. By similar
> triangles, it is easier to manage secur
t;against a file or database table as opposed to having a valid password or
>list of passwords held within the initial validation script?
> The password will be changed regularly and the server is unlikely to be
>changed to displaying the script text be mistake is unlikely.
This dep
I have to secure a newly developed web search service that deals with
sensitive fiscal information, this originally consisted of Perl scripts that
called html pages or other scripts. The default page ran a rudimentary login
script that launched a variety of html pages or further scripts, the html
--- Gunther Birznieks <[EMAIL PROTECTED]> wrote:
> There's actually quite a bit of interesting stuff out there that has really
> only been "discovered" and publicized at all in the last year or two. Null
> byte is another huge issue few Perl programmers seem to know
> about/understand as it aff
Con.
I've placed the slides are up here:
http://www.extropia.com/presentations/cgi_security_history.html
Since me and Selena Sol have been around giving out open source web apps
since 8 years ago (very early on the Web), we've of course seen the gamut
of security holes, including those within
le to this kind of attack in contrasts to, say,
using stored procedures.
I enjoyed reading your post :-)
joel
-Original Message-
From: Gunther Birznieks [mailto:[EMAIL PROTECTED]]
Sent: 02 September 2001 01:15
To: yahoo; [EMAIL PROTECTED]
Subject: RE: Is it a security risk to use identical
d
therefore being able to glean extra information is helpful to any cracker
on the system. I do firmly believe that restricting the information you
give the user about your system will help security, but I also think it is
a matter of diminishing returns and would rather the user who asked the
attempt to recreate fragments of the data model pah! best of luck...
joel
-Original Message-
From: Michael R. Fahey [mailto:[EMAIL PROTECTED]]
Sent: 31 August 2001 13:33
To: [EMAIL PROTECTED]
Subject: Is it a security risk to use identical names for database fields
and html forms?
At 01:55 PM 8/31/2001 -0700, Curtis Poe wrote:
>--- "Michael R. Fahey" <[EMAIL PROTECTED]> wrote:
> > Hi,
> >
> > I was looking at a perl script where the developer used different names
> > for the incoming parameters and the database field names. He
1 - 100 of 123 matches
Mail list logo
