@xuanan2001 Khi bạn XSS được rồi mà bạn còn phải cho user đi sang trang khác để CSRF nữa sao . Quan trọng là bạn tập trung vào điểm này nè. JWT của bạn không bị lấy cắp khi bị XSS nếu bạn để trong httpOnly cookie. Kể cả khi bạn tấn công CSRF sau khi đã XSS thì vẫn không lấy nó ra được. Nếu hacker lấy được JWT thì nó lại là một lỗi hoàn toàn khác. Và nó có thể được sử dụng cho các cuộc tấn công sau. Khi XSS thì bạn đã game over rồi. Nhưng nếu để lộ token thì game sau bạn cũng game over luôn.

Em có thể blacklist JWT nếu JWT của user bị compromised.

Đây chính là mất bò mới lo làm chuồng bạn ạ. Như mình đã nói bạn có thể có các phương pháp khác để bảo vệ JWT như set expire time ngắn, hoặc khi nào biết bị mất thì mới revoke như bạn chẳng hạn. Ở trường hợp này thì bạn mới có thể xem nó là 2 lớp bảo mật cho cùng một lỗ hổng. Nhưng nếu lớp kia bạn không kiểm soát được thì sao. Nếu token bạn sử dụng không nằm trong tầm kiểm soát của bạn mà do bên thứ ba cung cấp thì sao. Nếu API bạn sử dụng không cho phép revoke mà chỉ check expire time của JWT mà trước đó để code cho tiện bạn đã lỡ set expire time lên đến 1 năm thì sao. Vậy nên mới đẻ ra cái lớp bảo vệ mà bạn có thể hoàn toàn kiểm soát được kia, nên nó mới được recommend. Tất nhiên như mình đã nói, nếu bạn chắc chắn với 1 lớp bảo vệ kia rồi thì bạn có thể không cần quan tâm nữa, tùy theo security measure của bạn thôi. Quan trọng là bạn phải biết về nguy cơ để lộ JWT và việc bị XSS là hai thứ hoàn toàn khác nhau. Để lộ JWT nếu bạn không bảo vệ nó là một hậu quả của việc bạn bị XSS và bạn phải xử lý hậu quả đó.

Để làm rõ hơn việc chuyển từ tấn công XSS sang tấn công CSRF, em có thể ví dụ thế này:

Em lấy CSRF Token của anh trong localStorage về (Cookie mà không httpOnly thì cũng lấy được). Sau đó, XSS của em thực hiện một malicious HTTP POST có kèm CSRF Token này (Bởi vì nếu không có CSRF Token thì sẽ không make request được). Ở đây em không cần từ một domain khác, em vẫn có thể make request được. CSRF là chống khi em gửi request ở domain khác (social engineeering) thì cookie sẽ gửi kèm, nên nó gọi là "Cross-Site". Em đang thực hiện request "Cùng site" từ XSS, nhưng em vẫn cần CSRF Token để thực hiện request.

@phuongth Đầu tiên em trả lời argument của anh về việc này trước:

JWT token bạn dùng để authenticate tương đương với username/password của user. Khi bị XSS mà bạn không để lộ JWT thì bạn fix XSS là xong. Nhưng nếu bạn bị lộ JWT mà không có cơ chế bảo vệ nào khác thì hacker đã có trong tay toàn bộ thông tin login của user.

• Em có thể blacklist JWT nếu JWT của user bị compromised.
• Em không có JWT không có nghĩa là em không sử dụng JWT của user được. Bằng XSS, em có thể make request và gửi đi, và browser sẽ attach Cookie cho em, đó chính là username/password của người dùng. Anh có giấu JWT vào cookie, thì em cũng dùng được thôi ạ. httpOnly cũng không cản được, SameSite cũng không cản được.

Bạn có hiểu CSRF là gì chưa ạ. Nó là một kiểu tấn công hoàn toàn không cần inject bất cứ một script nào vào trang web của bạn, và nó được thực hiện từ một domain khác. Khi bạn bị XSS thì bạn bị tấn công từ chính domain của bạn nên nó không phải là cuộc tấn công CSRF. Tất nhiên CSRF chẳng bảo vệ bạn khỏi cái gì khi bạn bị XSS cả.

Mong anh biết là em đã đọc cái này rất nhiều và không cần anh nhắc lại định nghĩa ạ.

Khi em bị tấn công XSS, em có thể phá tất cả các loại CSRF Prevention của anh. Sau đó, em thực hiện tấn công CSRF. Nghĩa là từ XSS, em chuyển sang tấn công CSRF.

Đây chính là cái reminder to tướng mà mình nhắc đi nhắc lại với bạn từ nãy đấy. Khi bạn bị XSS thì CSRF chẳng giúp gì cho bạn cả. Vì nó là để bảo vệ bạn khỏi kiểu tấn công khác.

Vâng. Mong anh sử dụng CSRF và CSRF Prevention để đỡ hiểu nhầm. CSRF Prevention của anh bảo vệ anh khỏi CSRF. Nhưng nếu em tấn công XSS anh, em có thể vô hiệu hoá các CSRF Preventions của anh, và tấn công CSRF. Như vậy có rõ ràng không ạ?

ông toằn ơi ông có thể cho cháu lại link của pretrained model của ông không, link trong bài viết cháu k tải lại đc nữa

@xuanan2001 Bạn có hiểu CSRF là gì chưa ạ. Nó là một kiểu tấn công hoàn toàn không cần inject bất cứ một script nào vào trang web của bạn, và nó được thực hiện từ một domain khác. Khi bạn bị XSS thì bạn bị tấn công từ chính domain của bạn nên nó không phải là cuộc tấn công CSRF. Tất nhiên CSRF chẳng bảo vệ bạn khỏi cái gì khi bạn bị XSS cả.

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

