Trình duyệt có thể gửi cookie đến một miền khác không?

Bạn có thể biết thực tế là khi bạn đưa ra yêu cầu từ giao diện người dùng đến máy chủ của mình, trình duyệt có thể tự động gửi cùng với bất kỳ cookie nào được liên kết với miền máy chủ của bạn với yêu cầu đó. Bạn có thể cũng biết rằng bạn có thể đặt các tiêu đề CORS để bỏ qua chính sách cùng nguồn gốc của trình duyệt và để giao diện người dùng của bạn giao tiếp với các máy chủ có nguồn gốc khác với giao diện người dùng

Ngoài ra, bạn có thể tin rằng việc đặt chính sách CORS đảm bảo rằng trình duyệt sẽ không tự động gửi cookie đến máy chủ của bạn nếu yêu cầu đến từ một nguồn gốc không được chỉ định trong chính sách CORS. Ví dụ: một trang web độc hại mở trong một tab trình duyệt khác [còn gọi là một cuộc tấn công CSRF]. Thật không may, điều này không hoàn toàn đúng

“Tôi vẫn khá chắc chắn rằng trình duyệt sẽ không gửi cookie chỉ vì yêu cầu đang được gửi đến đúng miền. Trình duyệt biết nguồn gốc của tập lệnh và sử dụng nguồn gốc ĐÓ để so sánh với CORS. Nếu tôi tạo một trang web và trình duyệt tôn trọng CORS, thì không có cách nào để có quyền truy cập vào cookie từ một miền khác. ”

Tất nhiên, việc giữ an toàn cho người dùng khi họ sử dụng ứng dụng của chúng tôi là cực kỳ quan trọng. Tuy nhiên, vì các trình duyệt rất phức tạp, nên có thể dễ dàng phát triển sự hiểu biết không đầy đủ về mô hình bảo mật của trình duyệt và đưa ra các lỗi lập luận khiến người dùng của chúng tôi gặp rủi ro

Đối với trình duyệt, "yêu cầu" không phải tất cả đều được tạo ra như nhau. Bạn đang đề cập đến fetch hay XMLHTTPRequest?

Đợi đã, CSRF phải làm gì với quyền truy cập cookie từ miền khác?

Tôi sẽ nói rất nhiều về cách các ứng dụng của chúng ta có thể dễ bị CSRF tấn công trong bài viết này, vì vậy cần làm rõ cách CSRF liên quan đến quyền truy cập cookie từ một miền khác

CSRF là một cuộc tấn công lừa nạn nhân gửi yêu cầu độc hại. "Mánh khóe" thường liên quan đến việc thuyết phục nạn nhân truy cập vào một miền độc hại [miền "khác" mà chúng tôi đã nói đến] trong khi họ đăng nhập vào ứng dụng mục tiêu. Đăng nhập là điều kiện tiên quyết quan trọng của một cuộc tấn công CSRF thành công, bởi vì điều này thường có nghĩa là trình duyệt có một tệp cookie cho ứng dụng đích chứa thông tin phiên [ví dụ: JWT]. Vì vậy, nếu miền độc hại bằng cách nào đó có thể yêu cầu trình duyệt gửi cookie phiên với bất kỳ yêu cầu nào mà miền độc hại đưa ra cho ứng dụng đích, thì ứng dụng đích không có cách nào để biết rằng yêu cầu đó là độc hại hoặc trái phép. Do đó, f-word [“giả mạo”] trong CSRF. Nếu yêu cầu được thực hiện thay đổi trạng thái, thì bạn có thể tưởng tượng mức độ thiệt hại mà điều này có thể gây ra

Nói cách khác, một cookie “có thể truy cập được”* từ một miền khác là nguyên nhân dẫn đến lỗ hổng CSRF, miễn là chúng tôi đang đề cập đến cookie phiên. Là nhà phát triển, chúng tôi muốn ngăn điều này xảy ra. Trình duyệt thực hiện một số công việc này cho chúng tôi, nhưng vì trình duyệt rất phức tạp nên chúng tôi phải đánh giá sự cân bằng và tìm hiểu xem liệu chúng tôi có cần thực hiện thêm bất kỳ công việc nào để giữ an toàn cho người dùng hay không

* Việc có thể truy cập cookie không nhất thiết có nghĩa là kẻ tấn công có thể đọc nội dung của cookie. Chỉ là họ có thể sử dụng nó để thực hiện các yêu cầu trái phép

Ok, vậy trình duyệt có ẩn cookie khỏi các tên miền khác hay không?

Nó thực sự phụ thuộc vào 😅. Hãy xem sơ đồ bên dưới, được phát triển bởi Alex Lauerman tại Trust Foundry

