Tôi đang cố gắng hiểu toàn bộ vấn đề với CSRF và các cách thích hợp để ngăn chặn vấn đề này. (Tài nguyên tôi đã đọc, hiểu và đồng ý với: Bảng kiểm tra phòng chống CSRF của OWASP , Câu hỏi về CSRF .)

Theo tôi hiểu, lỗ hổng xung quanh CSRF được đưa ra bởi giả định rằng (theo quan điểm của máy chủ web) cookie phiên hợp lệ trong yêu cầu HTTP đến phản ánh mong muốn của người dùng được xác thực. Nhưng tất cả các cookie cho miền gốc được trình duyệt đính kèm theo yêu cầu của trình duyệt, vì vậy tất cả các máy chủ có thể suy ra sự hiện diện của cookie phiên hợp lệ trong yêu cầu là yêu cầu đến từ trình duyệt có phiên xác thực; nó không thể tiếp tục thừa nhận bất cứ điều gì về mãchạy trong trình duyệt đó, hoặc liệu nó thực sự phản ánh mong muốn của người dùng. Cách để ngăn chặn điều này là bao gồm thông tin xác thực bổ sung ("mã thông báo CSRF") trong yêu cầu, được thực hiện bằng một số phương tiện khác ngoài xử lý cookie tự động của trình duyệt. Nói một cách lỏng lẻo, sau đó, cookie phiên xác thực người dùng / trình duyệt và mã thông báo CSRF xác thực mã đang chạy trong trình duyệt.

Vì vậy, tóm lại, nếu bạn đang sử dụng cookie phiên để xác thực người dùng ứng dụng web của mình, bạn cũng nên thêm mã thông báo CSRF cho mỗi phản hồi và yêu cầu mã thông báo CSRF phù hợp trong mỗi yêu cầu (đột biến). Mã thông báo CSRF sau đó thực hiện quay vòng từ máy chủ sang trình duyệt trở lại máy chủ, chứng minh cho máy chủ rằng trang thực hiện yêu cầu được chấp thuận bởi (được tạo bởi, thậm chí) máy chủ đó.

Đối với câu hỏi của tôi, đó là về phương thức vận chuyển cụ thể được sử dụng cho mã thông báo CSRF đó trên vòng tròn đó.

Nó có vẻ phổ biến (ví dụ như trong AngularJS , Django , Rails ) để gửi mã thông báo CSRF từ máy chủ đến máy khách dưới dạng cookie (ví dụ: trong tiêu đề Set-Cookie), sau đó có Javascript trong ứng dụng khách loại bỏ nó ra khỏi cookie và đính kèm nó dưới dạng một tiêu đề XSRF-TOKEN riêng biệt để gửi lại cho máy chủ.

(Một phương thức thay thế là một phương pháp được đề xuất bởi vd Express , trong đó mã thông báo CSRF do máy chủ tạo ra được đưa vào phần thân phản hồi thông qua mở rộng mẫu phía máy chủ, được gắn trực tiếp vào mã / đánh dấu sẽ cung cấp lại cho máy chủ, ví dụ: như một đầu vào dạng ẩn. Ví dụ đó là một cách thức hoạt động trên web 1.0, nhưng sẽ khái quát hóa tốt cho một máy khách nặng hơn JS.)

Tại sao nó lại phổ biến để sử dụng Set-Cookie làm phương tiện vận chuyển xuôi dòng cho mã thông báo CSRF / tại sao đây là một ý tưởng tốt? Tôi tưởng tượng các tác giả của tất cả các khung này đã cân nhắc các lựa chọn của họ một cách cẩn thận và đã không hiểu sai điều này. Nhưng thoạt nhìn, việc sử dụng cookie để khắc phục những gì về cơ bản giới hạn thiết kế trên cookie dường như rất tệ. Trên thực tế, nếu bạn đã sử dụng cookie làm vận chuyển khứ hồi (Set-Cookie: xuôi dòng cho máy chủ để thông báo cho trình duyệt mã thông báo CSRF và Cookie: tiêu đề ngược dòng để trình duyệt trả lại cho máy chủ), bạn sẽ giới thiệu lại lỗ hổng cho bạn đang cố gắng sửa chữa.

