Использование PHP / Apache для ограничения доступа к статическим файлам (html, css, img и т. Д.)

Question

Допустим, у вас есть много файлов html, css, js, img и т. Д. В каталоге на вашем сервере.Обычно любой пользователь в сети Интернет может получить доступ к этим файлам, просто набрав полный URL-адрес примерно так: http://example.com/static-files/sub/index.html

Теперь, что если вы хотите, чтобы только авторизованные пользователи могли загружать эти файлы?В этом примере предположим, что ваши пользователи сначала входят в систему с URL-адреса, подобного следующему: http://example.com/login.php

Как разрешить вошедшему в систему пользователю просматривать файл index.html (или любой из файлов в разделе «static»)?-files "), но ограничить доступ к файлу для всех остальных?

Пока что я нашел два возможных решения:

Решение 1
Создайте следующееФайл .htaccess в разделе «static-files»:

Options +FollowSymLinks  
RewriteEngine on  
RewriteRule ^(.*)$ ../authorize.php?file=$1 [NC]

А затем в authorize.php ...

if (isLoggedInUser()) readfile('static-files/'.$_REQUEST['file']);
else echo 'denied';

Этот файл authorize.php сильно упрощен, но вы получаетеидея.

Решение 2
Создайте следующий файл .htaccess в "static-files":

Order Deny,Allow
Deny from all
Allow from 000.000.000.000

И тогда моя страница входа может добавить, чтоФайл .htaccess с IP-адресом для каждого пользователя, который входит в систему. Очевидно, что для удаления старых или более неиспользуемых IP-адресов также потребуется некоторая процедура очистки.

Я беспокоюсь, что мое первое решение может стоить довольно дорого на сервере, так как увеличивается количество пользователей и файлов, к которым они обращаются.Я думаю, что мое второе решение будет гораздо менее дорогим, но также менее безопасным из-за подмены IP-адреса и т. Д. Я также беспокоюсь о том, что запись этих IP-адресов в файл htaccess может стать узким местом приложения, если одновременно существует много пользователей.

Какое из этих решений звучит лучше и почему?В качестве альтернативы, вы можете придумать совершенно другое решение, которое будет лучше, чем любое из них?

Answer 1

Я хотел бы рассмотреть возможность использования загрузчика PHP для обработки аутентификации, а затем вернуть нужные вам файлы. Например, вместо того, чтобы делать <img src='picture.jpg' /> Сделайте что-то вроде <img src='load_image.php?image=picture.jpg' />.

Ваш загрузчик изображений может проверять сеансы, проверять учетные данные и т. Д., А затем решать, возвращать ли запрошенный файл в браузер. Это позволит вам хранить все ваши защищенные файлы вне корневого каталога, доступного через Интернет, поэтому никто не собирается просто WGET их или просматривать «случайно».

Просто не забудьте вернуть правильные заголовки в PHP и сделать что-то вроде readfile () в php, и это вернет содержимое файла в браузер.

Я использовал эту настройку на нескольких крупных защищенных веб-сайтах, и она работает как шарм.

Редактировать: система, которую я сейчас создаю, использует этот метод для загрузки Javascript, изображений и видео, но CSS мы не очень беспокоимся о безопасности.

Answer 2

X-Sendfile

Есть модуль для Apache (и других HTTP-серверов), который позволяет вам указать HTTP-серверу, чтобы он обслуживал файл, указанный вами в заголовке в вашем php-коде: так что ваш php-скрипт должен выглядетьнапример:

// 1) Check access rights code
// 2) If OK, tell Apache to serve the file
header("X-Sendfile: $filename");

2 возможных проблемы:

1. Вам необходим доступ к правилам перезаписи (включен .htaccess или прямой доступ к файлам конфигурации)
2. Вам нужен mod_xsendfileмодуль добавлен в ваш установленный Apache

Вот хороший ответ в другой теме: https://stackoverflow.com/a/3731639/2088061

Answer 3

Я много думал об одной и той же проблеме. Я одинаково недоволен движком PHP, работающим для каждого небольшого ресурса, который предоставляется. Я задал вопрос в том же духе несколько месяцев назад здесь , хотя и с другим фокусом.

