@xuanan2001 Để mình sửa lại nhé. Lưu vào localStorage thì có thể bị lấy cắp bởi XSS, còn lưu vào cookie thì không bị lấy cắp bởi XSS nhưng có thể bị CSRF, và CSRF có thể tránh được với CSRF token. Vấn đề không phải là làm nó khó hơn để hack mà nó là một lỗi hoàn toàn khác. Khi hacker có được JWT mà bạn không có cơ chế bảo vệ nào khác (timeout như mình đã nói ở trên chẳng hạn) thì kể cả bạn có fix xong XSS thì hacker vẫn có thể dùng JWT để thực hiện request như thường. 2 lỗi khác nhau hoàn toàn, script injection và authentication chứ không phải là một. Vậy nên mình mới đưa ra cho bạn ví dụ về SQL injection và để lộ authentication của DB đó.
@minhtuan.nguy Analogy này không hợp lệ ạ. Trong trường hợp anh hack được JWT từ localStorage, anh có biết được endpoint em đang sử dụng có những gì không ạ?
@phuongth Lại quay lại với ví dụ JWT ạ. localStorage thì bị XSS, còn Cookie thì bị XSS + CSRF. Và anh có chống CSRF thế nào đi nữa mà bị XSS thì anh cũng failed. Anh failed rồi thì còn gì để nói đâu ạ? "Khó hơn để hack" không phải là cách để giải quyết vấn đề ạ. Nếu anh là Facebook hay Google gì đó thì không bao giờ là "Khó hơn" cả ạ. Cách của anh làm thì vẫn có attacker attack được thôi ạ.
@xuanan2001 nhưng mà tên trộm k biết nhà bạn có cái gì, đi như thế nào, phải chờ em bé quay ra nói mới biết, nó mất thời gian, và khi em bé đấy k có quyền vào nhà bạn nữa thì bạn bó tay đúng k
@minhtuan.nguy Vâng, khó khăn không phải là không làm được ạ. Vấn đề trong ví dụ của anh là tên trộm lại có thể bảo em bé làm những việc tên trộm muốn.
@xuanan2001 Vì bạn hỏi tại sao lại phải bảo vệ JWT trong khi có một vấn đề to hơn là XSS nên mình lấy một ví dụ tương tự thôi. Cả 2 lỗi XSS/SQL injection đều là game over, để lộ JWT/DB authentication cũng là game over, thế đâu có nghĩa là bạn chỉ cần bảo vệ một cái vì đằng nào cũng là game over. Tất nhiên là nếu bạn có những cơ chế khác để bảo vệ JWT và không cần không quan tâm đến việc người ta có thể lấy trộm JWT và đem đi request thoải mái sau này kể cả khi bạn đã fix song XSS thì bạn không cần quan tâm đến việc bảo vệ nó khỏi XSS. Ví dụ như token của bạn có timeout là 30 phút thôi chẳng hạn. Vấn đề vẫn là bạn phải bảo vệ được JWT của bạn, chứ không phải là bỏ qua không cần quan tâm vì đằng nào cũng bị XSS.
Các framework hiện đại thì có rất nhiều cơ chế để giúp bạn bảo mật, nhưng cũng không có nghĩa là không bao giờ có. Chỉ riêng với lỗi XSS bạn có thể xem Vue đã bị dính tới 3 lần ở bản 2.x https://snyk.io/vuln/npm:vue. Nếu bạn xem trên npm thì những phiên bản này vẫn có vài chục nghìn lượt tải mỗi tuần, vậy bạn có thể tự suy ra xem các trang web bị XSS liệu có nhan nhản hay không. Và kể cả khi các thư viện mà bạn trực tiếp sử dụng không có lỗi gì thì những vụ tấn công supply chain vẫn nhan nhản ra đấy với vài tháng lại một vụ hoặc đôi khi là vài vụ một tháng. Thế nên tự bảo vệ mình khỏi những tai họa có thể xảy ra trong tương lai chẳng bao giờ là thừa cả.
@xuanan2001 nó giống cái việc 1 tên trộm có chìa khoá vào nhà của bạn, tên trộm đó muốn làm gì trong nhà của bạn cũng được, nhưng mà việc tên trộm không vào được nhà của bạn và sai 1 em bé được vào nhà của bạn và hành động giống những gì tên trộm đó sai bảo sẽ khó khăn hơn. Cái này chắc để bạn đánh giá thôi
@minhtuan.nguy Argument này của anh có thể áp dụng tương tự với việc JWT ở localStorage bị compromise ạ. Có JWT thì anh cũng chưa chắc make được cái request ạ.
@xuanan2001 Đúng rồi, nhưng mà việc đấy là do browser của người bị tấn công request, nhưng mà nó k xịn bằng việc bạn có JWT token của người bị tấn công, đúng không?
Và cái việc make request đó tốn thời gian và không chắc nó đã chạy được với các endpoint mà bạn không biết
@minhtuan.nguy Cũng như trong blog em nói đó ạ. Tốn thời gian không phải là không thể. Và vấn đề của web anh là chống XSS chứ không phải chống lấy JWT.
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
Không đúng. Attacker hoàn toàn có thể make request y hệt như cách mà Attacker tấn công khi biết JWT. Cứ craft một HTTP POST request, và gửi lên server. Attacker không cần biết JWT, browser gửi cho attacker. HTTP POST request đó vẫn được duyệt.
Đú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.
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ứ ạ?
THẢO LUẬN
đọc xong không hiểu gì luôn
@minhtuan.nguy Em có thể dành 1 năm để nghiên cứu xem các endpoint của Facebook có thể làm là gì. Sau đó viết script.
Anh login vào account của user thì làm gì ạ? Anh bấm nút thì có phải là gọi endpoint giống y hệt acc của em không ạ?
Em đang dùng client-side app. XSS là thấy hết endpoint ạ.
@xuanan2001 Để mình sửa lại nhé. Lưu vào localStorage thì có thể bị lấy cắp bởi XSS, còn lưu vào cookie thì không bị lấy cắp bởi XSS nhưng có thể bị CSRF, và CSRF có thể tránh được với CSRF token. Vấn đề không phải là làm nó khó hơn để hack mà nó là một lỗi hoàn toàn khác. Khi hacker có được JWT mà bạn không có cơ chế bảo vệ nào khác (timeout như mình đã nói ở trên chẳng hạn) thì kể cả bạn có fix xong XSS thì hacker vẫn có thể dùng JWT để thực hiện request như thường. 2 lỗi khác nhau hoàn toàn, script injection và authentication chứ không phải là một. Vậy nên mình mới đưa ra cho bạn ví dụ về SQL injection và để lộ authentication của DB đó.
@xuanan2001 NHƯ MÌNH ĐÃ NÓI Ở BÊN TRÊN
Sử dụng replay attack và truyền JWT token đã lấy được vào localStorage, load lại trang thì đã vào được acc của victim rồi
@minhtuan.nguy Analogy này không hợp lệ ạ. Trong trường hợp anh hack được JWT từ
localStorage, anh có biết được endpoint em đang sử dụng có những gì không ạ?@phuongth Lại quay lại với ví dụ JWT ạ.
localStoragethì bị XSS, còn Cookie thì bị XSS + CSRF. Và anh có chống CSRF thế nào đi nữa mà bị XSS thì anh cũng failed. Anh failed rồi thì còn gì để nói đâu ạ? "Khó hơn để hack" không phải là cách để giải quyết vấn đề ạ. Nếu anh là Facebook hay Google gì đó thì không bao giờ là "Khó hơn" cả ạ. Cách của anh làm thì vẫn có attacker attack được thôi ạ.@xuanan2001 nhưng mà tên trộm k biết nhà bạn có cái gì, đi như thế nào, phải chờ em bé quay ra nói mới biết, nó mất thời gian, và khi em bé đấy k có quyền vào nhà bạn nữa thì bạn bó tay đúng k
@minhtuan.nguy Vâng, khó khăn không phải là không làm được ạ. Vấn đề trong ví dụ của anh là tên trộm lại có thể bảo em bé làm những việc tên trộm muốn.
@xuanan2001 Vì bạn hỏi tại sao lại phải bảo vệ JWT trong khi có một vấn đề to hơn là XSS nên mình lấy một ví dụ tương tự thôi. Cả 2 lỗi XSS/SQL injection đều là game over, để lộ JWT/DB authentication cũng là game over, thế đâu có nghĩa là bạn chỉ cần bảo vệ một cái vì đằng nào cũng là game over. Tất nhiên là nếu bạn có những cơ chế khác để bảo vệ JWT và không cần không quan tâm đến việc người ta có thể lấy trộm JWT và đem đi request thoải mái sau này kể cả khi bạn đã fix song XSS thì bạn không cần quan tâm đến việc bảo vệ nó khỏi XSS. Ví dụ như token của bạn có timeout là 30 phút thôi chẳng hạn. Vấn đề vẫn là bạn phải bảo vệ được JWT của bạn, chứ không phải là bỏ qua không cần quan tâm vì đằng nào cũng bị XSS.
Các framework hiện đại thì có rất nhiều cơ chế để giúp bạn bảo mật, nhưng cũng không có nghĩa là không bao giờ có. Chỉ riêng với lỗi XSS bạn có thể xem Vue đã bị dính tới 3 lần ở bản 2.x https://snyk.io/vuln/npm:vue. Nếu bạn xem trên npm thì những phiên bản này vẫn có vài chục nghìn lượt tải mỗi tuần, vậy bạn có thể tự suy ra xem các trang web bị XSS liệu có nhan nhản hay không. Và kể cả khi các thư viện mà bạn trực tiếp sử dụng không có lỗi gì thì những vụ tấn công supply chain vẫn nhan nhản ra đấy với vài tháng lại một vụ hoặc đôi khi là vài vụ một tháng. Thế nên tự bảo vệ mình khỏi những tai họa có thể xảy ra trong tương lai chẳng bao giờ là thừa cả.
@xuanan2001 nó giống cái việc 1 tên trộm có chìa khoá vào nhà của bạn, tên trộm đó muốn làm gì trong nhà của bạn cũng được, nhưng mà việc tên trộm không vào được nhà của bạn và sai 1 em bé được vào nhà của bạn và hành động giống những gì tên trộm đó sai bảo sẽ khó khăn hơn. Cái này chắc để bạn đánh giá thôi
@minhtuan.nguy Argument này của anh có thể áp dụng tương tự với việc JWT ở
localStoragebị compromise ạ. Có JWT thì anh cũng chưa chắc make được cái request ạ.@xuanan2001 Đúng rồi, nhưng mà việc đấy là do browser của người bị tấn công request, nhưng mà nó k xịn bằng việc bạn có JWT token của người bị tấn công, đúng không? Và cái việc make request đó tốn thời gian và không chắc nó đã chạy được với các endpoint mà bạn không biết
@minhtuan.nguy Cũng như trong blog em nói đó ạ. Tốn thời gian không phải là không thể. Và vấn đề của web anh là chống XSS chứ không phải chống lấy JWT.
Không đúng. Attacker hoàn toàn có thể make request y hệt như cách mà Attacker tấn công khi biết JWT. Cứ craft một HTTP POST request, và gửi lên server. Attacker không cần biết JWT, browser gửi cho attacker. HTTP POST request đó vẫn được duyệt.
@xuanan2001
Đú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ư
postMessagecũng bị dính XSS như thường https://hackerone.com/reports/894518Việ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
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ứ ạ?
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
localStoragekhô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