Языки, архитектура и безопасный SQL

Где именно выбор языка становится решением по безопасности?

Не в рейтинге популярности и не в споре «компилируемый против интерпретируемого», а в архитектурном решении: какие ошибки возможны, где проходят границы доверия и какими средствами команда докажет выполнение требований.

К вечеру слушатель должен уметь

• сравнивать языки по нескольким признакам, а не по одному ярлыку;
• фиксировать выбор языка и стека как проверяемое архитектурное решение;
• различать библиотеку, фреймворк, платформу и предметно-ориентированный язык;
• проектировать SQL-схему с ограничениями целостности;
• разделять SQL-код и данные с помощью placeholders;
• применять allowlist там, где идентификаторы нельзя параметризовать;
• подтверждать результат тестами, SAST и CI, а не только ручным запуском.

Хроника языков: менялась не только запись программ

Каждое поколение языков переносило часть ответственности от разработчика к транслятору, среде выполнения, системе типов или библиотекам. Вместе с удобством перемещалась и поверхность атаки.

«Компилируемый» и «интерпретируемый» — недостаточно

Современный язык нужно рассматривать вместе с его реализацией и экосистемой. CPython, например, получает байткод и исполняет его виртуальной машиной; поэтому граница между компиляцией и интерпретацией размыта.

В конспекте зафиксированы четыре независимые оси классификации — уровень абстракции, парадигма, модель выполнения и область применения. Таблица ниже повторяет их и добавляет инженерные срезы (типизация, память, FFI, toolchain), которые понадобятся при выборе стека.

Язык исключает одни дефекты, но не отменяет требования

Выбор memory-safe языка способен устранить или сильно затруднить часть ошибок ручного управления памятью. Он не устраняет ошибки авторизации, SQL-инъекции, небезопасную десериализацию, секреты в коде и уязвимые зависимости.

Минимум для C/C++ в архитектурном решении

• обосновать, почему требования нельзя закрыть memory-safe альтернативой;
• минимизировать объём небезопасного кода и изолировать его интерфейс;
• включить -fstack-protector-strong, -D_FORTIFY_SOURCE=3, PIE/RELRO там, где поддерживается;
• на тестовых сборках применять ASan/UBSan, а при многопоточности — TSan отдельным прогоном;
• зафиксировать правила CERT C/C++ или применимый профиль MISRA и процесс управления отклонениями;
• добавить fuzzing и регрессионный тест на каждый подтверждённый дефект.

DSL: меньше свободы, больше смысла

Предметно-ориентированный язык выражает задачи конкретной области. SQL описывает выборку и изменение отношений; регулярные выражения — шаблоны строк; конфигурационный DSL — состояние инфраструктуры. Ограниченный словарь может сделать намерение проверяемым, но интерпретатор DSL остаётся границей доверия.

Shift Left: раньше, но не один раз

Требования безопасности, моделирование угроз, анализ архитектуры и автоматические проверки включаются раньше в существующий SDLC. Это не означает перенос всей безопасности только в начало проекта.

От инженерной практики к проверяемому процессу

Библиотека, фреймворк и платформа

Фраза «библиотеку вызываете вы, фреймворк вызывает вас» полезна как эвристика, но реальные продукты бывают гибридными. Для безопасности название не меняет обязательных действий.

• идентифицировать компонент, версию, поставщика и источник;
• проверить происхождение, целостность и лицензию;
• найти известные уязвимости и оценить достижимость;
• зафиксировать компонент в SBOM и политике допуска;
• назначить владельца обновления и срок поддержки;
• учесть расширения, плагины и транзитивные зависимости.

ADR выбора языка и стека

Архитектурное решение должно объяснять не только «что выбрали», но и какие угрозы учтены, какие альтернативы отклонены и чем контролируется остаточный риск.

Модель угроз реестра компонентов

Учебное приложение хранит наименование компонента, версию, SPDX-идентификатор лицензии, поставщика и критичность. Данные вымышлены, но угрозы типовые.

Безопасность начинается со схемы

