Выполнять HTTP-аутентификацию по HTTPS с перезаписью URL

Question

Я пытаюсь защитить каталог ~/public_html/dev с помощью http auth basic, но для обеспечения безопасности я хочу запустить его через ssl.

Средняя часть файла .htaccess ниже переключается на https, если URI запроса начинается с /dev и работает.

Последний раздел файла также работает, но не работает должным образом с перенаправлением https.

Я в основном хочу иметь возможность набрать http://www.example.com/dev/some_sub_dir/ и быть перенаправленным на https://www.example.com/dev/some_sub_dir/ и запросить http имя пользователя и пароль для аутентификации.

В настоящее время происходит, если я перехожу на http://www.example.com/dev/some_sub_dir/, когда меня запрашивают имя пользователя и пароль через порт 80, а затем сразу же снова запрашивают через порт 443. Поэтому мои учетные данные отправляются дважды, один раз в открытом виде, и однажды зашифрован. Заставлять весь https переписывать немного бессмысленно.

Причина этого заключается в том, что я не смогу случайно отправить своего пользователя / передать по http; https всегда будет использоваться для доступа к каталогу /dev.

.htaccess находится в каталоге ~/public_html/dev.

# Rewrite Rules for example.com
RewriteEngine On
RewriteBase /

# force /dev over https
RewriteCond %{HTTPS} !on
RewriteCond %{REQUEST_URI} ^/dev
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}

# do auth
AuthType Basic
AuthName "dev"
AuthUserFile /home/matt/public_html/dev/.htpasswd
Require valid-user

Answer 1

Существует довольно популярный способ взлома HTTPS перед выполнением базовой аутентификации. Я впервые увидел это здесь:

http://blog.jozjan.net/2008/02/htaccess-redirect-to-ssl-https-before.html

Он включает использование пользовательского документа об ошибках для обработки всего, что происходит после сбоя проверки HTTPS.

Например, у меня есть одна страница, на которой мне нужно включить HTTPS, поэтому я сделал это в файле .htaccess:

<FilesMatch "secure-page.php">
    SSLRequireSSL
    ErrorDocument 403 https://www.example.com/secure-page.php
    AuthType Basic
    AuthName "Secure Page"
    AuthUserFile /var/www/whatever/.htpasswdFile
    Require valid-user
</FilesMatch>

Что означает:

если запрашиваемой страницей является «secure-page.php» - если не HTTPS, то перенаправить на пользовательскую «страницу ошибок» - «страница ошибок» на самом деле является просто версией HTTPS страницы - во втором запросе, поскольку проверка HTTPS теперь проходит, выполните Basic Auth:)

Вы можете распространить эту концепцию на каталог или другие варианты использования - вашей пользовательской «страницей ошибок» может быть страница php, которая перенаправляет на правильный URL-адрес HTTPS, или скрипт CGI, как в приведенной выше ссылке ...

Answer 2

Основываясь на ответе silicrockstar, я добавляю сценарий php, который будет работать в том случае, если вы хотите принудительно установить SSL для всех файлов, а не только в случае с одним файлом, показанном silicrockstar.Здесь снова он работает в сочетании с файлом htaccess.

htaccess для защиты всего каталога:

    SSLRequireSSL
    ErrorDocument 403 /yourphp.php
    AuthType Basic
    AuthName "Secure Page"
    AuthUserFile /some_path_above_the_html_root/.htpasswdFile
    Require valid-user

php, вызываемый htaccess (путь, указанный для php в этом примереhtaccess - это корень вашего сайта), который вызывает https для URL, который вы назвали:

<?php
$path = "https://".$_SERVER['SERVER_NAME'].$_SERVER['REQUEST_URI'];
if ( $_SERVER['SERVER_PORT'] == 80) {
    header("Status: 302 Moved\n");
    header("Location: ".$path."\n\n");
}
else {
    header( "Content-type: text/html\n\n");
    echo "How did you get here???";
}
?>

Если у вашего сайта нет SSL-сертификата, вам придется установить его.Если это ваше единственное использование, вы можете установить самозаверяющий сертификат.На VPS cPanel с вашим сайтом на выделенном IP-адресе на это уходит несколько минут: в WHM посетите страницу

One.Сгенерируйте SSL-сертификат и запрос на подпись

, затем

Two.Установить сертификат SSL на домен

Answer 3

Я столкнулся с той же проблемой и, наконец, нашел уродливое решение, но оно работает. Поместите правило перезаписи в директиву Directory в httpd.conf или в один из ваших файлов conf.d (т. Е. В конфигурации сервера «Main»). Затем поместите строки Auth * и Require в директиву Directory внутри контейнера <VirtualHost _default_:443> в ssl.conf (или там, где определен ваш SSL VirtualHost).

Для меня это означает создание файла /etc/httpd/conf.d/test.conf с:

<Directory "/var/www/html/test">
        #
        # force HTTPS
        #
        RewriteEngine On
        RewriteCond %{HTTPS} off
        RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}
</Directory>

... и затем добавляем следующее внутри /etc/httpd/conf.d/ssl.conf чуть выше тега </VirtualHost>:

<Directory "/var/www/html/test">
        #
        # require authentication
        #
        AuthType Basic
        AuthName "Please Log In"
        AuthUserFile /var/www/auth/passwords
        Require valid-user
