Các hình thức đăng nhập có cần mã thông báo chống lại các cuộc tấn công CSRF không?

161

Từ những gì tôi đã học được cho đến nay, mục đích của các mã thông báo là để ngăn chặn kẻ tấn công giả mạo đệ trình biểu mẫu.

Ví dụ: nếu một trang web có một hình thức nhập các mặt hàng được thêm vào giỏ hàng của bạn và kẻ tấn công có thể spam giỏ hàng của bạn với các mặt hàng bạn không muốn.

Điều này có ý nghĩa bởi vì có thể có nhiều đầu vào hợp lệ cho hình thức giỏ hàng, tất cả những kẻ tấn công sẽ phải làm là biết một mặt hàng mà trang web đang bán.

Tôi hiểu cách mã thông báo hoạt động và thêm bảo mật trong trường hợp này, vì chúng đảm bảo người dùng đã thực sự điền và nhấn nút "Gửi" của biểu mẫu cho mỗi mục được thêm vào giỏ hàng.

Tuy nhiên, các mã thông báo có thêm bất kỳ bảo mật nào vào biểu mẫu đăng nhập của người dùng, yêu cầu tên người dùng và mật khẩu không?

Vì tên người dùng và mật khẩu rất độc đáo, kẻ tấn công sẽ phải biết cả hai để giả mạo đăng nhập hoạt động (ngay cả khi bạn không thiết lập mã thông báo) và nếu kẻ tấn công biết điều đó, anh ta có thể đăng nhập vào trang web bản thân anh ấy. Chưa kể, một cuộc tấn công CSRF khiến người dùng tự đăng nhập sẽ không có bất kỳ mục đích thực tế nào.

Sự hiểu biết của tôi về các cuộc tấn công và mã thông báo CSRF có đúng không? Và chúng có vô dụng đối với các hình thức đăng nhập người dùng như tôi nghi ngờ không?

php token csrf

— php_learner
nguồn

Họ có thể chiếm quyền điều khiển bộ định tuyến của bạn, bởi vì bạn có thể sử dụng mật khẩu mặc định trên đó và không được CSRF bảo vệ để đăng nhập.

— AbiusX

Có, vì vậy các trang web khác không thể bắt chước mẫu đăng nhập của bạn. Họ có thể đạt được gì khi làm điều đó? Đầu tiên bạn không muốn cho phép điều đó. Thứ hai: Các trường hợp thất bại rất dễ dàng như chặn người dùng do mật khẩu không chính xác n không. của thời gian, có thể tránh được.

— mayankcpdixit

126

Đúng. Nói chung, bạn cần bảo mật các hình thức đăng nhập của mình khỏi các cuộc tấn công CSRF giống như bất kỳ hình thức nào khác.

Nếu không, trang web của bạn dễ bị tấn công "lừa đảo tên miền đáng tin cậy". Nói tóm lại, trang đăng nhập dễ bị tổn thương CSRF cho phép kẻ tấn công chia sẻ tài khoản người dùng với nạn nhân.

Lỗ hổng diễn ra như thế này:

Kẻ tấn công tạo một tài khoản máy chủ trên miền đáng tin cậy
Kẻ tấn công giả mạo yêu cầu đăng nhập trong trình duyệt của nạn nhân với thông tin đăng nhập của tài khoản chủ này
Kẻ tấn công lừa nạn nhân sử dụng trang web đáng tin cậy, nơi họ có thể không nhận thấy họ đã đăng nhập thông qua tài khoản máy chủ
Kẻ tấn công hiện có quyền truy cập vào bất kỳ dữ liệu hoặc siêu dữ liệu nào mà nạn nhân "đã tạo" (cố ý hoặc vô ý) trong khi trình duyệt của họ đã đăng nhập bằng tài khoản máy chủ

Để làm ví dụ thích hợp, hãy xem xét YouTube . YouTube cho phép người dùng xem bản ghi lịch sử xem "của chính họ" và hình thức đăng nhập của họ dễ bị CSRF! Do đó, kẻ tấn công có thể thiết lập một tài khoản bằng mật khẩu mà họ biết, đăng nhập nạn nhân vào YouTube bằng tài khoản đó - theo dõi những video mà nạn nhân đang xem.

Có một số cuộc thảo luận trong luồng nhận xét này ngụ ý rằng nó chỉ có thể được sử dụng cho các vi phạm quyền riêng tư như thế. Có lẽ, nhưng để trích dẫn phần trong bài viết CSRF của Wikipedia :

Đăng nhập CSRF làm cho các cuộc tấn công mới lạ có thể; chẳng hạn, kẻ tấn công sau đó có thể đăng nhập vào trang web bằng thông tin xác thực hợp pháp của mình và xem thông tin cá nhân như lịch sử hoạt động đã được lưu trong tài khoản.

