Сценарий учебного занятия (Конспект)

«Здравствуйте, коллеги! Прошу садиться. Сегодня мы приступаем к изучению темы, которая находится на стыке проектирования реляционных баз данных, сетевой безопасности и эргономики пользовательских интерфейсов: "Организация интерфейса с пользователем: контроль".

Представьте типовую ситуацию: начинающий веб-разработчик создал красивую форму перевода денег в интернет-банке. Он написал на JavaScript проверку: если сумма меньше или равна нулю, форма подсвечивается красным и кнопка блокируется. Разработчик горд собой и считает, что система надежно защищена.

Но злоумышленник открывает утилиту командной строки curl и отправляет HTTP POST запрос напрямую к API-серверу, передав amount = -50000. А в коде сервера программист просто подставил это число в SQL-запрос UPDATE accounts SET balance = balance - amount. Минус на минус дает плюс, и баланс счета злоумышленника волшебным образом увеличился на 50 тысяч рублей! Почему это произошло? Потому что разработчик нарушил золотое правило архитектуры: клиентскому интерфейсу никогда нельзя доверять слепо.

Сегодня мы с вами разберем полную цепочку эшелонированного контроля данных: от регулярных выражений и проверки контрольных разрядов на клиенте до параметризованных запросов, серверных триггеров и перехвата исключений SQLSTATE в СУБД. Открываем рабочие материалы занятия 24!»

«Давайте вспомним фундаментальные механизмы СУБД. Коллеги, скажите: какие встроенные инструменты реляционной базы данных препятствуют появлению недостоверных или противоречивых данных?»

«Верно. А теперь представим, что мы создаем бронирование переговорной комнаты или покупаем последний товар на складе. Что произойдет, если два покупателя одновременно нажмут кнопку "Купить", а наш бэкенд перед оформлением делает обычный SELECT stock FROM products?»

«Блестяще! Вот почему мы обязаны применять эшелонированный контроль, где клиент дает мгновенный UX-отклик, а серверная СУБД жестко блокирует строки через SELECT FOR UPDATE или ограничения EXCLUDE. Переходим к изложению теории».

«Обратите внимание на Слайд 3. Перед нами классическая двухуровневая модель. Запомните формулу: Frontend — это забота о пользователе (User Experience), а СУБД — это выживание и целостность базы данных (Data Integrity).

На клиенте мы стремимся дать реакцию за 0 миллисекунд. Как только пользователь вводит ИНН или телефон, скрипт на лету проверяет его регулярным выражением. Посмотрите на Слайд 4. Главное правило регулярных выражений: обязательное наличие граничных якорей — символа домика ^ (начало строки) и символа доллара $ (конец строки).

Если вы напишете просто /\d{10}/, валидатор сочтет корректной строку "грязь1234567890мусор", потому что внутри нее нашлись десять цифр! И только шаблон /^\d{10}$/ гарантирует, что вся строка состоит строго из десяти цифр.

Далее взгляните на Слайд 5. Для корпоративных систем мало проверить количество цифр. Например, 10-й знак ИНН юридического лица — это контрольный разряд, вычисляемый по сумме произведений первых 9 цифр на весовые коэффициенты. Если пользователь случайно перепутает две соседние цифры местами, контрольная сумма сразу выявит ошибку на клиенте еще до отправки запроса в сеть!

А теперь перейдем к вопросу безопасности — Слайды 6 и 7. Почему возникают SQL-инъекции? Потому что неграмотные программисты собирают запрос склеиванием строк. Если в поле логина передать кавычку с комментарием admin' --, то весь парольный фильтр запроса просто превратится в комментарий. Решение здесь только одно — Prepared Statements (параметризованные запросы).

При параметризации СУБД сначала компилирует структуру команды в абстрактное синтаксическое дерево (AST) с плейсхолдерами $1, $2, а затем принимает значения отдельно по бинарному протоколу. Что бы пользователь ни написал в параметре — хоть 10 кавычек и DROP TABLE — СУБД воспримет эти символы строго как литеральные текстовые данные. Структура запроса не может измениться физически!

Наконец, посмотрите на Слайды 11 и 12. Что происходит, если база данных всё-таки отвергла операцию? Например, клиент попытался зарегистрировать организацию с ИНН, который уже есть в базе. В СУБД сработает уникальное ограничение и ядро выбросит исключение с кодом SQLSTATE 23505 (unique_violation).

Что делает плохой разработчик? Выводит на экран пользователю сырую техническую ошибку: ERROR: duplicate key value violates unique constraint "clients_inn_key". Это двойной провал! Во-первых, рядовой бухгалтер не понимает, что такое "constraint" и "unique". Во-вторых, мы раскрыли потенциальному хакеру внутреннее имя таблицы и структуру индексов базы данных!

Профессиональный бэкенд применяет паттерн Error Mapping: драйвер перехватывает код 23505 и возвращает на форму понятную и вежливую фразу: "Клиент с данным ИНН уже зарегистрирован в системе. Проверьте правильность ввода или воспользуйтесь поиском"».

«Коллеги, открываем интерактивный рабочий лист zanyatie.html. В верхней панели обязательно введите свои реальные фамилию, имя и номер группы.

У нас подготовлены 4 дифференцированных сценария: 1. Вариант 1 (Корпоративный клиент): проверка формата и контрольной суммы ИНН (10 цифр), проверка формата ОГРН (13 цифр) и маппинг системной ошибки 23505 unique_violation в дружественное сообщение.
2. Вариант 2 (Банковский перевод): валидация номера счета (20 цифр) и БИК (9 цифр), клиентская блокировка отправки при сумме <= 0, перехват серверной ошибки недостатка средств и сбоя сериализации транзакции 40001.
3. Вариант 3 (Онлайн-заказ): валидация email и маски телефона +7, перехват исключения триггера P0001 out of stock при одновременной покупке товара несколькими покупателями.
4. Вариант 4 (Бронирование отеля): клиентский контроль Дата_выезда > Дата_заезда, перехват серверной ошибки ограничения 23P01 exclusion_violation при пересечении броней.

Все ваши ответы автоматически сохраняются в памяти браузера через LocalStorage. Приступайте к выполнению!»

«Внимание на экран — Слайд 15! Перед вами самый знаменитый мем в истории баз данных: комикс xkcd про "Маленького Бобби Таблицы" — Little Bobby Tables.

Мама назвала сына именем Robert'); DROP TABLE Students; --. В результате нерадивая школьная программа, собравшая SQL-запрос обычной склейкой строк, удалила всю таблицу учащихся за текущий учебный год!

Теперь вы дипломированные специалисты в вопросах контроля ввода и знаете: если бы разработчики школы использовали Prepared Statements и регулярные выражения для проверки допустимых символов в имени, база данных школы осталась бы в абсолютной безопасности.

В рабочих листах нажимаем кнопку "Сохранить ответы", при необходимости экспортируем страницу в PDF. Оценки за занятие будут выставлены по 4-балльной критериальной шкале нашей рубрики. Для тех, кому потребуется дистанционное закрепление, подготовлен файл domashnee_zadanie.html. Спасибо за отличную инженерную работу!»