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 ở CDN thường không hiểu đúng về các trang và dịch vụ xử lý nội dung kỹ thuật. Đây không chỉ là vấn đề của Cloudflare; Akamai cũng tương tự
  Nếu bật các quy tắc chống SQL injection cơ bản trên một trang thảo luận về cơ sở dữ liệu thì trang sẽ hỏng, còn bộ quy tắc chống file inclusion sẽ chặn các chuỗi như /etc/hosts, /etc/passwd
  Cũng có khía cạnh cân bằng giữa bảo mật và tính khả dụng. Vì không thể biết dịch vụ nào được triển khai dễ bị tổn thương, nên việc chồng tất cả quy tắc WAF lên sẽ có phần an toàn hơn. Tuy nhiên, khi một dịch vụ được triển khai an toàn cần thảo luận các khái niệm kỹ thuật, cùng bộ quy tắc đó lại trở nên cực kỳ phiền toái
  Việc tinh chỉnh quy tắc tốn rất nhiều thời gian. Sửa lỗi trang không hiện vì tham số truy vấn có /etc/hosts, thì tiếp theo tài nguyên XHR lại không hiện vì referrer có /etc/hosts, rồi sau đó thư viện JS phân tích đưa URL truy cập vào cookie và lại hỏng, khiến người ta chỉ muốn tắt luôn quy tắc

  • Không chỉ có bảo mật và tính khả dụng, mà còn có tính kinh tế. Nhiều chính sách bảo mật nhìn qua có vẻ ngớ ngẩn lại xuất phát từ yêu cầu của công ty bảo hiểm
    Nếu công ty bảo hiểm nói “nếu không bắt nhân viên đổi mật khẩu mỗi 90 ngày, phí bảo hiểm sẽ tăng 20%”, thì dù NIST đã thay đổi khuyến nghị từ hơn 10 năm trước để không còn khuyến nghị đổi mật khẩu định kỳ, và dù có nói đúng đến đâu rằng đó là thực hành tệ, phí bảo hiểm vẫn tăng
    Vì vậy người ta thở dài triển khai chính sách hết hạn mật khẩu, rồi phải nghe nhân viên phàn nàn rằng mình kém năng lực. Vì log4shell đã quá nổi tiếng, nên giờ nếu các công ty bảo hiểm yêu cầu máy chủ phải từ chối các “chuỗi hack” phổ biến như /etc/hosts, /etc/passwd, jndi: thì cũng không có gì đáng ngạc nhiên
  • “Phòng khi có chuyện” là cách bảo mật tệ nhất và rốt cuộc khiến toàn bộ hệ thống kém an toàn hơn. Kiểu như vì an toàn mà bắt đổi mật khẩu hằng tháng, yêu cầu 20 ký tự gồm chữ-số và 5 ký hiệu, phải vượt qua đủ loại compliance ba chữ cái với checklist dài hàng trăm trang, và vì có trong checklist nên cũng phải bật WAF trên máy chủ
    Nếu hỏi CIO điều này thực sự chặn mối đe dọa nào, thứ nhận lại chỉ là ánh mắt trống rỗng
    Từ góc nhìn kỹ sư, không có động lực để hiểu từng form nhập liệu sẽ đi đâu và làm sạch theo cách có ý nghĩa. Việc được trả tiền là đánh dấu checkbox rồi đi tiếp, và người mới cũng nhanh chóng học được điều đó. Những tổ chức như vậy không tập trung cải thiện bảo mật, mà tập trung né trách nhiệm sau khi xảy ra sự cố xâm nhập
  • Việc này trông như một biến thể của vấn đề Scunthorpe, khi bộ lọc quá ngây thơ, quá hung hăng, lại còn áp dụng vào sai loại nội dung
    Việc áp dụng bộ lọc cho “những thứ khác” đi tới/đi từ máy chủ hoặc được truyền giữa các máy chủ có thể hợp lý, nhưng tôi không thấy lợi ích bảo mật nào khi lọc phần văn bản thực tế sẽ được hiển thị dưới dạng nội dung blog. Tôi xem đây gần như là một lỗi khá rõ ràng
    https://en.wikipedia.org/wiki/Scunthorpe_problem
  • Tôi không hiểu vì sao lại lọc SQL injection cho các trường nhập liệu ở cấp CDN. Ngoài độ dài hoặc kiểm tra kiểu đơn giản, chẳng hạn số hoặc ngày tháng, không có lý do gì để xác thực trường nhập liệu ở CDN
    Backend phải có khả năng xử lý nội dung byte tùy ý của trường nhập liệu, và không được dễ bị SQL injection chỉ vì không có lớp lọc trước ở tầng CDN
  • Nếu một WAF bị kích hoạt chỉ vì chuỗi "/etc/hosts" xuất hiện nguyên văn ở bất kỳ đâu trong nội dung của tài nguyên được yêu cầu, thì có vẻ khá rõ là nó đã hỏng

