HTML을 구문 분석할 수 있다고 해서 HTML을 안전하게 표시할 수 있다는 의미는 아닙니다.

BeautifulSoup이 성공적으로 구문 분석한다고 해서 HTML이 안전하다는 의미는 아닙니다. 외부 HTML을 처리해야 하는 개발자 및 문서화 팀을 위해 이 문서에서는 파서와 정화기를 별도로 살펴봐야 하는 이유를 설명하고 일련의 화이트리스트 정리 아이디어, 테스트 사례 및 수동 검토 기준을 제공합니다.

이 기사의 예는 합성 샘플이며 처리 방법을 보여주기 위해서만 사용됩니다. 코드는 격리된 환경에서 샘플 검사를 거쳤지만 이것이 모든 실제 파일이나 제품에서 작동한다는 것을 보장한다는 의미는 아닙니다. 중요한 문서를 처리하기 전, 원본을 보관하신 후, 문서에 기재된 경계 및 허용 항목에 따라 하나씩 검토하시기 바랍니다.

한 문장으로 결론: 분석 후 청소는 별도로 해야 함

<img src=x onerror=alert(1)>와 같은 위험한 속성은 BeautifulSoup가 구문 분석한 후에도 출력에 그대로 유지됩니다. 정리는 구문 분석 후에 겹쳐지는 비즈니스 로직의 추가 계층이어야 합니다.

분석 역량과 안전 책임 간의 불일치

BeautifulSoup 공식 문서는 이를 트리 구조 탐색, 검색 및 수정에 초점을 맞춘 "HTML 및 XML 파일에서 데이터를 추출하기 위한 라이브러리"로 정의합니다. 따라서 콘텐츠의 의미론적 보안에 대해서는 중립적입니다. <a href="javascript:void(0)">Click</a>가 입력되면 BS4는 href 속성을 사용하여 태그 개체를 올바르게 구축하지만 프로토콜이 허용되는지 여부는 결정하지 않습니다.

문서 처리에서 이러한 중립성은 장단점이 있습니다. 다양한 불규칙한 역사적 지표를 처리할 수 있다는 장점이 있습니다. 개발자가 "BS4 처리됨"이 "삭제됨"과 동일하다고 가정할 경우 검증되지 않은 HTML이 미리보기 인터페이스나 번역 결과물에 직접 포함될 수 있다는 위험이 있습니다.

진정한 보안 클리닝은 명시적인 화이트리스트 전략을 필요로 합니다: 알려진 안전 라벨 이름과 속성 이름만 유지하고, 속성 값의 형식을 확인하며, 그 외 모든 정보를 제거합니다. 이것은 BS4의 내장 기능이 아니라 사용자가 스스로 겹쳐야 하는 논리입니다.

합성 예제에서의 경계 입력

정화의 필요성을 설명하기 위해, 다음 샘플은 일반적인 공격 벡터와 합법적인 콘텐츠를 다루는 데 사용됩니다. 이 입력값들은 경계 상태를 보여주는 데만 사용되며, 실제 교통 통계가 아니고 업계 표준 임계값을 나타내지 않습니다. 실제 문서를 테스트하려면 먼저 비즈니스 데이터를 둔감화하여 개인 정보와 민감한 링크를 제거하세요.

올바르게 입력하세요

<p>See <a href="https://example.com/doc">reference</a>.</p>

p와 a가 화이트리스트에 포함되어 있고 href는 HTTPS 프로토콜을 사용하기 때문에 예상 출력은 단락과 링크를 그대로 유지해야 합니다.

경계 입력 1: 이벤트 핸들러

<div onclick="steal()">Safe text</div>

텍스트가 무해하더라도, onclick는 이벤트 핸들러 속성에 속하므로 완전히 제거되어야 하며, <div>Safe text</div>만 남습니다. div가 태그 화이트리스트에 없다면, 전체 태그를 일반 텍스트 콘텐츠로 대체해야 합니다.

경계 입력 2: 데이터: 프로토콜

<a href="data:text/html,<script>alert(1)</script>">Link</a>

