Một số hacker có thể ăn cắp cookie từ người dùng và đăng nhập bằng tên đó trên trang web không?

Question

Đọc câu hỏi này

different users get the same cookie value in aspxanonymous

và tìm kiếm một giải pháp, tôi bắt đầu suy nghĩ, nếu nó có thể cho một số một để thực sự ăn cắp cookie với một cách nào đó, và sau đó đặt nó trên trình duyệt và đăng nhập của mình cho phép nói với tư cách là quản trị viên.

Bạn có biết cách xác thực biểu mẫu có thể đảm bảo rằng ngay cả khi cookie bị loại bỏ, thì hacker không thực sự đăng nhập bằng cách sử dụng?

Hoặc bạn có biết bất kỳ cơ chế bảo vệ tự động nào khác không?

Cảm ơn bạn đã nâng cao.

Answer 1

Có thể ăn cắp cookie và xác thực với tư cách là quản trị viên không?

Có thể, nếu cookie Biểu mẫu xác thực không được mã hóa, ai đó có thể hack cookie để cung cấp cho họ đặc quyền cao hoặc nếu SSL không yêu cầu, hãy sao chép cookie của người khác. Tuy nhiên, có những bước bạn có thể làm để giảm thiểu những rủi ro:

Trên yếu tố system.web/chứng thực/hình thức:

1. requireSSL = true. Điều này yêu cầu cookie chỉ được truyền qua SSL
2. slidingExpiration = false. Khi đúng, vé đã hết hạn có thể được kích hoạt lại.
3. cookieless = false. Không sử dụng các phiên không có cookieless trong một môi trường mà bạn đang cố gắng thực thi bảo mật.
4. enableCrossAppRedirects = false. Khi sai, xử lý cookie trên các ứng dụng không được phép.
5. bảo vệ = tất cả. Mã hóa và băm các hình thức Auth Cookie sử dụng phím máy được quy định trong machine.config hoặc web.config. Tính năng này sẽ ngăn ai đó hack cookie của riêng họ vì cài đặt này yêu cầu hệ thống tạo chữ ký của cookie và trên mỗi yêu cầu xác thực, so sánh chữ ký với cookie được truyền.

Nếu bạn muốn, bạn có thể thêm một chút bảo vệ bằng cách đặt một số loại thông tin xác thực trong Phiên như băm tên người dùng của người dùng (Không bao giờ tên người dùng trong văn bản thuần tuý cũng như mật khẩu của họ). Điều này sẽ yêu cầu kẻ tấn công ăn cắp cả cookie phiên và cookie Biểu mẫu xác thực.

Answer 2

Tôi không biết chi tiết cụ thể của cookie được đề cập nhưng thực tế là không tốt để lưu trữ cả tên người dùng và mật khẩu trong cookie của người dùng. Nói chung, bạn chỉ muốn lưu tên người dùng trong cookie cùng với các thông tin không nhạy cảm khác. Bằng cách đó người dùng được nhắc cung cấp mật khẩu của họ chỉ khi đăng nhập.

Answer 3

Trong nhiều trường hợp, cookie được sử dụng để xác thực được khớp với một phiên trên máy chủ, vì vậy không chỉ có thể lấy cookie và 'đăng nhập', tuy nhiên, bạn có thể muốn có một đọc về giả mạo yêu cầu qua trang web, mà làm phép một cơ chế cho cookie này sẽ được sử dụng độc hại:

http://en.wikipedia.org/wiki/Cross-site_request_forgery

Answer 4

có rất nhiều cách mà một phiên id có thể bị rò rỉ cho kẻ tấn công. XSS là đòn tấn công được sử dụng phổ biến nhất để chiếm đoạt một ID phiên và bạn nên test for XSS vulnerabilities trong ứng dụng của mình. . Một phương pháp phổ biến để cải thiện sức mạnh của một phiên là kiểm tra địa chỉ IP. Khi người dùng đăng nhập, hãy ghi lại địa chỉ IP. Kiểm tra địa chỉ IP cho mọi yêu cầu, nếu IP thay đổi thì đó có thể là phiên bị tấn công. Phương pháp bảo mật này có thể ngăn chặn các yêu cầu hợp pháp, nhưng đó là không thể rất.