• Tôi nhớ tới một câu chuyện về một nền tảng thương mại điện tử. Có người tạo một webshop bị rò rỉ bộ nhớ, và như cách обход tạm, họ cấu hình để ứng dụng khởi động lại khi chuỗi "OutOfMemoryException" xuất hiện trong log
  Rồi 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ào log, và nếu ai đó nhập "OutOfMemoryException" vào ô tìm kiếm thì…

  • Phân tích log văn bản tự do một cách bất cẩn là một đường khai thác hệ thống bị đánh giá thấp. Đáng sợ là rất nhiều phần mềm cứ vô tội vạ ghi dữ liệu vào log mà không escape ngoài băng hay làm sạch
  • Thực tế tôi đã gặp chuyện kiểu này vài lần vì WAF. Người dùng để lại ghi chú có chuỗi "system(...)", WAF phán là PHP injection và chặn IP

• Tôi tò mò không biết /etc//hosts hay /etc/./hosts có bị chặn không. Trò đập chuột kiểu này chắc chắn thất bại
  Những người tạo ra thứ như vậy cần hiểu rằng kẻ tấn công thông minh và dai dẳng hơn họ, và chỉ nên dựa vào các phương pháp bảo mật đã được kiểm chứng, chẳng hạn không thực thi đầu vào không đáng tin cậy

  • Đúng vậy. Thứ này trông giống một checkbox bắt buộc phổ biến ở Fortune 500. Tường lửa ứng dụng web thì nhất định phải có, quy tắc là gì không quan trọng, chỉ cần có vài cái là được
    Có lần tôi còn được bảo rằng một ứng dụng không dùng cơ sở dữ liệu SQL vẫn cần WAF để chặn tấn công SQL injection
    Nếu phản bác, lúc nào cũng sẽ được nghe bài giảng “phòng thủ nhiều lớp”; còn nếu nói rằng mỗi sáng thứ Năm gõ bàn một cái rồi quay ba vòng tại chỗ còn hiệu quả hơn, họ sẽ nhìn mình như người điên thật sự. Tôi đã làm vậy hằng tuần và chưa từng bị hack, vậy chẳng phải là phòng thủ nhiều lớp sao. Có hại gì đâu
  • Liệt kê những thứ xấu là một chiến lược thua cuộc. Khoảng 5 phút sau khi bắt đầu công việc đầu tiên vào năm 1995, tôi đã biết đó là ý tưởng tệ
  • Tôi vừa tạo tài khoản trên Substack để thử, có vẻ họ đã sửa vấn đề hoặc tắt hẳn WAF rồi
  • Tôi không hiểu tại sao việc đó lại khó. Chức năng lấy đường dẫn tuyệt đối của một chuỗi có trong hầu hết thư viện chuẩn của mọi ngôn ngữ. Chỉ cần tìm các chuỗi có dấu gạch chéo rồi thử diễn giải chúng
    Diễn giải wildcard thì khó hơn, nhưng nếu có danh sách tệp bị cấm thì hoàn toàn làm được
    https://nodejs.org/api/path.html#pathresolvepaths
    Sửa: realpath của C hoạt động hơi khác nên tôi đã đổi liên kết
  • Nếu không chặn được kẻ tấn công có chủ đích thì một giải pháp bảo mật có phải là vô giá trị không? Nhiều quy tắc WAF được dùng để chặn các yêu cầu dò tìm của những trình quét lỗ hổng có sẵn