Tôi nhận ra rằng các khung ở trên không sử dụng cookie cho toàn bộ roundtrip cho mã thông báo CSRF; họ sử dụng Set-Cookie xuôi dòng, sau đó một cái gì đó khác (ví dụ như tiêu đề X-CSRF-Token) ngược dòng và điều này sẽ loại bỏ lỗ hổng. Nhưng ngay cả khi sử dụng Set-Cookie khi vận chuyển xuôi dòng có khả năng gây hiểu lầm và nguy hiểm; giờ đây trình duyệt sẽ đính kèm mã thông báo CSRF cho mọi yêu cầu bao gồm các yêu cầu XSRF độc hại chính hãng; tốt nhất là làm cho yêu cầu lớn hơn yêu cầu và tệ nhất là một đoạn mã máy chủ có ý nghĩa tốt nhưng sai lầm thực sự có thể cố gắng sử dụng nó, điều này thực sự tồi tệ. Và hơn nữa, vì người nhận dự định thực sự của mã thông báo CSRF là Javascript phía máy khách, điều đó có nghĩa là cookie này không thể được bảo vệ chỉ bằng http.

Một lý do chính đáng, mà bạn đã chạm vào, đó là khi đã nhận được cookie CSRF, nó sẽ có sẵn để sử dụng trong toàn bộ ứng dụng trong tập lệnh máy khách để sử dụng ở cả dạng thông thường và AJAX POST. Điều này sẽ có ý nghĩa trong một ứng dụng nặng JavaScript như ứng dụng được AngularJS sử dụng (sử dụng AngularJS không yêu cầu ứng dụng đó sẽ là một ứng dụng trang duy nhất, vì vậy sẽ rất hữu ích khi nhà nước cần chuyển giữa các yêu cầu trang khác nhau trong đó giá trị CSRF thông thường không thể tồn tại trong trình duyệt).

Xem xét các kịch bản và quy trình sau đây trong một ứng dụng điển hình cho một số ưu và nhược điểm của từng phương pháp bạn mô tả. Chúng dựa trên Mẫu mã thông báo đồng bộ hóa .

Yêu cầu phương pháp tiếp cận cơ thể

1. Người dùng đăng nhập thành công.
2. Máy chủ phát hành cookie xác thực.
3. Người dùng nhấp để điều hướng đến một hình thức.
4. Nếu chưa được tạo cho phiên này, máy chủ sẽ tạo mã thông báo CSRF, lưu trữ phiên này với phiên người dùng và đưa nó vào trường ẩn.
5. Người dùng gửi biểu mẫu.
6. Máy chủ kiểm tra trường ẩn khớp với mã thông báo phiên được lưu trữ.

Ưu điểm:

• Đơn giản để thực hiện.
• Hoạt động với AJAX.
• Hoạt động với các hình thức.
• Cookie thực sự có thể chỉ là HTTP .

Nhược điểm:

• Tất cả các hình thức phải xuất trường ẩn trong HTML.
• Bất kỳ POST AJAX nào cũng phải bao gồm giá trị.
• Trang phải biết trước rằng nó yêu cầu mã thông báo CSRF để có thể đưa nó vào nội dung trang để tất cả các trang phải chứa giá trị mã thông báo ở đâu đó, điều này có thể khiến bạn mất thời gian để triển khai cho một trang web lớn.

Tiêu đề HTTP tùy chỉnh (xuôi dòng)

1. Người dùng đăng nhập thành công.
2. Máy chủ phát hành cookie xác thực.
3. Người dùng nhấp để điều hướng đến một hình thức.
4. Tải trang trong trình duyệt, sau đó yêu cầu AJAX được thực hiện để truy xuất mã thông báo CSRF.
5. Máy chủ tạo mã thông báo CSRF (nếu chưa được tạo cho phiên), lưu nó vào phiên người dùng và xuất nó thành tiêu đề.
6. Người dùng gửi biểu mẫu (mã thông báo được gửi qua trường ẩn).
7. Máy chủ kiểm tra trường ẩn khớp với mã thông báo phiên được lưu trữ.

Ưu điểm:

• Hoạt động với AJAX.
• Cookie chỉ có thể là HTTP .

Nhược điểm:

