我在 Ubuntu 12 上运行 LAMP 堆栈,其主要功能是提供基于 PHP 的 API。
我只想向公众公开一个文件,名为:api.php
它需要引用我拥有的配置文件,/cfg/api-config.php
其中包含数据库密码,以便 API 可以写入数据库等。
所以我只希望api.php
apache 被“服务”并公开。
我放入 /cfg 的配置文件必须可以被 api.php 读取,但不能被任何可能访问该站点的人读取。
我没有.htaccess
,只是httpd.conf
按照下面的配置。
<VirtualHost *:44448>
DocumentRoot "/api"
ServerName localhost:44448
ServerAlias Server.local
DirectoryIndex index.html
CustomLog "/var/log/apache_access.log" combined
ErrorLog "/var/log/apache_error.log"
SetEnv APPLICATION_ENV development
php_flag magic_quotes_gpc off
<Directory "/api">
Options Indexes MultiViews FollowSymLinks
AllowOverride All
Order allow,deny
Allow from all
</Directory>
</VirtualHost>
我的/cfg
和/api
文件夹的权限是:我的敏感配置文件的drwxr-xr-x
权限和数据库密码位于/cfg/api-config.php
-rw-r--r--
我想知道是否有人可以告诉我这是否设置正确且安全?
借此:
A)除 之外的所有文件/api/api.php
都不是公开的,并且无法访问我的服务器文件。
B)任何访问该站点的人也无法读取带有 db 密码(用于 api)的配置文件?
我试图通过在/cfg
with中创建一个新文件夹来测试这一点chmod 777
,但我似乎无法访问它,这很好!
您有两个文件(假设它们位于 /var/www)
首先,使用 apache 限制对 /cfg 的访问(这确保没有人可以从 http 访问它)并允许访问 /api:
接下来,使用 open_basedir 限制您的 php:
(如果需要,在此处添加 /tmp、session 和其他目录)
接下来,更改 /var/www/cfg 目录和 /var/www/cfg/api-config.php 文件的访问模式(假设您的 apache 用户是 www-data):
通过在 /cfg 上使用711,您可以确保没有人可以读取(列出)目录的内容,同时仍然可以读取 api-config.php(您需要这个来通过 PHP 读取文件)
首先,我将更改您的 cfg 的文件权限以及驻留在其中的文件。如果您将 DB - 设置存储在其中,这是一个读取访问权限,并且应该删除写入访问权限。很高兴您的 Apache HTTP 守护程序 - 环境设置安全,但这是另一层安全性。你的 PHP - 安装在你的 HTTP - 守护进程的用户上下文中运行,所以我个人什至会删除该组的读取权限。我想知道你进行的测试。cfg - 文件夹似乎不在您的 DocumentRoot 下,因此乍一看您的 HTTP - Server 似乎无法访问它。但是试图闯入您的安装的人不会依赖这种方法。您的配置中有 AllowOverride All Order allow,deny Allow from all 这只是意味着:根本没有访问控制。您还声明了 FollowSymLinks,它引入了其他安全影响。所以这个安装远远落后于安全。您可以通过在安装的 DocumentRoot 中放置一个 .htaccess 文件来保护您的 cfg 文件夹。其中的条目可以极大地保护文件和目录访问,例如
<Files RELEASE_NOTES.txt>
命令允许,拒绝
所有
</Files> (取自 magento - 安装)
如果您想知道 FollowSymLinks 的安全影响:请记住 PHP 在您的 Apache HTTP 守护程序安装的上下文中运行,并且 PHP 可以在您的文件系统上执行写入操作。如果 PHP - 代码被插入到您的应用程序中创建符号链接,以便有人可以通过创建符号链接到他或她感兴趣的系统部分来监视您的文件系统。将一个简单的 .htaccess - 文件放入您的 cfg - Order allow,deny Deny from all 形式的目录将删除通过 HTTP 守护程序浏览此目录的能力。如果您的 api.php 是您的 PHP - Installation / Webapp 的前端控制器,您应该考虑使用 Apache 的 mod_rewrite 重写所有请求指向您的 api.php 的 URL,例如
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI} !=/favicon.ico
RewriteRule ^ api.php [L]
在 .htaccess - 文件中,您放置在 /api - 目录中,该目录会将所有请求路由到您的 api.php。例如 localhost:44448/someURL?id=988 将在内部成为请求 localhost:44448/api.php?id=988 。
澄清:
重写-规则不应该用于访问-控制,它们的主要目的是改变请求的处理方式。
许多 PHP - 框架或 CMS 使用 RewriteRules 来为 Web 应用程序提供一个中央入口点,在该入口点处加载应用程序组件,可以调用路由组件,并执行从 URL 参数到内部结构的转换。
例如 Symfony2 将 Query / 和 Post 参数转换为更面向对象的结构,将其封装成一个对象。
Symfony2 还通过在生成 HTTP 响应之前读取路由信息和配置来利用安全概念,例如确保已执行身份验证或用户必须具有正确的用户角色才能访问 URL 路径。
您似乎已经完成了一件关键的事情,那就是放在
/cfg/api-config.php
DocumentRoot 之外。如果/cfg
不在 URL 空间内,则网站用户无法阅读。这是您可以采取的最基本的预防措施。用户仍然可以读取该文件吗?当然,如果您在其他地方破坏了配置(例如,通过设置文件的
Alias
orRewriteRule
),或者如果应用程序做了一些愚蠢的事情,比如输出文件的内容。应用程序漏洞是真正值得关注的问题:应用程序必须能够读取文件,并且应用程序越复杂,就越有可能隐藏漏洞。但就 Apache 配置而言,我认为你已经完成了。除了上述建议之外,我建议您删除对您的 apache 用户拥有的 DocumentRoot 中的任何文件/文件夹的写访问权限。(例如您的 api.php 文件)这假定 api.php(或它调用的任何东西)不需要向本地 Web 服务器写入任何内容。这应该有助于防止不需要的文件被写入您的 Web 服务器