2012-09-01 17 views
8

Tôi đang tham gia bước đột phá đầu tiên vào mô-đun bảo mật Kim tự tháp. Tôi đang sử dụng mã đăng nhập này để thiết lập auth_tkt:Câu hỏi Pyramid.security: Double cookies? Cookie không an toàn? Hết hạn?

@view_config(route_name='LoginForm', request_method='POST', renderer='string') 
class LoginForm(SimpleObject): 
    def __call__(self): 

     emailAddress = self.request.params.get('emailAddress') 
     password = self.request.params.get('password') 

     if emailAddress != '[email protected]' or password != 'testpassword': 
      errorDictionary = { 'message' : "Either the email address or password is wrong." } 
      self.request.response.status = 400 
      return json.dumps(errorDictionary, default=json_util.default) 

     testUserGUID = '123123123' 

     headers = remember(self.request, testUserGUID) 
     return HTTPOk(headers=headers) 

Có vẻ như để làm việc ok, nhưng có một số chi tiết khó hiểu:

Trước hết, 2 cookie thực sự được thiết lập thay vì một. 2 cookie giống nhau (cả với tên "auth_tkt") ngoại trừ một sự khác biệt: một cookie có giá trị máy chủ lưu trữ là ".www.mydomain.com" trong khi cookie khác có giá trị máy chủ lưu trữ là "www.mydomain.com" 2 cookie được đặt thay vì một cookie? Ý nghĩa của các giá trị host khác nhau là gì?

Câu hỏi 2, các công cụ web báo cáo rằng cả cookie đều không an toàn. Tôi có thể làm gì để đảm bảo cookie/s được bảo mật?

Câu hỏi 3: Cả hai cookie đều có giá trị hết hạn là "Vào cuối phiên". Điều này có nghĩa là gì và làm thế nào tôi có thể tùy chỉnh giá trị hết hạn của bản thân mình? Thực hành được khuyến nghị cho thời gian hết hạn cookie đăng nhập là gì?

Câu hỏi 4: Tôi không hiểu tại sao đối số đầu tiên của "ghi nhớ" là self.request thay vì self.request.response. Không nên ghi nhớ dữ liệu trên đối tượng phản hồi, không phải đối tượng yêu cầu?

+0

Có lẽ bạn có nghĩa là 'serverUserGUID = '1123123123''; bạn gọi 'nhớ' với tên biến đó. –

+0

Cảm ơn bạn ... Tôi đã sửa lỗi. – zakdances

Trả lời

11
  1. Thực ra, 3 cookie được tạo; một không có mã số Domain, một có và thứ ba với phiên bản ký tự đại diện của tên miền của bạn (dấu chấm đầu). Trình duyệt của bạn thường kết hợp cả hai hoặc bỏ qua một trong số đó (trình duyệt khác với trình duyệt, đó là lý do tại sao 2 trình duyệt được đặt).

    Cookie cuối cùng được tạo khi tùy chọn wild_domain được đặt trên AuthTktAuthenticationPolicy (Đúng theo mặc định); xem AuthTktAuthenticationPolicy API. Bạn cần điều này nếu cookie xác thực của bạn được chia sẻ giữa các tên miền phụ khác nhau (nghĩ app1.domain, app2.domain); trình duyệt của bạn sẽ không chia sẻ cookie trên các tên miền phụ mà không có cookie ký tự đại diện.

  2. Bạn cần đặt tùy chọn secure trên chính sách xác thực của bạn cho cookie để đặt cờ an toàn. Một lần nữa, hãy xem API.

  3. Không đặt hết hạn, có nghĩa là cookie sẽ bị xóa khi bạn đóng trình duyệt (cuối phiên mà trình duyệt của bạn hiển thị). Nếu bạn muốn người dùng của mình bị đăng xuất khi họ đóng trình duyệt, hãy để người dùng này làm mặc định.

    Chỉ nếu bạn muốn phiên cuối cùng trên đóng cửa trình duyệt, đặt độ tuổi tối đa của cookie, hãy xem tùy chọn max_age trong API. Tùy chọn này sẽ khiến các trình duyệt lưu trữ cookie trên đĩa để duy trì giữa các lần đóng trình duyệt và xóa chúng khi độ tuổi tối đa đã qua.

    Lưu ý rằng đối tượng chính sách AuthTktAuthenticationPolicy có thể quản lý phiên đăng nhập một cách chi tiết hơn bằng cách giới hạn thời gian sẽ xem xét bất kỳ cookie xác thực nào hợp lệ và sẽ cho phép bạn thiết lập chính sách làm mới cookie. Với chính sách làm mới như vậy, người dùng sẽ nhận được cookie mới (làm mới) khi họ tiếp tục sử dụng ứng dụng của bạn, nhưng nếu họ không kết nối với máy chủ của bạn trong một khoảng thời gian nhất định, cookie của họ sẽ bị coi là không hợp lệ và họ sẽ có để đăng nhập lại.

    Xem các tùy chọn timeoutreissue_time trong API documentation để biết thêm chi tiết về cách định cấu hình này.

  4. Đối tượng chính sách yêu cầu một số thông tin từ yêu cầu để có thể tạo cookie, không ít nhất là tất cả tên máy chủ lưu trữ của máy chủ của bạn.

+1

Cảm ơn bạn đã làm rõ. Một điều tôi muốn biết là, chính sách AuthTKTAuthentication có an toàn chống lại các cuộc tấn công csrf không ?? Nếu không làm thế nào chúng ta có thể làm cho nó an toàn. Và một điều khác làm thế nào chúng ta có thể sử dụng nó cho các máy chủ kết nối với một ứng dụng di động của khách hàng. Điều cookie sẽ khó mà tôi đoán được. Và sẽ không tùy chọn mã thông báo được tốt hơn ?? –

+1

Đặt 'http_only' thành' True' để yêu cầu các trình duyệt ẩn cookie khỏi JavaScript; điều này làm cho các cuộc tấn công CSRF ăn cắp cookie không hiệu quả. Cookie chỉ là tiêu đề HTTP, ứng dụng khách di động của bạn sẽ phải quản lý chúng giống như chúng cho bất kỳ trang web nào khác. Không có ý tưởng những gì bạn có ý nghĩa bởi các tùy chọn mã thông báo. –

+0

Tôi không chắc chắn nếu điều đó sẽ ngăn chặn các cuộc tấn công csrf, các tập tin cookie được tự động gắn liền với bất kỳ yêu cầu đến tên miền mà họ đã được thiết lập từ. Csrf tấn công thực hiện chính xác điều đó. Tôi hỏi về việc tạo mã thông báo và phục vụ cho khách hàng và máy chủ ghi nhớ mã thông báo được cấp cho người dùng cụ thể. –

Các vấn đề liên quan