Но у меня только что была ужасно интересная идея, что может работать.

• Поддерживайте каталог с именем /sessions где-нибудь на вашем веб-сервере.

• Каждый раз, когда пользователь входит в систему, создайте пустой текстовый файл с идентификатором сеанса в /sessions. Например. 123456

• В вашем приложении PHP раздайте изображения следующим образом: /sessions/123456/images/test.jpg

• В вашем файле htaccess есть две команды перенаправления.

• Тот, который переводит /sessions/123456/images/test.jpg в /sessions/123456?filename=images/test.jpg

• Второй, который перехватывает любые вызовы //sessions/(.*) и проверяет, существует ли указанный файл, используя флаг -f. Если /sessions/123456 не существует, это означает, что пользователь вышел из системы или истек срок его сеанса. В этом случае Apache отправляет 403 или перенаправляет на страницу ошибки - ресурс больше не доступен.

Таким образом, мы выполняем квазисессионную аутентификацию в mod_rewrite, выполняя только одну проверку "файл существует"!

Мне не хватает рутины для создания операторов mod_rewrite на лету, но их должно быть достаточно легко писать. (С надеждой смотрю в вашу сторону @Gumbo:)

Примечания и предостережения:

• Файлы сеансов с истекшим сроком действия пришлось бы быстро удалять с помощью задания cron, если только невозможно проверить mtime файла в .htaccess (что вполне возможно).

• Образ / ресурс доступен для любого клиента , пока существует сеанс, поэтому 100% защиты. Вы можете обойти это, добавив IP-адрес клиента в уравнение (= имя файла, которое вы создаете), и выполнить дополнительную проверку для% {REMOTE_ADDR}. Это расширенное мастерство .htaccess, но я уверен, что это выполнимо.

• Ресурсные URL-адреса не являются статичными и должны извлекаться каждый раз при входе в систему, поэтому кэширование не требуется.

Я очень заинтересован в обратной связи по этому вопросу, о любых недостатках или невозможностях, которые я мог упустить из виду, и о любых успешных реализациях (у меня сейчас нет времени, чтобы самому настроить тест).

Answer 4

Создайте карту перезаписи , которая проверяет учетные данные пользователя и перенаправляет их на соответствующий ресурс или на страницу «Отказано в доступе».

Answer 5

Сохранение содержимого файлов htaccess выглядит кошмаром. Кроме того, ваша заявленная цель состоит в том, чтобы предотвратить доступ к этому контенту неаутентифицированным пользователям , а не не аутентифицированным ip-адресам клиентов - поэтому подход не подходит для цели:

Может появиться несколько пользователей с одного IP-адреса

Сеанс одного пользователя может отображаться с нескольких адресов.

Я беспокоюсь, что мое первое решение может стоить довольно дорого на сервере, так как число количество пользователей и файлов, к которым они обращаются, увеличивается

Если вы хотите предотвратить выщелачивание вашего контента и не хотите использовать HTTP-аутентификацию, то единственный разумный выбор - обернуть весь доступ к файлам в дополнительный уровень логики. Кроме того, вы не знаете, что использование PHP для этого является проблемой - тестировали ли вы его? Я думаю, вы будете удивлены, какую пропускную способность он может обеспечить, особенно если вы используете кэш кода операции.

Полагаю, что ваше «упрощение» обертки решает такие проблемы, как тип MIME и кэширование.

С

Answer 6

У меня может быть предложение, основанное на iframe и HTTP_REFERER, но оно не является пуленепробиваемым, и оно будет зависеть от того, что именно вы хотите защитить этим доступом.

Но в случае предотвращения отображения полной статической страницы без аутентификации вы можете сделать следующее:

1 - использовать страницу PHP для аутентификации пользователя

2 - перенаправить на другую страницу PHP, содержащую ключ в URL и iframe, ссылающийся на статический контент в теле:

<iframe src="static/content.html" />

3 - Тогда в вашем htaccess вы можете проверить ключ внутри HTTP_REFERER следующим образом:

RewriteEngine On
RewriteCond %{HTTP_REFERER} !AUTH_KEY
RewriteCond %{REQUEST_URI} ^/path/to/protected/page$
RewriteRule . - [F]

4 - Наконец, если вы хотите сделать его более динамичным и не использовать один и тот же KEY каждый раз, когда вы можете использовать rewrite map, как предложено в ответе Игнасио Васкеса-Абрамса, или создать файл, используя IP-адрес пользователя в качестве имени файла, и проверьте, если файл существует с помощью REMOTE_ADDR, затем удалите файл через некоторое время.

Но имейте в виду, что поведение iframe + HTTP_REFERER может варьироваться от одного сеанса браузера к другому, а также от REMOTE_ADDR, поэтому оно ограничено ...

Answer 7

Предположим, что вы хотите защитить все ваши статические файлы , и вам нужно их сервер хранить внутри своего корня , вы можете защитить все HTTP-методы, кроме HEAD. Если вы авторизованы, вы отправляете запрос заголовка через заголовки и отправляете содержимое файла как тело. Конечно, это дорого, но вы защищены и у вас такое же поведение.

Answer 8

Если вы используете apache, вы можете настроить, как показано ниже, в файле .htaccess или httpd.conf. Ниже приведен пример предотвращения доступа к файлу * .inc. Это очень хорошо работает для меня.

<Files ~ "\.inc$">
Order allow,deny
Deny from all
</Files>

Более подробную информацию см. По адресу: http://www.ducea.com/2006/07/21/apache-tips-tricks-deny-access-to-certain-file-types/.

Answer 9

Я написал динамическое веб-приложение и развернул его на сервере приложений Webshere, и вот как я защищал свои статические файлы:

Я впервые добавил

<login-config id="LoginConfig_1">
  <auth-method>FORM</auth-method>
    <realm-name>Form-Based Authentication</realm-name>
      <form-login-config>
        <form-login-page>/login.html</form-login-page>
        <form-error-page>/login_error.html</form-error-page>
       </form-login-config>
</login-config>

в web.xml, который скажет вашему веб-серверу использовать аутентификацию на основе форм (код для входа в систему приведен ниже).

код для входа на страницу:

<form id="form1" name="form1" method="post" action="j_security_check" style="padding: 0px 0px 0px 12px;">
        Username: 
          <label>
          <input name="j_username" type="text" class="font2" />
        </label>

        <br />
        <br />
        Password:
        <span class="font2" >
        <label>
      <input name="j_password" type="password" class="font2" />
      </label>
      </span> 
        <br />
        <br />
            <label>
        <input type="submit"  class="isc-login-button" name="Login" value="Login" />
        </label>
    </form></td>

Чтобы войти в систему на основе форм, вы должны настроить свой веб-сервер на использование определенного реестра пользователей, который может быть LDAP или базой данных.

Вы можете объявить свои защищенные ресурсы, и каждый раз, когда пользователь пытается получить доступ к этим ресурсам, контейнер автоматически проверяет, аутентифицирован ли пользователь или нет. Даже вы можете назначать роли также с помощью защищенных ресурсов. Для этого я добавил следующий код в мой web.xml

<security-constraint>
        <display-name>Authenticated</display-name>
        <web-resource-collection>
            <web-resource-name>/*</web-resource-name>
            <url-pattern>/*</url-pattern>
            <http-method>GET</http-method>
            <http-method>PUT</http-method>
            <http-method>HEAD</http-method>
            <http-method>TRACE</http-method>
            <http-method>POST</http-method>
            <http-method>DELETE</http-method>
            <http-method>OPTIONS</http-method>
        </web-resource-collection>
        <auth-constraint>
            <description>Auth Roles</description>
            <role-name>role1</role-name>            
            <role-name>role2</role-name>            
        </auth-constraint>
    </security-constraint>

    <security-role>
        <role-name>role1</role-name>
    </security-role>
    <security-role>
        <role-name>role2</role-name>
    </security-role>

Таким образом, этот код не позволит пользователю видеть какой-либо статический файл (начиная с / *), пока он не войдет в систему под рольми role1 и role2. Таким образом, вы можете защитить свои ресурсы.