Валидация только в интерфейсе обходится другим клиентом. Ограничения базы данных действуют для каждого пути записи и становятся исполняемой частью требований.

CREATE TABLE components (
  id INTEGER PRIMARY KEY,
  name TEXT NOT NULL
    CHECK (length(trim(name)) BETWEEN 1 AND 100),
  criticality TEXT NOT NULL
    CHECK (criticality IN (
      'low', 'medium', 'high'
    ))
) STRICT;

SQL-инъекция: данные стали кодом

sql = (
  "SELECT id, name FROM components "
  f"WHERE name = '{term}'"
)
rows = conn.execute(sql).fetchall()

rows = conn.execute(
  """
  SELECT id, name
  FROM components
  WHERE name = ?
  """,
  (term,),
).fetchall()

В первом примере значение попадает внутрь грамматики SQL. Во втором драйвер передаёт текст запроса и значение раздельно; payload остаётся строкой. Ручное «экранирование кавычек» не заменяет параметризацию.

Placeholder не подставляет имя столбца

Параметры предназначены для значений. Если пользователь выбирает сортировку, имя столбца нельзя передавать как ?. Его отображают на константу, принадлежащую коду.

SORT_COLUMNS = {
  "name": "name",
  "version": "version",
  "license_spdx": "license_spdx",
  "criticality": "criticality",
}

try:
    column = SORT_COLUMNS[user_choice]
except KeyError:
    raise ValueError("Недопустимый ключ сортировки")  # контракт: ValueError
sql = f"SELECT ... ORDER BY {column} ASC"

Транзакция, аудит и минимальные полномочия

with conn:
  cursor = conn.execute(
    "UPDATE components SET license_spdx = ? WHERE id = ?",
    (new_license, component_id),
  )
  if cursor.rowcount != 1:
    raise LookupError("Компонент не найден")
  conn.execute(
    "INSERT INTO audit_events (...) VALUES (?, ?)",
    ("license_changed", component_id),
  )

Для читающего процесса используется отдельное подключение file:...?...mode=ro. В рабочей клиент-серверной СУБД принцип продолжается отдельной учётной записью с минимальными правами. Только приложение не должно решать, может ли оно писать: запрет должен обеспечивать и нижний слой.

Маршрут трёх практических занятий

Команды

py step1_schema.py
py -m unittest -v test_examples.py   # служебная проверка примеров, по желанию
py demo_unsafe_query.py
py step2_secure_queries.py
py -m unittest -v test_student.py

CI проверяет именно студенческий результат

Ответ на вопрос дня

Выбор языка становится решением по безопасности тогда, когда он связан с активами и угрозами, зафиксирован в архитектуре, ограничивает конкретные классы дефектов и сопровождается проверяемым набором мер для оставшихся рисков.

• язык влияет на возможные ошибки памяти, типизации и границ FFI;
• архитектура определяет доверительные границы и полномочия компонентов;
• фреймворк и платформа расширяют цепочку поставок и поверхность обновления;
• схема SQL превращает часть требований в исполняемые ограничения;
• placeholder отделяет данные от кода, но не заменяет allowlist идентификаторов;
• тесты и CI превращают правила в повторяемые свидетельства;
• Shift Left означает раннюю и постоянную интеграцию безопасности во весь SDLC.

Скачать комплект

Архив содержит офлайн-лекцию, конспект, задания и учебный код. Для основных упражнений достаточно Python 3.11 или новее; SQLite и unittest входят в стандартную библиотеку.

Первичные источники

• ГОСТ Р 56939-2024 — официальная карточка Росстандарта
• NIST SP 800-218 v1.1 Secure Software Development Framework
• ISO/IEC 27034-1:2011 Application security
• ISO/IEC 24772-1:2024 Language vulnerabilities
• Dennis Ritchie, The Development of the C Language
• ISO C++ FAQ: история C++
• Python General FAQ
• MITRE CWE-119: Memory Buffer Bounds
• MITRE CWE-89: SQL Injection
• OWASP SQL Injection Prevention Cheat Sheet
• Python sqlite3: placeholders и транзакции
• SQLite Security и Foreign Keys