Tại sao "Security Through Obscurity" vẫn là một lớp phòng thủ hữu hiệu?

Trong cộng đồng phát triển phần mềm, có một câu nói kinh điển thường được lặp lại như một chân lý bất biến: "Security through obscurity is bad" (Bảo mật bằng sự che giấu là xấu). Tuy nhiên, quan điểm này thực chất là một sự đơn giản hóa nguy hiểm. Trong bài viết này, chúng ta sẽ cùng phân tích lại khái niệm này và lý giải tại sao sự che giấu, khi được áp dụng đúng cách, vẫn là một công cụ hữu hiệu trong chiến lược phòng thủ nhiều lớp.

Thoát khỏi "buồng vang" tư duy

Gần đây, tôi đã bắt gặp một cuộc thảo luận trên một diễn đàn phát triển web. Một người dùng tên Mini hỏi về việc có nên sử dụng kỹ thuật làm rối mã (obfuscation) cho các đoạn JavaScript trên website của mình hay không. Mục tiêu của Mini là làm khó khăn hơn cho các bot thu thập dữ liệu (data-scraping bots) trong việc đảo ngược kỹ thuật và sao chép các yêu cầu API.

Ngay lập tức, một phản ứng tự động xuất hiện từ một người dùng khác, gọi là Echo: "Security through obscurity is bad". Bình luận này nhận được nhiều sự đồng thuận, nhưng thực chất nó chỉ là sự lặp lại máy móc của một khẩu hiệu đã cũ.

Tôi đã phản lại: "Bảo mật bằng sự che giấu KHÔNG xấu. Chỉ ĐỘC QUYỀN dựa vào sự che giấu mới là xấu (theo Nguyên lý Kerckhoffs). Bảo mật bằng sự che giấu, với tư cách là một lớp bổ sung, là TỐT!"

Echo tin rằng mọi hình thức che giấu đều thừa thãi, đặc biệt là trong thời đại AI khi việc phá vỡ sự che giấu trở nên dễ dàng. Đây là một sai lầm. Hãy cùng xem xét tại sao sự che giấu vẫn có vị trí quan trọng trong an ninh mạng hiện đại.

Đừng để lộ "bài làm" của bạn

Bảo mật bằng sự che giấu là thực hành giảm thiểu sự tiếp xúc bằng cách giữ cho các hoạt động nội bộ hoặc chi tiết triển khai của ứng dụng ít hiển thị hơn với kẻ tấn công. Không giống như trong toán học, nơi bạn cần trình bày cách giải, trong bảo mật, bạn không muốn kẻ khác biết cách hệ thống của bạn hoạt động.

Đây là tương đương kỹ thuật số của việc giấu chìa khóa dự phòng dưới thảm chùi chân thay vì để nó trong ổ khóa. Trong kịch bản này, một tác nhân độc hại có thể sẽ không bother soi xét dưới tấm thảm và bỏ đi. Chúc mừng, sự che giấu vừa cứu bạn khỏi một vụ đột nhập. Họ vẫn có thể tìm thấy chìa khóa, nhưng họ có thể kiểm tra các chậu cây gần đó hoặc hộp thư trước. Điều này tốn thời gian, và thời gian là tiền bạc. Đối với kẻ tấn công, càng dành nhiều thời gian theo đuổi các ngõ cụt, khả năng họ bỏ cuộc và chuyển sang mục tiêu khác càng cao.

Ví dụ về việc giấu chìa khóa dưới thảm chùi chân như một lớp bảo mật bổ sung

Tất nhiên, biện pháp bảo mật đúng đắn ở đây là không giấu chìa khóa dự phòng gần cửa, mà thay vào đó giao nó cho một thành viên tin cậy. Chỉ dựa vào sự che giấu để bảo mật là xấu. Bạn nên luôn bảo mật ứng dụng của mình ở mức độ xứng đáng, sau đó rắc một chút "sự che giấu" lên trên để làm cho nỗ lực tấn công bạn trở nên đắt đỏ hơn. Đây đơn giản là một phần của chiến lược phòng thủ theo chiều sâu (defense-in-depth).

Sự che giấu trong thế giới thực

