On Mon, Aug 8, 2011 at 10:08 AM, Jen Rasmussen j...@cetaceasound.com wrote:
[snip]
On a side note, PHP versions prior to 5.3+ do not allow to set the httponly
flag as a cookie parameter, is there any acceptable alternative for this?
I believe that has been supported since 5.2.0. As for a
Thanks, Andrew! I am unfortunately not even running 5.2..so that helps.
Jen
-Original Message-
From: Andrew Ballard [mailto:aball...@gmail.com]
Sent: Monday, August 08, 2011 9:57 AM
To: j...@cetaceasound.com
Cc: php-general@lists.php.net
Subject: Re: [PHP] PHP Security: Best Practices
I am currently researching security best
practices/methods. Can anyone offer
any current resources/recommendations?
That is a huge arena and the question can not be answered very well
without describing what you are needing to protect. Security in debth
depends upon what you are protecting and
On 8 August 2011 15:08, Jen Rasmussen j...@cetaceasound.com wrote:
Hello all,
I am currently researching security best practices/methods. Can anyone offer
any current resources/recommendations?
My research thus far has included password hashing with salting/stretching,
session hash
H, how about some details on OS, etc
Bastien
Sent from my iPod
On Jun 2, 2009, at 17:26, Grant Peel gp...@thenetnow.com wrote:
Hi all,
I am currently setting up the next generation web server for our
company and am in need of general consulting/advice on php set up
security issues.
On Jun 2, 2009, at 17:26, Grant Peel gp...@thenetnow.com wrote:
I am currently setting up the next generation web server for our
company and am in need of general consulting/advice on php set up
security issues.
For general considerations, start here:
-Grant
- Original Message -
From: Phpster phps...@gmail.com
To: Grant Peel gp...@thenetnow.com
Cc: php-general@lists.php.net
Sent: Tuesday, June 02, 2009 5:53 PM
Subject: Re: [PHP] PHP Security
H, how about some details on OS, etc
Bastien
Sent from my iPod
On Jun 2, 2009
At 11:22 AM +0100 7/4/07, Ross wrote:
http://amazon.co.uk/s/ref=nb_ss_w_h_/203-1671317-2810350?initialSearch=1url=search-alias%3Dapsfield-keywords=php+securityGo.x=0Go.y=0Go=Go
looking at the top 3 on the list here, personally I quite like the O'Reilly
books. Can someone recommend one of these
On Jul 4, 2007, at 3:22 AM, Ross wrote:
http://amazon.co.uk/s/ref=nb_ss_w_h_/203-1671317-2810350?
initialSearch=1url=search-alias%3Dapsfield-
keywords=php+securityGo.x=0Go.y=0Go=Go
looking at the top 3 on the list here, personally I quite like the
O'Reilly
books. Can someone recommend
I would look here for an idea. http://phpsec.org/projects/guide/
I think you'll find many opinions on the matter. One thing to
remember is that once the app goes live your job doesnt stop there
you'll need to be just as stringent about security and checking logs
and errors as you were when you
Dallas Cahker wrote:
I was looking to see if there was a quick checklist of settings for php to
be disabled/enabled in the ini file to make the application more secure.
I'm making sure the apps we come out with dont allow sql injections, or form
injections and so forth, I have just seen some
Dallas Cahker wrote:
I was looking to see if there was a quick checklist of settings
for php to be disabled/enabled in the ini file to make the
application more secure.
Although there are some directives worth disabling (register_globals,
magic_quotes_gpc, allow_url_fopen), most
php.ini-anal-retentive-paranoid.
I'm editing mine for that right now, everything is off, the sever has
a keyboard, mouse, monitor no cd/dvd, no floppy, no usb and is
unplugged from the network, there are 6 security guards that surround
you and they give you 5 minutes on a timer.
On 4/6/06, Kevin
Cool Chris I'm going to take a look at that movie. Dallas there is a
section at the top of the ini file that lists some directives and
their status to address security or performance issues, but as Chris
mentioned your code could be as big of a risk as anything so pay
attention to that.
On
Cool Chris I'm going to take a look at that movie. Dallas there is a
section at the top of the ini file that lists some directives and
their status to address security or performance issues, but as Chris
mentioned your code could be as big of a risk as anything so pay
attention to that.
Richard Lynch wrote:
The actual text is:
...in a Web service protocol FOR PHP
Good catch. The summary sent to the list was:
A new security flaw in the PHP Web service protocol used by a large
number of Web applications could allow attackers to take control of
vulnerable servers.
Thanks
Santosh:
Personally what I think you did wrong, was to simply paste the header
of that news article into your email. You simply said that PHP was hit
by another security hole, that allowed crackers(sometimes incorrectly
refered to as hackers), to gain access to any php service. I don't
think you
At 02:37 AM 8/26/2005, Santosh Jambhlikar wrote:
As this is the php mailing list it is obvious that i should not write
against php. but people should know the truth. And it's a news (not by me)
that's why i wanted to send link to u peoples.
I am sorry if i did something wrong, i am new user in
snip
Of course, if you ever see a news story that describes PHP as a web
service protocol, you probably want to stop reading immediately. :-)
Chris
--
Chris Shiflett
Brain Bulb, The PHP Consultancy
http://brainbulb.com/
Actually, I wanted to read more, just to find out how badly things
On Fri, August 26, 2005 12:32 am, Chris Shiflett wrote:
Of course, if you ever see a news story that describes PHP as a web
service protocol, you probably want to stop reading immediately. :-)
The actual text is:
...in a Web service protocol FOR PHP
^^^
[emphasis
also
PHP HIT BY ANOTHER CRITICAL FLAW
A new security flaw in the PHP Web service protocol used by a large
number of Web applications could allow attackers to take control of
vulnerable servers.
http://www.computerworld.com/securitytopics/security/holes/story/0,10801,104124,00.html
Ian C.
Santosh Jambhlikar wrote:
also
PHP HIT BY ANOTHER CRITICAL FLAW
A new security flaw in the PHP Web service protocol used by a large
number of Web applications could allow attackers to take control of
vulnerable servers.
Ian C. McGarvey wrote:
I have been studying PHP all summer because I wanted to put some
PHP code on my schools web site. I got to school and went to the
web design teacher. I asked him if they had installed PHP on their
server. He said that the district thinks that it would be a HUGE
As this is the php mailing list it is obvious that i should not write
against php. but people should know the truth. And it's a news (not by
me) that's why i wanted to send link to u peoples.
I am sorry if i did something wrong, i am new user in php mailing list.
Jasper Bryant-Greene wrote:
Santosh Jambhlikar wrote:
As this is the php mailing list it is obvious that i should not write
against php. but people should know the truth.
Jasper is trying to make sure people know the truth. Articles like the
one you mentioned are doing quite the opposite.
I am sorry if i did
Santosh Jambhlikar wrote:
As this is the php mailing list it is obvious that i should not write
against php. but people should know the truth. And it's a news (not by
me) that's why i wanted to send link to u peoples.
I am sorry if i did something wrong, i am new user in php mailing list.
On Thu, 17 Feb 2005 20:47:28 -0600, .hG [EMAIL PROTECTED] wrote:
It makes me wonder how secure in reallity it is to place your UN and
Passwords on a PHP file.
Best idea is to place such information in an include file, which you
can call using the include() or require() statements - and
you could also encrypt the file using one of the encoders that are out
there. Some are free and some are paid for
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
On Fri, 18 Feb 2005 11:42:36 +, John Cage [EMAIL PROTECTED] wrote:
you could also encrypt the file using one of the encoders that are out
there. Some are free and some are paid for
Never thought of that ;-)
http://www.zend.com/store/products/zend-encoder.php?home (Commercial)
Thanks everyone for your input. I was just curios since everyone is so
concern about security, yet some messageboards/CMS use passwords for their
databases on the index page or an include.
--
...hG
http://www.helmutgranda.com
Robby Russell [EMAIL PROTECTED] wrote in message
news:[EMAIL
On Thu, 2005-02-17 at 20:47 -0600, .hG wrote:
While back I read in an article that placing UN and PASSwords in a PHP was
not secure. couple of open source programs that I have seen they have for
example
$database = ;
$username = ;
$password = ;
It makes me wonder how
--- .hG [EMAIL PROTECTED] wrote:
While back I read in an article that placing UN and PASSwords in a PHP
was not secure.
Well, that's very subjective. In a shared hosting environment, it
certainly does pose a risk. If you place it within document root (don't do
that), it poses a significant
Chris Shiflett mailto:[EMAIL PROTECTED]
on Sunday, January 30, 2005 10:19 PM said:
The PHP Security Consortium has officially launched. The following is
the press release:
Oooh cool! This looks to be a great resource. Keep up the good work
Chris.
Another,
Chris.
--
PHP General Mailing
There are better ways to do this than parsing .jpg files as PHP. One
obvious one is:
http://example.org/image.php/foo.jpg
I believe this broke on a very very very obscure version of IE -- Maybe
even the re-branded IE I ran into one time [shudder].
In theory, it was just IE X.xx.yy, but it
Greg Donald wrote:
The other day a post came across one of those mailing lists discussing
PHP security. One of the posters was describing how insecure PHP's
file upload functionality is and went on to explain a simple method of
attaching exploit code to the end of a jpeg or other image
There are times when one needs to parse a file that ends in .jpg (or
.jpeg) as PHP.
Specifically, broken browsers (various versions of IE) that ignore
Content-type: headers and use the URL to determine the MIME type will not
correctly display a URL such as:
Rory Browne wrote:
There are times when one needs to parse a file that ends in .jpg (or
.jpeg) as PHP.
Specifically, broken browsers (various versions of IE) that ignore
Content-type: headers and use the URL to determine the MIME type will
not
correctly display a URL such as:
--- Richard Lynch [EMAIL PROTECTED] wrote:
There are times when one needs to parse a file that ends in .jpg
(or .jpeg) as PHP.
I can't think of any, unless it's prove that you can do it. :-)
Specifically, broken browsers (various versions of IE) that ignore
Content-type: headers and use the
--- Greg Donald [EMAIL PROTECTED] wrote:
The other day a post came across one of those mailing lists discussing
PHP security. One of the posters was describing how insecure PHP's
file upload functionality is and went on to explain a simple method of
attaching exploit code to the end of a jpeg
Pablo Gosse wrote:
Hi folks. I recently set up hosting for my site and have noticed
something which is making me nervous.
If you are really nervous you cannot use shared hosting. Simple as that.
Even if other users don't access your stuff, the root user can. While
it's against the system
Chris,
I believe that is the reason that the PHP group came up with the
open_basedir directive.
The open_basedir prevents you from looking into anything higher than a
particular directory tree using PHP.
So, a combination of safe_mode and open_basedir should prevent your script
from being
Oh, and I forgot, you can also specify specific include directories to be
allowed for a particular user...
Tim.
At 09:47 PM 9/25/2004, Chris Shiflett wrote:
--- Tim Traver [EMAIL PROTECTED] wrote:
I can guarantee that is not the way it is supposed to be. We
make sure that can't happen by
Tim Traver wrote:
Chris,
I believe that is the reason that the PHP group came up with the
open_basedir directive.
The open_basedir prevents you from looking into anything higher than a
particular directory tree using PHP.
So, a combination of safe_mode and open_basedir should prevent your
--- Tim Traver [EMAIL PROTECTED] wrote:
I believe that is the reason that the PHP group came up with the
open_basedir directive.
The open_basedir prevents you from looking into anything higher
than a particular directory tree using PHP.
So, a combination of safe_mode and open_basedir
On Monday 27 September 2004 02:26, Chris Shiflett wrote:
If you do not offer CGI access or any interpreter besides PHP, then I
suppose it's better than nothing, but I wouldn't characterize this as
safe. I suspect that if I were a user on this host, I could give you a URL
that displays another
[snip]
I just published a free article on my Web site about shared hosting:
http://shiflett.org/articles/security-corner-mar2004
In short, what you've found is typical for most shared hosts, and
safe_mode (a directive created to help mitigate this problem a bit) does
little to help. However,
--- Pablo Gosse [EMAIL PROTECTED] wrote:
http://shiflett.org/articles/security-corner-mar2004
[snip]
Hi, Chris. Thanks for that link. It was incredibly informative.
I'm glad you thought so. :-)
I just took your code for the file browser and it was able to
read the information in all users'
[snip]
In short, what you've found is typical for most shared hosts
[/snip]
I've just been reviewing the way sites are housed on my host, and what
directories are readable by the web server and I'm curious to get
opinions on this.
When I use Chris' file browser script, there is a folder called
Ahhh...ok, now you're talking about something else.
I thought we were just talking about the security model of PHP only. Yes,
if a host has decided to offer another means for CGI that isn't safe, then
that is another issue all together...;)
I was just talking about PHP's security model. Safe
Pablo,
I tested Chris's script on our systems, and couldn't browse anywhere other
than my own directories, so it is possible to set php up on shared hosts
that is a lot more secure than what your host has done.
May I ask what host this is ? Is it a major one ?
Tim.
At 02:09 PM 9/26/2004, Pablo
Pablo,
As a shared hosting company myself (http://www.simplenet.com/), I can
guarantee that is not the way it is supposed to be. We make sure that can't
happen by running in Safe mode, using the open_basedir directive, and
making sure the directory tree has the correct permissions so the
--- Pablo Gosse [EMAIL PROTECTED] wrote:
Hi folks. I recently set up hosting for my site and have noticed
something which is making me nervous.
I can't seem to include files outside of my webroot, so I wrote
a script to test permissions using passthru to output the results
of a bunch of ls
--- Tim Traver [EMAIL PROTECTED] wrote:
I can guarantee that is not the way it is supposed to be. We
make sure that can't happen by running in Safe mode, using the
open_basedir directive, and making sure the directory tree has
the correct permissions so the situation you described cannot
Chris Shiflett wrote:
This news is a bit old, but I have made the workbook for my OSCON tutorial
freely available from this URL:
http://shiflett.org/php-security.pdf
It's a 55 page PDF that has a lot of information (more than the slides)
about some of the more important security topics.
I hope you
--- John Nichel [EMAIL PROTECTED] wrote:
Chris Shiflett wrote:
This news is a bit old, but I have made the workbook for my
OSCON tutorial freely available from this URL:
http://shiflett.org/php-security.pdf
It's a 55 page PDF that has a lot of information (more than
the slides)
Thanks for the article Chris. Printing it out now and will read it later.
Chris
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Chris Shiflett wrote:
This news is a bit old, but I have made the workbook for my OSCON tutorial
freely available from this URL:
http://shiflett.org/php-security.pdf
It's a 55 page PDF that has a lot of information (more than the slides)
about some of the more important security topics.
Nice
--- Burhan Khalid [EMAIL PROTECTED] wrote:
Most of the stuff was common sense to me (and I was glad I
was doing those things unconsciously).
That's good to hear. :-)
Most of the people that have heard me give this talk (which is a few
hundred now) have realized several vulnerabilities in their
PROTECTED]; [EMAIL PROTECTED]
Sent: Sunday, August 15, 2004 4:05 PM
Subject: Re: [PHP] PHP Security Workbook
--- Burhan Khalid [EMAIL PROTECTED] wrote:
Most of the stuff was common sense to me (and I was glad I
was doing those things unconsciously).
That's good to hear. :-)
Most of the people
--- Octavian Rasnita [EMAIL PROTECTED] wrote:
I have also read that pdf document and I have found another
interesting advice.
The author says that a good way of hiding the username/password
is to put a file that exports 2 environment variables in a directory
that can be read only by the
Oh thank you for this information. This is very important for me to know.
Yes, this is another thing that I mention in the talk but failed to
include in the workbook. When this approach is being applied to a shared
hosting environment, you want to put the Include directive within a
My suggestion would be to run the PHP Web Server on a different server to
where you are retrieving your files. The file server can then define its own
polices of what you can read/write to etc. Your web server can then map a
drive to the file server, and anybody writing PHP scripts won't be able
Ben Joyce wrote:
hi.
one of my clients whom we host a website for has expressed interest in
writing their own php/mySQL applications for their site.
i've been looking in to the security implications of offering this service.
My concerns are that the client *could* use a php script to access
From: Ben Joyce [EMAIL PROTECTED]
one of my clients whom we host a website for has expressed interest in
writing their own php/mySQL applications for their site.
i've been looking in to the security implications of offering this
service.
My concerns are that the client *could* use a php
--- Ben Joyce [EMAIL PROTECTED] wrote:
one of my clients whom we host a website for has expressed interest
in writing their own php/mySQL applications for their site.
i've been looking in to the security implications of offering this
service.
How are you not offering it now? Can the client
request floods and such are not the responsability of the programmer is
it? Sounds more like a sys admin problem? i could be wrong.
Jason
Martin Nicholls [EMAIL PROTECTED] wrote:
I know somebody who coded a PHP script that attempts to prevent post
flooding and some other potential security
no, but i suppose you have options available to prevent them, and it may be
a sysadmins problem, but there is a good chance that it may be your fault, I
can see how if you are a freelance devloper, it may look bad if the client
wants to hire for another job, and your code was the flaw in an
--- Pushpinder Singh Garcha [EMAIL PROTECTED] wrote:
i wanted to check with if it is possible to see the
contents of a .php file.
You can open any normal PHP script in a text editor.
I have heard of the Zend Encoder, but I was wondering
how could a person see my php script?
If you use Zend
On Tue, 23 Jul 2002, Richard Lynch wrote:
This is excluding support contracts for software you paid for -- Once you
pay Oracle enough money for Support Contracts, they have pretty good
support, from what I hear... :-)
They're attentive and responsive and about as knowledgeable as you could
restart apache
-Original Message-
From: Michal Dvoracek [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, 23 July 2002 4:34 PM
To: Jason Soza
Cc: [EMAIL PROTECTED]
Subject: [PHP] PHP security bug and patch
Hello,
when applying patch on version 4.2.1 then in phpinfo(); is still PHP
[snip]
Well, trying to updrade on Slackware Linux 8.0 and compiling with the GD
(1.8.4) libraries are giving us some headaches. Some of what seems to be
wrong;
...
You're simply looking at the old PHP.
You did stop/start Apache, right?... Cuz the new PHP won't kick in until
you do.
If so,
Who said anything about M$? I don't use their crappy products so I
don't have to deal with their security issues.
I'm the one who brought up Microsoft, I'm saying it's a whole lot better
then the alternatives.
If PHP 4.2 is unsafe then why is it listed at the top of the page for
Hi,
1. Every peice of software has bugs - PHP still bugs - it always will
have. Deal with it.
2. It is no-one's responsibility other than your own to *test the
software*. Anyone using any form of software in a production environment
has at least one test bed to install new versions of software
Well, I'm not sure about the 'you get what you pay for'. Some paid for
software has less support and documentation than PHP!
Justin French [EMAIL PROTECTED] wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
Greg,
Your attitude stinks.
PHP is a FREE scripting language. Think
Well, I'm not sure about the 'you get what you pay for'. Some paid for
software has less support and documentation than PHP!
In my experience, *ALL* paid-for software has less support and documentation
than PHP.
This is excluding support contracts for software you paid for -- Once you
pay
On July 22, 2002 10:12 am, 1LT John W. Holmes wrote:
[snip]
PHP Security Advisory: Vulnerability in PHP versions 4.2.0 and 4.2.1
[/snip]
Looks like everyone will be using the new super globals, now... :)
Well, I guess I'm still assuming that in a perfect world, people will
upgrade
IIRC, just about every upgrae has security fixes, you may be hard
pressed to find an older version that doesn't have any big holes in it.
On Mon, 2002-07-22 at 10:55, Ilia A. wrote:
On July 22, 2002 10:12 am, 1LT John W. Holmes wrote:
[snip]
PHP Security Advisory: Vulnerability in PHP
On Mon, 22 Jul 2002, Marko Karppinen wrote:
PHP Security Advisory: Vulnerability in PHP versions 4.2.0 and 4.2.1
Not only did I get to re-write all my apps the past few months because of
the new register_globals default that was imposed by `the php group`...
Now I get to upgrade my PHP
Hey man, if you can't stand the heat, get out of the freakin sun.
Atleast PHP tells you about holes, not like Microsoft who will fix it
six months down the line (if they even admit a hole exists). Plus, if
your running anything past 4.1.2 on production systems, it's your own
damn fault because
)
To: [EMAIL PROTECTED]
Subject: Re: [PHP] PHP Security Advisory: Vulnerability in PHP versions 4.2.0
and 4.2.1
On 22 Jul 2002, Adam Voigt wrote:
Hey man, if you can't stand the heat, get out of the freakin sun.
Atleast PHP tells you about holes, not like Microsoft who will fix it
six months
I actually enjoy all the security releases. They give me something to
do at work!
tyler
On Mon, 22 Jul 2002 11:55:31 -0500 (CDT)
Greg Donald [EMAIL PROTECTED] wrote:
On Mon, 22 Jul 2002, Marko Karppinen wrote:
PHP Security Advisory: Vulnerability in PHP versions 4.2.0 and
4.2.1
Quoting Greg Donald [EMAIL PROTECTED]:
It's not about that.. It's about the hell I've already been
through with the new register_globals setting. Then two huge ass
security holes following in the next couple of months after that.
If it doesn't bother you the hassles 'the php group' is
Well from the sound of it, it's a quick painless process to upgrade php to
the newest version using the patch. Can anyone that has done it comment
on
the complexities of the upgrade? Im just going on what it says on the php
homepage...
Nice and easy for me, I'm running it on windows,
, July 22, 2002 1:52 PM
To: Richard Baskett; PHP General
Subject: Re: [PHP] PHP Security Advisory: Vulnerability in PHP
versions4.2.0 and 4.2.1
Well from the sound of it, it's a quick painless process to upgrade
php to the newest version using the patch. Can anyone that has done
it comment
[snip]
Can anyone that has done it comment on the complexities of the upgrade?
[/snip]
Well, trying to updrade on Slackware Linux 8.0 and compiling with the GD
(1.8.4) libraries are giving us some headaches. Some of what seems to be
wrong;
phpinfo() does not show new build times for each
[snip]
PHP Security Advisory: Vulnerability in PHP versions 4.2.0 and 4.2.1
[/snip]
Looks like everyone will be using the new super globals, now... :)
Well, I guess I'm still assuming that in a perfect world, people will
upgrade because of security issues...
---John Holmes...
--
PHP
The superglobals have been a round for a bit so it's not as if everything's
got to be updated overnight.
I run PHP on windows and upgrading is just a matter of unzipping the archive
to my PHP folder and overwriting all the older files - dead simple. Don't
even have to change php.ini if I don't
On Mon, 22 Jul 2002, 1LT John W. Holmes wrote:
This other guy needs to quit his freakin whining and just do his job. Or go
use ASP...the choice is yours.
Or JSP, for that matter. I've just discussing with a friend about this
security issue, and he was trying to convince me to move to Java...
22, 2002 9:19 AM
Subject: Re: [PHP] php security mailing list ...
php-announce sends out notices.
On Monday 22 July 2002 16:07 pm, Dario Bahena Tapia wrote:
Hi ...
I want to be warned about php security issues, I couldn't find
an exact match in the mailing list names ... which one do
times, but you'll notice
people asking on every other list about what the changes are.
- Original Message -
From: Evan Nemerson [EMAIL PROTECTED]
To: Dario Bahena Tapia [EMAIL PROTECTED];
[EMAIL PROTECTED]
Sent: Monday, July 22, 2002 9:19 AM
Subject: Re: [PHP] php security mailing
Well, trying to updrade on Slackware Linux 8.0 and compiling with the GD
(1.8.4) libraries are giving us some headaches. Some of what seems to be
wrong;
phpinfo() does not show new build times for each compile, not seemingly a
caching problem (we have shut down browsers and then re-opened them
On Mon, 22 Jul 2002, Marko Karppinen wrote:
PHP Security Advisory: Vulnerability in PHP versions 4.2.0 and 4.2.1
Not only did I get to re-write all my apps the past few months because of
the new register_globals default that was imposed by `the php group`...
You could have just *CHANGED*
On Mon, 22 Jul 2002, Greg Donald wrote:
Not only did I get to re-write all my apps the past few months because of
the new register_globals default that was imposed by `the php group`...
You didn't have to. The choice was given to you, for your own good. If you
have very disciplined
Greg,
Your attitude stinks.
PHP is a FREE scripting language. Think about the amount of money you are
probably charging hosting clients, or charging in web or programming
services, or making in site revenue, or whatever way you 'commercially
function' through PHP.
The register globals
On Mon, 29 Apr 2002, Jay Fitzgerald wrote:
Can someone point me in the right direction in determining just how secure
PHP really is?
What are you actually trying to find out?
As far as actual security problems in PHP, where the interpreter behaves
contrary to documentation when provided with
-Original Message-
From: Liam Gibbs [mailto:[EMAIL PROTECTED]]
Sent: Thursday, April 25, 2002 8:20 PM
To: [EMAIL PROTECTED]
Subject: [PHP] PHP Security Leak
I'm wondering if anyone has any ideas on how to make a
login site more secure. Since I'm not really sure if
I've explained
This brings up another issue, how the heck do you get data binding? For
the life of me I don't see where the _query functions support SQL like:
SELECT AuthenticateUser(?,?) where then the first param might be a
usernamd and the second would be a password. The idea is that without this
sort of
]
Subject: RE: [PHP] PHP Security Leak
This brings up another issue, how the heck do you get data binding?
For
the life of me I don't see where the _query functions support SQL
like:
SELECT AuthenticateUser(?,?) where then the first param might be a
usernamd and the second would be a password
-BEGIN PGP MESSAGE-
Comment: For info see http://www.gnupg.org
owGlWL9vHMcVlmy4IcDCQIC0L2qONJZLibGS4GDrN63QpkRFRyURDEGY2527Hd3s
znpmlucNYDduXLhwlyqA/4BUaVwZSJogQJIirowAKVykc7oAQrp8b3bvdu9ES5bM
I4i7mX1v3rz3fd97x083Xz770qsffPPOHz6JPv/p2b9+48+88Rf15QH5TBUzqk1F
[mailto:[EMAIL PROTECTED]]
Sent: Thursday, April 25, 2002 10:26 PM
Cc: [EMAIL PROTECTED]
Subject: RE: [PHP] PHP Security Leak
This brings up another issue, how the heck do you get data binding?
For
the life of me I don't see where the _query functions support SQL
like:
SELECT
1 - 100 of 130 matches
Mail list logo
