Co robi force_ssl w Railsach?


84

W poprzednim pytaniu dowiedziałem się, że powinienem ustawić zakończenie nginx ssl i nie zezwalać Railsom na przetwarzanie zaszyfrowanych danych.

Więc dlaczego istnieje następujące?

config.force_ssl = true

Widzę to zakomentowane w pliku konfiguracyjnym produkcji. Ale jeśli oczekuje się, że nginx obsłuży wszystkie rzeczy związane z SSL, aby moja aplikacja rails nie obsługiwała zaszyfrowanych danych, to co config.force_ssl = truezrobi?

Czy powinienem zostawić to zakomentowane w produkcji, jeśli wiem, że zawsze będę używać nginx?

Odpowiedzi:


77

Nie tylko zmusza przeglądarkę do przekierowania HTTP na HTTPS. Ustawia również pliki cookie jako „bezpieczne” i umożliwia HSTS , z których każdy zapewnia bardzo dobrą ochronę przed usunięciem SSL.

Mimo że HTTPS chroni Twoją aplikację pod adresemhttps://example.com/yourapp ” przed atakami MITM, jeśli ktoś znajdzie się między Twoim klientem a serwerem, może dość łatwo nakłonić Cię do odwiedzenia strony „ http://example.com/yourapp ” . Bez żadnej z powyższych zabezpieczeń Twoja przeglądarka z radością wyśle ​​sesyjny plik cookie do osoby wykonującej MITM.


1
Źródło force_ssl nie zawiera informacji o włączeniu HSTS przez tę opcję
agios

13
@agios To jest oddzielna force_sslwłaściwość dla każdego kontrolera . force_sslZmienna config, który instaluje Rack::SSLoprogramowanie warstwy pośredniej, która ma umożliwić TGV domyślnie .
Brent Royal-Gordon

@agios, szukasz w złym miejscu: github.com/rails/rails/blob/ ...
jmera

4
wygląda na to, że config.force_ssl = truepowinno być domyślne, dlaczego zespół railsowy skomentował to jako domyślne?
Henry Yang,

55

Ustawienie config.force_sslobejmuje ActionDispatch::SSL. Dokumenty ActionDispatch::SSLopisują funkcjonalność w następujący sposób (podkreślenia dodane dla przejrzystości):

Zobacz załączniki tutaj i dokumentację dotyczącą ActionDispatch :: SSL tutaj .

DOCS

To oprogramowanie pośredniczące jest dodawane do stosu, gdy config.force_ssl = trueopcje ustawione w programie są przekazywane i przekazywane config.ssl_options. Wykonuje trzy zadania, aby wymusić bezpieczne żądania HTTP:

  1. Przekierowanie TLS: na stałe przekierowuje żądania http: // do https: // z tym samym hostem URL, ścieżką itp. Domyślnie włączone. Ustaw config.ssl_options modyfikację docelowego adresu URL (np. redirect: { host: "secure.widgets.com", port: 8080 }) Lub redirect: falsewyłącz tę funkcję.

  2. Bezpieczne pliki cookie: ustawia secureflagę plików cookie, aby poinformować przeglądarki, że nie mogą być wysyłane wraz z żądaniami http: //. Domyślnie włączone. Ustaw za config.ssl_optionspomocą, secure_cookies: falseaby wyłączyć tę funkcję.

  3. HTTP Strict Transport Security (HSTS): nakazuje przeglądarce zapamiętać tę witrynę jako tylko TLS i automatycznie przekierowywać żądania inne niż TLS . Domyślnie włączone. Skonfiguruj za config.ssl_optionspomocą, hsts: falseaby wyłączyć. Ustaw za config.ssl_optionspomocą, hsts: { … }aby skonfigurować HSTS:

    • expires: Jak długo (w sekundach) te ustawienia będą obowiązywać. Domyślnie 180.days(zalecane). Minimalne wymagane do zakwalifikowania się do listy wstępnego ładowania przeglądarki to 18.weeks.
    • subdomains: Ustaw, aby truepoinformować przeglądarkę o zastosowaniu tych ustawień do wszystkich subdomen. Chroni to pliki cookie przed przechwyceniem przez wrażliwą witrynę w subdomenie. Domyślnie true.
    • preload: Reklamuj, że ta witryna może być uwzględniona na wstępnie załadowanych listach HSTS przeglądarek. HSTS chroni Twoją witrynę podczas każdej wizyty z wyjątkiem pierwszej wizyty, ponieważ nie widziała jeszcze Twojego nagłówka HSTS. Aby wypełnić tę lukę, dostawcy przeglądarek dołączają gotową listę witryn obsługujących HSTS. Przejdź do https://hstspreload.appspot.com, aby przesłać swoją witrynę do uwzględnienia. Aby wyłączyć HSTS, pominięcie nagłówka nie wystarczy. Przeglądarki będą pamiętać oryginalną dyrektywę HSTS do czasu jej wygaśnięcia. Zamiast tego użyj nagłówka, aby powiedzieć przeglądarkom, aby natychmiast wygaśnie HSTS. Ustawienie hsts: falseto skrót do hsts: { expires: 0 }.

Żądania można zrezygnować z przekierowania za pomocą exclude:

config.ssl_options = { redirect: { exclude: -> request { request.path =~ /healthcheck/ } } }

3
„Żądania mogą zrezygnować z przekierowania za pomocą exclude” - Ostrzeżenie: ta funkcja została dodana dopiero niedawno w Rails 5, więc nie będzie działać dla tych z nas, którzy korzystają z Rails 4.2 lub
starszych

1
Uważam, że excludeopcje globalne były dostępne na długo przed Railsami 5, więc ma nieco inną składnię: config.ssl_options = { exclude: proc { |env| env['PATH_INFO'].start_with?('/healthcheck/') } }- serverfault.com/a/517401
jwadsack

12

To ustawienie wymusza HTTPS, przekierowując żądania HTTP do ich odpowiedników HTTPS. Tak więc odwiedzający przeglądarkę http://domain.com/pathzostanie przekierowany do https://domain.com/path.

Pozostawienie ustawienia w komentarzu pozwoliłoby na użycie obu protokołów.

Nadal musisz skonfigurować swój serwer WWW do obsługi żądań HTTPS.


1
Ale jeśli włączysz HTTPS na poziomie nginx (przekierowując wszystko do HTTPS przez redirect 301 https:...), czy WSZYSTKO nie będzie przechodzić przez https, więc config.force_ssl = truetak naprawdę nic nie robi (ponieważ nic nigdy nie będzie http)? Czy jest tu głębszy powód bezpieczeństwa?
Tristan Tao

2
@TristanTao tak, to by działało równie dobrze. Ale nawet wtedy zostawiłbym config.force_sslwłączone, na wypadek gdyby ktoś usuwał przekierowanie z konfiguracji serwera WWW.
Stefan,

2
uważaj doh, config.force_ssl różni się nieco od force_ssl w kontrolerze pod względem zabezpieczania plików cookie przed przejmowaniem
odpowiednik8

1
Zwróć też uwagę, że posiadanie obu config.force_ssli add_header Strict-Transport-Security max-age=...;spowoduje 2 Strict-Transport-Securitynagłówki
Victor Ivanov

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.