@xuanan2001

User bị tấn công CSRF

Đúng, tuy nhiên như mình đã nói ở trên, attacker tấn công CSRF không phải attacker có được JWT Token, mà lợi dụng JS để thực thi giúp một vài tính năng, tuy nhiên để sử dụng những tính năng đó attacker cần đọc code html, js để xem những tính năng đó sử dụng như thế nào, ra làm sao, việc này rất tốn thời gian.

Với open source thì có khả năng viết payload nhanh hơn, tuy nhiên với 1 trang private source thì cần phải recon endpoint rất nhiều để có thể tấn công tiếp.

Nếu bạn để ở localStorage và attacker lấy được JWT Token, attacker chỉ việc paste cái JWT Token đó vào browser của attacker và sử dụng tài khoản của bạn tuỳ ý, lúc đó thì attacker k cần đọc code JS hay html và code lại payload XSS làm gì nữa cho mệt người (và bạn không thể chặn được attacker đang tấn công bằng 1 cú click chuột nữa đâu)

@minhtuan.nguy Bị XSS -> CSRF Prevention thất bại -> Attacker chuyển sang tấn công CSRF -> User bị tấn công CSRF.

Cái này có đúng không ạ? Ẩn ý trong việc Attacker có thể tấn công CSRF là Attacker đã có được JWT Token rồi đó ạ. (Hoặc có thể sử dụng JWT Token từ Cookie tuỳ ý)

@xuanan2001 khác chứ bạn, việc lưu trong localStorage khi bị dính XSS thì attacker hoàn toàn có thể lấy được JWT Token và replay attack (tức là có thể login với cái quyền bạn đang có ở cái website đó luôn, giúp attacker có thể khám phá ra nhiều chức năng khác => dẫn đến nhiều lỗi khác nữa). Còn việc lưu ở Cookie sẽ chặn attacker có thể lấy được JWT token, lúc này attacker chỉ có thể dùng JS để truy cập các tính năng khác, tuy nhiên user tắt tab browser đi là attacker khỏi làm gì nữa luôn. Đấy chính là phòng thủ.

@minhtuan.nguy Vâng, không phải là không có ạ. Nhưng nếu theo anh nói, dính XSS, thì anh có CSRF Prevention đến đâu thì cũng thất bại ạ. Nghĩa là anh đang bảo Chắc chắn sẽ bị dính XSS. Em cũng tiếp lời là Bị XSS thì chắc chắn CSRF Prevention là không được. Vậy có đúng không ạ?

Bị XSS thì lưu JWT trong localStorage hay Cookie thì cũng như nhau, vẫn compromised như bình thường.

@xuanan2001 Khá khó chứ k phải là k có bạn ạ ví dụ như postMessage cũng bị dính XSS như thường https://hackerone.com/reports/894518

Việc code ẩu, hay chính trong framework cũng có bug 0-day cũng có thể tồn tại XSS, vậy nên chính mình nên bảo vệ mình trước, đừng dựa dẫm quá

@phuongth

Việc bạn để JWT trong cookie là để bảo vệ nó khỏi XSS chứ không phải để bảo vệ toàn bộ trang web của bạn khỏi XSS.

Nói vậy cũng không đúng lắm ạ. Bị XSS rồi thì đã gọi là Game Over rồi thì họ có tất cả chứ ạ. CSRF Prevention của anh cũng không hoạt động rùi. Có XSS vẫn có khả năng bị make request bất chính chứ ạ?

Chứ không lẽ giờ chỉ vì SQL injection tồn tại và việc set username/password cho DB không giúp bạn tránh khỏi nó thì bạn không cần bảo vệ DB của bạn luôn

Em chưa liên kết được ví dụ của anh lắm. Nhưng bị XSS thì là Game Over, nghĩa là họ làm gì cũng được, CSRF Prevention cũng chịu (according to OWASP), vậy có đúng không ạ? Vậy em chỉ cần chống XSS tốt thôi là ok chứ ạ? Vậy em có quyền dùng localStorage không ạ?