Làm không kiểm tra X-Forwarded-For hoặc User-Agent, tầm quan trọng của nó để kẻ tấn công sửa đổi các giá trị này.

tôi cũng khuyên bạn nên httpOnlyCookies cho phép trong tập tin web.config của bạn:

<httpCookies httpOnlyCookies="true"/> 

này làm cho nó khó khăn hơn cho kẻ tấn công chiếm quyền điều khiển một phiên với javascript, nhưng nó vẫn có thể.

Answer 5

Trường hợp cookie có thể bị đánh cắp xảy ra trong môi trường không dây công cộng. Trong khi bạn hoặc tôi sẽ không bao giờ hoạt động trong một thiết lập như vậy, nó có thể là không thể ngăn chặn khách hàng của bạn làm như vậy.

Nếu kẻ tấn công biết bạn đang kết nối trang web an toàn nào, ý tưởng là trình duyệt của bạn có thể bị lừa khi đăng lên phiên bản không an toàn của cùng một url. Vào thời điểm đó, cookie của bạn bị xâm nhập.

Đó là lý do ngoài httpOnlyCookies bạn sẽ muốn chỉ định requireSSL="true"

<httpCookies httpOnlyCookies="true" requireSSL="true" /> 

Tôi không đồng ý với bình luận của Rook, trong đó tôi thấy nó không lành mạnh;

@Aristos i đã cập nhật câu trả lời của tôi. Nhưng thành thật mà nói, nếu bạn sử dụng nền tảng phát triển của Microsoft, ứng dụng của bạn sẽ vốn không an toàn. - The Rook 22 phút trước

Bảo mật không xảy ra do tai nạn và nó không xảy ra "ngay ngoài hộp", ít nhất là trong kinh nghiệm của tôi. Không có gì là an toàn cho đến khi nó được thiết kế để được như vậy, bất kể nền tảng hoặc các công cụ.

Answer 6

Tôi đang làm việc về vấn đề này và tôi nảy ra ý tưởng, rằng tôi không chắc chắn liệu nó có an toàn 100% hay không, nhưng là một ý tưởng.

Ý tưởng của tôi là mỗi người dùng phải vượt qua từ trang đăng nhập.
Nếu một ai đã đánh cắp cookie, không vượt qua trang đăng nhập, nhưng là đi trực tiếp vào bên trong để các trang còn lại. Anh không thể vượt qua trang đăng nhập, vì không biết thực sự mật khẩu, vì vậy nếu anh vượt qua ông thất bại nào.

Vì vậy, tôi đặt một giá trị phiên bổ sung, mà người dùng đã vượt qua thành công với trang đăng nhập. Bây giờ bên trong mỗi trang quan trọng, tôi kiểm tra giá trị phiên bổ sung và nếu tìm thấy nó null, tôi đăng nhập và yêu cầu một lần nữa cho mật khẩu.

Bây giờ tôi không biết, có thể tất cả những việc đó đã được thực hiện bởi microsoft, cần phải kiểm tra thêm.

Để kiểm tra ý tưởng này tôi sử dụng chức năng này mà đạo làm cho một người dùng đăng nhập.

FormsAuthentication.SetAuthCookie("UserName", false); 

an ninh thứ hai của tôi rằng tôi có tất cả các sửa chữa sẵn sàng và sử dụng, là tôi kiểm tra ip khác nhau và hoặc cookie khác nhau từ cùng một người dùng đã đăng nhập. Tôi đã thực hiện nhiều suy nghĩ về điều đó, nhiều kiểm tra (nếu là đằng sau proxy, nếu là từ các quốc gia khác nhau, những gì đang tìm kiếm, bao nhiêu lần tôi đã nhìn thấy anh ta, vv ...) nhưng đây là ý tưởng chung.

This video hiển thị chính xác những gì tôi cố gắng ngăn chặn. Bằng cách sử dụng mẹo tôi đã mô tả ở đây, bạn không thể chỉ đặt cookie đăng nhập.

Chỉ cần chia sẻ ý tưởng của tôi ...