Pha này có chết anh Quảng Nổ BKAV không cơ chứ?

[mooney583377]

JWT thì client ko tự chế đc nhưng những thông tin khác của request thì fake đc hết, nên mới dẫn tới dễ bị IDOR nếu ko cẩn thận đó man, vì mình ko control đc cái JWT từ đâu mà ra, đc map với user nào vào lúc nào

thế nên mới sinh ra quả đi compare thông tin trong jwt với các nội dung khác để validate
còn việc đi lưu cái jwt vào DB thì k có ý nghĩa gì với bảo mật, thậm chí còn mất an toàn hơn do thêm 1 chỗ để khai thác thông tin.

 

[Meryem]

Phải lưu nha ông, nếu chỉ check valid thôi sẽ dễ bị IDOR -> 1 token đc sử lụng lại bởi 1 user khác, do client có thể chế biến được. Nên trc h chỗ nào tui làm nó cũng sẽ maintain 1 cái access token table, lưu username + token + expire time. Cái table này thì thường nào riêng trên 1 con server luôn vì đòi hỏi bảo mật cao.

Cái này bên nhánh banking/finance (đòi hỏi bảo mật cao) cũng làm vậy nên nó là chuẩn rồi ông. Quan trọng là cách ông bảo kê và tách biệt cái token db với các db khác như nào thôi

thế cái token bạn lưu trong db nó làm đc những gì? nói chung ý của mình là không có chuyện chỉ hack đc db mà access đc vào account

 

[EG.Arteezy]

thế nên mới sinh ra quả đi compare thông tin trong jwt với các nội dung khác để validate
còn việc đi lưu cái jwt vào DB thì k có ý nghĩa gì với bảo mật, thậm chí còn mất an toàn hơn do thêm 1 chỗ để khai thác thông tin.

Thì đúng là có chỗ sẽ lưu hash/checksum của token thay vì lưu token, để verify khi client send, nhưng rất nhiều chỗ tôi làm đều chỉ lưu token thôi vì 2 lý do chính: expire time nhanh (15-30p do thuộc nhánh banking) và cái db đó đc bảo mật tối đa, nếu nó lủng thì tất cả các cái khác đi hết rồi

Nói chung điểm chính là ko tin bất cứ cái gì thằng user gửi lên thôi, và cũng ko verify bằng cách sử dụng thông tin client gửi lên luôn, mà verify với data lưu ở server side

 

[talaai1312_ver2]

Phải lưu nha ông, nếu chỉ check valid thôi sẽ dễ bị IDOR -> 1 token đc sử lụng lại bởi 1 user khác, do client có thể chế biến được. Nên trc h chỗ nào tui làm nó cũng sẽ maintain 1 cái access token table, lưu username + token + expire time. Cái table này thì thường nào riêng trên 1 con server luôn vì đòi hỏi bảo mật cao.

Cái này bên nhánh banking/finance (đòi hỏi bảo mật cao) cũng làm vậy nên nó là chuẩn rồi ông. Quan trọng là cách ông bảo kê và tách biệt cái token db với các db khác như nào thôi

Điểm lợi là nếu có dấu hiệu bị lủng thì có thể drop luôn cái db này -> tất cả user phải login lại, nếu chỉ check valid thì sẽ ko làm đc trò này.

cho em hỏi JWT được mã hóa + key thì client bác chế lại như thế nào để bypass được check valid dưới server?

 

[ministerduong]

Thì đúng là có chỗ sẽ lưu hash/checksum của token thay vì lưu token, để verify khi client send, nhưng rất nhiều chỗ tôi làm đều chỉ lưu token thôi vì 2 lý do chính: expire time nhanh (15-30p do thuộc nhánh banking) và cái db đó đc bảo mật tối đa, nếu nó lủng thì tất cả các cái khác đi hết rồi

Nói chung điểm chính là ko tin bất cứ cái gì thằng user gửi lên thôi, và cũng ko verify bằng cách sử dụng thông tin client gửi lên luôn, mà verify với data lưu ở server side

token nó càng ngày càng nhiều thì sao fen?

 

[F0 hung hãn]

thấy nó screenshot dòng chữ xanh, vậy nv bkav bị lộ tài khoản à

Nó hack cả sv thì nó vào bằng user nào chả đc. user đó là của Ngô Tuấn Anh, phó giám đốc phụ trách an ninh mạng của Bkav đó

 

[EG.Arteezy]

