Як запобігти доступу до веб-сайту без підключення SSL?


11

У мене веб-сайт, на якому встановлений сертифікат SSL, так що якщо я заходжу на веб-сайт, використовуючи httpsзамість нього, httpя зможу підключитися за допомогою захищеного з'єднання.

Однак я помітив, що я все ще можу отримати безпечний доступ до веб-сайту, тобто. за допомогою httpзамість https.

Як я можу запобігти людям користуватися веб-сайтом незахищеним чином?

Якщо у мене на веб-сайті є каталог, наприклад. samples/, чи можу я запобігти незахищеним підключенням лише до цього каталогу?

Відповіді:


12

На жаль, єдине загальне рішення цієї проблеми - це дати своїм користувачам https://єдине і переконатися, що вони розраховують використовувати саме це. Зрештою, користувач повинен перевірити, що вони використовують SSL / TLS, як вони очікують.

Інші рішення є вразливими для атак людини в середині, навіть якщо веб-сайт приймає тільки з'єднання SSL / TLS. Зловмисники можуть перехопити трафік http://example.com(як того вимагає користувач, навіть якщо example.comвін навіть не слухає цей порт) і замінити його, встановивши власне з'єднання https://example.com, проксі-сервер його назад до користувача.

Через це існувало правило OWASP проти автоматичних переадресацій. Це було знято, ймовірно, тому що перенаправлення не є поганим способом зменшити ризик (особливо щодо пасивних підслуховувачів), але не вирішити принципову проблему.

Існують різні методики, якими ви можете скористатись для того, щоб орієнтувати користувача на сайт HTTPS, і не погано їх використовувати (хоча це не захистить їх від активних MITM-зловмисників).

По-перше, якщо у вас немає нічого, що взагалі повинно подаватися у звичайному HTTP на веб-сервері, вимкніть порт 80 (наприклад, видаліть Listen 80у конфігурації Apache Httpd). Користувачам доведеться користуватися https://постійно, що може бути незручно.

По-друге, у розділі конфігурації Apache Httpd для певного шляху (або Locationабо Directory) використовуйте SSLRequireSSLдирективу : вона вимагатиме використання SSL / TLS (навіть якщо ви фактично налаштували її на альтернативному порту). На інших веб-серверах, ймовірно, є подібні директиви.

По-третє, ви можете використовувати перенаправлення, використовуючи mod_rewriteабо в коді (якщо це програма). Щось подібне слід зробити для певного місця ( див. HTTPSСпеціальну змінну ; можна використовувати і 302, але 301 краще, якщо це буде більш постійним):

RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^(samples/.*)$ https://example.com/$1 [R=301,L]

Що ще важливіше, переконайтеся, що використовуються всі посилання на безпечний розділ https://. Ніколи не покладайтеся на автоматичне перенаправлення, щоб зробити роботу за вас. З цієї причини я б рекомендував взагалі не використовувати його на етапі розробки .

Однак я помітив, що я все ще можу отримати безпечний доступ до веб-сайту, тобто. за допомогою httpзамість https.

Це також здається, що ви використовуєте однакову конфігурацію і для, httpі для https. Якщо ви використовуєте Apache Httpd, я б запропонував розділити конфігурацію на два різних VirtualHosts: один для порту 80 і один для порту 443. Вони не повинні мати точно однакову конфігурацію: просто не вкладайте те, що тільки для HTTPS у віртуального хоста HTTP взагалі.


Спосіб усунення вищезгаданих проблем - це використання суворої безпеки HTTP-транспорту для браузерів, які його підтримують (наскільки я знаю, це стосується всього хоста). Перше підключення може все-таки виявитись, якщо https://воно не використовується без перенаправлення, але можливий попередньо завантажений список сайтів, які очікують у https:// будь-якому випадку (і увімкнено для HSTS).


Хороша інформація, як це робить Gmail? - з вигляду речей, які вони змушують https.
toomanyairmiles

3
Вони використовують перенаправлення. Це добре працює за умови, що ви, як очікує користувач, це буде https://mail.google.com. Якщо, як користувача, ви бачите, що він працює з ним http://mail.google.com, ймовірно, є MITM, що супроводить запити справжньому https://mail.google.com. На жаль, Gmail не може з цим зробити багато, якщо користувачі самі не перевіряють. Той самий принцип, що і в реальному житті: якщо Аліса хоче поговорити з Боб, але розмовляє з Чак (який стверджує, що є Боб) замість того, щоб перевірити посвідчення особи, Боб не дізнається про цю розмову і не зможе зробити нічого про це. Це відповідальність Аліси.
Бруно

Я бачив деякі сценарії PHP навколо того, що він перевірить, чи підключений він до HTTPS і перенаправить, якщо не використовує SSL на адресу HTTPS. Це, звичайно, непросте завдання, якщо ви зараз не будуєте свій сайт.
Анонімний пінгвін

@AnnonomusPerson, це точно той же принцип, і саме це робить правило перезапису з HTTP на HTTPS. Незалежно від того, чи це ви робите програмно, чи за конфігурацією, не має значення, це все одно перенаправлення з початковим запитом у звичайному HTTP, що представляє ту ж проблему.
Бруно

3

Все, що вам потрібно, - це перенаправлення http-трафіку на https - див. Цю статтю "Перенаправлення http на безпечне з'єднання https Apache - примусові з'єднання HTTPS" .

Для підкаталога розмістіть це у файлі htaccess у самому каталозі.

RewriteEngine on
RewriteCondition %{SERVER_PORT} !^443$
RewriteRule ^(.*)$ https://www.maindomain.com/directory/$1 [R=301,L] 

Чи можете ви зробити це лише для певних підкаталогів?
CJ7

@CraigJ Вибачте, пропустила частину підкаталогу, відповідь оновлена.
toomanyairmiles

3
Хоча це трохи зменшує ризики, це не працює проти активних нападників MITM.
Бруно

0

Примусовий доступ через HTTPS насправді можливий, окрім необхідного кроку у створенні вашого сайту MITM-, snooper- та PEBKAC-стійкого. Це не повинно бути відповідальністю користувача, це не працює . Заохочуйте своїх користувачів використовувати захищені веб-переглядачі.

Примушування HTTPS здійснюється через HSTS ( HTTP Strict-Transport-Security ). Базовий HSTS захищений після першого доступу користувача до вашого веб-сайту через HTTPS (у всіх підтримуваних браузерах; IE не має можливості ). Попередньо завантажений HSTS завжди захищений та охоплює сучасні браузери з швидким випуском (Chromium та похідні, Firefox).

Щоб отримати більш повний огляд безпеки HTTP (адресація URL-адрес, переадресацій, файлів cookie та змішаного вмісту), див. Інструкцію щодо міграції HTTPS . HSTS - це останній крок у прогресивній міграції. Вам не потрібно стежити за порядком, якщо ваш сайт абсолютно новий.

Пов'язані стандарти: захищені файли cookie (важливо, якщо ваші файли cookie живуть довше, ніж заголовок HSTS), файли cookie HttpOnly (поки ви захищаєте свої файли cookie), HPKP (для сучасних браузерів та більш спритних зловмисників).

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.