• Hỏi Substack có thể cải thiện tình trạng này cho các cây viết kỹ thuật như thế nào ư?
  Chỉ cần đừng gắn một tường lửa ứng dụng web ngu như đá vào endpoint biên tập bài viết, nơi người ta có thể viết về bất kỳ chủ đề nào, kể cả những chuỗi có thể kích hoạt một WAF ngớ ngẩn
  Nó giống như một diễn đàn phát triển web gắn bộ lọc XSS khiến thành viên không thể nói về XSS. Họ cần học cách escape nội dung cho đúng

  • Về phía họ, để vượt qua chứng nhận bảo mật thì phải chạy WAF. WAF mã nguồn mở thì gần như chỉ có modsecurity và hậu duệ beta của nó là coraza
    Chúng ngu ngốc, và chỉ dùng đống rác khó đọc của OWASP gọi là coreruleset
  • Họ cần thuê người phụ trách an ninh mạng. Có vẻ là chưa có

• Tôi khó đồng ý với nhận định rằng ví dụ này cho thấy một sự căng thẳng thú vị giữa bảo vệ và tính khả dụng trong bảo mật web. Đây chỉ là một lỗi, mà còn là một lỗi ngu ngốc. Nó chỉ cho thấy những người lẽ ra phải hiểu rõ hơn lại không hiểu
  Sự căng thẳng giữa bảo mật và tính khả dụng là có thật, nhưng đây không phải trường hợp đó. Thông thường đó là kiểu đánh đổi trong đó triển khai bảo mật tốt làm người dùng bất tiện. Xác thực hai yếu tố, khóa sau 3 lần thất bại, giới hạn tốc độ để chống DoS — khi tăng bảo mật thì trải nghiệm người dùng kém đi, còn khi tăng trải nghiệm người dùng thì bảo mật giảm
  Cái này không thuộc cả hai. Vừa là bảo mật tệ, vừa là trải nghiệm người dùng tệ. Tôi không hiểu sự căng thẳng nằm ở đâu

  • Nói chung, áp WAF đồng loạt lên mọi endpoint rồi gỡ chọn lọc khi phát sinh vấn đề kiểu này là một thực hành bảo mật hữu ích. Đặc biệt khi host phần mềm bên thứ ba như Wordpress có plugin, việc đánh giá từng endpoint công khai một còn khó hơn nhiều
  • Làm tôi nhớ thời PHP 3. Hình như PHP từng “làm sạch” nội dung yêu cầu URL để chặn SQL injection hàng loạt, hoặc cũng có thể đó là một thiết lập thường được bật trên shared hosting
    Tất nhiên tác giả các site PHP nhanh chóng phát hiện ra điều này và nhiều kỹ thuật né tránh đã được dùng; xét tổng thể rất có thể việc “làm sạch” đó còn gây kết quả tệ hơn so với khi không có nó