Dưới đây là một số ví dụ cụ thể mà tôi đã từng gặp, chứng minh hiệu quả của sự che giấu.

Tiền tố bảng cơ sở dữ liệu WordPress

Có một khuyến nghị bảo mật lâu đời là thay đổi tiền tố bảng cơ sở dữ liệu mặc định của WordPress thành một chuỗi ngẫu nhiên. Ví dụ, wp_users trở thành wp_8df7b8_users. Điều này thường bị coi là "vô giá trị" vì nó là bảo mật bằng sự che giấu.

Trước đây, tôi chạy blog này trên WordPress. Vào năm 2015, một trong các plugin tôi sử dụng có lỗ hổng SQL injection cho phép kẻ tấn công đổ cơ sở dữ liệu của các trang web sử dụng nó. Các bot này tự động quét web để tìm các mục tiêu WordPress dễ bị tấn công.

Trang web của tôi cũng bị lỗ hổng đó. Tuy nhiên, tôi không bị ảnh hưởng bởi bất kỳ cuộc tấn công nào và đã cập nhật plugin lên phiên bản vá lỗi vài ngày sau đó. Trong khi các trang web khác bị "xóa sổ" và phá hủy, tôi may mắn thoát nạn. Sau này, tôi tìm thấy một kịch bản PoC (Proof of Concept) trên GitHub minh họa cách khai thác. Khi chạy PoC trên trang của mình, nó thất bại với lỗi chung chung như Table 'wordpress.wp_users' doesn't exist. Do đó, mặc dù tôi vẫn có thể bị khai thác bằng các truy vấn SQL khác, truy vấn tiêu chuẩn nhắm đến đa số người dùng đã không ảnh hưởng đến tôi.

Tôi được an toàn nhờ lớp bảo mật bổ sung thông qua sự che giấu. Ngay cả khi các công cụ AI hiện nay có thể thử các truy vấn khác nhau, nhưng token vẫn tốn tiền. Càng nhiều thời gian và tiền bạc bot tiêu tốn, khả năng nó bỏ cuộc càng cao. Đây là cuộc chiến về khả năng kháng cự bền bỉ.

Rò rỉ ký hiệu gỡ lỗi (Debug Symbol) trong CSGO

Tôi từng vận hành một máy chủ cộng đồng CSGO tại Úc và New Zealand tên là Invex Gaming. Để tạo ra các mod tùy chỉnh, tôi sử dụng nền tảng SourceMod, cho phép viết các plugin và tiện ích mở rộng. Để viết các mod hữu ích, chúng tôi thường phải tìm và gọi các hàm trực tiếp trong các tệp nhị phân của trò chơi như engine.dll hoặc client.dll.

Vấn đề là chúng tôi không thể truy cập mã nguồn của Valve. Khi nhìn vào mã đã biên dịch, chúng tôi thấy một mớ code hỗn độn mất nhiều công sức để đảo ngược và tài liệu hóa. Tên hàm, tên biến và kiểu dữ liệu đều bị loại bỏ. Đây là thực hành phổ biến là loại bỏ các ký hiệu gỡ lỗi (debug symbols) khỏi các tệp nhị phân của trò chơi. Debug symbols là siêu dữ liệu ánh xạ mã máy của chương trình trở lại mã nguồn có thể đọc được của con người.

Một ngày nọ, Valve vô tình đẩy một bản cập nhật cho phiên bản macOS của CS:GO bao gồm đầy đủ các ký hiệu gỡ lỗi Mach-O chưa được loại bỏ trong các tệp nhị phân .dylib. Điều này phơi bày nhiều nội bộ của trò chơi. Điều này dẫn đến việc các nhà vận hành máy chủ sử dụng thông tin mới để tạo các kịch bản mới, nhưng cũng khiến các nhà phát triển cheat (phần mềm gian lận) sử dụng nó để phát triển cheat của họ.

Đây là ví dụ điển hình cho thấy Valve coi trọng lớp bảo mật bổ sung mà sự che giấu mang lại. Valve chọn loại bỏ debug symbols vì làm như vậy cực kỳ hiệu quả trong việc giảm hiệu quả của các nhà phát triển cheat. Ngay sau khi phát hiện sự cố, Valve đã phát hành lại phiên bản với các ký hiệu gỡ lỗi bị loại bỏ.

