it-swarm-vi.com

Làm cách nào để đảm bảo rằng cookie luôn được gửi qua SSL khi sử dụng ASP.NET trên IIS 7.5?

Firesheep đã đưa vấn đề trao đổi cookie không an toàn lên hàng đầu.

Làm thế nào bạn có thể đảm bảo rằng tất cả các trao đổi cookie bị buộc chỉ xảy ra thông qua kết nối được bảo mật SSL với máy chủ khi bạn liên lạc với người dùng web?

Kịch bản của chúng tôi là ứng dụng web được viết bằng ASP.NET 4.0 và được lưu trữ trên Windows Server 2008 R2 đang chạy IIS 7.5 nếu điều đó thu hẹp phạm vi.

23
cpuguru

Bạn có thể sử dụng app.config để buộc nó; định dạng là (trong <system.web> phần)

<httpCookies domain="String"
             httpOnlyCookies="true|false" 
             requireSSL="true|false" />

vì vậy bạn thực sự muốn, ở mức tối thiểu

<httpCookies requireSSL='true'/>

Nhưng tốt nhất là bạn cũng sẽ bật httpOnlyCookies, trừ khi bạn đang thực hiện một số javascript thực sự hấp dẫn.

21
blowdart

Cách an toàn nhất để bảo vệ trang web của bạn chống lại Firesheep (và các cuộc tấn công liên quan):

  • Di chuyển đến bảo vệ SSL trên toàn trang web : Di chuyển toàn bộ trang web của bạn sang HTTPS và vô hiệu hóa tất cả quyền truy cập HTTP. Nói cách khác, bảo vệ toàn bộ trang web của bạn bằng SSL. Dưới đây là một số tài nguyên khác để thực hiện điều đó: cách bảo vệ chống lại Firesheep , ưu và nhược điểm của SSL trên toàn trang web , tại sao SSL bảo vệ chống lại Firesheep .

  • Đặt cờ AN TOÀN trên tất cả các cookie : Bất cứ khi nào máy chủ đặt cookie, hãy sắp xếp để đặt cờ AN TOÀN trên cookie. Cờ AN TOÀN yêu cầu trình duyệt của người dùng chỉ gửi lại cookie này qua các kết nối bảo mật SSL (HTTPS); trình duyệt sẽ không bao giờ gửi cookie AN TOÀN qua kết nối không được mã hóa (HTTP). Bước đơn giản nhất là đặt cờ này trên mọi cookie mà trang web của bạn sử dụng.

Ngoài ra, tôi khuyên bạn nên một số bước bổ sung:

  • Hãy cẩn thận về nội dung của bên thứ ba : Các tiện ích, thư viện và nội dung của bên thứ ba có thể là một rủi ro bảo mật. Nếu bạn bao gồm Javascript từ các bên thứ ba (ví dụ: qua <SCRIPT SRC=...>), Tôi khuyên bạn nên đảm bảo rằng họ tham chiếu các URL HTTPS; nếu không, bạn đang phơi bày sự bảo mật của trang web của mình trước các cuộc tấn công đang hoạt động. (Xem thêm Jeremiah Grossman's FAQ trên các tiện ích của bên thứ ba .) Để tránh làm ngập người dùng của bạn với cảnh báo nội dung hỗn hợp , bạn sẽ muốn đảm bảo rằng tất cả nội dung, bao gồm cả hình ảnh và thư viện của bên thứ ba, cũng được phân phối thông qua HTTPS.

Một số người có thể lập luận rằng những điều trên là quá mức cần thiết. Trong một số trường hợp, có thể bảo vệ chống lại Firesheep bằng cách sử dụng SSL trên một phần của trang web. Tuy nhiên, làm như vậy đòi hỏi sự quan tâm và kiến ​​thức chi tiết, và khó hơn để làm đúng. Cho rằng bạn phải đặt câu hỏi ở đây, cá nhân tôi khuyên bạn nên bắt đầu với SSL trên toàn trang web; bạn có cơ hội tốt hơn để làm cho đúng.

Cách triển khai điều này trong IIS : Tôi không phải là chuyên gia IIS, vì vậy tôi không thể cung cấp cho bạn công thức dứt khoát về Cách triển khai các bước này trong IIS. Tuy nhiên, tham chiếu này trên bật SSL trên IIS có thể hữu ích cho bạn. Có vẻ như bạn có thể nhấp chuột phải vào gốc trang web, chọn Properties , nhấp vào tab Directory Security, sau đó trong Secure Communications, nhấp Edit và bật Require Secure Channel (SSL). Tôi không biết cách định cấu hình IIS để tự động đặt cờ AN TOÀN trên tất cả các cookie. Để di chuyển một trang web hiện có, tôi khuyên bạn nên thiết lập chuyển hướng để bất kỳ ai truy cập trang HTTP đều được chuyển hướng đến HTTPS. chưa được kiểm tra): chuyển hướng đến HTTPS , ba phương pháp để chuyển hướng đến HTTPS . Nếu di chuyển một trang web hiện tại, bạn cũng sẽ cần thay đổi tất cả các liên kết và tham chiếu đến trang web của mình từ http: URL tới https: URL. Tôi không chắc chắn cách định cấu hình ASP.NET để đặt cờ AN TOÀN trên tất cả các cookie, nhưng tôi nghĩ bạn có thể thêm cookieRequireSSL="true" Hoặc <httpCookies requireSSL="true"> Thành Web.config; đó là điều quan trọng cần làm và đặc biệt quan trọng nếu bạn đã bật HTTP hoặc nếu bạn có một số loại chuyển hướng từ trang HTTP sang trang HTTPS. Cuối cùng, có rất nhiều tài liệu được xuất bản trên điều chỉnh hiệu suất cho HTTPS .

18
D.W.

Tôi đã xem qua chủ đề này trong khi giải quyết vấn đề bản thân mình. Độ phân giải tôi có là đường dẫn cookie phân biệt chữ hoa chữ thường. Đây là câu hỏi liên quan.

https://stackoverflow.com/questions/399982/why-are-cookie-paths-case-sensitive

Giải pháp của tôi là chuyển hướng từ trang đích đến đúng đường dẫn. Hãy chắc chắn để ý các vòng lặp chuyển hướng có thể.

url.com/VirtualDirectory/default.aspx ->

// mà bây giờ sẽ đưa ra đường dẫn chính xác url.com/virtualdirectory/default.aspx answer.redirect ("~/default.aspx");

1
MichaelChan