Tiếp nối câu chuyện ro phym 🐧

Anh bạn kia code thì lắm, chèn cả trash code (code ko dùng tới) cho nó nhiều, rồi dùng jsfuc* để làm rối, cuối cùng cũng chỉ để ẩn đoạn code bé tý này 😌

• Tính ra chỉ sử dụng 33/642 dòng code (5%)
• Còn lại toàn là code kiểm tra điều kiện, code rác, code chống "ăn c*p bản quyền cờ rắc" 🙂
• Anh bạn còn ảo tưởng nghĩ ad mất cả đêm thức để giải mã 🤣 Dùng web de4js giải 5s bạn ơi, tại bạn cờ rắc cả FB AIO nên tui mới giúp bạn "trả gió"

Cờ rắc là sai trái, không cần biện hộ nhiều.
P/s: Mình đã báo cho chủ trang web, trước khi công khai code này, họ cũng xác nhận chưa ảnh hưởng lắm, nên chưa cần fix
P/s 2: Bài viết này nhằm mục đích chia sẻ kiến thức, tìm phương thức bảo mật tốt hơn, không khuyên mn dùng code dưới nha

Giờ bàn tới chuyện làm sao để chủ trang web tránh được dạng chít lỏ này 🥸

Có RẤT NHIỀU cách:

• 🕵️ Self-check (tamper detection): kiểm tra hàm send có phải native hay không, hay đã bị chỉnh sửa bởi bên khác.
• 🔏 Ký response bằng HMAC / JWT — gửi dữ liệu kèm chữ ký (signature) do server tạo; client có thể đọc nhưng attacker không thể tạo chữ ký hợp lệ nếu không có secret
• 🧰 Đặt mọi quyền / logic VIP phía server Check logic VIP theo session, không phải theo fetch => server toàn quyền check, không bao giờ tin data từ client
• 🧩 Dùng SRI (Subresource Integrity) + CSP (Content Security Policy) để giảm rủi ro mã JS bị thay đổi khi tải từ CDN hoặc supply-chain — đảm bảo script bạn load không bị thay đổi trên đường truyền
• 🧊 Đóng băng prototype / harden môi trường tải script — Object.freeze(XMLHttpRequest.prototype) hoặc defineProperty không configurable để làm khó override, nhưng không tuyệt đối (attacker có full control client)
• 🔐 TLS + HSTS + đúng CORS để giảm MITM (man-in-the-middle) khả năng sửa payload trên đường truyền. (HTTPS / HSTS / CORS)
• ⏳ Token ngắn hạn + refresh flow: nếu cần quyền đặc biệt, trả token ngắn hạn sau khi re-auth; khó cho attacker giữ token lâu để giả mạo. (short-lived token).
• 🧾 Kiểm tra dữ liệu trên server khi thực hiện hành động quan trọng (authorization check) — ví dụ: trước khi cấp phép xem nội dung VIP, server kiểm tra DB/role, không chỉ đọc từ JSON client.

⚠️ Những thứ không nên tin tưởng client:

• ❌ Tin hoàn toàn vào check JS trên client (ví dụ: kiểm tra send có bị override) — attacker có thể sửa cả code kiểm tra.
• ❌ Mã hoá/obfuscate JS để bảo vệ logic nhạy cảm —> chỉ làm khó nhẹ, không ngăn giải mã. (obfuscation ≠ security).

Bài viết trước đó:

Tập 1: https://www.facebook.com/share/p/1DAJw6ZhEV/

Tập 2: https://www.facebook.com/share/p/1DHRbAHxPY/

#fb_aio