权限和脚本'可见性' [英] permissions and script 'visibility'

问题描述

我对PHP比较陌生。对我来说很明显很明显的事情之一（来自C / C ++背景）是开放的一切似乎 -

（AFAIK）。例如，URL通常具有他们正在调用的PHP脚本名称

- 也只是查看大多数网页的来源

将向您展示辉煌的细节，任何PHP脚本的路径和名称

他们可能正在使用。


如果要实现用户授权（或任何其他模块的

逻辑需要保持私有）在PHP模块中（除了encypting

脚本 - 它有自己的陷阱） - 没有任何意义的

这样一个模块（脚本或一组脚本）明显可见/可访问用户 - 他们可以在闲暇时检查您的用户身份验证等，

，同时啜饮他最喜欢的饮料。什么是保持你的

脚本对用户不可用的方式，这样他们就不能简单地FTP或获取你的

脚本 - 给出路径和文件名已经提供了？


我想我记得在某处读取这与设置

文件权限有关 - 例如将脚本放在了
$以上的文件中b $ b web服务器doc root。但是这引出了一个问题，即如果用户没有保留php文件的文件夹，那么他怎么能执行它们。-b
执行它们。实际上，最后一句话让我意识到围绕这个（可能？）的方式是让Apache作为一个不同的用户从

Web客户端运行。我在这个假设中是否正确？建议欢迎。

解决方案

>我是PHP的新手。对我来说很明显的事情之一

（来自C / C ++背景）是开放的一切似乎是什么 -
（AFAIK）。例如，URL通常具有他们正在调用的php脚本的名称 - 也只是查看大多数网页的来源
将向您展示辉煌的细节，任何PHP脚本的路径和名称<他们可能正在使用。


HTML可见。 PHP代码不能通过HTTP看到。

如果要实现用户授权（或其他需要保密的模块）


如果* logic *需要保密，那么它可能是一个

安全漏洞。

在PHP模块中（除了encypting
脚本 - 它有自己的缺陷） - 没有任何意义可以让用户明白可见/可访问这样的模块（脚本或脚本集） - 谁可以检查你的用户身份验证闲暇时等，


如果您正在谈论使用网络浏览器的远程用户，他们将无法*在他们闲暇时检查您的PHP代码。

同时啜饮他最喜欢的饮料。什么是让用户无法使用
脚本的方法，这样他们就不能简单地FTP或获取你的脚本 - 提供路径和文件名已经提供了？


确保您提供* NO *路径，用户只需获取您的

受保护文件而无需进行身份验证。这通常是用
和一个用于检查用户身份验证的PHP页面，如果它是

OK，则输出Content-type：header，然后fpassthru（）使用

a文件名*在文档树之外*。

我想我记得在某处读取这与设置
文件权限有关 - 例如将脚本放在web服务器doc根目录上方的afolder中。但这就引出了一个问题：如果用户对保存php文件的文件夹没有任何意义 - 他怎么能执行它们。实际上，最后一句话让我意识到围绕这个（可能？）的方式是让Apache作为与web客户端不同的用户运行。我在这个假设中是否正确？欢迎提出建议。

如果您试图保护与您共享访问权限的人

到同一台服务器，那么您就是可能搞砸了。


Gordon L. Burditt

首先，打开一个php文件不会告诉你PHP代码。只有

显示了php脚本运行后的结果。 ftp应该是

密码保护，没有人，但你会有这个密码。


我发现放在document_root上面的感知文件工作

很像你提到过的。以下是它的完成方式：

/ usr / local / apache / htdocs /是doc root。

创建/ usr / local / apache / incfiles / dir保存敏感文件，db

连接srcipts，用户/传递信息等。用户无法直接访问这些文件，因为他们不在doc root。此目录中的文件是

与include（）或require（）函数一起使用。用户不需要这个文件夹的

权限，因此不需要特殊权限。

apache用户（通常是nobody）将访问这些文件。


例如：

/usr/local/apache/htdocs/verifylogin.php是一个你可以猜到的页面

它的确如此。 />
我想要包含（）脚本

" /usr/local/apache/incfiles/chkpass.inc.php"在verifylogin.php中，

连接数据库并检查客户端用户名密码。


verifylogin.php ...


<？php

包括''../ incfiles / chkpass.inc.php'';

？>

< html>

< body>

<？php

如果用户/通行证正确

如果用户/通行证失败，请显示此



显示此

？>

< / body>

< / html>


如果您查看verifylogin.php的来源，您将看到没有PHP代码而且没有

路径/引用/usr/local/apache/incfiles/chkpass.inc.php。

Gordon Burditt写道：