• Không hoạt động mà không có yêu cầu AJAX để nhận giá trị tiêu đề.
• Tất cả các biểu mẫu phải có giá trị được thêm vào HTML của nó một cách linh hoạt.
• Bất kỳ POST AJAX nào cũng phải bao gồm giá trị.
• Trang phải thực hiện yêu cầu AJAX trước tiên để nhận mã thông báo CSRF, vì vậy nó sẽ có nghĩa là một chuyến đi khứ hồi thêm mỗi lần.
• Cũng có thể chỉ cần xuất mã thông báo đến trang sẽ lưu yêu cầu bổ sung.

Tiêu đề HTTP tùy chỉnh (ngược dòng)

1. Người dùng đăng nhập thành công.
2. Máy chủ phát hành cookie xác thực.
3. Người dùng nhấp để điều hướng đến một hình thức.
4. Nếu chưa được tạo cho phiên này, máy chủ sẽ tạo mã thông báo CSRF, lưu trữ phiên này với phiên người dùng và xuất nó trong nội dung trang ở đâu đó.
5. Người dùng gửi biểu mẫu qua AJAX (mã thông báo được gửi qua tiêu đề).
6. Máy chủ kiểm tra tiêu đề tùy chỉnh phù hợp với mã thông báo phiên được lưu trữ.

Ưu điểm:

• Hoạt động với AJAX.
• Cookie chỉ có thể là HTTP .

Nhược điểm:

• Không hoạt động với các hình thức.
• Tất cả các AJAX POST phải bao gồm tiêu đề.

Tiêu đề HTTP tùy chỉnh (ngược dòng & xuôi dòng)

1. Người dùng đăng nhập thành công.
2. Máy chủ phát hành cookie xác thực.
3. Người dùng nhấp để điều hướng đến một hình thức.
4. Tải trang trong trình duyệt, sau đó yêu cầu AJAX được thực hiện để truy xuất mã thông báo CSRF.
5. Máy chủ tạo mã thông báo CSRF (nếu chưa được tạo cho phiên), lưu nó vào phiên người dùng và xuất nó thành tiêu đề.
6. Người dùng gửi biểu mẫu qua AJAX (mã thông báo được gửi qua tiêu đề).
7. Máy chủ kiểm tra tiêu đề tùy chỉnh phù hợp với mã thông báo phiên được lưu trữ.

Ưu điểm:

• Hoạt động với AJAX.
• Cookie chỉ có thể là HTTP .

Nhược điểm:

• Không hoạt động với các hình thức.
• Tất cả các AJAX POST cũng phải bao gồm giá trị.
• Trang phải thực hiện yêu cầu AJAX trước tiên để nhận mã thông báo CRSF, vì vậy nó sẽ có nghĩa là một chuyến đi khứ hồi thêm mỗi lần.

Set-Cookie

1. Người dùng đăng nhập thành công.
2. Máy chủ phát hành cookie xác thực.
3. Người dùng nhấp để điều hướng đến một hình thức.
4. Máy chủ tạo mã thông báo CSRF, lưu trữ theo phiên người dùng và xuất nó thành cookie.
5. Người dùng gửi biểu mẫu qua AJAX hoặc qua biểu mẫu HTML.
6. Máy chủ kiểm tra tiêu đề tùy chỉnh (hoặc trường biểu mẫu ẩn) khớp với mã thông báo phiên được lưu trữ.
7. Cookie có sẵn trong trình duyệt để sử dụng trong AJAX bổ sung và yêu cầu biểu mẫu mà không yêu cầu thêm đến máy chủ để lấy mã thông báo CSRF.

Ưu điểm:

• Đơn giản để thực hiện.
• Hoạt động với AJAX.
• Hoạt động với các hình thức.
• Không nhất thiết yêu cầu yêu cầu AJAX để nhận giá trị cookie. Bất kỳ yêu cầu HTTP nào cũng có thể truy xuất nó và nó có thể được thêm vào tất cả các biểu mẫu / yêu cầu AJAX thông qua JavaScript.
• Khi mã thông báo CSRF đã được truy xuất, vì nó được lưu trữ trong cookie, giá trị có thể được sử dụng lại mà không cần thêm yêu cầu.

Nhược điểm:

• Tất cả các biểu mẫu phải có giá trị được thêm vào HTML của nó một cách linh hoạt.
• Bất kỳ POST AJAX nào cũng phải bao gồm giá trị.
• Cookie sẽ được gửi cho mọi yêu cầu (tức là tất cả các GET cho hình ảnh, CSS, JS, v.v., không liên quan đến quy trình CSRF) tăng kích thước yêu cầu.
• Cookie không thể chỉ là HTTP .