cho em hỏi JWT được mã hóa + key thì client bác chế lại như thế nào để bypass được check valid dưới server?

Vấn đề là mình control xem cái jwt từ đâu mà ra đó man, mặc dù mình có thể embed tất cả thông tin trong jwt khi nó được tạo, nhưng cách này ko tối ưu nếu config của thím lớn (cái này trong system gọi là orthogonality) thì tổ hợp các option phải lưu trong chính cái jwt tăng theo hàm mũ -> ko ổn, chưa kể system bây giờ là dynamic, các config có thể thay đổi bất cứ lúc nào. Ví dụ access level của user đổi nhưng ko muốn trigger bắt user re-login -> phải sửa lại access level cho token -> thì việc lưu uuid/hash của token phía server side có thể làm cái này dễ dàng

Ví dụ thím giảm access level của user, nhưng ko revoke token, và ko có table nào check token + access level của nó thì user cầm token cũ vẫn access phè phè, cái này là IDOR

token nó càng ngày càng nhiều thì sao fen?

Token nó có expire nên sẽ ko tăng hoài nha fen, nó như access log thôi, request nào ông cũng phải lưu lại log nên cái table token ko là gì so với các table khác

 

[ministerduong]

Token nó có expire nên sẽ ko tăng hoài nha fen, nó như access log thôi, request nào ông cũng phải lưu lại log nên cái table token ko là gì so với các table khác

tại sao có expire thì ko tăng hoài fen?

 

[EG.Arteezy]

tại sao có expire thì ko tăng hoài fen?

vì như sql thì sẽ có job automate delete fen, còn redis thì nó tự bay màu các token cũ rồi, nếu số lượng user của ông ổn định thì cái table token nó cũng ổn định theo vậy à

điểm chính là về size thì table token nó ko là gì so với table access logs á fen

 

[mooney583377]

Thì đúng là có chỗ sẽ lưu hash/checksum của token thay vì lưu token, để verify khi client send, nhưng rất nhiều chỗ tôi làm đều chỉ lưu token thôi vì 2 lý do chính: expire time nhanh (15-30p do thuộc nhánh banking) và cái db đó đc bảo mật tối đa, nếu nó lủng thì tất cả các cái khác đi hết rồi

Nói chung điểm chính là ko tin bất cứ cái gì thằng user gửi lên thôi, và cũng ko verify bằng cách sử dụng thông tin client gửi lên luôn, mà verify với data lưu ở server side

tôi thấy khó hiểu, jwt sinh ra để đơn giản hoá cho quá trình xác thực, thay vì đi lưu thông tin xác thực ở DB, và mỗi lần authen bắt DB chịu thêm tải thì dùng jwt để tiết kiệm performance cho việc này, chỉ cần server side bảo mật kỹ cái key ký jwt là đc. chỗ anh nếu còn k tin cả jwt user truyền lên thì việc gì phải xài cái này cho nặng nhỉ? nếu mỗi lượt authen đều phải tác động tới DB thì cần gì jwt, hash cái password rồi compare như bao bài tập lớn của đám sinh viên có phải đơn giản k
với cả expire time thì jwt cũng làm tốt mà nhỉ.

 

[EG.Arteezy]

tôi thấy khó hiểu, jwt sinh ra để đơn giản hoá cho quá trình xác thực, thay vì đi lưu thông tin xác thực ở DB, và mỗi lần authen bắt DB chịu thêm tải thì dùng jwt để tiết kiệm performance cho việc này, chỉ cần server side bảo mật kỹ cái key ký jwt là đc. chỗ anh nếu còn k tin cả jwt user truyền lên thì việc gì phải xài cái này cho nặng nhỉ? nếu mỗi lượt authen đều phải tác động tới DB thì cần gì jwt, hash cái password rồi compare như bao bài tập lớn của đám sinh viên có phải đơn giản k
với cả expire time thì jwt cũng làm tốt mà nhỉ.

Đúng rồi fen, vì ít nhất cũng sẽ lưu lại cái uuid của token đó, như tui nói ở trên do system dynamic, config của cái jwt đó có thể thay đổi bất cứ lúc nào nhưng mình ko muốn trigger lại login để tạo mới token, nên vẫn phải lưu 1 số cái ở db và verify

Còn việc expiry thì thật sự tui ko bao giờ xài cái field embed trong jwt mà luôn check ở server db, vì cái webserver tạo/check token đc scale dynamic ở các region khác nhau nên timezone có thể bậy, trong khi db là centralize nên check expire db side là ổn nhất, vì tui ko muốn phải đụng tới timezone config

 

