"/etc/hosts" 파일 작성으로 인한 Substack 에디터 오류 발생
(scalewithlee.substack.com)- Substack 에디터에서 특정 시스템 경로를 입력할 때 네트워크 오류가 발생함
- 웹 애플리케이션 방화벽(WAF) 가 이러한 경로를 차단하는 이유는 경로 탐색 공격 및 명령어 삽입 공격 방지 때문임
- 보안과 사용성 사이의 균형이 중요한 문제로 부각됨
- 기술 작가를 위한 더 나은 해결책이 필요함
- 대체 경로를 사용하여 문제를 해결할 수 있음
/etc/h*sts가 Substack 에디터를 방해할 때: 웹 콘텐츠 필터링의 모험
신비로운 네트워크 오류
- DNS 해상도에 대한 기술 포스트 작업 중 예상치 못한 오류 발생
-
/etc/h*sts
경로 입력 시 네트워크 오류 발생, 자동 저장 실패 - Substack의 상태 페이지는 정상 작동 중임을 보여줌
조사 시작
- 특정 파일 경로 입력 시 오류 발생, 경로 변형 시 정상 작동
-
/etc/h*sts
와 같은 경로는 오류를 일으키고, 변형된 경로는 문제 없음
내부에서 무슨 일이 일어나고 있는가?
- 브라우저 개발자 도구에서 403 Forbidden 응답 확인
- Cloudflare가 관련되어 있음
웹 애플리케이션 보안 필터 이해하기
WAF 간단 설명
- 웹 애플리케이션 방화벽(WAF) 는 웹사이트의 보안 경비원 역할
- 의심스러운 요청을 차단함
경로 탐색 공격: 주의 이유
- 경로 탐색 공격은 민감한 시스템 파일에 접근하려는 시도
-
/etc/h*sts
와 같은 경로는 공격 대상이 될 수 있음
명령어 삽입: 또 다른 보안 문제
- 명령어 삽입 공격은 시스템 명령어 실행을 유도
- 시스템 경로 언급 시 필터가 차단할 수 있음
신비가 깊어지다: 역사적 예
- 다른 Substack 포스트에서 유사한 경로 사용 사례 발견
- 필터링 동작이 특정 시점에 변경되었을 가능성
보안 대 사용성: 미묘한 균형
- Substack의 필터는 보호를 위한 것이지만, 기술 작가에게는 장애물이 됨
- 개선의 여지가 있음: 명확한 오류 메시지, 기술적 내용 인식, 문서화된 해결책 제공
HTTP 응답 살펴보기
- API 수준에서 403 Forbidden 상태 코드 확인
기술 콘텐츠 플랫폼을 위한 더 나은 해결책
- 맥락적 필터링: 코드 블록이나 기술 토론에서 시스템 경로 인식
- 명확한 오류 메시지: "네트워크 오류" 대신 보안 필터로 인한 차단 설명
- 문서화된 해결책: 민감한 경로 논의 방법 제공
결론: 보안과 기술 작문의 교차점
-
Substack 에디터의 문제는 보안과 기술 작문의 복잡한 도전 과제를 드러냄
-
보안 필터에 의해 공격 패턴으로 보일 수 있는 것이 실제로는 합법적인 콘텐츠일 수 있음
-
대체 경로를 사용하여 문제 해결 가능
-
유사한 필터링 문제를 다른 플랫폼에서 겪은 경험이 있는지 댓글로 공유 요청
Hacker News 의견
-
CDN에서 WAF 규칙을 설정하는 사람들은 기술 콘텐츠를 다루는 사이트와 서비스를 잘 이해하지 못하는 경우가 많음. Cloudflare뿐만 아니라 Akamai도 같은 문제를 겪음
- 데이터베이스를 다루는 사이트라면 기본 SQL 인젝션 공격 방지 규칙을 켜면 사이트가 망가질 수 있음
- 파일 포함 규칙 세트도 있어서
/etc/hosts
나/etc/passwd
같은 것이 차단됨 - 보안과 사용성 간의 균형이 중요하다고 생각함. 모든 WAF 규칙을 적용하면 보안이 강화되지만, 기술 개념을 논의해야 하는 서비스에서는 불편함
- 규칙을 세밀하게 조정하는 것은 시간이 많이 걸림. 규칙을 유지하면서 사용 사례를 허용하려면 많은 변경이 필요함
- 페이지가 로드되지 않거나 리소스가 로드되지 않는 등의 문제가 발생할 수 있음. 규칙을 끄고 싶은 유혹이 있음
-
전자상거래 플랫폼에 대한 일화가 떠오름: 누군가 메모리 누수가 있는 웹샵을 코딩했고, 로그에 "OutOfMemoryException" 문자열이 나타나면 앱을 재시작하는 방식으로 해결했음
- 다른 개발자가 고객 검색어를 기록하고 싶어 했고, 누군가 검색창에 "OutOfMemoryException"을 입력하면 문제가 발생함
-
/etc/hosts
나/etc/./hosts
를 차단하는지 궁금함. 이는 실패할 수밖에 없는 두더지 잡기 게임 같음. 해커들은 더 똑똑하고 결단력이 강하므로 검증된 보안에만 의존해야 함 -
Substack이 기술 작가들을 위해 이 상황을 어떻게 개선할 수 있을지에 대한 의견
- 사람들이 어떤 주제에 대해서든 글을 편집할 수 있는 엔드포인트에서 어리석은 WAF를 실행하지 말아야 함
- 웹 개발 포럼에서 XSS 필터를 구현하여 회원들이 XSS에 대해 이야기하지 못하게 하는 것과 같음
- 콘텐츠를 적절히 이스케이프하는 방법을 배워야 함
-
웹 보안에서 보호와 사용성 간의 긴장감에 대한 흥미로운 사례를 강조함
- 하지만 이 경우는 버그를 강조함. 보안과 사용성 간의 긴장감은 실제로 존재하지만, 이 경우는 아님
- 보안과 사용성 간의 긴장은 보통 트레이드오프임. 보안을 강화하면 사용자 경험이 저하됨
- 이 경우는 나쁜 보안과 나쁜 사용자 경험 모두를 보여줌
-
경쟁 프로그래밍 팀을 가르치던 중 발생한 문제: C++ 타입과 키워드가 코드에 나타나면 403 오류가 발생함
- 은행에서 일할 때, Python 파일을 제출해야 하는 API가 있었고, 대부분의 Python 파일이 403 오류를 발생시킴
- 새로운 클라우드 환경에서도 비슷한 문제가 발생함
-
내부 레드 팀이 XSS 및 기타 인젝션 공격 시도를 포함한 데이터를 게시했을 때 발생한 문제
- 공격 자체는 작동하지 않았지만, 이러한 항목의 존재로 인해 내부 관리자 페이지가 로드되지 않음
-
오래된 문제가 다시 나타남. 이를 Scunthorpe 문제라고 부름
-
OpenRouter와 관련된 유사한 문제를 경험함. OpenRouter는 다양한 LLM을 사용할 수 있는 단일 엔드포인트를 제공하는 서비스임
- 특정 HTML 및 JavaScript 조각이 POST 요청 본문에 포함되면 많은 요청이 차단됨
-
콘텐츠 필터링은 맥락에 크게 의존해야 함. WAF가 필터링해야 할 것과 분리되어 있으면 문제가 발생함
- 스팸 필터링과 유사함. 이메일 서버는 발신 서버의 구성에 따라 필터링함
- 콘텐츠 기반 필터링보다 전달 기반 필터링이 더 효과적임. 웹 사이트와 WAF에서도 동일하게 적용됨