• Vì từng bị một lần trước đây, nên ngay khi thấy chữ “lỗi mạng” là tôi lập tức nghĩ ra nguyên nhân
  Khi dạy một đội lập trình thi đấu, một nửa học sinh trong lớp nhận trang trắng khi nộp lời giải; sau một giờ debug, chúng tôi thu hẹp được còn vài kiểu và từ khóa C++ mà khi xuất hiện trong code sẽ gây 403, và tất cả đều là những thứ cũng có ý nghĩa trong JavaScript
  Khi làm ở ngân hàng cũng có một API yêu cầu nộp file Python; hầu hết file Python đều bị 403, còn file ngắn thì qua. Sau vài giờ debug, chúng tôi thu hẹp được còn một từ khóa thỉnh thoảng xuất hiện trong code
  Vài tháng sau, chuyện tương tự xảy ra ở môi trường cloud mới và lại tốn thêm vài giờ. Từ lần thứ hai trở đi, một đồng nghiệp đã làm cho script triển khai in ra "HAHAHA YOU'VE BEEN WAFFED" nếu nhận 403, và tôi đến giờ vẫn biết ơn vì đã thấy lỗi đó thường xuyên hơn mong đợi rất nhiều

  • Tôi tò mò không biết bạn có nhớ đó là Cloudflare hay một WAF khác không

• Ứng dụng của chúng tôi cũng từng gặp chuyện tương tự. Red team nội bộ đang đăng dữ liệu chứa các nỗ lực XSS và những kiểu tấn công injection khác
  Bản thân các cuộc tấn công không thành công, nhưng chỉ vì các mục đó tồn tại mà tường lửa công ty đã chặn các yêu cầu mạng chứa payload ấy, khiến trang quản trị nội bộ không tải được. Rốt cuộc một cuộc tấn công XSS thất bại lại trở thành một cuộc tấn công DoS hiệu quả

• Cái cũ lại thành cái mới. Ngày xưa người ta gọi kiểu này là vấn đề Scunthorpe
  https://en.m.wikipedia.org/wiki/Scunthorpe_problem

  • Tôi nhớ trên diễn đàn Eve Online ngày xưa, từ cockpit luôn bị đổi thành c***pit. Khá buồn cười
  • Cũng làm tôi nhớ đến chuyện gần đây các website chính phủ Mỹ xóa những từ như “diversity”, “equity”, “inclusion”
    Nếu bạn đang viết về sinh học, tài chính, địa chất thì sao? Đành chịu xui thôi
    Lọc ngu ngốc đã đủ tệ rồi, ngay cả khi do người thông minh và có thiện ý viết ra
  • Đã đến lúc thêm trường hợp Substack này vào bài Wikipedia

• Tối qua tôi cũng gặp vấn đề tương tự trên OpenRouter. OpenRouter là một dịch vụ kiểu “tổng đài” rất hay, cho phép dùng nhiều LLM qua một endpoint, và tối qua tôi bắt đầu thử xem model nào xử lý HTML thô theo nhiều cách tốt nhất
  Nhưng API của OpenRouter được Cloudflare bảo vệ, nên khi phần thân yêu cầu POST chứa một số đoạn HTML thô và JavaScript nhất định, nhiều yêu cầu — dù không phải tất cả — bị chặn. Gửi cùng prompt trực tiếp đến OpenAI hoặc Anthropic thì không vấn đề gì
  Nếu là model miễn phí thì tôi hiểu việc siết mạnh để chống lạm dụng, nhưng đây là các yêu cầu bị tính phí cho model thương mại nên càng khó chịu hơn

  • Không biết bạn đã báo lỗi chưa

• Trước đây tôi từng gặp vấn đề này và cực kỳ bực. Vì "Network error", tôi không thể cập nhật một bài đã viết trong nhiều tháng; tôi tưởng do bài viết dài lên sau khi chỉnh sửa nên không tìm ra nguyên nhân
  Việc liên hệ hỗ trợ cũng khó vì chatbot AI, và khi cuối cùng gặp được người thật thì “hỗ trợ kỹ thuật” của họ có vẻ chẳng định xem xét trong một khoảng thời gian hợp lý
  Chỉ sau khi một người trên Twitter gợi ý khả năng có một chuỗi ma thuật chạm vào logic bảo mật ngu ngốc, tôi mới tìm ra vấn đề và cuối cùng có thể sửa bài