[mooney583377]

Đúng rồi fen, vì ít nhất cũng sẽ lưu lại cái uuid của token đó, như tui nói ở trên do system dynamic, config của cái jwt đó có thể thay đổi bất cứ lúc nào nhưng mình ko muốn trigger lại login để tạo mới token, nên vẫn phải lưu 1 số cái ở db và verify

Còn việc expiry thì thật sự tui ko bao giờ xài cái field embed trong jwt mà luôn check ở server db, vì cái webserver tạo/check token đc scale dynamic ở các region khác nhau nên timezone có thể bậy, trong khi db là centralize nên check expire db side là ổn nhất, vì tui ko muốn phải đụng tới timezone config

oh, mindset của ông thiết kế hệ thống chắc khác, bên tôi tine dùng epoch format nên k cần để ý timezone. tải quá lớn nên tiết kiệm đc tí perf nào thì phải tiết kiệm tí đó, database là cái khó scale nhất trên hệ thống nên k hiếp nó đc

 

[NickNayLaDeChemGio]

6/ Lại làm việc với PA05


7/ Đếch còn gì để nói


8/ Đếch còn gì để nói

Như ai đó dưới đây nói:" Làm với BKAV kiểu gì cũng lên chức đã là truyền thống"

Vậy hacker người việt nhỉ. Đọc hiểu tốt quá rùi.

Sent from Xiaomi Redmi K30 5G using vozFApp

 

[CreativeThinkingV2i]

Hài thật . Để ra nông nỗi này ko biết còn Nổ nữa ko ? Lộ hết cả Info luôn ???

 

[Wchang]

Phải có chỗ chứa access token đc tạo khi sign in chứ man, nó có thể là redis hoặc sql. Như web login nó sẽ hay tạo JWT thôi, cái này server side sẽ phải lưu lại ở DB để check access với request header

cái này nó như XSS attack để lấy đc token thôi man, nhưng do site của BKAV nằm trong VPN nên ko thể XSS từ public site đc, nên cái này hoặc XSS từ nội bộ hoặc thủng DB access thôi

jwt ông đòi lưu db

 

[Wchang]

JWT thì client ko tự chế đc nhưng những thông tin khác của request thì fake đc hết, nên mới dẫn tới dễ bị IDOR nếu ko cẩn thận đó man, vì mình ko control đc cái JWT từ đâu mà ra, đc map với user nào vào lúc nào

anh có chắc là anh hiểu mình đang nói gì không thế?

 

[Shane™]

Thấy mấy bác bình luận vụ JWT em ớn quá, nào giờ chỉ dùng JWT để thay cho session chứ toàn bộ xác thực và info đều phải qua server chứ ko dám tin client

 

[Conan kun]

tại sao có expire thì ko tăng hoài fen?

chắc là chạy quét định kì (tuần/tháng/...) cái nào expired rồi thì xoá thôi

 

[RED AL]

hình như là do phản đối vụ bkav tống tù 1 hacker mũ trắng vì hack và thông báo lỗi tới bkav, đại khái ông bkav này chơi ko đẹp với giới underground

Thế này thật thì ai dám thông báo lỗ hỏng cho mấy cha nữa. Thêm thông tin về vụ ông hacker mũ trắng đi Đồng Chí ơi.

 

[Hoai cmn Linh]

Phải lưu nha ông, nếu chỉ check valid thôi sẽ dễ bị IDOR -> 1 token đc sử lụng lại bởi 1 user khác, do client có thể chế biến được. Nên trc h chỗ nào tui làm nó cũng sẽ maintain 1 cái access token table, lưu username + token + expire time. Cái table này thì thường nào riêng trên 1 con server luôn vì đòi hỏi bảo mật cao.

Cái này bên nhánh banking/finance (đòi hỏi bảo mật cao) cũng làm vậy nên nó là chuẩn rồi ông. Quan trọng là cách ông bảo kê và tách biệt cái token db với các db khác như nào thôi

Điểm lợi là nếu có dấu hiệu bị lủng thì có thể drop luôn cái db này -> tất cả user phải login lại, nếu chỉ check valid thì sẽ ko làm đc trò này.

chuẩn rồi có nó 1 con gọi là auth server (cái trò login với fb hay gg đó, thực chất là gọi tới con auth service của bọn này). các rq sau BE sẽ cầm cái jwt đó gọi cho thằng auth sv hỏi nó thằng này có phải user ko