@phuongth Dạ vâng, em hiểu rồi ạ. Nghĩa là dùng Cookie là để tránh trường hợp bị XSS thì bị dùng luôn JWT để làm việc bất chính đúng không ạ?

Nhưng khi dùng framework như React, nếu em làm mọi thứ đúng, sanitize đầy đủ, thì khá khó để bị XSS ạ. Không nói là nó dễ, nhưng nếu nó dễ đến như vậy thì web bây giờ không an toàn đến như thế ạ. Đương nhiên là web bây giờ không tệ đến mức XSS nhan nhản chứ ạ?

https://stackoverflow.com/questions/33644499/what-does-it-mean-when-they-say-react-is-xss-protected

@xuanan2001 Việc bạn để JWT trong cookie là để bảo vệ nó khỏi XSS chứ không phải để bảo vệ toàn bộ trang web của bạn khỏi XSS. Từng cái div, form, input, button của bạn thì có liên quan gì đến cookie đâu, bạn vẫn phải dùng các phương pháp khác để bảo vệ nó chứ. Trên trang web và server của bạn có vô số chỗ để người tấn công có thể inject script vào đấy và với mỗi chỗ thì bạn đều phải có cơ chế bảo vệ khác nhau. Chứ không lẽ giờ chỉ vì SQL injection tồn tại và việc set username/password cho DB không giúp bạn tránh khỏi nó thì bạn không cần bảo vệ DB của bạn luôn 😐️

@xuanan2001 đúng rồi, nó là chống cho XSS k đọc được JWT token để chống tấn công replay attack đó tức là mình phòng bị website của mình khi cuộc tấn công XSS xảy ra ý

@phuongth Vâng ạ. Thì cứ coi như là em dùng Cookie như anh nói đi ạ, implement đầy đủ. Nhưng web của anh bị XSS thì người ta đâu thiếu gì cách phá web anh ạ? XSS là JavaScript, là Game Over đối với web anh rồi ạ. Có thể thêm ads, xoá nội dung, inject link, làm nhiều thứ khác nữa ạ. Vậy anh đang lưu JWT trong cookie thì anh chỉ cho XSS không truy cập JWT thôi, thế anh không fix XSS ạ? Nếu anh fix XSS rồi thì cần gì quan trọng localStorage bị hổng XSS nữa ạ? Hơn nữa, theo trong bài blog của em, em argue là với phương thức làm web modern như bây giờ thì rất khó để bị XSS.

@xuanan2001 Bạn cần phải nhớ là CSRF_TOKEN là để bảo vệ bạn khỏi request từ một domain khác. Nếu request tới từ chính domain của bạn (XSS) thì không có cuộc tấn công CSRF nào ở đây cả nên tất nhiên là CSRF_TOKEN không có tác dụng gì hết. Vậy nên người ta mới nói là với tấn công XSS thì CSRF token chắc chắn không có tác dụng gì cả. Vì mọi người hay hiểu lầm là CSRF_TOKEN là một phần lí do bạn dùng cookie để lưu JWT token. Sự thật là ngược lại, vì bạn lưu JWT token ở cookie nên bạn mới phải thêm CSRF_TOKEN để bảo vệ bạn khỏi một kiểu tấn công khác.

@minhtuan.nguy Khoan hãy nói lưu Token ở đâu ạ. Nếu web của anh bị XSS thì anh có implement CSRF Prevention xịn thế nào thì cũng không thể chống được, nếu OWASP nói đúng. "Chống XSS" của anh ở đây em hiểu là "Chống cho XSS không đọc được JWT" chứ không phải website của anh đã an toàn với XSS ạ. Lúc này token không quan trọng, nó phá UI inject vài cái malware ads là đủ chán rồi ạ.

