Можливість аналізувати HTML не означає здатність безпечно відображати HTML

BeautifulSoup успішно аналізує, але це не означає, що HTML безпечний. Для розробників і груп документації, яким потрібно обробляти зовнішній HTML, ця стаття пояснює, чому синтаксичні аналізатори та очищувачі слід розглядати окремо, і надає набір ідей очищення білого списку, тестових прикладів і критеріїв перевірки вручну.

Приклади в цій статті є синтетичними і використовуються лише для демонстрації методів обробки. Зразок коду перевірено в ізольованому середовищі, але це не означає, що він гарантовано працюватиме з усіма реальними файлами чи продуктами. Перед обробкою важливих документів збережіть оригінали, а потім перегляньте їх один за одним відповідно до меж і пунктів прийняття в документі.

Висновок одним реченням: після аналізу очищення потрібно робити окремо

Небезпечні атрибути, такі як <img src=x onerror=alert(1)>, залишаються недоторканими у вихідних даних після їх аналізу BeautifulSoup. Очищення має бути додатковим рівнем бізнес-логіки, що накладається після аналізу.

Невідповідність між аналітичними можливостями та обов'язками щодо безпеки

BeautifulSoup Офіційна документація визначає це як «бібліотеку для вилучення даних із файлів HTML і XML», зосереджену на навігації, пошуку та модифікації деревоподібних структур. Таким чином, він нейтральний щодо семантичної безпеки вмісту. Коли введено <a href="javascript:void(0)">Click</a>, BS4 правильно побудує об’єкт Tag з атрибутом 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 відповідає за перетворення рядків на об’єкти, які можна пройти, а логіка очищення відповідає за визначення того, які об’єкти можна зберегти.

Реалізація очищення пам'яті на основі білого списку

Наступний приклад Python показує, як це зробити в пам’яті. Цей код призначений лише для демонстрації навчання. Він не обробляє такі деталі, як багатозначні атрибути, нормалізація регістру, кодування об’єктів тощо. Його суворо заборонено використовувати безпосередньо у виробничому середовищі. Це залежить від 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. Чи зникне шкідливий код після аналізу та повторної серіалізації за допомогою BeautifulSoup?

не буду. Приклад у цій статті показує, що <img src=x onerror=alert(1)> залишається незмінним у вихідних даних після аналізу та серіалізації.

2. Як працювати з тегами та атрибутами поза білим списком?

Якщо мітки немає в білому списку, її текст можна розгорнути, щоб зберегти її; атрибути обробника подій, такі як onclick, слід повністю видалити.

3. Чи можна використати зразок коду безпосередньо у виробничому середовищі?

не можу Приклад призначений лише для демонстрації навчання та не обробляє такі деталі, як багатозначні атрибути, нормалізація регістру та кодування об’єктів. Виробниче середовище може розглядати bleach і налаштовувати білий список зовні.

4. Якщо демонстрація коду пройдена, чи означає це, що ефект обробки є надійним?

Це не можна зробити висновок. Якщо форма позначена як така, що потребує перевірки вручну, автоматизований процес слід призупинити та надіслати на перевірку вручну.

5. Чи можна перевірити безпосередньо з реальними файлами?

Рекомендується спочатку десенсибілізувати бізнес-дані, видалити особисту інформацію та конфіденційні посилання, а потім перевірити відповідно до пунктів прийняття.

Використовуйте контрольні списки для перекладу документів

Текст, посилання, код і структура веб-документів повинні оброблятися окремо. Додайте захищені частини до списку прийому, а потім оцініть читабельність і вигляд сторінки після перекладу.

OmniDoc (портал продуктів) надає багатоформатний портал перекладу документів, а на офіційному веб-сайті представлені функції OCR, глосарій і двомовне порівняння. Для команд, які хочуть працювати безпосередньо з файлами, це шлях, який варто оцінити на прикладах із реального життя. Будь ласка, використовуйте десенсибілізовані файли, на завантаження яких у вас є дозвіл, і скористайтеся прапорцями в цій статті, щоб переглянути результати. Тут немає жодних тверджень, що OmniDoc використовує бібліотеки з відкритим кодом або внутрішні алгоритми, згадані в цій статті, і приклади не є заміною для тестування продуктивності продукту.

📝 Підсумок

Синтаксичний аналіз відповідає лише на те, як виглядає HTML, а безпека покладається на білий список і перевірку вручну. Спочатку запустіть приклад у закритому середовищі залежностей, потім використовуйте десенсибілізовані зразки, щоб перевірити кожен елемент відповідно до форми прийняття, а потім вирішіть, чи приєднуватися до офіційного процесу.

Спробуйте зараз: завантажте документ, щоб розпочати переклад, зберігаючи вихідний макет