Nhấn mạnh vào "các cuộc tấn công tiểu thuyết". Hãy tưởng tượng tác động của một cuộc tấn công lừa đảo đối với người dùng của bạn và sau đó tưởng tượng rằng cuộc tấn công lừa đảo hoạt động thông qua dấu trang đáng tin cậy của chính người dùng đến trang web của bạn! Bài viết được liên kết trong chuỗi nhận xét đã nói ở trên đưa ra một số ví dụ vượt xa các cuộc tấn công riêng tư đơn giản.

— giáng sinh
nguồn

6

CSRF bảo vệ như thế nào? Có bất cứ điều gì ngăn chặn kẻ tấn công yêu cầu mã thông báo CSRF của riêng mình và chỉ cần gửi với điều đó không? Vì không có phiên xác thực tồn tại, không có lý do gì để máy chủ web thích một mã thông báo hơn một mã thông báo khác.

— A. Wilson

2

"Có bất cứ điều gì ngăn chặn kẻ tấn công yêu cầu mã thông báo CSRF của riêng mình và chỉ cần gửi với điều đó không?" - Đúng! Đó là toàn bộ giả định đằng sau logic phòng ngừa CSRF. Các trình duyệt đã / không cho phép gửi biểu mẫu để nhắm mục tiêu nguồn gốc khác, nhưng họ chưa bao giờ [cố ý] cho phép JS đọc dữ liệu trên các trang web, ngoại trừ bây giờ thông qua CORS chọn tham gia. Trừ khi bạn thiết lập CORS sai, kẻ tấn công có thể kích hoạt gửi biểu mẫu (có thể bao gồm mã thông báo CSRF hiện có trong cookie ) nhưng không có cách nào biết mã thông báo để gửi bản sao thứ hai cần thiết (ví dụ: trong phần thân / tiêu đề). Vì vậy, mã CSRF sẽ từ chối.

— natevw

7

Tôi nghĩ nhận xét cuối cùng của bạn là sai (bạn đã hiểu nhầm những gì A. Wilson đã nói). Chúng tôi đang nói rằng kẻ tấn công có thể tải http://good.com/login.htmltại một khách hàng, phân tích CSRF thẻ lồng nhau, và sau đó xuất bản http://bad.com/login.htmlcó chứa một hình thức sửa đổi mà lần gửi ông tên truy cập, mật khẩu và mã thông báo bất kể những gì các loại nạn nhân trong. CORS không áp dụng vì bạn' đã có hai khách hàng riêng biệt: kẻ tấn công và nạn nhân. Vì vậy, để nhắc lại câu hỏi: bảo vệ CSRF có thực sự hoạt động đối với các biểu mẫu đăng nhập không?

— Gili

8

Có, CSRF sẽ bảo vệ một hình thức đăng nhập khỏi sự giả mạo yêu cầu trên nhiều trang web . Mã thông báo CSRF thích hợp là mã hóa duy nhất mỗi lần được tạo. Chắc chắn, kẻ tấn công có thể tự nhận được mã thông báo nhưng nó vẫn KHÔNG BẮT ĐẦU cookie [có khả năng chưa đặt] mà nạn nhân có trong trình duyệt của họ và kẻ tấn công không có cách nào để đặt cookie nói mà không ảnh hưởng đến một trang trên tên miền tốt. (Tuy nhiên, ví dụ của bạn có vẻ hơi nhầm lẫn giữa CSRF và một số cuộc tấn công lừa đảo kỳ lạ, vì vậy tôi không chắc liệu tôi có trả lời câu hỏi thực tế của bạn hay không)

— natevw

3

Tôi có thể sai, nhưng dường như có một mối đe dọa đáng kể nếu người dùng vô tình làm bất cứ điều gì liên quan đến việc mua các mặt hàng. Ví dụ: kẻ tấn công lừa người dùng đăng nhập vào trang web và người dùng tiến hành mua các mặt hàng mà không nhận ra chúng nằm trong một tài khoản khác (nghĩ rằng Amazon hoặc tương tự). Bây giờ kẻ tấn công có quyền truy cập vào thông tin thanh toán đã lưu, có thể chuyển hướng mua hàng, v.v.

— you786

14

Hiểu biết của bạn là chính xác - toàn bộ quan điểm của CSRF là kẻ tấn công có thể giả mạo một yêu cầu tìm kiếm hợp pháp từ trước. Nhưng điều này không thể được thực hiện bằng một hình thức đăng nhập trừ khi kẻ tấn công biết tên người dùng và mật khẩu của nạn nhân, trong trường hợp đó có nhiều cách hiệu quả hơn để tấn công (đăng nhập chính bạn).

Cuối cùng, điều duy nhất mà kẻ tấn công có thể làm là gây bất tiện cho người dùng của bạn bằng cách spam các thông tin đăng nhập thất bại, khi hệ thống bảo mật có thể khóa người dùng trong một khoảng thời gian.

