Recent Content by itnd

Vậy mà rất nhiều cái cơ bản mà nãy giờ cụ chả hiểu gì cả. Thôi e xin phép tạm dừng

Đã nói rồi. Nó có thay đổi thiết bị đâu, nó thực hiện 2 lệnh đăng ký cùng lúc (thời điểm đó db chưa có thiết bị nào nên đều check pass). Và do đánh chặn không tốt nên mới xảy ra vấn đề trên. Khi đã reverse được clientApp thì mô phỏng được mọi thiết bị, mọi thông số. Còn iPhone với Android gì ở...

Thì rõ ràng 2 "thiết bị" kích hoạt ở thời gian cực gần nhau mà không chặn được là bug rõ ràng đó thôi. Cụ hơi bị nhầm ở hệ thống lớn nhé, việc giải quyết vài trăm ngàn event ở 1 cùng 1 thời điểm nó không đơn giản như cụ nghĩ đâu. Làm chơi chơi nhỏ nhỏ ai cũng thấy dễ, nhưng để đáp ứng đúng và...

Khổ quá. Ngay từ đầu em đã nói là backend phía bank có bug chứ có phải nói nó không có bug đâu. Tuy nhiên, nếu không có sự "giúp sức" của "bị hại" (em không nói cụ thể trường hợp khách hàng này nhé) thì cũng không thể lấy tiền được. Nếu dùng app chính chủ không can thiệp thì sẽ không khai thác...

Nói vậy mà cụ vẫn ko hiểu là do cụ ngoài ngành nên e giải thích thêm 1 lần nữa thôi nhé: chỉ có 1 clientApp (fake/đã bị chỉnh sửa) duy nhất gửi các lệnh này. Khi app thật đã bị reverse các logic về mã hóa đã bị sao chép thì bên tấn công muốn gửi thông tin nào đi cũng được. Kể cả là iphone18...

Nó đều nằm ở trình độ làm app và bảo mật thôi cụ. Cuối cùng nó đều quy là các lệnh gọi thuần về backend. Khi backend yếu thì cụ chẳng cần app nào cả, chỉ cần các lệnh raw cũng làm được mọi thứ.

Cụ đọc comment mới của em sẽ hiểu nhé, khi clientApp giả mạo thì mọi thông tin xác thực (gồm cả dữ liệu sinh trắc) đã được đồng thời chuyển cho bên thứ 3. Nó là cùng 1 clientApp (giả mạo/chỉnh sửa) thực hiện chứ robotic nào ở đây cụ.

À. E thêm 1 ý nữa vì có thể cụ ko làm việc liên quan tới bảo mật thì cụ sẽ không hiểu. Việc chèn vào DB (nếu có) thì cũng vô nghĩa. Vì bản chất là: clientApp (real/fake) xác thực > được chấp nhận (được thêm vào db) > server trả 1 key cho clientApp. Với key này (được bind với các thông số phần...

Nó chỉ không thể đồng thời nếu được thiết kế đúng, làm đúng (vd db chỉ cần set Unique Constraint (account, actived) cho chốt chặn cuối ở db. Thực tế sẽ cần validate > ngăn chặn ở nhiều tầng trước đó . Còn đã có bug thì chả có gì là không thể. Khi clientApp đã bị giả mạo thì bắn 2 lệnh API cuối...

À e trả lời thêm vụ cùng 1 thời điểm gán 2 điện thoại là không thể. Cái này là "mục tiêu" đúng với mọi hệ thống tương tự, với điều kiện là hệ thống phải được lập trình tốt. Còn trường hợp này hệ thống lập trình không tốt nên khi bị 2 luồng gần như gọi đồng thời nó đã không chặn được. Giống...

Theo quan điểm của em. Đó là bug trong thiết kế của họ, họ đã không lường trước kịch bản này (thực ra nó rất cơ bản trong các hệ thống cần tính atomic - tức là chỉ 1 hành động được hoàn thành duy nhất). Với các thao tác đăng ký, đổi thiết bị thông thường: hệ thống check xem đã có trong db chưa...

Trường hợp này thì không phải hack, nếu hack thì sẽ rất nhiều tài khoản khác cùng ngân hàng này sẽ bị mất tiền. Nhưng về bảo mật thì rõ ràng ngân hàng này yếu kém, và có bug. Trường hợp 2 thiết bị cùng đăng ký và đặc biệt đăng ký rất gần nhau thì phải phát hiện được đây là hành vi bất thường...

E đoán là không phải mình em mà rất nhiều người hy vọng không gặp cụ :D

Cụ mới là người cố tình không hiểu luật. Đầu tiên người di chuyển phải biết mình có ưu tiên hơn hay thấp hơn. Còn ông dùng sai đèn thì nó lại là vấn đề khác, lỗi khác. Chính những ông cho rằng rẽ phải ưu tiên hơn đi thẳng như cụ mới dẫn tới tình huống trên

Cụ nói em tự suy diễn luật. Vậy cụ nói sao về quy tắc chuyển hướng? Ở đây rẽ phải là chuyển hướng, tất nhiên chuyển hướng nó chỉ xảy ra ở nút giao. Sao cụ không áp dụng quy tắc chuyển hướng mà lại "đòi" áp dụng quy tắc nhường xe đến từ bên phải?