Vì vậy, cách tiếp cận cookie khá năng động cung cấp một cách dễ dàng để truy xuất giá trị cookie (bất kỳ yêu cầu HTTP nào) và sử dụng nó (JS có thể tự động thêm giá trị vào bất kỳ biểu mẫu nào và nó có thể được sử dụng trong các yêu cầu AJAX dưới dạng tiêu đề hoặc dưới dạng giá trị hình thức). Khi mã thông báo CSRF đã được nhận cho phiên, không cần phải tạo lại vì kẻ tấn công sử dụng khai thác CSRF không có phương thức truy xuất mã thông báo này. Nếu người dùng độc hại cố gắng đọc mã thông báo CSRF của người dùng theo bất kỳ phương pháp nào ở trên thì điều này sẽ bị Chính sách nguồn gốc tương tự ngăn chặn . Nếu người dùng độc hại cố truy xuất phía máy chủ mã thông báo CSRF (ví dụ: thông quacurl) sau đó mã thông báo này sẽ không được liên kết với cùng một tài khoản người dùng vì cookie phiên xác thực của nạn nhân sẽ bị thiếu trong yêu cầu (đó sẽ là kẻ tấn công - do đó nó sẽ không được liên kết với phía máy chủ với phiên của nạn nhân).

Cũng như Mẫu mã thông báo đồng bộ hóa cũng có Cookie gửi đôiPhương pháp ngăn chặn CSRF, tất nhiên sử dụng cookie để lưu trữ một loại mã thông báo CSRF. Điều này dễ thực hiện hơn vì nó không yêu cầu bất kỳ trạng thái phía máy chủ nào cho mã thông báo CSRF. Mã thông báo CSRF trên thực tế có thể là cookie xác thực tiêu chuẩn khi sử dụng phương thức này và giá trị này được gửi qua cookie như bình thường với yêu cầu, nhưng giá trị cũng được lặp lại trong trường ẩn hoặc tiêu đề, trong đó kẻ tấn công không thể sao chép như họ không thể đọc giá trị ở vị trí đầu tiên. Tuy nhiên, nên chọn một cookie khác, ngoài cookie xác thực để cookie xác thực có thể được bảo mật bằng cách được đánh dấu httpOnly. Vì vậy, đây là một lý do phổ biến khác khiến bạn tìm thấy phòng ngừa CSRF bằng phương pháp dựa trên cookie.

Sử dụng cookie để cung cấp mã thông báo CSRF cho khách hàng không cho phép tấn công thành công vì kẻ tấn công không thể đọc giá trị của cookie và do đó không thể đặt nó ở nơi xác thực CSRF phía máy chủ yêu cầu.

Kẻ tấn công sẽ có thể gây ra yêu cầu đến máy chủ bằng cả cookie mã thông báo xác thực và cookie CSRF trong các tiêu đề yêu cầu. Nhưng máy chủ không tìm kiếm mã thông báo CSRF dưới dạng cookie trong các tiêu đề yêu cầu, nó đang tìm kiếm trong trọng tải của yêu cầu. Và ngay cả khi kẻ tấn công biết nơi đặt mã thông báo CSRF trong tải trọng, họ sẽ phải đọc giá trị của nó để đặt nó ở đó. Nhưng chính sách nguồn gốc chéo của trình duyệt ngăn việc đọc bất kỳ giá trị cookie nào từ trang web mục tiêu.

Logic tương tự không áp dụng cho cookie xác thực mã thông báo, bởi vì máy chủ dự kiến ​​nó trong tiêu đề yêu cầu và kẻ tấn công không phải làm gì đặc biệt để đặt nó ở đó.

Dự đoán tốt nhất của tôi về câu trả lời: Hãy xem xét 3 tùy chọn này để biết cách đưa mã thông báo CSRF từ máy chủ xuống trình duyệt.

1. Trong phần thân yêu cầu (không phải tiêu đề HTTP).
2. Trong tiêu đề HTTP tùy chỉnh, không phải Set-Cookie.
3. Là một cookie, trong tiêu đề Set-Cookie.