data: URI는 실행 가능한 콘텐츠를 담을 수 있습니다. 태그 자체가 유효하더라도 href는 비워두거나 삭제해야 합니다. 클리너는 프로토콜 접두사가 http인지 확인할 뿐만 아니라, 디코딩된 콘텐츠가 중첩된 실행 컨텍스트를 구성하는지 여부도 검증합니다.

이러한 사례들은 보안 결정이 해결 후 속성 수준 검토 단계에서 이루어진다는 점을 보여줍니다. BS4는 문자열을 이동 가능한 객체로 바꾸는 역할을 하며, 클린 로직은 어떤 객체를 유지할 수 있을지 결정합니다.

화이트리스트를 기반으로 한 메모리 정리

다음 파이썬 예제는 메모리에서 이 과정을 수행하는 방법을 보여줍니다. 이 코드는 시연 교육용으로만 사용되며 다중 값 속성, 케이스 정규화, 엔터티 인코딩 또는 기타 세부 사항을 다루지 않습니다. 생산 환경에서 직접 사용하는 것은 엄격히 금지됩니다. beautifulsoup4에 따라 다르니 직접 설치해야 하고, 버전을 잠그는 것이 권장됩니다. 이 코드는 네트워크 요청을 시작하지도, 파일 시스템에 읽거나 쓰지도 않습니다. 이 주장들은 기대되는 행동만을 표현하며, 실제 결과는 환경과 의존성에 따라 달라집니다.

# 教学示例：演示BS4配合白名单清洗原理，非生产级实现
from bs4 import BeautifulSoup, Comment
import re

ALLOWED_TAGS = {'p', 'a', 'b', 'i', 'ul', 'li'}
ALLOWED_ATTRS = {'href'}
SAFE_URL_PATTERN = re.compile(r'^https?://', re.IGNORECASE)

def sanitize_html(raw: str) -> str:
    soup = BeautifulSoup(raw, 'html.parser')
    # 移除注释
    for comment in soup.find_all(string=lambda t: isinstance(t, Comment)):
        comment.extract()
    # 遍历所有标签
    for tag in soup.find_all(True):
        if tag.name not in ALLOWED_TAGS:
            tag.unwrap()  # 保留子节点，移除标签本身
            continue
        # 清理属性
        attrs_to_remove = [k for k in tag.attrs if k not in ALLOWED_ATTRS]
        for attr in attrs_to_remove:
            del tag[attr]
        # 校验剩余安全属性值
        if 'href' in tag.attrs:
            href = tag['href']
            if not isinstance(href, str) or not SAFE_URL_PATTERN.match(href.strip()):
                del tag['href']
    return str(soup)

# 合成测试用例（仅用于理解原理）
safe = '<p>Hello <a href="https://ok.com">link</a></p>'
unsafe_event = '<p onclick="x()">text</p>'
unsafe_uri = '<a href="javascript:alert(1)">bad</a>'

assert sanitize_html(safe) == '<p>Hello <a href="https://ok.com">link</a></p>'
assert 'onclick' not in sanitize_html(unsafe_event)
assert 'href' not in sanitize_html(unsafe_uri)

운영 환경에서는 전용 정리 라이브러리(예: bleach)를 사용하고 코드 외부에 화이트리스트 구성을 배치하는 것을 고려할 수 있습니다. 핵심은: 정화 논리는 '허용되는 것'을 명확히 밝히는 것이지, '금지된 것'을 나열하려 해서는 안 된다는 점입니다.

수동 검토의 수용 기준과 트리거 포인트

코드 내 주장은 미리 설정된 규칙이 실행되고 있는지 검증할 뿐이며, 모든 현실 세계 이상 현상을 다룰 수는 없습니다. 아래 표는 실제 문서 처리에서 흔히 발생하는 상황과 자동화 처리와 인간 개입 간의 경계를 나열합니다.

"코드 데모 통과"는 "엔드 투 엔드 효과가 신뢰할 만하다"는 뜻이 아닙니다. 표에 "예"로 표시된 프로젝트의 경우, 자동화된 프로세스는 일시정지되어 수동 검토에 넘겨져야 합니다. 번역 전달 시나리오에서는 과도한 정리가 용어 인용 구절이나 잘못된 서식 규칙을 유발할 수 있습니다.