• Các hộp “thiết bị đầu cuối” màu lục nhạt [nơi lưu đồ kết thúc] cho biết các tình huống có khả năng xảy ra CSRF. Trong những tình huống này, kẻ tấn công có thể sử dụng cookie của người dùng và do đó có “quyền truy cập” vào chúng. Điều quan trọng cần nhớ là kẻ tấn công không thực sự đọc được nội dung của cookie hoặc phản hồi để gây ra “sự cố”
• Các đường dẫn đến hộp thiết bị đầu cuối màu đỏ [cái có nội dung “Không thể thực hiện CSRF”] đáng được chú ý vì chúng cho chúng ta biết cách chúng ta có thể ngăn chặn các cuộc tấn công CSRF xảy ra. Trong những trường hợp này, kẻ tấn công sẽ không thể sử dụng cookie của người dùng để thực hiện một cuộc tấn công
• Chính sách CORS, khi được đặt, không thể bảo vệ người dùng của bạn khỏi CSRF nhiều hơn chính sách gốc tương tự có thể. Trong một số trường hợp, khi được đặt quá tùy tiện, nó có khả năng làm tăng khả năng xảy ra tấn công CSRF
• Cách đáng tin cậy nhất để ngăn chặn CSRF là sử dụng mã thông báo chống CSRF ngẫu nhiên bằng mật mã. Nếu bạn đang sử dụng mã thông báo chống CSRF, việc trình duyệt có gửi cookie đến máy chủ của bạn hay không hầu như không thành vấn đề, bởi vì bạn sẽ yêu cầu máy chủ của mình thực hiện thêm một số công việc để xác minh xem cookie có đáng tin cậy hay không
• Mặc dù sơ đồ không đề cập đến nó, nhưng việc đặt đúng cờ SameSite trên cookie của bạn sẽ tiến thêm một bước để bảo vệ người dùng của bạn khỏi CSRF

CSRF có thể xảy ra chính xác vì kẻ tấn công có thể sử dụng cookie của người dùng vì lợi ích của họ, bằng cách khai thác các trường hợp cạnh trong giao điểm của hành vi trình duyệt và các lựa chọn cấu hình bảo mật cụ thể mà bạn đã thực hiện

Ghi chú. Lưu đồ này và bài viết liên quan đã được xuất bản vào năm 2014, điều đó có nghĩa là một số thông tin có thể đã lỗi thời do các trình duyệt đã phát triển các biện pháp bảo mật mới hơn. Tôi không nghĩ rằng điều này quan trọng cho mục đích của chúng tôi mặc dù

Đây là một công cụ đơn giản mà tôi đã viết để giúp bạn hiểu rõ hơn về bảo mật trình duyệt. Mục đích chính của nó là giúp bạn khám phá các khái niệm như CORS, CSRF, quyền truy cập cookie và các khái niệm khác có liên quan như thế nào

Hướng dẫn