Tôi nghĩ rằng cơ thể thứ nhất, yêu cầu (trong khi được thể hiện bởi hướng dẫn Express mà tôi đã liên kết trong câu hỏi ), không phù hợp với nhiều tình huống khác nhau; không phải ai cũng tạo ra mọi phản hồi HTTP một cách linh hoạt; nơi mà cuối cùng bạn cần đặt mã thông báo vào phản hồi được tạo có thể rất khác nhau (ở dạng đầu vào ẩn; trong một đoạn mã JS hoặc một biến có thể truy cập bằng mã JS khác; để đặt mã thông báo CSRF). Vì vậy, trong khi có thể thực hiện được với một số tùy chỉnh, # 1 là một nơi khó thực hiện cách tiếp cận một kích cỡ phù hợp với tất cả.

Cái thứ hai, tiêu đề tùy chỉnh, rất hấp dẫn nhưng thực sự không hoạt động, bởi vì trong khi JS có thể lấy các tiêu đề cho một XHR mà nó đã gọi, thì nó không thể lấy các tiêu đề cho trang mà nó được tải từ đó .

Điều đó khiến cho cái thứ ba, một cookie được mang theo bởi tiêu đề Set-Cookie, như một cách tiếp cận dễ sử dụng trong mọi tình huống (máy chủ của bất kỳ ai cũng có thể đặt tiêu đề cookie theo yêu cầu và không quan trọng là loại nào dữ liệu trong cơ thể yêu cầu). Vì vậy, mặc dù nhược điểm của nó, nó là phương pháp dễ nhất để các khung công tác triển khai rộng rãi.

Ngoài cookie phiên (loại tiêu chuẩn), tôi không muốn sử dụng cookie bổ sung.

Tôi đã tìm thấy một giải pháp phù hợp với mình khi xây dựng Ứng dụng web một trang (SPA), với nhiều yêu cầu AJAX. Lưu ý: Tôi đang sử dụng Java phía máy chủ và máy khách JQuery, nhưng không có điều kỳ diệu nào nên tôi nghĩ nguyên tắc này có thể được thực hiện trong tất cả các ngôn ngữ lập trình phổ biến.

Giải pháp của tôi không có thêm cookie rất đơn giản:

Phía khách hàng

Lưu trữ mã thông báo CSRF được máy chủ trả về sau khi đăng nhập thành công vào một biến toàn cục (nếu bạn muốn sử dụng lưu trữ web thay vì toàn cầu thì tất nhiên là tốt). Hướng dẫn JQuery cung cấp tiêu đề X-CSRF-TOKEN trong mỗi lệnh gọi AJAX.

Trang "chỉ mục" chính chứa đoạn mã JavaScript này:

// Intialize global variable CSRF_TOKEN to empty sting. 
// This variable is set after a succesful login
window.CSRF_TOKEN = '';

// the supplied callback to .ajaxSend() is called before an Ajax request is sent
$( document ).ajaxSend( function( event, jqXHR ) {
    jqXHR.setRequestHeader('X-CSRF-TOKEN', window.CSRF_TOKEN);
}); 

Phía máy chủ

Khi đăng nhập thành công, hãy tạo mã thông báo CSRF ngẫu nhiên (và đủ dài), lưu trữ mã này trong phiên phía máy chủ và trả lại cho khách hàng. Lọc một số yêu cầu đến (nhạy cảm) nhất định bằng cách so sánh giá trị tiêu đề X-CSRF-TOKEN với giá trị được lưu trữ trong phiên: những giá trị này phải khớp.

Các cuộc gọi AJAX nhạy cảm (dữ liệu dạng POST và dữ liệu GET) và bộ lọc phía máy chủ bắt chúng, nằm dưới đường dẫn / dataervice / *. Yêu cầu đăng nhập không được nhấn bộ lọc, vì vậy những yêu cầu này nằm trên một đường dẫn khác. Các yêu cầu cho tài nguyên HTML, CSS, JS và hình ảnh cũng không nằm trên đường dẫn / dataervice / *, do đó không được lọc. Chúng không chứa gì bí mật và không thể làm hại, vì vậy điều này là tốt.

@WebFilter(urlPatterns = {"/dataservice/*"})
...
String sessionCSRFToken = req.getSession().getAttribute("CSRFToken") != null ? (String) req.getSession().getAttribute("CSRFToken") : null;
if (sessionCSRFToken == null || req.getHeader("X-CSRF-TOKEN") == null || !req.getHeader("X-CSRF-TOKEN").equals(sessionCSRFToken)) {
    resp.sendError(401);
} else
    chain.doFilter(request, response);
}