我对PHP比较陌生。对我来说很明显的事情之一（来自C / C ++背景）是开放的一切似乎是什么 -
（AFAIK）。例如，URL通常具有他们正在调用的php脚本的名称 - 也只是查看大多数网页的来源
将向您展示辉煌的细节，任何PHP脚本的路径和名称<他们可能正在使用。

HTML是可见的。通过HTTP看不到PHP代码。

错误！确实是这种安全的悠闲方法（以及一般的b / b
编程）让我担心脚本编写和编写脚本语言b
语言。我在短短两天内一直在使用PHP，我看到一个

显而易见的安全''漏洞'，你随便告诉我PHP代码不是
通过PHP可见 - 试试这个大小：


在你的shell /命令提示符下输入这个，看看你得到了什么：


GET http：//yourhostname/notsecure.php HTTP / 1.1

如果要实现用户授权（或任何其他需要保密的逻辑模块）

如果* logic *需要保密，它可能是一个安全漏洞。

wtf你在说什么？为什么你想让整个世界知道

你如何验证用户（如果你是那样的话，你也可以将你所有的b / b $ b用户名/密码发布到互联网上关于安全性的松懈。

在一个PHP模块中（除了包含脚本 - 它有自己的陷阱） - 没有意义这样一个模块（脚本或脚本集）明显可见/可访问用户 - 他们可以在闲暇时检查您的用户身份验证等，

如果你在谈论一个带有Web浏览器的远程用户，他们不能*在闲暇时检查您的PHP代码。

真的吗？看看我对你的第一个答案的回答。

同时啜饮他最喜欢的饮料。什么是让用户无法使用
脚本以便他们不能简单地FTP或获取你的脚本的方法 - 给出路径和文件名已经提供了？

确保您提供* NO *路径，用户只需获取受保护的文件而无需进行身份验证。通常使用PHP页面来检查用户的身份验证，如果确定，则输出Content-type：标头，然后使用

这看起来更像是它。但它绕过这个问题。你在哪里

保留用于验证用户身份验证的PHP？ （这正是我首先要提出的问题）。

我想我记得在某处读取这与设置
文件权限有关 - 例如将脚本放在
Web服务器doc根目录下方。但这就引出了一个问题：如果用户对保存php文件的文件夹没有任何意义 - 他怎么能执行它们。实际上，最后一句话让我意识到围绕这个（可能？）的方式是让Apache作为与web客户端不同的用户运行。我在这个假设中是否正确？欢迎提出建议。

如果你试图保护那些与你同一台服务器共享访问权限的人，你可能会被搞砸了。

是的，但是解决这个问题并不费脑筋（只需使用专用服务器）。
Gordon L. Burditt

I am relatively new to PHP. One of the things that seems glaring obvious
to me (coming from a C/C++ background) is how ''open'' everything seems -
(AFAIK). For instance, URLs typically have the name of the php script
that they are calling - also just viewing the source of most web pages
will show you in glorious detail, the paths and names to any PHP scripts
they may be using.

If one was to implement user authorisation (or any other module whose
logic needs to be kept private) in a PHP module (apart from encypting
the script - which has its own pitfalls) -it makes no sense in having
such a module (script or set of scripts) plainly visible/accesible to
the user - who can inspect your user authentication etc at leisure,
whilst sipping his favourite beverage. What is the way to keep your
script inacesible to users so that they cannot simply FTP or GET your
script - giving that the path and file name has been kindly provided?

I think I remember reading somewhere that this is to do with setting
file permissions - for example placing the scripts in afolder above the
web server doc root. But this begs the question that if the user has no
permision to the folder where the php files are kept - how can he
execute them. Actually, the last sentence made me realise that the way
around this (may?) be to have Apache run as a different user from the
web client. Am I correct in this assumption?. Suggestions welcome.

解决方案

>I am relatively new to PHP. One of the things that seems glaring obvious

to me (coming from a C/C++ background) is how ''open'' everything seems -
(AFAIK). For instance, URLs typically have the name of the php script
that they are calling - also just viewing the source of most web pages
will show you in glorious detail, the paths and names to any PHP scripts
they may be using.
HTML is visible. PHP code isn''t visible via HTTP.
If one was to implement user authorisation (or any other module whose
logic needs to be kept private)
If the *logic* needs to be kept private, it''s probably a
security hole.
in a PHP module (apart from encypting
the script - which has its own pitfalls) -it makes no sense in having
such a module (script or set of scripts) plainly visible/accesible to
the user - who can inspect your user authentication etc at leisure,
If you''re talking about a remote user with a web browser, they
*cannot* inspect your PHP code at their leisure.
whilst sipping his favourite beverage. What is the way to keep your
script inacesible to users so that they cannot simply FTP or GET your
script - giving that the path and file name has been kindly provided?
Ensure that you provide *NO* path where a user can simply GET your
protected files without authenticating. This is typically done
with a PHP page which checks the user''s authentication, and if it''s
OK, outputs a Content-type: header, then does a fpassthru() using
a file name *outside the document tree*.
I think I remember reading somewhere that this is to do with setting
file permissions - for example placing the scripts in afolder above the
web server doc root. But this begs the question that if the user has no
permision to the folder where the php files are kept - how can he
execute them. Actually, the last sentence made me realise that the way
around this (may?) be to have Apache run as a different user from the
web client. Am I correct in this assumption?. Suggestions welcome.

