Кризис с регистром, о котором все молчат

Вы разрабатываете веб-приложение. На локальной машине всё летает. Staging-сервер работает без сбоев. А в production — хаос. Или security-исследователи находят дыры, о которых вы не подозревали.

Часто проблема не в коде или проверках. Виновник — неправильная обработка регистра символов.

Почему регистр может всё сломать

Все знают: domain'ы нечувствительны к регистру. example.com, Example.Com или EXAMPLE.COM — один и тот же адрес. Логично.

А вот с этим сложнее:

• Email в системе авторизации?
• ID пользователей в базе?
• Пути к файлам в облаке?
• Эндпоинты API?
• Проверки SSL-сертификатов?

Если разные части системы по-разному приводят строки к единому виду, вы открываете дверь хакерам.

Реальный сценарий атаки

Допустим, emails в вашей базе хранятся в lowercase. Стандартно. Но OAuth-провайдер присылает John.Smith@gmail.com с заглавными. А вы сравниваете строки без нормализации.

Хакер регистрируется на john.smith@gmail.com. Заходит в аккаунт. Потом пробует John.Smith@gmail.com. Из-за разницы в регистре:

• Обходит лимиты запросов (система видит разных юзеров).
• Создаёт дубли аккаунтов с повышенными правами.
• Маскируется в логах.
• Получает доступ к чужим ресурсам.

Ситуация хуже с:

IDN (Internationalized Domain Names). Unicode-нормализация зависит от языка. В турецком 'i' без точки ломает простые правила. Некоторые символы не имеют uppercase-версии.

Облачные хранилища. В AWS S3 ключи объектов чувствительны к регистру, а bucket'ы — нет. Ошибка ведёт к утечке данных или эскалации прав.

DNS-записи. Запросы case-insensitive, но ваша валидация может нет. Wildcard-сертификаты и CNAME — новые уязвимости.

Как защитить инфраструктуру

1. Введи единые правила нормализации

Определи стандарты на уровне приложения. Обрабатывай входные данные сразу.

# Правильно: нормализация на границе
def normalize_email(email):
    return email.lower().strip()

def authenticate_user(email):
    normalized = normalize_email(email)
    user = User.query.filter_by(email=normalized).first()
    return user

2. Бери Unicode-библиотеки

Для интернационального контента не пиши сам. Используй готовое:

• Python: unicodedata
• JavaScript: String.localeCompare()
• Go: strings с Unicode-поддержкой

3. Тестируй на всех системах

Приложение не в вакууме. Проверяй обработку регистра:

• API DNS-провайдера.
• Валидацию SSL-издателя.
• OAuth-сервисы.
• Облачное хранилище.
• Правила CDN.

Запиши поведение каждой системы. Обеспечь единообразие.

4. Жёстко валидируй вход

Не верь внешним сервисам. Нормализуй на каждом стыке.

// Перед звонком внешнего API
const normalizeForAPI = (input, format = 'lowercase') => {
  const normalized = format === 'lowercase' 
    ? String(input).toLowerCase() 
    : String(input);
  return normalized.trim();
};

5. Логируй проблемы с регистром

Ставь алерты на подозрительные вариации:

def detect_case_variance(email):
    normalized = email.lower()
    if email != normalized:
        logger.warning(f"Разный регистр: {email} vs {normalized}")
        # Проверяй на атаку

6. Применяй практики NameOcean

При работе с domain'ами и DNS в NameOcean:

• Пиши domain'ы в коде только lowercase.
• Храни DNS-записи с единым регистром.
• Доверяй case-insensitive фичам API.
• Опиши стратегию в infrastructure-as-code.

Главный вывод

Безопасность — не только пароли и HTTPS. Это понимание, как вся экосистема работает с данными. Маленькая ошибка в регистре пройдёт через авторизацию, хранилище и API.

Разрабы, которые ловят такие баги заранее:

1. Не верят предположениям — проверяют нормализацию везде.
2. Тестируют края — вариации регистра в security-тестах.
3. Фиксируют поведение — описывают, как системы обрабатывают регистр.
4. Нормализуют везде — один стандарт на всю систему.

Ваши будущие аудиторы (или хакеры) оценят.