📊 핵심 비교

🎯 어떤 방법이 당신에게 맞나요?

데이터만 추출하면 된다면

BeautifulSoup을 직접 사용하되, 소독된 것처럼 출력물을 표시하지 마세요.

외부 또는 과거 유산 HTML을 표시하고 싶다면

먼저 화이트리스트 청소 계층을 설정하고, 수락 시트에 따라 각 항목을 테스트합니다.

제작 준비를 하고 있다면

bleach 같은 특수 라이브러리를 사용하고, 화이트리스트를 외부에서 설정하며, 수동 검토 트리거 규칙을 유지하는 것을 고려하세요.

문서 번역과 전달을 하고 싶다면

본문, 링크, 코드, 구조를 별도로 확인하고, 표에 표시된 항목에 대해 수동 검증을 주선하세요.

❓ 자주 묻는 질문 (FAQ)

1. BeautifulSoft로 파싱하고 직렬화하면 악성 코드가 사라질까요?

아니. 논문의 예시는 파싱과 직렬화 후에도 <img src=x onerror=alert(1)>가 출력에 완전히 유지됨을 보여줍니다.

2. 화이트리스트 밖의 태그와 속성을 어떻게 처리하나요?

만약 태그가 화이트리스트에 없으면, 텍스트를 유지하기 위해 언랩할 수 있습니다; onclick 같은 이벤트 프로세서 속성은 완전히 제거해야 합니다.

3. 샘플 코드를 프로덕션 환경에서 직접 사용할 수 있나요?

아니, 그럴 수 없어. 예제들은 교육 시연용으로만 제공되며, 다중 값 속성, 케이스 정규화, 엔터티 인코딩 등의 세부 사항은 다루지 않습니다. 운영 환경에서는 bleach를 고려할 수 있으며, 화이트리스트는 외부에서 구성할 수 있습니다.

4. 코드 시연이 통과된다면, 처리 효과가 신뢰할 만하다는 뜻인가요?

그렇게 추론할 수 없습니다. 양식이 승인되어 수동 검토가 필요한 경우, 자동화된 절차는 중단되고 수동 검토가 허용되어야 합니다.

5. 실제 파일로 직접 테스트할 수 있나요?

먼저 비즈니스 데이터를 둔감화시키고, 개인 정보와 민감한 링크를 제거한 후, 수용 기준에 따라 테스트를 하는 것이 권장됩니다.

문서 번역에 체크리스트를 사용하세요

웹페이지의 본문, 링크, 코드, 구조는 별도로 처리해야 합니다. 수락 체크리스트에 보호된 섹션을 포함시키고, 번역 후 가독성과 페이지 표시 상태를 평가하세요.

OmniDoc (제품 입력)는 다중 형식의 문서 번역 포털을 제공하며, 공식 웹사이트에서는 OCR, 용어집, 이중 언어 참고 기능을 소개합니다. 파일을 직접 시작하고자 하는 팀에게는 실제 샘플을 활용해 평가할 가치가 있는 경로입니다. 업로드를 승인한 익명 파일을 사용해 이 기사의 체크리스트와 결과를 확인해 주시기 바랍니다. 이는 OmniDoc이 이 글에서 언급한 오픈 소스 라이브러리나 내부 알고리즘을 사용한다는 주장도 아니며, 예시들이 제품 성능 테스트를 대체하지도 않습니다.

📝 요약

구문 분석은 "HTML은 어떻게 생겼는가?"라는 질문만 할 뿐이며; 보안은 화이트리스트 등록과 수동 검증에 달려 있습니다. 먼저, 고정된 의존성 환경에서 예제를 실행하고, 수락 시트에 따라 둔감화된 샘플로 각 항목을 테스트한 후, 최종 정식 프로세스에 통합할지 결정합니다.

지금 경험해보세요: 원본 형식을 유지하면서 번역을 시작하려면 문서를 업로드하세요