If you are attempting to protect against someone who is sharing access
to the same server as you are, you''re probably screwed.

Gordon L. Burditt

To start off with, opening a php file won''t show you php code. It only
shows the results of the php script after it''s run. ftp should be
password protected, no one but you will have this password.

I''ve found that placing sensetive files above document_root works
nicely like you''ve mentioned. Here''s how it''s done:
/usr/local/apache/htdocs/ is the doc root.
Make a /usr/local/apache/incfiles/ dir to keep sensitive files, db
connect srcipts, user/pass info, etc. Users have no direct access to
these files since they''re not in the doc root. Files in this dir are
used with the include() or require() functions. Users don''t need
permission to this folder so there are no special permissions required.
The apache user (usually nobody) will access the files.

example:
/usr/local/apache/htdocs/verifylogin.php is a page you can guess what
it does.
I want to include() the script
"/usr/local/apache/incfiles/chkpass.inc.php" in verifylogin.php that
connects to the db and check the clients username password.

verifylogin.php...

<?php
include''../incfiles/chkpass.inc.php'';
?>
<html>
<body>
<?php
if user/pass correct
show this
if user/pass failed
show this
?>
</body>
</html>

If you view source of verifylogin.php you''ll see no php code and no
path / reference to /usr/local/apache/incfiles/chkpass.inc.php.

Gordon Burditt wrote:

I am relatively new to PHP. One of the things that seems glaring obvious
to me (coming from a C/C++ background) is how ''open'' everything seems -
(AFAIK). For instance, URLs typically have the name of the php script
that they are calling - also just viewing the source of most web pages
will show you in glorious detail, the paths and names to any PHP scripts
they may be using.

HTML is visible. PHP code isn''t visible via HTTP.

WRONG !. It is EXACTLY this kind of laid back approach to security (and
programming in general) that lets me worry about scripters and scripting
languages. I have been playing around with PHP in just 2 days, I see an
obvious security ''hole'' and you casually tell me that PHP code isn''t
visible via PHP - well try this for size:

type this at your shell/command prompt and see what you get back:

GET http://yourhostname/notsecure.php HTTP/1.1

If one was to implement user authorisation (or any other module whose
logic needs to be kept private)

If the *logic* needs to be kept private, it''s probably a
security hole.

wtf are you talking about?. Why would you want the whole world to know
how you authenticate users (you may just as well publish all your
usernames/passwords onto the internet if you''re that lax about security).

in a PHP module (apart from encypting
the script - which has its own pitfalls) -it makes no sense in having
such a module (script or set of scripts) plainly visible/accesible to
the user - who can inspect your user authentication etc at leisure,

If you''re talking about a remote user with a web browser, they
*cannot* inspect your PHP code at their leisure.

Really ?. See my response to your first answer.

whilst sipping his favourite beverage. What is the way to keep your
script inacesible to users so that they cannot simply FTP or GET your
script - giving that the path and file name has been kindly provided?

Ensure that you provide *NO* path where a user can simply GET your
protected files without authenticating. This is typically done
with a PHP page which checks the user''s authentication, and if it''s
OK, outputs a Content-type: header, then does a fpassthru() using
a file name *outside the document tree*.

This seems more like it. But it skirts around the issue. Where do you
keep the PHP which ckecks the user''s authentication? (this was precisely
my question in the first place).

I think I remember reading somewhere that this is to do with setting
file permissions - for example placing the scripts in afolder above the
web server doc root. But this begs the question that if the user has no
permision to the folder where the php files are kept - how can he
execute them. Actually, the last sentence made me realise that the way
around this (may?) be to have Apache run as a different user from the
web client. Am I correct in this assumption?. Suggestions welcome.

If you are attempting to protect against someone who is sharing access
to the same server as you are, you''re probably screwed.

True, but its a no brainer to solve that one (just use a dedicated server).
Gordon L. Burditt

这篇关于权限和脚本'可见性'的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！