Организация интерфейса с пользователем: контроль

1. Проблема доверия: почему нельзя верить интерфейсу?

2. Двухуровневая модель эшелонированного контроля

3. Регулярные выражения: правила составления масок

Ключевое правило безопасности регулярных выражений — строгое ограничение начала и конца строки:

// КАТАСТРОФА: без якорей /^...$/
const weakPattern = /\d{10}/;
weakPattern.test("мусор 1234567890 грязь"); // Вернет TRUE!

// ЭТАЛОН: строгие границы начала (^) и конца ($)
const strictPattern = /^\d{10}$/;
strictPattern.test("1234567890");          // TRUE (строго 10 цифр)
strictPattern.test("мусор 1234567890");    // FALSE (отклонено)

4. Клиентская валидация контрольных сумм (ИНН-10)

function checkInn10(inn) {
  if (!/^\d{10}$/.test(inn)) return false;
  const w = [2, 4, 10, 3, 5, 9, 4, 6, 8];
  let sum = 0;
  for (let i = 0; i < 9; i++) {
    sum += parseInt(inn[i]) * w[i];
  }
  return (sum % 11) % 10 === parseInt(inn[9]);
}

5. Анатомия катастрофы: инъекция SQL-кода

Что происходит, когда программист соединяет строки запроса через конкатенацию:

// Опасный код бэкенда:
String sql = "SELECT * FROM users WHERE login = '" + req.get("login") + "' AND pass = '" + pass + "'";

// Если злоумышленник введет в поле логина:  admin' --
// Запрос превращается в:
SELECT * FROM users WHERE login = 'admin' --' AND pass = '...'
// Символы -- превращают весь остаток запроса в комментарий! Вход без пароля выполнен!

6. Абсолютная защита: Prepared Statements

-- Протокол PostgreSQL Prepared Statements:
PREPARE auth_stmt (text, text) AS
  SELECT id, full_name FROM users WHERE login = $1 AND pass_hash = $2;

EXECUTE auth_stmt('admin' OR 1=1 --', 'hash123'); -- Ищет буквального юзера с таким именем!

7. Серверный контроль: ограничения CHECK и NOT NULL

Ограничения в СУБД действуют как последняя линия обороны, которую невозможно обойти:

CREATE TABLE bank_accounts (
  account_id BIGSERIAL PRIMARY KEY,
  account_number CHAR(20) NOT NULL,
  bik CHAR(9) NOT NULL,
  current_balance NUMERIC(15,2) NOT NULL DEFAULT 0.00,
  is_active BOOLEAN NOT NULL DEFAULT TRUE,
  -- Серверные предикаты целостности:
  CONSTRAINT chk_account_format CHECK (account_number ~ '^\d{20}$'),
  CONSTRAINT chk_bik_format CHECK (bik ~ '^04\d{7}$'),
  CONSTRAINT chk_non_negative_balance CHECK (current_balance >= 0.00)
);

8. Триггеры бизнес-логики: проверка остатков перед записью

Когда условия зависят от данных других таблиц, декларативного CHECK недостаточно:

CREATE OR REPLACE FUNCTION trg_verify_stock() RETURNS TRIGGER AS $$
BEGIN
  -- Блокируем складской остаток от конкурентных изменений
  IF (SELECT stock_qty FROM products WHERE id = NEW.product_id FOR UPDATE) < NEW.quantity THEN
    RAISE EXCEPTION 'Товар отсутствует на складе в требуемом количестве!'
      USING ERRCODE = 'check_violation';
  END IF;
  RETURN NEW;
END;
$$ LANGUAGE plpgsql;

CREATE TRIGGER check_stock_before_order
BEFORE INSERT ON order_items
FOR EACH ROW EXECUTE FUNCTION trg_verify_stock();

9. Аномалия Race Condition и блокировки транзакций

10. Стандартизация ошибок: коды SQLSTATE

Международный стандарт ISO/IEC 9075 кодирует все ошибки СУБД пятизначными шифрами:

11. Архитектурный паттерн Error Mapping

Трансляция технического исключения СУБД в безопасное экранное уведомление:

ERROR: duplicate key value violates 
unique constraint "clients_inn_key"
DETAIL: Key (inn)=(7701234567) already exists.

switch (err.code) {
  case '23505':
    return "Организация с данным ИНН уже зарегистрирована в системе.";
  case '23P01':
    return "Выбранный номер уже занят на эти даты.";
}

12. Дифференцированные сценарии практикума

13. Инженерный манифест надежного интерфейса

14. Классика веб-безопасности: Little Bobby Tables

Тематический интернет-мем: «Exploits of a Mom» (культовый веб-комикс про «Little Bobby Tables», xkcd №327).
Автор: Randall Munroe. Первоисточник: xkcd.com/327. Лицензия: Creative Commons Attribution-NonCommercial 2.5 Generic (CC BY-NC 2.5).
Связь с темой занятия: Мама назвала сына Robert'); DROP TABLE Students; --. Когда школа вставила имя ученика через конкатенацию SQL-строки, база данных стерла всех студентов года. Занятие 24 учит будущих разработчиков: использование параметризованных запросов (Prepared Statements) и строгий контроль входных данных в интерфейсе навсегда исключают подобные инциденты!