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

@xuanan2001 JWT của bạn để trong cookie thì sẽ được browser tự động gửi lên server chứ không cần bạn lấy nó ra để thêm vào header nữa. Cái bạn cần lấy ra để thêm vào header là cái CSRF token cơ .

@minhtuan.nguy Dạ vâng ạ. Em gửi JWT bằng Header Authorization, mà muốn gửi như vậy thì phải để JWT có thể đọc được ở trong JavaScript để thêm vào request header chứ ạ? Đúng là kiểu này của em không thể bị CSRF được, vì nó không phải dùng Cookie. Em có thể để JWT ở trong localStorage để lấy ra cho vào Header Authorization, và chỉ cần chống XSS.

Anh bảo là phải cho JWT vào Cookie ấy ạ. Và anh bảo cũng phải để httpOnly. Việc này làm rồi thì không có cách nào cho JWT vào Header Authorization nữa. Việc gửi JWT đi là do Browser làm. Nhưng nếu anh làm như vậy thì chắc chắn sẽ phải chống CSRF, vì nó là Cookie. Mà đã chống CSRF theo kiểu của Serverless thì sẽ không thể để httpOnly được.

Không thể nào có cách nào để JWT trong Cookie mà có httpOnly được ấy ạ. Làm như thế không thể "Double Submit Cookie" được ạ. Anh có thể tham khảo Double Submit Cookie ở OWASP ạ: https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html#double-submit-cookie

@xuanan2001 Vẫn cần phải lưu trong cookie để bảo vệ JWT token. Theo như mô tả của bạn thì hình như bạn gửi JWT Token đi bằng Header Authorization hoặc bằng cái nào đấy tương tự, việc sử dụng JWT là server sẽ decode và xác thực chính xác JWT đó mà server đã ký bằng key từ server, mà với kiểu này thì không bị tấn công CSRF

@minhtuan.nguy Cảm ơn anh vì góp ý ạ!

Trong bài em có nhắc đến việc em đang sử dụng serverless server ấy ạ. Serverless server thì sẽ không có session nào cả, và các request sẽ được identify bằng token JWT. Khác với Stateful server, là các server có lưu lại session và bên client cần lưu lại session_id để giữ session (Nếu em hiểu không nhầm là vậy, vì em không rành Stateful server).

Khi em phải dùng Cookie để lưu JWT, thì em phải implement "Double Submit Cookie" để chống CSRF. Mà nếu implement cái này thì sẽ không thể sử dụng được httpOnly để chống XSS, vì không có cách nào lấy CSRF token từ một cookie httpOnly để cho vào JavaScript rồi cho vào HTTP Request Body được ạ. Nên sử dụng httpOnly trong trường hợp Serverless là không thể.

Mong anh góp ý thêm ạ.

@Sudhakar you can try https://www.npmjs.com/package/swagger-spec-to-pdf or https://www.npmjs.com/package/html-pdf or https://www.npmjs.com/package/html-pdf-node

có cách nào crawl mà k cần đăg nhập k bác

Cám ơn bạn đã chia sẻ

Ai dốt toán chắc chả hiểu gì!

• Rational number -> số hợp lý (là số gì, what the hell???) Trong khi nghĩa của nó là số hữu tỉ (toán lớp 7)
• Terminating expansion: phần mở rộng kết thúc? Cái này có lẽ hiểu là phần thập phân hữu hạn (trong cơ số 10)

@ngo.quang.trung I am trying that one option, but I want in Nestjs code. How to download pdf file in nestjs.

Bài viết rất rõ ràng và chi tiết. Cảm ơn bạn nhiều

bài viết rất hay và dễ hiểu ạ

Using Browser Printing/Preview ? https://stackoverflow.com/a/41257222

@pinpolygons Thế thì chịu đấy. Có thể bạn bị rate limited, có thể server của họ bị quá tải. Mình gợi ý liên lạc support nếu có, theo mình thì API không phải trả tiền thì không đáng tin cậy lắm.