Lỗi trình soạn thảo Substack do nhập tệp "/etc/hosts"

• Trình soạn thảo Substack gặp lỗi mạng khi nhập một số đường dẫn hệ thống cụ thể
• Tường lửa ứng dụng web (WAF) chặn các đường dẫn như vậy để ngăn tấn công duyệt đường dẫn và tấn công chèn lệnh
• Sự cân bằng giữa bảo mật và khả năng sử dụng nổi lên như một vấn đề quan trọng
• Cần có giải pháp tốt hơn cho các cây bút kỹ thuật
• Có thể giải quyết vấn đề bằng cách dùng đường dẫn thay thế

---

Khi /etc/h*sts làm hỏng trình soạn thảo Substack: cuộc phiêu lưu của việc lọc nội dung web

Lỗi mạng bí ẩn

• Khi viết một bài đăng kỹ thuật về phân giải DNS, đã xảy ra lỗi ngoài dự kiến
• Khi nhập đường dẫn /etc/h*sts, xuất hiện lỗi mạng và tự động lưu thất bại
• Trang trạng thái của Substack cho thấy hệ thống vẫn hoạt động bình thường

Bắt đầu điều tra

• Lỗi xảy ra khi nhập một đường dẫn tệp cụ thể, nhưng nếu biến đổi đường dẫn thì hoạt động bình thường
• Các đường dẫn như /etc/h*sts gây lỗi, còn các biến thể thì không có vấn đề

Bên trong đang xảy ra chuyện gì?

• Trong công cụ dành cho nhà phát triển của trình duyệt, xác nhận phản hồi 403 Forbidden
• Cloudflare có liên quan

Tìm hiểu bộ lọc bảo mật ứng dụng web

Giải thích ngắn gọn về WAF

• Tường lửa ứng dụng web (WAF) đóng vai trò như nhân viên bảo vệ an ninh cho website
• Nó chặn các yêu cầu đáng ngờ

Tấn công duyệt đường dẫn: vì sao cần cảnh giác

• Tấn công duyệt đường dẫn là nỗ lực truy cập các tệp hệ thống nhạy cảm
• Những đường dẫn như /etc/h*sts có thể trở thành mục tiêu tấn công

Chèn lệnh: một vấn đề bảo mật khác

• Tấn công chèn lệnh tìm cách thực thi các lệnh hệ thống
• Khi đề cập đến đường dẫn hệ thống, bộ lọc có thể chặn nội dung đó

Bí ẩn sâu hơn: ví dụ trong quá khứ

• Tìm thấy các trường hợp dùng đường dẫn tương tự trong những bài viết khác trên Substack
• Có khả năng hành vi lọc đã thay đổi từ một thời điểm nào đó

Bảo mật đối đầu khả năng sử dụng: sự cân bằng tinh tế

• Bộ lọc của Substack nhằm mục đích bảo vệ, nhưng lại trở thành rào cản với cây bút kỹ thuật
• Có dư địa để cải thiện: thông báo lỗi rõ ràng hơn, nhận biết nội dung kỹ thuật, và cung cấp giải pháp đã được tài liệu hóa

Xem xét phản hồi HTTP

• Xác nhận mã trạng thái 403 Forbidden ở cấp độ API

Giải pháp tốt hơn cho các nền tảng nội dung kỹ thuật

1. Lọc theo ngữ cảnh: nhận biết đường dẫn hệ thống trong khối mã hoặc thảo luận kỹ thuật
2. Thông báo lỗi rõ ràng: thay vì "lỗi mạng", hãy giải thích rằng nội dung bị chặn bởi bộ lọc bảo mật
3. Giải pháp được tài liệu hóa: cung cấp cách thảo luận về các đường dẫn nhạy cảm

Kết luận: giao điểm giữa bảo mật và viết kỹ thuật

• Vấn đề của trình soạn thảo Substack cho thấy những thách thức phức tạp giữa bảo mật và viết kỹ thuật

• Thứ trông giống mẫu tấn công đối với bộ lọc bảo mật thực ra có thể là nội dung hợp lệ

• Có thể giải quyết vấn đề bằng cách dùng đường dẫn thay thế

• Tác giả kêu gọi chia sẻ trong phần bình luận nếu từng gặp vấn đề lọc tương tự trên các nền tảng khác

[GN⁺]

Ý kiến trên Hacker News