— Jon
nguồn

2

Wow siêu nhanh trả lời! Cảm ơn rất nhiều! Bây giờ tôi có thể tiếp tục xây dựng trang web của tôi một cách tự tin.

— php_learner

21

Đăng nhập CSRF vẫn có thể được sử dụng cho các cuộc tấn công vào quyền riêng tư của người dùng seclab.stanford.edu/websec/csrf/csrf.pdf

— squiddle

6

@squiddle: Đó là một bài báo khá thú vị, cảm ơn vì liên kết. Nhưng bản lề của việc đăng nhập người dùng bằng tài khoản dưới sự kiểm soát của kẻ tấn công và cho rằng người dùng sẽ không nhận ra điều gì đó không đúng và cho rằng người dùng sẽ tạo ra thông tin nhạy cảm sẽ được lưu trữ trên máy chủ. Vì vậy, IMHO nó khá ít nghiêm trọng hơn CSRF "cổ điển".

— Jon

6

@Jon Vâng, nó có thể ít nghiêm trọng hơn, nhưng cuối cùng nó có thể không chỉ là sự bất tiện, cụ thể là xâm phạm quyền riêng tư. Mỗi dịch vụ phải tự xác định mô hình mối đe dọa của họ và xử lý tương ứng. Để làm điều đó, bạn cần ít nhất là nhận thức được các mối đe dọa có thể. Đó là lý do tại sao tôi thêm 2 xu của mình.

— câu đố

1

Xin vui lòng bạn có thể mở rộng về cách họ sẽ "Cuối cùng, điều duy nhất mà kẻ tấn công có thể làm là gây bất tiện cho người dùng của bạn bằng cách spam các thông tin đăng nhập thất bại, khi hệ thống bảo mật có thể khóa người dùng trong một khoảng thời gian."

— samthebest

0

Có , vì vậy các trang web khác không thể bắt chước mẫu đăng nhập của bạn! Đơn giản vậy thôi.

Họ có thể đạt được gì khi làm điều đó?

Đầu tiên: bạn không muốn cho phép điều đó.
Thứ hai: Ngay cả những trường hợp thất bại rất đơn giản như:
- ngăn chặn người sử dụng do mật khẩu sai nkhông. của thời gian, có thể tránh được.
- Cảnh báo hack flase có thể được ngăn chặn. Vân vân.

— mayankcpdixit
nguồn

Hầu hết các điểm này là không chính xác. Kẻ tấn công có thể tạo biểu mẫu đăng nhập, nhận thông tin đăng nhập của người dùng tải biểu mẫu đăng nhập (với mã thông báo csrf) và đăng ba thông tin lên mục tiêu. CSRF không ngăn chặn điều này.

— Snapey

Các trình duyệt @Snapey thường không cho phép JS đọc dữ liệu CSRF. Sử dụng JS, bạn không thể bắt chước yêu cầu gửi biểu mẫu chính hãng.

— mayankcpdixit

Mã thông báo csrf thường được chuyển đến máy khách để sử dụng bởi javascript. Tôi không nói về cors Tôi lấy về kẻ tấn công chỉ yêu cầu biểu mẫu đăng nhập và nhồi thông tin đăng nhập. @mayankcpdxit. Bạn dường như ngụ ý rằng csrf ngăn chặn nhồi thông tin xác thực, nhưng điều đó không.

— Snapey

Về mặt lý thuyết, vâng, nó không thể ngăn chặn. Nhưng không thể tự động hóa nhồi thông tin xác thực sau CSRF nếu bạn ngừng tải các biểu mẫu CSRF trong iframe và ngừng cho phép req có nguồn gốc chéo.

— mayankcpdixit

-1

Xác thực trước khi đăng nhập CSRF không có ý nghĩa quá nhiều IMHO.

Cảm ơn @squiddle cho liên kết: seclab.stanford.edu/websec/csrf/csrf.pdf , chúng tôi có thể đọc trên trang đầu tiên:

The most popular CSRF defense is to include a secret
token with each request and to validate that the received
token is correctly bound to the user’s session,
preventing CSRF by forcing the attacker to guess the
session’s token.

Nếu bạn thử đăng nhập trước xác thực CSRF, thì bạn sẽ cho kẻ tấn công tiềm năng cơ hội để lấy mã hợp lệ của trang web của bạn! Anh ấy / cô ấy sau đó sẽ có thể đăng lại mã thông báo đánh bại mục đích.

Có lẽ kẻ tấn công sau đó có thể cố gắng đoán tên người dùng của trang web của bạn. Những gì tôi đã làm, nếu địa chỉ IP cố gắng đoán 10 tên người dùng mà không thành công, tôi chỉ đơn giản là liệt kê nó.

— Patrice Gagnon
nguồn