Note
Last updated
Theo mn thì token nên lưu trữ ở localstoregare hay là cookie? Tại sao? Nếu lưu ở localstoregare để được bảo mật hơn thì tại sao lại ko lưu trữ ở mỗi localstoregare thôi?
Còn Session thì lưu trữ ở Sever, nhưng mà lưu ở đâu sever và ví dụ về vấn đề này cho clear hơn được ko ạ?
khi làm API thì validate về cookie và session như thế nào?
Bạn nghiên cứu thử theo tài liệu của OWASP sẽ hiểu rõ hơn cơ chế bảo mật của nó. Đại khái là như thế này:
Access Token (AT) tối ưu nhất là nên Stateless hoàn toàn, để việc sử dụng token qua lại giữa các hệ thống không bị phụ thuộc vào nhau (chẳng hạn như cả đống service phải phụ thuộc vào 1 jwt blacklist). Để làm được chuyện đó mà ko bị rủi ro về bảo mật thì thời hạn sử dụng của AT phải cực kì ngắn, VD như thằng Keycloak đang mặc định expire time chỉ là 5 phút.
AT có expire time ngắn như vậy thì buộc phải có Refresh Token (RT) để gia hạn AT khi hết hạn. RT chỉ tương tác với Identity Server để lấy về AT mới chứ không tương tác với Resource Server.
Lúc này đẻ ra thêm 2 vấn đề: persist AT ở đâu để sử dụng lại cho các requests khác nhau, và persist RT ở đâu để khi tắt máy thì auth session của user vẫn được đảm bảo.
Có nhiều tranh luận về việc nên lưu token (AT và RT) ở đâu. Có bên thì nói là lưu ở Local Storage/Session Storage là được rồi, có bên thì nói là lưu ở Cookie. Nhưng theo OWASP thì….không nên persist ở đâu cả. Nếu lưu ở Local Storage thì dễ bị XSS attack, nếu lưu ở Cookie thì dễ bị CSRF attack, nếu lưu Cookie strict quá thì sẽ bất tiện khi sử dụng. AT tốt nhất chỉ nên nằm trên memory (lưu vào 1 biến tạm hoặc trên các state management), khi cần dùng cho request nào thì mới gọi biến đó ra để append vô Authorization Bearer header. Đương nhiên, khi không lưu xuống disk thì AT sẽ biến mất khi user tắt máy, hoặc thậm chí là ko dùng lại đc giữa các tabs trên cùng 1 trình duyệt.
Vậy nên thứ cần được lưu xuống disk sẽ là RT, nhưng để tránh việc bị lấy mất RT bằng phương thức tấn công XSS, chúng ta sẽ lưu bằng cả 2 phương pháp: Local Storage và Cookie. Cụ thể: Khi trả về RT, Identity Server sẽ trả về thêm 1 random string vào Cookie của trình duyệt, tạm gọi cookie này là “userContext”, đặt chế độ HttpOnly + SameSite + … để cookie này chỉ có thể kẹp vào request gửi lên Identity Server chứ ko kẹp vào request khác hoặc bị XSS. Đồng thời, trong RT cũng có thêm 1 claim nữa, tạm gọi là “userContextHash”, là bản hash của cookie “userContext”. Khi 1 request renew AT đc gửi lên Identity Server, cả RT và cookie userContext cùng đc gửi lên, và chỉ khi bản hash của cookie “userContext” trùng với claim “userContextHash” của RT thì mới cấp AT mới. Do đó, nếu user bị tấn công XSS và mất RT thì hacker cũng ko thể dùng RT đó đc, do ko biết đc “userContext” - thứ đc quản lý rất chặt bởi policy của Cookie. Nói chung bằng cách này thì giải quyết đc cả bài toán về tính chặt chẽ trong bảo mật lẫn tính mềm dẻo trong việc sử dụng JWT token. Bạn có thể tham khảo thêm mục “Token Sidejacking” trong tài liệu của OWASP mà mình để bên dưới.
AT cũng có thể dùng cách bên trên để lưu xuống disk, để có thể reuse mà ko lo bị mất AT. Tuy nhiên mình thấy có vẻ cách giữ AT trong memory được ưa chuộng hơn.
Thật ra OWASP recommend lưu RT trong Session Storage và chỉ dùng Local Storage để sync RT giữa các tabs, tuy nhiên cá nhân mình thì chưa có use case nào cần phải strict đến vậy, nên mình vẫn dùng cách lưu xuống Local Storage và Cookie.
“Em có câu hỏi nào dành cho công ty không?
Một câu hỏi mà ai cũng từng được nghe, tuy nhiên nhiều bạn vẫn lúng túng nói: dạ, em không ạ. Không phải là các bạn không có chuẩn bị cho cuộc phỏng vấn, mà đơn giản vài bạn ngại hỏi, thấy cơ hội làm việc không khả thi nên không dám hỏi thêm.Về việc không hỏi thêm gì, tôi có 3 vấn đề cơ bản:
Một, nhà tuyển dụng có thể đánh giá thấp bạn. Mình thì không có đánh giá gì, vì mình biết tâm lý của các bạn là đang đi phỏng vấn chứ không phải đến để trao đổi. Nhưng mình có đọc ở đâu đó nói là sẽ bị đánh giá thấp.
Hai, Các bạn sẽ mất cơ hội được tìm hiểu sâu hơn nhiều thứ. Ví dụ: bạn sẽ thay đổi vai trò là ngồi trao đổi hơn là phỏng vấn, từ đó tâm lý sẽ thoải mái một phần và được nói chuyện nhiều hơn, cơ hội pass cũng cao hơn. Hoặc, Bạn sẽ có thêm kinh nghiệm đi phỏng vấn lần sau. Ít nhất bạn sẽ nhận được nhiều thông tin hơn từ phía công ty, có thể là quy trình làm việc, cách tính kpi hoặc một vài câu trả lời cho các câu hỏi sau đây.
Ba, hỏi đi, hỏi để xem redflag có lòi ra không nha.
Sau đây là một vài câu hỏi mà các bạn có thể hỏi nhà tuyển dụng:
Anh/chị có thể kể sơ qua về công việc hằng ngày của vị trí ABC không ạ? Bao gồm cả nhiệm vụ được giao và các công việc chung của công ty, liệu việc chuyên môn thì ít nhưng drama, việc vặt,... thì nhiều?
Theo anh/chị, vị trí này sẽ đóng góp gì cho công ty ạ? Vị trí này sẽ tạo ra lợi ích trực tiếp hay là gián tiếp, sẽ được ghi nhận ra sao. Em thấy nhiều nơi họ không đánh giá đúng sự đóng góp, và đánh giá thấp cũng gì mà nhân viên làm.
Vị trí này sẽ chịu những KPI nào? Mục tiêu nào? Và nó sẽ được đánh giá như thế nào ạ?. Hoàn thành bao nhiêu là oke với cấp trên (cái này có vẻ hơi khó hiểu, nhưng ở công ty cũ thì với mình, các bạn đạt tối thiểu 80% là oke, vì thường khi đặt mục tiêu mình sẽ cùng các bạn cân đo đong đếm trong khoảng năng lực, đạt 80% là bằng 100% bình thường rồi).
Team làm việc này gồm những ai? Anh/chị đánh giá sao về những người ý ạ, cả về năng lực làm việc lẫn tính cách ạ?. Bạn có thể trao đổi sơ qua những khó khăn mà bạn thấy khi làm việc chung với các nhân sự khác. Nói về lo sợ quy trình làm việc rắc rối, khiến hiệu quả công việc không cao.
Một câu này hơi khó chịu và sợ mọi người chỉ trích nhưng, nếu công ty hỏi sao bạn nghỉ việc ở công ty cũ, thì các bạn cũng nên hỏi lại: Điều gì khiến người ở vị trí ABC (vị trí bạn đang ứng tuyển) lại nghỉ việc?. Đã cái nư của các bé mỏ hỗn =)))
Điều khác biệt giữa nhân viên cũ và nhân viên trong kỳ vọng của anh/chị là gì ạ?. Từ đó, tự tin deal rằng em làm được những gì anh/chị mong đợi. Nếu tại đây được hỏi về mức lương, thì sử dụng những thứ bạn có thể làm, có thể giải quyết để deal lương nhé.
Trên đây là 6 câu cơ bản thôi, còn trong quá trình phỏng vấn, nhà tuyển dụng có thể trao đổi kỹ hơn về các vấn đề khác.
Xin chào mọi người, dạo gần đây mình đọc về các best practice cho API security trên roadmap.sh thấy có một ý là nên dùng UUID thay cho increment id. Theo mọi người thì rủi ro khi dùng increment id trên các dự án thực tế có thực sự đáng lo?
Theo kinh nghiệm cá nhân thì increment id lúc sử dụng đa dạng cơ sở dữ liệu thì buộc phải chờ RDB insert trước để lấy key cho các DB khác. Nên là sử dụng UUID có thể tạo ngay ID và insert vào nhiều hệ cơ sơ dữ liệu. Ngoài ra, trường chứa UUID sẽ làm gia tăng kích thước lữu trữ và tìm kiếm Index sẽ kém hơn. Nếu bác đang làm các hệ phân tán thì có thể nghiên cứu snowflake-id nhé. Theo mình thì việc đáng ngại là ko hẳn. Dùng uuid có vẻ là bảo mật khi nó sinh ra 1 chuỗi ngẫu nhiên và khó bị giả mạo nhưng rõ ràng trong việc quản lý truy xuất thì nó vẫn là một vị trí mà ta cần quan tâm. Ví dụ như việc findByUuid chẳng hạn. Khi csdl của bạn đủ lớn xác suất nhập bậy vào và tồn tại 1 entity có cùng id vẫn là điều có thể xảy ra. Do đó việc validation cái id để quyết định có trả lại dữ liệu hay ko thì vẫn là cần thiết. Do đó nó ko mang lại lợi ích gì nhiều hơn so với cách dùng increase id truyền thống.
Theo em thì dùng increment id mà public ra ngoài thì dễ cho người ngoài biết số lượng data để họ viết script cào dữ liệu, em thì vẫn increment id nhưng trong internal thui
---------------------------------------------------------------------------------------------------------------------
