Khi sử dụng unoconv thì báo lỗi như thế nào vậy bạn ?

Tks Anh zaiii 😜

thanks. e.

A nghĩ là làm ở đâu cũng được, miễn là e thấy vui 😁

bây giờ bạn đang làm việc tại Nhật hay Vn vậy!

bonus thêm: ở các phiên bản java mới hình như là từ java11 thì phải, interface đã có thêm access modifiers là default và static và có thể thêm body cho các phương thức sử dụng 2 access Modifiers này!

kiểu type bạn hiểu nôm na giống như cái table của sql vậy, nhưng nó cũng sẽ có nhiều cái khác với table của sql. bạn có thể đọc qua link này để hiểu hơn nhá: https://stackoverflow.com/questions/36649113/what-does-the-type-mean-in-elasticsearch

Cassandra không có where "or". Nên khi thiết kế hệ thống mà dùng database này thì các bạn nên chú ý.

@huytuchim789 phải đăng nhập mới thấy được full comments b ơi.

thanks bác

Bài viết hay quá, cảm ơn bạn nhiều, hy vọng bạn sẽ ra thêm nhiều bài viết hữu ích như vậy

đơn giản dễ hiểu

Domain Driven Desgin pattern cũng có ứng dụng kiến trúc lục giác này, code mà sử dụng DDD thì cực ngon

@xuanan2001 mình hiểu scenario của bạn. Nhưng bản chất nó là cuộc tấn công XSS thôi. Csrf bảo vệ được bạn vì form request từ domain khác không thể lấy csrf token từ cookie ra và submit lên được. Khi nó chạy từ chính domain của bạn thì nó không gọi là csrf attack vì script hoàn toàn truy cập được csrf token trong cookie. Việc lấy nó ra và gửi lên chỉ là một bước yêu cầu thôi. Từ cái tên thì bạn cũng thấy đây không phải là csrf attack rồi vì nó đến từ chính domain của bạn.

@xuanan2001 Mình túm lại nhé

• Việc bạn để JWT vào cookie chính xác là để hacker không lấy được nó ra. Nó là để bảo vệ bạn khi cuộc tấn công XSS đã xảy ra rồi, không phải là để bảo vệ bạn khỏi cuộc tấn công XSS. Khi bạn bị XSS thì tất nhiên hacker sẽ sử dụng được cookie của bạn rồi, nó là mục đích của XSS mà.
• CSRF không liên quan gì đến việc này, nó là để bảo vệ khi bạn bị CSRF attack, nếu bạn cảm thấy bạn không bị CSRF attack hoặc không quan tâm đến việc bị CSRF attack thì bạn bỏ qua nó cũng không ảnh hưởng gì đến mục đích của việc lưu JWT trong cookie.
• Việc bạn bị mất JWT lại là một lỗ hổng khác và nó có thể được khai thác bởi XSS chứ không phải chỉ là side-effect như bạn nghĩ. Như mình nói thì bạn có thể có những lớp bảo mật khác cho JWT và lưu nó trong httpOnly cookie là một trong số những lớp bảo mật đấy. Tùy security measure của bạn mà bạn lựa chọn những lớp bảo mật nào. Mình cũng ví dụ trường hợp nào bạn cần lớp bảo mật này rồi.

@phuongth Đây là thứ em muốn nói ạ: https://portswigger.net/web-security/cross-site-scripting/exploiting/lab-perform-csrf

Nếu anh rảnh có thể xem qua và phân tích cách làm này ạ. Em thấy khá giống thứ em muốn nói.

@phuongth Anh đã đọc scenario của em chưa ạ? Anh có thể phân tích theo cái scenario trên đó ạ. Em nghĩ đến đây thì nó cũng lòng vòng và hơi dài rồi ạ.

Để 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 Scenario trên không cần chuyển trang khác anh ạ. Em bảo "lấy về" là "lấy về script" ạ. Em xin lỗi vì làm anh hiểu nhầm. Và em không cần lấy nó ra ạ. Mong anh đọc lại câu trả lời của em.

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

Em đồng ý cách của em không tốt. Em có thể expire các thứ như anh nói, ok ạ.

Quá hay, người chưa viết test bao giờ như em cảm thấy rất cuốn hút. Cho khả năng tạo ra sản phẩm chất lượng.

@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.