• Những người thiết lập quy tắc WAF trên CDN thường không hiểu rõ các website và dịch vụ xử lý nội dung kỹ thuật. Không chỉ Cloudflare mà Akamai cũng gặp vấn đề tương tự

  • Nếu là một website làm việc với cơ sở dữ liệu, chỉ cần bật bộ quy tắc chống SQL injection mặc định cũng có thể làm hỏng site
  • Cũng có các bộ quy tắc về file inclusion, nên những thứ như /etc/hosts hoặc /etc/passwd sẽ bị chặn
  • Tôi nghĩ cân bằng giữa bảo mật và tính khả dụng là rất quan trọng. Áp mọi quy tắc WAF sẽ tăng cường bảo mật, nhưng lại gây bất tiện cho các dịch vụ cần thảo luận về khái niệm kỹ thuật
  • Việc tinh chỉnh quy tắc rất tốn thời gian. Để vẫn giữ quy tắc mà cho phép các trường hợp sử dụng hợp lệ, cần rất nhiều thay đổi
  • Có thể phát sinh các vấn đề như trang không tải hoặc tài nguyên không tải được. Điều đó khiến người ta muốn tắt quy tắc đi

• Nhớ lại một giai thoại về một nền tảng thương mại điện tử: ai đó đã code một web shop bị rò rỉ bộ nhớ, rồi giải quyết bằng cách khởi động lại ứng dụng mỗi khi chuỗi "OutOfMemoryException" xuất hiện trong log

  • Một lập trình viên khác muốn ghi lại từ khóa tìm kiếm của khách hàng, và sự cố xảy ra khi ai đó nhập "OutOfMemoryException" vào ô tìm kiếm

• Tò mò không biết họ có chặn /etc/hosts hay /etc/./hosts không. Đây giống như một trò đập chuột chũi chắc chắn sẽ thất bại. Hacker thông minh hơn và quyết liệt hơn, nên chỉ nên dựa vào bảo mật đã được kiểm chứng

• Ý kiến về việc Substack có thể cải thiện tình huống này như thế nào cho các cây bút kỹ thuật

  • Không nên chạy một WAF ngớ ngẩn trên endpoint nơi mọi người được phép chỉnh sửa bài viết về bất kỳ chủ đề nào
  • Điều này giống như triển khai bộ lọc XSS trên một diễn đàn phát triển web rồi khiến thành viên không thể nói về XSS
  • Cần học cách escape nội dung đúng cách

• Nhấn mạnh đây là một ví dụ thú vị về sự căng thẳng giữa bảo vệ và tính khả dụng trong bảo mật web

  • Nhưng trường hợp này lại làm nổi bật một lỗi. Sự căng thẳng giữa bảo mật và tính khả dụng là có thật, nhưng không phải ở trường hợp này
  • Căng thẳng giữa bảo mật và tính khả dụng thường là một sự đánh đổi. Tăng bảo mật thì trải nghiệm người dùng sẽ giảm
  • Trường hợp này cho thấy cả bảo mật tệ lẫn trải nghiệm người dùng tệ

• Vấn đề từng xảy ra khi dạy một đội competitive programming: nếu các kiểu dữ liệu và từ khóa C++ xuất hiện trong code thì sẽ gặp lỗi 403

  • Khi làm việc ở một ngân hàng, từng có một API yêu cầu phải nộp file Python, và phần lớn file Python đều gây ra lỗi 403
  • Trong môi trường cloud mới, vấn đề tương tự cũng xảy ra

• Vấn đề phát sinh khi red team nội bộ đăng dữ liệu có chứa các nỗ lực XSS và các kiểu tấn công injection khác

  • Bản thân cuộc tấn công không hoạt động, nhưng sự hiện diện của các mục đó lại khiến trang quản trị nội bộ không tải được

• Một vấn đề cũ lại xuất hiện. Người ta gọi đây là vấn đề Scunthorpe

• Từng gặp vấn đề tương tự với OpenRouter. OpenRouter là dịch vụ cung cấp một endpoint duy nhất để dùng nhiều LLM khác nhau

  • Nếu một số đoạn HTML và JavaScript cụ thể có trong phần thân của yêu cầu POST, nhiều yêu cầu sẽ bị chặn

• Lọc nội dung cần phụ thuộc rất nhiều vào ngữ cảnh. Nếu WAF bị tách rời khỏi thứ mà nó phải lọc thì sẽ phát sinh vấn đề

  • Điều này tương tự lọc spam. Máy chủ email lọc dựa trên cấu hình của máy chủ gửi
  • Lọc dựa trên cách truyền tải hiệu quả hơn lọc dựa trên nội dung. Điều tương tự cũng áp dụng cho website và WAF