Mã nguồn bị làm rối (Obfuscated Code)

Tôi thường xuyên phân tích phần mềm độc hại (malware) và tham gia các cuộc thi CTF. Rất phổ biến khi gặp phải mã bị làm rối (obfuscated code) – mã nguồn bị cố tình làm phức tạp để con người và công cụ khó hiểu hơn nhưng vẫn hoạt động đầy đủ. Ngành công nghiệp malware trị giá hàng tỷ đô la và không ai dựa vào sự che giấu nhiều hơn các tác nhân độc hại. Payload độc hại càng bị làm rối, các nhà nghiên cứu bảo mật và công cụ càng khó hiểu được điều gì đang xảy ra.

Ngược lại, các doanh nghiệp như Google cũng sử dụng obfuscation JavaScript để ẩn logic nhạy cảm trong trình duyệt. Một ví dụ tuyệt vời là Google reCAPTCHA, nơi obfuscation thường phức tạp và tinh vi để làm khó bot hiểu được các kiểm tra đang thực hiện và tự động hóa việc giải chúng. Netflix cũng sử dụng obfuscation trong các thành phần DRM phía trình duyệt để giúp bảo vệ logic cho phép trình duyệt phát video mà không phơi bày mọi thứ cần thiết để dễ dàng trích xuất và lưu bản sao có thể phát. Riot Games cũng sử dụng obfuscation xung quanh một phần truyền thông giữa hệ thống chống gian lận cấp hạt nhân Riot Vanguard và máy chủ của họ để làm khó cho những kẻ gian lận giả tín hiệu sạch.

Có ý kiến cho rằng sự tiến bộ của AI đã làm cho obfuscation trở nên lỗi thời. Tôi không đồng ý. Mặc dù các công cụ AI tốt trong việc giải mã, nhưng đó vẫn thường là một quá trình chậm và tốn kém. Tôi tin rằng một mô hình mạnh cuối cùng sẽ tìm ra giải pháp, nhưng nó sẽ mất thời gian và tiền bạc. Một lần nữa, càng lâu và tốn kém, mọi người càng có khả năng bỏ cuộc.

Tôi không có dữ liệu cụ thể để chia sẻ, nhưng tôi có bằng chứng thực tế. Năm ngoái, tôi đã thử một thử thách CTF kiểu PWN khó mà tôi không thể tự giải quyết. Sử dụng LLM Claude Opus 4.5 và cung cấp cho nó tất cả thông tin, tệp nhị phân và công cụ cục bộ cần thiết, ban đầu nó vẫn thất bại.

Mãi đến sau 4,5 giờ đốt token liên tục và nhiều lần thử và sai, LLM mới tìm ra giải pháp. Nỗ lực này đã sử dụng 61 triệu token đầu vào và 11 triệu token đầu ra, khoảng 300 USD. Mặc dù tôi sẵn sàng chi số tiền đó để đánh giá khả năng của mô hình, nhưng điều quan trọng cần lưu ý là chúng ta đã biết giải pháp tồn tại vì đây là thử thách CTF có giải pháp định sẵn. Liệu những kẻ tấn công có sẵn sàng chi nhiều như vậy cho mỗi lần thử trên một bề mặt tấn công doanh nghiệp lớn, nơi kết quả hoàn toàn không được đảm bảo không? Họ sẵn sàng lặp lại bao lâu trên một góc độ cụ thể? Sự không chắc chắn đó chính là nơi sự che giấu vẫn giữ được giá trị.

Lan tỏa thông điệp đúng đắn

Rõ ràng đến nay, bảo mật bằng sự che giấu vẫn có chỗ đứng như một lớp bảo mật bổ sung trong thế giới hiện đại, ngay cả khi có sự hỗ trợ của công cụ AI.

Vì vậy, tôi không còn muốn nghe cụm từ "bảo mật bằng sự che giấu là xấu".

Từ nay về sau, hãy lan tỏa hai phát biểu này thay vào đó:

1. Chỉ ĐỘC QUYỀN dựa vào sự che giấu là xấu.
2. Bảo mật bằng sự che giấu, với tư cách là một lớp bổ sung, là TỐT!