php-general Digest 3 Dec 2006 15:58:36 -0000 Issue 4494
Topics (messages 245460 through 245465):
Re: alternative method
245460 by: Richard Lynch
Re: security and .htaccess
245461 by: Richard Lynch
245465 by: tedd
Error in php doc?
245462 by: MS P
245463 by: Roman Neuhauser
Re: problem with register globals on new server
245464 by: Tony Marston
Administrivia:
To subscribe to the digest, e-mail:
[EMAIL PROTECTED]
To unsubscribe from the digest, e-mail:
[EMAIL PROTECTED]
To post to the list, e-mail:
php-general@lists.php.net
----------------------------------------------------------------------
--- Begin Message ---
The browser is not supposed to change that, unless you hard-link to
http:// somewhere in your application.
I don't guarantee no browser ever had a bug like that, but I never
heard of such a bug.
And there ain't no stopping a pesky user from taking the 's' out to
see what happens... So you should be ready for that, and Do The Right
Thing, whatever that might be for your application.
On Sat, December 2, 2006 3:31 pm, Alain Roger wrote:
> Hi Richard,
>
> i already work on SSL also.
> basically, if $_SERVER['HTTPS'] is not setup to 'on', i redirect
> everything
> on the logon form window.
>
> I'm just scared about how SSL can be hold on between pages...
> for example :
>
> if on page index.php, SSL is activate.
> customer click on submit button and his redirected to main.php, i will
> redirect him with https:// in link, but does it keep SSL working ?
> will it not stop it for a while and restart it ?
>
> Alain
>
> On 12/2/06, Richard Lynch <[EMAIL PROTECTED]> wrote:
>>
>> On Sat, December 2, 2006 10:29 am, Alain Roger wrote:
>> > Based on phpsec.org documentation it is written ("between lines")
>> that
>> > GET
>> > and POST methods are still used but they are not the most secured
>> > (except if
>> > we take care for that).
>> > So, i would like to know which other methods are more secured that
>> > those 2.
>>
>> In addendum to Larry's post:
>>
>> You should also consider requiring SSL for any sensitive data, to
>> protect it in its travels from their computer to your server.
>>
>> SSL is kind of like an armored truck on the information
>> super-highway.
>> It doesn't stop bank robbers (server hacks) or muggers (viruses on
>> your users' computers), but the data is safe in transit between the
>> two.
>>
>> --
>> Some people have a "gift" link here.
>> Know what I want?
>> I want you to buy a CD from some starving artist.
>> http://cdbaby.com/browse/from/lynch
>> Yeah, I get a buck. So?
>>
>>
>
>
> --
> Alain
> ------------------------------------
> Windows XP SP2
> PostgreSQL 8.1.4
> Apache 2.0.58
> PHP 5
>
--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some starving artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?
--- End Message ---
--- Begin Message ---
On Sat, December 2, 2006 3:35 pm, Alain Roger wrote:
> I'm working on .htaccess file for improving security.
> Based on documentation from PHPSEC.org, we should be able to store
> DB_USER
> login and DB_PASS password in some secret-stuff (for example) file,
> which
> should be located outside root of web document root. (for example in
> some
> /path_to_secret folder)
I think .htaccess *is* the file being included...
It might be possible to use Apache's . operator (I think it's . ) to
suck in yet another file, outside the web root, so that a change to
the rules about not serving up .ht* files would not matter to that
file to be included...
But you've strayed into the "this is an Apache question" realm pretty
heavily...
http://apache.org/ probably addresses this somewhere, one way or the
other, if you dig enough.
--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some starving artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?
--- End Message ---
--- Begin Message ---
At 10:35 PM +0100 12/2/06, Alain Roger wrote:
I'm working on .htaccess file for improving security.
Based on documentation from PHPSEC.org, we should be able to store DB_USER
login and DB_PASS password in some secret-stuff (for example) file, which
should be located outside root of web document root. (for example in some
/path_to_secret folder)
The "path_to_secret folder" thing -- I have a question about.
I'm working with what a host provides me and I've seen paths that I
can traverse/access and paths in a .htpacess file that I can't. For
example, in one site I see a .htaccess file that contains:
AuthUserFile /home/admin/public_html/_vit_pvt/service.pwd
But, the "_vit_pvt" folder is not apparent. I can't get to it -- is
this a host file that only they can access, or is there a secret
handshake I need to get to it, or what?
Thanks.
tedd
--
-------
http://sperling.com http://ancientstones.com http://earthstones.com
--- End Message ---
--- Begin Message ---
Hi. There seems to be a minor error in the page
http://www.php.net/manual/en/features.file-upload.php. In Example 38-2
"Validating file uploads", there is a line:
$uploadfile = $uploaddir . basename($_FILES['userfile']['name']);
It looks like basename() is not required there. Because i found that when i
upload a file using IE6 (IE6 includes the whole path to the uploaded file,
see
http://jakarta.apache.org/commons/fileupload/faq.html#whole-path-from-IE),
the value of $_FILES['userfile']['name'] is a file name but not a path. It
looks like php has taken the file name from the path automatically. (I am
using php 5.2.0 and win2k.) Can someone check if i am correct? Thanks.
_________________________________________________________________
Learn English via Shopping Game, FREE!
http://www.linguaphonenet.com/BannerTrack.asp?EMSCode=MSN06-03ETFJ-0211E
--- End Message ---
--- Begin Message ---
# [EMAIL PROTECTED] / 2006-12-03 18:39:41 +0800:
> Hi. There seems to be a minor error in the page
> http://www.php.net/manual/en/features.file-upload.php. In Example 38-2
> "Validating file uploads", there is a line:
>
> $uploadfile = $uploaddir . basename($_FILES['userfile']['name']);
>
> It looks like basename() is not required there. Because i found that when i
> upload a file using IE6 (IE6 includes the whole path to the uploaded file,
> see
> http://jakarta.apache.org/commons/fileupload/faq.html#whole-path-from-IE),
> the value of $_FILES['userfile']['name'] is a file name but not a path. It
> looks like php has taken the file name from the path automatically. (I am
> using php 5.2.0 and win2k.) Can someone check if i am correct? Thanks.
That basename() call costs virtually nothing and protects you
against a bug in PHP and whatnot. Leave it there.
--
How many Vietnam vets does it take to screw in a light bulb?
You don't know, man. You don't KNOW.
Cause you weren't THERE. http://bash.org/?255991
--- End Message ---
--- Begin Message ---
""Richard Lynch"" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> On Sat, December 2, 2006 5:31 am, Tony Marston wrote:
>> If you site administrator thinks that using an htaccess file is a
>> security
>> issue then he is very much mistaken. The directives in an htaccess
>> file DO
>> NOT enable you to access any one else's data on a shared server. All
>> they do
>> is apply additional settings to your own site while leaving UNTOUCHED
>> the
>> settings being used by other sites.
>>
>> Most professional web hosting companies do not have an issue with
>> htaccess
>> files, so if yours does I would suggest switching to one with a more
>> professional attuitude.
>
> I think it is quite possible for a sysAdmin to configure AllowOverride
> and .htaccess in such a way that "too much" latitude is granted to
> their clients to access each others' data...
I disagree. What directives can give you access to other people's data?
> And there is alleged to be a significant performance loss to
> .htaccess, so a hurried sysAdmin may have over-simplified their
> decision process...
"Alleged" is the word. Where are the figures to support this? While there is
"some" performance loss, with the speed of today;'s PCs can this really be
considered as "significant"?
> At any rate, if you need .htaccess, and they don't want to provide it,
> there are a few thousand webhosts that do.
Exactly. So it canno be that much of a problem.
> I certainly wouldn't sign up with a host that didn't provide it, and
> would move to one that did ASAP if I found myself using one that
> didn't provide that.
I agree absolutely.
--
Tony Marston
http://www.tonymarston.net
http://www.radicore.org
--- End Message ---