Đây chính là cái reminder to tướng mà mình nhắc đi nhắc lại với bạn từ nãy đấy. Khi bạn bị XSS thì CSRF chẳng giúp gì cho bạn cả. Vì nó là để bảo vệ bạn khỏi kiểu tấn công khác.

Bạn đọc đoạn mình giải thích về việc tại sao lại phải bảo vệ JWT của bạn chưa

Mình nói rõ hơn chút 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 thể bị lấy cắp bởi XSS. Và đây là một lỗi hoàn toàn khác chứ không phải là cùng một lỗi với XSS. JWT token bạn dùng để authenticate tương đương với username/password của user. Khi bị XSS mà bạn không để lộ JWT thì bạn fix XSS là xong. Nhưng nếu bạn bị lộ JWT mà không có cơ chế bảo vệ nào khác thì hacker đã có trong tay toàn bộ thông tin login của user.

Bởi vì nó là một lỗi hoàn toàn khác. Bạn đã để mất toàn bộ thông tin login của user. Kể cả bạn có fix xong XSS thì lỗi này vẫn còn ở đó và nó không liên quan gì đến nhau. XSS chỉ là một phương pháp để hacker khai thác lỗ hổng này thôi.

@minhtuan.nguy

Có 2 lớp phòng thủ nó vẫn xịn hơn là 1, mình nghĩ thế.

Vâng. Argument này thì em có thể hiểu được. Em vẫn giữ quan điểm là cái gốc rễ vẫn ở XSS. Em có thể lưu JWT vào localStorage và sống khá bình thường, vì em biết em mà có bị attack XSS thì các site khác dùng Cookie cũng bị XSS như em thôi (và sẽ có ngày bị exploit CSRF), nếu cả hai team làm ra 2 web đều biết mình đang làm gì.

Em nghĩ so với việc implement Cookie thì em sẽ chọn localStorage và stay up to date với các lỗ hổng XSS hơn là dùng Cookie, nó thêm một tầng phức tạp, em không thích.

@phuongth

Mình nói rõ thêm lần nữa là CSRF không liên quan gì đến XSS cả, nó dùng để bảo vệ bạn khỏi một kiểu tấn công khác. Khi bạn bị XSS thì CSRF không có vai trò gì ở đây hết.

Anh đã đọc cái em gửi chưa ạ?

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

Em không cần biết JWT của user. Browser nó tự gửi cho em, vì em đang CSRF ạ.

@xuanan2001 Như mình đã nói ở trên

Nó là một cách phòng thủ để làm khó attacker, còn nếu bạn muốn thì bạn có thể sử dụng, không thì thôi, không ai ép bạn phải sử dụng làm gì cả

Có 2 lớp phòng thủ nó vẫn xịn hơn là 1, mình nghĩ thế.

@xuanan2001 Mình nói rõ hơn chút 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 thể bị lấy cắp bởi XSS. Và đây là một lỗi hoàn toàn khác chứ không phải là cùng một lỗi với XSS. JWT token bạn dùng để authenticate tương đương với username/password của user. Khi bị XSS mà bạn không để lộ JWT thì bạn fix XSS là xong. Nhưng nếu bạn bị lộ JWT mà không có cơ chế bảo vệ nào khác thì hacker đã có trong tay toàn bộ thông tin login của user.

Mình nói rõ thêm lần nữa là CSRF không liên quan gì đến XSS cả, nó dùng để bảo vệ bạn khỏi một kiểu tấn công khác. Khi bạn bị XSS thì CSRF không có vai trò gì ở đây hết.

@minhtuan.nguy Còn việc em cân nhắc nên dùng hay không thì em cũng đang xem xét ạ. Em thấy chưa đủ thuyết phục, vì Cookie thì vẫn bị attack thôi.

@xuanan2001 ùm nhưng với việc victim k tắt browser đi, còn nếu victim tắt browser đi thì sao bạn, bạn làm gì còn gì nữa đâu mà khóc với sầu

@minhtuan.nguy App em là app Client-side chứ không phải là check role Admin rồi gửi trang web về cho React hiện ạ.

Hack ngân hàng hay Google account thì 2 năm hay 3 năm cũng không lâu đâu ạ.

Anh có thể argue là em nên làm như kiểu có role admin thì gửi web về có các endpoint. Em nghĩ architecture này hơi lạ với em ạ.

Em hack CSRF, em có thể dùng JWT mà không cần biết JWT. Giờ em HTTP GET để crawl các kiểu. Tính đến đây đã ạ, vì anh biết web anh đang bị rất nhiều vấn đề khi bị exploit đến đây chưa ạ?

@phuongth

Để mình sửa lại nhé. Lưu vào localStorage thì bị XSS, còn lưu vào cookie thì không bị XSS nhưng có thể bị CSRF, và CSRF có thể tránh được với CSRF token.

Câu này chưa đủ và chưa đúng ạ. Lưu vào Cookie thì web anh vẫn bị XSS như bình thường, chỉ là không thấy JWT đâu cả. Mà đã XSS rồi thì không thể tránh được với CSRF token.

@xuanan2001 ừ đấy là bạn có 1 năm, mình k có thời gian làm việc đó

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 ạ?

Bạn chưa nghĩ đến việc mình chôm được acc của admin hay sao, đương nhiên có những endpoint mà bạn không biết rồi

Nó là một cách phòng thủ để làm khó attacker, còn nếu bạn muốn thì bạn có thể sử dụng, không thì thôi, không ai ép bạn phải sử dụng làm gì cả

đọ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 ạ. 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 ạ.