@xuanan2001 à đương nhiên là mình vẫn cần phải sử dụng 1 lớp bảo vệ chống CSRF nữa, tuy nhiên mình thấy lợi thế hơn là lưu và Cookie vì nó có nhiều tuỳ chọn hơn như set được hết hạn session, ... httpOnly thì chống được XSS đọc được session, CSRF token thì chặn được CSRF, thế nên bạn nên sử dụng cả 2 cái để được bảo vệ tốt nhất

@phuongth Lưu JWT trên Cookie httpOnly không có nghĩa là website của anh an toàn với XSS. XSS bây giờ không đọc được JWT của anh, nhưng có thể đọc được CSRF_TOKEN của anh. Em không rõ XSS lấy được CSRF_TOKEN thì tiếp theo sẽ làm gì, nhưng theo OWASP nói thì bị XSS thì chắc chắn sẽ bị hỏng CSRF Prevention.

Vấn đề của website của anh là website anh đang bị XSS, chứ không phải là token của anh đang lưu ở Cookie httpOnly hay ở đâu đó khác ạ.

@xuanan2001 mình trả lời bạn ở comment dưới nha .

@minhtuan.nguy Nếu anh đặt httpOnly mà không sử dụng CSRF Prevention để chống CSRF thì sẽ bị lỗ hổng CSRF ạ. Mà trong serverless thì OWASP recommend cách "Double Submit Cookie". Mà cách này thì lưu CSRF Token, như anh @phuongth nói, ở đâu đó mà JavaScript có thể đọc được. Vậy là XSS vẫn có thể lấy CSRF Token ra.

@xuanan2001 mình cũng giải thích ở trên rồi ấy, CSRF token không phải để bảo vệ bạn khỏi XSS nên nó có bị ảnh hưởng bới XSS hay không cũng không quan trọng . Nó là để bảo vệ bạn khỏi request tới từ một domain khác vì script từ domain khác không thể truy cập cookie ở domain của bạn.

Nếu token được lưu trong localStorage thì sẽ không có cách nào để ngăn cản script chạy trên chính domain của bạn truy cập nó (XSS). httpOnly cookie là cái bảo vệ bạn khỏi XSS (script được chạy trên chính domain của bạn, có thể truy cập được cookie từ domain của bạn). Tuy nhiên vì cookie luôn được submit theo request nên bạn sẽ bị ảnh hưởng bởi CSRF attack.

Vậy nên bạn mới cần cả 2 cơ chế để bảo vệ. Mỗi cái sẽ bảo vệ bạn khỏi một kiểu tấn công.

@phuongth Anh đang sử dụng một phương pháp chống CSRF ạ. Và nếu sử dụng CSRF Prevention thì OWASP có dòng này để nói ạ:

Remember that any Cross-Site Scripting (XSS) can be used to defeat all CSRF mitigation techniques!

Vậy tại sao lại không sử dụng localStorage vì nó bị XSS, trong khi CSRF Prevention của anh có thể bị failed vì XSS ạ?

@xuanan2001 Ùm nhỉ mình quên mất cái này sorry bạn rất nhiều

Vấn đề này thì để đảm bảo an toàn thì vẫn set JWT vào Cookie đặt cờ httpOnly nhưng mà server phải xác thực bằng Cookie chứ k bằng header Authorization nữa , vì mấu chốt là chỉ có server là cần đọc cái giá trị JWT token để xác thực thôi

Server sẽ tự set cookie tự đọc thôi, browser sẽ k cần quan tâm đến nó nữa.

@phuongth Em cảm ơn trả lời của anh ạ!

Theo em thấy thì cách anh nói là đang sử dụng một cái CSRF_TOKEN để làm một CSRF Prevention. Vậy cách của anh có miễn nhiễm với XSS không ạ?

Remember that any Cross-Site Scripting (XSS) can be used to defeat all CSRF mitigation techniques!

Nếu CSRF Prevention của anh không miễn nhiễm với XSS, thì tại sao lại có ác cảm với việc sử dụng localStorage sẽ bị XSS vậy ạ?