• Chọn một ứng dụng mà bạn muốn kiểm tra lỗ hổng CSRF
• Đảm bảo bạn có quyền truy cập vào nhật ký máy chủ ứng dụng của mình. Bạn sẽ theo dõi chặt chẽ nhật ký để xác minh xem công cụ có thể đưa ra yêu cầu được xác thực cho ứng dụng của bạn hay không
• Mở ứng dụng trong tab trình duyệt khác và đăng nhập
• Khi bạn quay lại đây, hãy mở devtools và chuyển đến tab Mạng. Chúng tôi sẽ theo dõi điều này để hiểu cách các yêu cầu được thực hiện
• Nhập URL của điểm cuối bạn muốn kiểm tra bên dưới [ví dụ. //localhost:3000/account/12/update]. Bạn muốn chọn một điểm cuối yêu cầu người dùng phải đăng nhập
• Chọn Phương thức HTTP mà điểm cuối của bạn mong đợi
• Nhấp vào 'Yêu cầu giả mạo. ’
• Bây giờ bit quan trọng. Kiểm tra nhật ký máy chủ của bạn. Nếu bạn dễ bị CSRF, bạn sẽ thấy một yêu cầu được xác thực thành công hiển thị trong nhật ký của mình hoặc một lỗi cho bạn biết xác thực đã thành công nhưng lại xảy ra lỗi sau đó trong chu kỳ yêu cầu [ví dụ: lỗi xác thực dữ liệu]
• Nếu bạn thấy lỗi cho biết xác thực thành công, hãy xem liệu bạn có thể tiến xa hơn bằng cách sửa đổi yêu cầu để bao gồm dữ liệu bổ sung hay không
• Rửa sạch và lặp lại. Hãy thử giả mạo yêu cầu cho mọi thứ bạn có trong tay – ứng dụng đồ chơi, ứng dụng công việc, môi trường cục bộ, môi trường đã triển khai, trang quản trị bộ định tuyến của bạn, v.v. Về cơ bản, bất cứ thứ gì có thể mở được trong trình duyệt. Nếu có thể, hãy thử nó trên các trình duyệt khác nhau để điều tra xem có bất kỳ sự khác biệt nào trong hành vi không

Làm thế nào nó hoạt động

Khi bạn đã nhập điểm cuối và phương thức yêu cầu, công cụ sẽ cố gắng

1. Tạo thông qua API fetch đến điểm cuối đã chỉ định, không sử dụng tiêu đề bổ sung và loại nội dung mặc định
2. Tạo một biểu mẫu với action và method được đặt thành điểm cuối đã chỉ định và phương thức HTTP, đồng thời gửi biểu mẫu đó bằng loại nội dung mặc định [mục tiêu của biểu mẫu được đặt thành iframe ẩn để ngăn chuyển hướng]

Ý tưởng là sau khi công cụ thực hiện việc này, bạn sẽ truy cập nhật ký máy chủ của mình và kiểm tra kết quả của các yêu cầu đã được thực hiện

Lưu ý rằng trong cả hai trường hợp, công cụ không gửi dữ liệu đến điểm cuối. Mục đích duy nhất của nó là để xem liệu một yêu cầu được xác thực [khớp với một trong hai ràng buộc trên] có thể được thực hiện cho ứng dụng của bạn hay không. Khi bạn xác minh rằng điều này là có thể, nó sẽ đủ đơn giản để tìm ra cách gửi dữ liệu chính xác tới nó, nếu cần. Mã nguồn cho công cụ này có thể được tìm thấy ở đây. Thực hiện thử nghiệm với việc gửi dữ liệu, các loại nội dung khác, v.v.

từ chối trách nhiệm

Công cụ này là một món đồ chơi, được tối ưu hóa cho việc học. Mặc dù nó đóng vai trò là điểm khởi đầu tốt để xác minh xem bạn có lỗ hổng CSRF hay không, nhưng đừng tin tưởng nó một cách mù quáng. "Vượt qua" kiểm tra này không có nghĩa là bạn không có lỗ hổng CSRF. Đối với một, chúng tôi đang giới hạn bản thân trong các yêu cầu đơn giản. Như bạn đã thấy từ lưu đồ ở trên, có nhiều cách có khả năng các yêu cầu "phức tạp" có thể dễ bị CSRF tấn công. Ngoài ra, có nhiều thứ khác có thể xảy ra sai sót, ngay cả khi bạn làm đúng mọi thứ [Ví dụ như lỗ hổng trong chính trình duyệt. Điều này rất hiếm, nhưng đã xảy ra trước đây]. Điều đó đang được nói, nếu bạn tìm thấy lỗi hoặc sự cố với công cụ này, hãy viết thư cho tôi

Sự kết luận

Mặc dù các trình duyệt đôi khi không bảo vệ cookie của bạn khỏi bị gửi cùng với các yêu cầu, nhưng thực sự rất dễ dàng để bảo vệ người dùng của bạn khỏi CSRF

Mặc dù sơ đồ mà chúng ta đã thấy trước đó trông có vẻ đáng sợ, nhưng hóa ra việc bảo vệ chống lại CSRF là một vấn đề nổi tiếng mà nhiều người thông minh đã suy nghĩ thấu đáo. Chỉ cần hai điều

1. Mã thông báo chống CSRF phải được bao gồm trong mọi yêu cầu đột biến. Hầu hết các khung đều có giải pháp thử nghiệm cho việc này
2. Cookie của bạn phải có cờ SameSite được đặt thành XMLHTTPRequest1 [hoặc tối thiểu là XMLHTTPRequest2]

Lợi ích chính của việc áp dụng các biện pháp phòng vệ này là nó sẽ giúp bạn không phải lo lắng về các trường hợp cạnh trong hành vi của trình duyệt khi bạn xây dựng và mở rộng ứng dụng của mình, bởi vì bạn đang yêu cầu máy chủ của mình thực hiện công việc xác minh xem nguồn gốc của cookie có thể là

Nếu bạn chưa biết cách thêm mã thông báo chống CSRF vào khuôn khổ lựa chọn của mình, hãy tự mình tìm kiếm và tìm kiếm nó. Nếu bạn sử dụng Rails, hãy xem. Nếu bạn sử dụng Express, hãy xem gói csurf. Tôi cũng khuyên bạn nên đọc thông tin trong cả hai liên kết này bất kể khung bạn đang sử dụng là gì, bởi vì có một số thông tin hữu ích trong đó thường được áp dụng

Bạn cũng có thể thấy bài viết của tôi về những sai lầm có thể mắc phải với JWT hữu ích

Mặt khác, nếu tất cả những điều này khiến bạn nghĩ rằng bạn muốn tránh rắc rối với cookie và thay vào đó hãy đặt mã thông báo xác thực của bạn vào bộ nhớ cục bộ, hãy xem bài viết của tôi để tìm hiểu lý do tại sao điều này thực sự có thể kém an toàn hơn

Cuối cùng, nếu bạn thấy bài viết này hữu ích và muốn được thông báo khi tôi xuất bản một bài viết mới, hãy gửi email của bạn vào hộp bên dưới. Tôi đặt mục tiêu xuất bản một bài báo hai lần một tháng. ]

Có thể đặt cookie cho tên miền khác không?

Cookie có dành riêng cho một miền không?

JavaScript có thể truy cập cookie từ miền khác không?