Chuyển hướng / người dùng / đăng nhập vào HTTPS, tất cả các yêu cầu khác đến HTTP


7

Tôi đang sử dụng Drupal 7. Trang đăng nhập cho người dùng của tôi được đặt tại / user / login, do đó, đường dẫn đăng nhập mặc định. Tôi cần trang đó được mã hóa bằng SSL để mọi người không truyền mật khẩu rõ ràng.

Tôi đã cấu hình Apache để trang web có thể được điều hướng qua HTTP hoặc HTTPS. Tuy nhiên, tôi muốn thực hiện một số quy tắc viết lại để tất cả các yêu cầu khác ngoài / người dùng / đăng nhập được thực hiện qua HTTP vì nó nhanh hơn và sẽ mang lại trải nghiệm tốt hơn cho người dùng. Tôi từ chối sử dụng Trang bảo mật tại thời điểm này vì hỗ trợ có lỗi trong Drupal Core và tôi sẽ không vá Core theo cách thủ công. Điều đó có nghĩa là tôi còn lại với việc sử dụng các quy tắc viết lại của Apache.

Tôi có các quy tắc sau:

<VirtualHost *:80>
  ...
  RewriteCond %{HTTPS} off
  RewriteCond %{REQUEST_URI} ^/user/login$
  RewriteRule ^/(.*) https://%{HTTP_HOST}/$1 [L,R]
  ...
</VirtualHost>

<VirtualHost *:443>
  ...
  RewriteCond %{HTTPS} on
  RewriteCond %{REQUEST_URI} !^/user/login$
  RewriteRule ^/(.*) http://%{HTTP_HOST}/$1 [L,R]
  ...
</VirtualHost>

Bây giờ với tôi, điều đó có ý nghĩa, nhưng Drupal dường như không thích nó.

Điều gì đang xảy ra như sau:

  1. Nếu tôi điều hướng xung quanh trang web bằng cách sử dụng HTTP đến bất kỳ trang nào khác ngoài / user / login, nó hoạt động tốt.
  2. Nếu tôi điều hướng đến / người dùng / đăng nhập qua HTTP, tôi sẽ được chuyển hướng đến trang trước.
  3. Nếu tôi điều hướng đến bất kỳ trang nào qua HTTPS, tôi sẽ được chuyển hướng đến trang đầu qua HTTP.

Các trang HTTPS rất chậm có thể không bình thường nhưng chỉ ra rằng hệ thống của bạn sắp hết entropy. Giải thích và cách khắc phục tại đây .
tanius

Câu trả lời:


8

Bạn không thực sự cần / người dùng / đăng nhập để được phục vụ qua https; bạn cần mẫu đăng nhập người dùng được gửi qua https.

Bạn nên xem mô-đun securepages_prevent_hijack - không sử dụng trực tiếp, vì nó phụ thuộc vào bảo mật, nhưng để xem cách thay đổi hình thức đăng nhập. Thích như vậy:

function securepages_prevent_hijack_form_alter(&$form, &$form_state, $form_id) {
  // Secure the login form, so that we always have a secure connection to transmit the
  // initial cookie.  Also, protect the password in transit.
  if ($form['#id'] == 'user-login-form' || $form['#id'] == 'user-login') {
    $url = parse_url($form['#action']);

    $base_path = base_path();
    $path = (!strncmp($url['path'], $base_path, drupal_strlen($base_path)) ? drupal_substr($url['path'], drupal_strlen($base_path)) : $url['path']);
    $options = array('secure' => TRUE);
    if (isset($url['query'])) {
      $options['query'] = $url['query'];
    }
    $form['#action'] = securepages_url($path, $options);
  }
}

Bạn cũng nên tìm hiểu xem cookie mà Drupal đang đặt cho bạn có an toàn hay không. Điều này sẽ phụ thuộc vào cài đặt của bạn trong php.ini. Kiểm tra xem bạn đã đặt session.cookie_secure thành 1. Nếu bạn có, thì cookie sẽ không được gửi đến các phiên http của bạn, đó có thể là lý do khiến bạn kết thúc tại trang chủ (không có cookie phiên == no session = = không có thông tin đăng nhập == đăng xuất). Tất nhiên, nếu session.cookie_secure bằng 0, thì các bên khác có thể quan sát cookie phiên của bạn trong quá trình và giả trang thành người dùng của bạn. Có lẽ bạn đã xem xét rủi ro này, nhưng nó có một số cân nhắc.


Hấp dẫn. Chà, tôi đã xem qua settings.php và php.ini và session.cookie_secure không được đặt ở bất cứ đâu. Vì vậy, bạn nghĩ rằng tôi chỉ có thể tạo một mô-đun tùy chỉnh thực hiện hook_form_alter và nhắm mục tiêu biểu mẫu đăng nhập? Tôi không thực sự chắc chắn điều gì securepages_url(...)...
Lester Peabody

securepages_url tương tự như converse của parse_url; đó là trong mô-đun bảo mật (tất nhiên), vì vậy bạn có thể tra cứu nó. Nó phức tạp hơn bạn cần; bạn chỉ có thể đặt trước http đến https ở dạng $ ['# action']. Thay đổi biểu mẫu lý do tốt hơn so với chuyển hướng http-to-https của bạn là nó cũng sẽ hoạt động trên các biểu mẫu đăng nhập nằm trong một khối trên một số trang khác ngoài người dùng / đăng nhập. Bạn có thể gắn bó với kỹ thuật hiện tại của mình nếu bạn không cần những thứ đó. Tất nhiên, vấn đề thực sự của bạn là chuyển từ https sang http. Bạn sẽ phải theo dõi lý do tại sao cookie phiên không tồn tại.
greg_1_anderson

Hãy chắc chắn rằng nó RewriteCond %{REQUEST_URI} !^/user/login$đang hoạt động đúng; nếu quy tắc này bắt được một phần của quá trình chuyển hướng đăng nhập, thì mật khẩu của bạn sẽ được gửi rõ ràng. Chụp một số gói với wireshark để đảm bảo điều này không xảy ra. Điều này cũng có thể giúp bạn tìm hiểu những gì đang xảy ra với cookie phiên của bạn. Tôi biết tôi chưa trả lời câu hỏi của bạn, nhưng hy vọng điều này sẽ giúp bạn bắt đầu đi đúng hướng.
greg_1_anderson

Bạn đã làm một công việc khá tốt khi chỉ cho tôi đi đúng hướng. Ví dụ, tôi không biết rằng các phiên khác nhau vẫn tồn tại giữa HTTP và HTTPS, điều này rõ ràng sẽ giúp ích cho sự hiểu biết của tôi về vấn đề này. Tôi đến từ thế giới Rails, vì vậy, đây là điều mới đối với tôi :)
Lester Peabody

1
Bạn cũng có thể thấy bài viết gần đây về DrupalPlanet này rất thú vị: solotandem.com/ Kẻ
greg_1_anderson

4

Tôi nghĩ rằng mô-đun Đăng nhập an toàn cũng sẽ làm những gì bạn muốn mà không yêu cầu bạn hack lõi.

Mô-đun Đăng nhập an toàn cho phép người dùng đăng nhập và các biểu mẫu khác được gửi an toàn qua HTTPS, do đó ngăn mật khẩu và dữ liệu người dùng riêng tư khác được truyền đi trong văn bản rõ ràng.


Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.