</Directory>

Благодаря этому Apache применяет RewriteRule ко всем запросам, а требования к аутентификации - только к запросам в 443 VirtualHost.

Answer 4

Защита контента с помощью обычной аутентификации никогда не будет работать надежно через HTTP.

Как только пользователь ввел свое имя пользователя и пароль, он отправляется в незашифрованном виде при каждом просмотре страницы на этом сайте - он отправляется не только в тот момент, когда пользователю предлагают.

Вы должны обрабатывать запросы через HTTP как не прошедшие проверку подлинности, и все входить в систему через HTTPS.

Многие веб-сайты использовали HTTPS для входа в систему - используя формы и файлы cookie, а не базовую аутентификацию - и затем переходят к HTTP. Это означает, что их cookie «Вы вошли в систему» ​​отправляются в незашифрованном виде. Все ценные цели были взломаны из-за этого, и теперь gmail переходит на полный HTTPS, и другие последуют за ним.

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

Answer 5

Если вы поместите правила перезаписи в основную конфигурацию, вне каких-либо или аналогичных, перезапись будет выполняться перед аутентификацией.

См. Переписать Tech

Answer 6

У меня есть два ответа на этот вопрос, один с мышлением 2010 года, а другой с мышлением после 2012 года.

Чтобы ответить на этот вопрос, как будто это был 2010 год, когда его спросили: используйте две разные конфигурации VirtualHost.

Это решение немного выходит за рамки вопроса, поскольку подразумевается, что "у меня есть доступ только для изменения .htaccess!" но жизнеспособное решение во многих случаях состоит в том, чтобы попросить администратора du jour просто настроить две разные конфигурации VirtualHost.

• VirtualHost без SSL не настроен для доступа к чему-либо в файловой системе и просто возвращает перенаправления 301 в https://... местоположения для всех запросов.

• В этом случае прослушивающий SSL VirtualHost теперь может бесплатно реализовать базовую аутентификацию, не беспокоясь о том, что стандартный прослушиватель HTTP выдаст товар.

Тем не менее, с моей шляпой после 2018 года и с учетом того, что этот вопрос задавался до Apache 2.4 (начало 2012 года?), Пришло время для обновления. В Apache 2.4 введены <If condition> проверки, что делает это намного проще и понятнее:

• Во-первых, не делайте IfModule RewriteEngine. Поскольку Apache прослушивает порты 80 и 443 (в стандартной настройке), и мы хотим принудительно использовать SSL, мы хотим, чтобы сервер сломался, если модуль Rewrite отключен.

  RewriteEngine On 
  

• Во-вторых, достаточно просто выполнить немедленное и постоянное (301) перенаправление, если запрос не защищен. Обратите внимание, что R (edirect) и L (ast) работают вместе, чтобы гарантировать, что незашифрованные запросы перенаправляются и не могут быть использованы для получения доступа без аутентификации. (Для OCD, не склонного к копированию и вставке, учтите, что не хватает пробела между != и on. Это сделано намеренно.)

  RewriteCond %{HTTPS} !=on 
  RewriteRule .* https://%{SERVER_NAME}%{REQUEST_URI} [R=301,QSA,L,NC]
  

• Наконец, используйте эту же переменную с проверкой <If-condition>, чтобы гарантировать, что нам требуется только пароль для запроса TLS.

  <If "%{HTTPS} == 'on'">
          AuthName "Password please!" 
          AuthType Basic 
          AuthUserFile /path/to/htpasswdfile
          AuthGroupFile /dev/null 
          require valid-user
  </If>
  

И всего:

# .htaccess

RewriteEngine On

RewriteCond %{HTTPS} !=on
RewriteRule .* https://%{SERVER_NAME}%{REQUEST_URI} [R=301,QSA,L,NC]

<If "%{HTTPS} == 'on'">
        AuthName "Password please!"
        AuthType Basic
        AuthUserFile /path/to/htpasswdfile
        AuthGroupFile /dev/null
        require valid-user
</If>

Answer 7

Я знаю, что это старый вопрос, но у меня были проблемы с простым перенаправлением ht.access. После многих других проблем и ответов я наконец собрал этот htaccess, который работает как задумано.

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}

AuthName "Private Server"
AuthUserFile /var/www/.htpassword
AuthType Basic
require valid-user
Order allow,deny
Allow from env=!HTTPS
Satisfy Any

отметить

Order allow,deny

Чего не хватает во многих других ответах, которые я видел, так как это позволило бы людям напрямую использовать https Другой раздел, который отсутствовал в моих тестах, был следующим:

Satisfy Any

В следующем фрагменте разрешено использование клиентов без SSL для перенаправления. HTTPS env var устанавливается из mod_ssl для клиентов ssl.

Allow from env=!HTTPS

Answer 8

Я обхожу это таким образом. Просто разрешите Non-SSL, так как он будет перенаправлен, затем потребуется авторизация один раз для SSL ...

SetEnvIf %{SERVER_PORT} ^80$ IS_NON_SSL

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}

AuthUserFile /.htpasswd
AuthName "Enter your Username and Password:"
AuthType Basic
require valid-user
Allow from env=IS_NON_SSL

Answer 9

Работает ли помещение вашего раздела аутентификации в тег <Location> или <LocationMatch> с использованием протокола в качестве термина?