Mã thông báo CSRF cần thiết khi sử dụng Xác thực không trạng thái (= Không phiên)?

Có cần thiết phải sử dụng Bảo vệ CSRF khi ứng dụng dựa vào xác thực không trạng thái (sử dụng thứ gì đó như HMAC) không?

Thí dụ:

• Chúng tôi đã có một ứng dụng trang duy nhất (nếu không chúng ta phải thêm mã thông báo mỗi liên kết: <a href="...?token=xyz">...</a>.

• Người dùng tự xác thực bằng cách sử dụng POST /auth. Khi xác thực thành công, máy chủ sẽ trả về một số mã thông báo.

• Mã thông báo sẽ được lưu trữ qua JavaScript trong một số biến bên trong ứng dụng trang đơn.

• Mã thông báo này sẽ được sử dụng để truy cập các URL bị hạn chế như /admin.

• Mã thông báo sẽ luôn được truyền bên trong Tiêu đề HTTP.

• KHÔNG CÓ Phiên Http và KHÔNG CÓ Cookie.

Theo như tôi hiểu, không nên (?!) Không có khả năng sử dụng các cuộc tấn công chéo trang web, bởi vì trình duyệt sẽ không lưu trữ mã thông báo và do đó nó không thể tự động gửi nó đến máy chủ (đó là điều sẽ xảy ra khi sử dụng Cookie / Phiên).

Tui bỏ lỡ điều gì vậy?

Tôi đã tìm thấy một số thông tin về CSRF + không sử dụng cookie để xác thực:

1. https://auth0.com/blog/2014/01/07/angularjs-authentication-with-cookies-vs-token/
   "vì bạn không dựa vào cookie, bạn không cần phải bảo vệ khỏi các yêu cầu trang web chéo"

2. http://angular-tips.com/blog/2014/05/json-web-tokens-introduction/
   "Nếu chúng tôi sử dụng cookie, bạn thực sự cần thực hiện CSRF để tránh các yêu cầu trên nhiều trang web. Đó là điều chúng tôi có thể quên khi sử dụng JWT như bạn sẽ thấy. "
   (JWT = Json Web Token, xác thực dựa trên Token cho các ứng dụng không trạng thái)

3. http://www.jamesward.com/2013/05/13/securing-single-page-apps-and-rest-services
   "Cách dễ nhất để xác thực mà không gặp rủi ro về lỗ hổng CSRF là chỉ cần tránh sử dụng cookie để xác định người dùng "

4. http://sitr.us/2011/08/26/cookies-are-bad-for-you.html
   "Vấn đề lớn nhất với CSRF là cookie hoàn toàn không có khả năng bảo vệ chống lại kiểu tấn công này. Nếu bạn đang sử dụng xác thực cookie bạn cũng phải sử dụng các biện pháp bổ sung để bảo vệ khỏi CSRF. Biện pháp phòng ngừa cơ bản nhất mà bạn có thể thực hiện là đảm bảo rằng ứng dụng của bạn không bao giờ thực hiện bất kỳ tác dụng phụ nào theo yêu cầu GET. "

Có rất nhiều trang khác, trong đó nói rằng bạn không cần bất kỳ bảo vệ CSRF nào, nếu bạn không sử dụng cookie để xác thực. Tất nhiên bạn vẫn có thể sử dụng cookie cho mọi thứ khác, nhưng tránh lưu trữ bất cứ thứ gì như session_idbên trong nó.

Nếu bạn cần ghi nhớ người dùng, có 2 lựa chọn:

1. localStorage: Kho lưu trữ khóa-giá trị trong trình duyệt. Dữ liệu được lưu trữ sẽ khả dụng ngay cả sau khi người dùng đóng cửa sổ trình duyệt. Các trang web khác không thể truy cập dữ liệu vì mỗi trang web đều có bộ nhớ riêng.

2. sessionStorage: Cũng là một kho dữ liệu trong trình duyệt. Sự khác biệt là: Dữ liệu bị xóa khi người dùng đóng cửa sổ trình duyệt. Nhưng nó vẫn hữu ích, nếu ứng dụng web của bạn bao gồm nhiều trang. Vì vậy, bạn có thể làm như sau:

   • Người dùng đăng nhập, sau đó bạn lưu trữ mã thông báo vào sessionStorage
   • Người dùng nhấp vào một liên kết sẽ tải một trang mới (= một liên kết thực và không có nội dung javascript thay thế)
   • Bạn vẫn có thể truy cập mã thông báo từ sessionStorage
   • Để đăng xuất, bạn có thể xóa thủ công mã thông báo khỏi sessionStoragehoặc đợi người dùng đóng cửa sổ trình duyệt, thao tác này sẽ xóa tất cả dữ liệu được lưu trữ.

(cho cả hai, hãy xem tại đây: http://www.w3schools.com/html/html5_webstorage.asp )

Có bất kỳ tiêu chuẩn chính thức nào cho xác thực mã thông báo không?

JWT (Json Web Token): Tôi nghĩ nó vẫn là một bản nháp, nhưng nó đã được nhiều người sử dụng và khái niệm này trông đơn giản và an toàn. (IETF: http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-25 )
Cũng có sẵn các thư viện cho rất nhiều khuôn khổ. Chỉ cần google cho nó!

TL; DR

JWT, nếu được sử dụng mà không có Cookie, sẽ phủ nhận sự cần thiết phải có mã thông báo CSRF - NHƯNG! bằng cách lưu trữ JWT trong session / localStorage, bạn sẽ tiết lộ JWT và danh tính người dùng nếu trang web của bạn có lỗ hổng XSS (khá phổ biến). Tốt hơn là thêm một csrfTokenkhóa vào JWT và lưu trữ JWT trong một cookie với securevà http-onlythuộc tính được đặt.

Đọc bài viết này với mô tả tốt để biết thêm thông tin https://stormpath.com/blog/where-to-store-your-jwts-cookies-vs-html5-web-storage

Bạn có thể làm cho bảo vệ CSRF này không có trạng thái bằng cách bao gồm một yêu cầu JWT xsrfToken:

{ "iss": "http://galaxies.com", "exp": 1300819380, "scopes": ["explorer", "solar-harvester", "seller"], "sub": "tom@andromeda.com", "xsrfToken": "d9b9714c-7ac0-42e0-8696-2dae95dbc33e" }

Vì vậy, bạn sẽ cần lưu trữ csrfToken trong localStorage / sessionStorage cũng như trong chính JWT (được lưu trữ trong một cookie chỉ http và an toàn). Sau đó, để bảo vệ csrf, hãy xác minh rằng mã thông báo csrf trong JWT khớp với tiêu đề mã thông báo csrf đã gửi.