С нуля: что такое веб-безопасность на самом деле
Веб-безопасность — это проектирование так, чтобы враждебный незнакомец мог отправить что угодно, а система устояла. Это карта «с нуля» и восемь слов, которые остальной трек считает уже знакомыми.
Кто-то в интернете уже прямо сейчас отправляет запросы к твоему приложению. Не только пользователи — краулеры, сканеры, боты и иногда люди, которые намеренно пытаются что-то сломать. Они будут слать строки, похожие на SQL. Они будут представляться администратором. Они будут отправлять форму тысячу раз в секунду. Они вставят JavaScript прямо в поле для имени пользователя. Остановить попытки невозможно. Можно сделать другое — спроектировать систему так, чтобы всё это не имело значения: чтобы плохой ввод никуда не попадал, украденные токены ничего не открывали, а утечка данных не давала ничего читаемого. Этот урок — карта перед восхождением.
Единственная идея, на которой строится безопасность
В интернете ты не можешь контролировать, кто к тебе подключается. Запрос может прийти от реального пользователя, сломанного клиента, автоматического сканера или злоумышленника. Основное допущение веб-безопасности: считай любой ввод потенциально враждебным, пока не проверишь обратное. Это звучит параноидально. Это также единственный дизайн-принцип, который работает на масштабе. Каждая уязвимость, которую ты изучишь в этом треке — от SQL-инъекции до угона сессии — существует потому, что что-то доверяло вводу, которому не должно было доверять.
Всё остальное — механика реализации этой одной идеи: проектируй так, чтобы компрометация одного звена не компрометировала всё.
Восемь слов, которые остальной трек считает знакомыми
Когда ты видишь в новостях «утечка паролей», «украденный токен» или «обход авторизации» — за этим всегда стоит одно из этих восьми слов. Senior-уроки дальше используют эти термины, не останавливаясь на определениях. Вот они, по одному предложению — что это и зачем оно.
| Слово | Что это | Зачем оно |
|---|---|---|
| Аутентификация | Доказательство того, кто ты есть — подтверждение, что пользователь тот, за кого себя выдаёт. | Чтобы система знала, кто именно отправляет запрос, прежде чем что-либо делать от его имени. |
| Авторизация | Решение о том, что тебе можно делать — проверка, что установленный пользователь вправе совершить это действие. | Чтобы знание того, кто ты есть, не открывало автоматически доступ ко всему. |
| Угроза / Злоумышленник | Любой актор (человек, бот или программа), пытающийся заставить систему вести себя не так, как задумано. | Явно называется, чтобы при проектировании безопасности можно было рассуждать о мотиве, возможностях и вероятных векторах атаки. |
| Валидация ввода | Проверка того, что данные снаружи системы соответствуют ожидаемой форме и диапазону, прежде чем их использовать. | Чтобы некорректные или вредоносные данные отвергались на границе, а не передавались глубже, где могут навредить. |
| Секрет | Пароль, API-ключ или криптографический ключ, который нужен системе, но она никогда не должна его раскрывать. | Чтобы учётные данные не попадали в исходный код, логи или сообщения об ошибках, где их мог бы найти злоумышленник. |
| Шифрование в транзите / в покое | Преобразование данных с помощью ключа так, чтобы только владелец соответствующего ключа мог их прочитать — при передаче (TLS — Transport Layer Security, протокол защиты канала) или при хранении (шифрование базы / диска). | Чтобы перехваченный трафик или украденный диск не давали ничего полезного без ключа. |
| Сессия / Токен | Краткосрочные учётные данные, выданные после аутентификации, которые клиент отправляет с каждым запросом, чтобы сервер мог его повторно идентифицировать без запроса пароля. | Чтобы отсутствие состояния в HTTP не заставляло пользователей входить при каждом клике. |
| Граница доверия | Линия между двумя частями системы, где уровень доверия меняется — например, между публичным интернетом и твоим сервером или между пользовательским вводом и запросом к базе. | Чтобы проверки безопасности проводились на каждой границе, а не подразумевались где-то выше по цепочке. |
Как они складываются вместе
Прочитанные по порядку, слова рассказывают одну историю: сначала ты аутентифицируешь пользователя, чтобы узнать, кто он, затем авторизуешь его, чтобы понять, что ему разрешено. Любой ввод, пересекающий границу доверия, не считается безопасным до тех пор, пока не прошёл валидацию. Секреты хранятся в недоступном месте, чтобы утечка кода или логов не давала злоумышленнику ничего полезного. Данные шифруются в транзите, поэтому перехват сети бесполезен, и шифруются в покое, поэтому украденный диск нечитаем. Сессия или токен несут идентичность между состояниями без повторной аутентификации при каждом запросе и истекают, ограничивая окно вреда от кражи.
▸Почему это работает
Стоит сразу назвать два распространённых заблуждения. Первое: хеширование — это не шифрование. Хеширование (используется для паролей) — одностороннее преобразование: оригинал не восстанавливается даже с ключом. Шифрование двустороннее: данные расшифровывает тот, у кого есть ключ. Они решают разные задачи. Второе: валидация ввода необходима, но недостаточна. Она останавливает многое, но злоумышленник, получивший прямой доступ к уровню приложения или базы, её обходит. Глубокая защита — несколько перекрывающихся слоёв контроля — именно поэтому трек состоит из многих юнитов, а не одного.
В чём разница между аутентификацией и авторизацией?
Расставь проверки безопасности, которые выполняет сервер, получив запрос пользователя «удалить мой аккаунт»:
- 1 Проверить токен сессии, чтобы подтвердить, кто отправил запрос (аутентификация)
- 2 Убедиться, что этот пользователь вправе удалить аккаунт — именно свой (авторизация)
- 3 Валидировать и санировать все входные данные, пересекающие границу доверия
- 4 Выполнить действие, не раскрывая секреты и зашифрованные данные в ответах об ошибках
- 01Каково единственное основное допущение веб-безопасности и почему?
- 02Назови восемь основных слов, объяснив, что каждое из них и зачем оно.
Веб-безопасность — одна идея с кучей навешанных слоёв: проектируй так, чтобы враждебный незнакомец мог отправить что угодно, а система устояла. Половина идентичности — это аутентификация (кто ты) и следующая за ней авторизация (что тебе можно): знание того, кто ты есть, не открывает доступ ко всему. Половина ввода — валидация на каждой границе доверия, потому что каждый класс атак с инъекцией возникает там, где что-то доверяло данным, которым не должно было. Половина данных — хранить секреты вне кода и логов, шифровать данные в транзите через TLS, чтобы перехват был бесполезен, и шифровать в покое, чтобы украденный диск ничего не открывал. Сессии и токены несут идентичность между состояниями без сохранения HTTP, и они истекают, ограничивая окно вреда от кражи. Ни один из этих слоёв не достаточен сам по себе — глубокая защита именно поэтому трек состоит из многих юнитов. Теперь, когда встретишь в коде «доверяем этому параметру» или увидишь токен без срока жизни, ты знаешь точно, какое из восьми слов нарушается — и где искать исправление. Дальше: Unit 01, OWASP Top 10 (список десяти наиболее критичных уязвимостей веб-приложений) и самые распространённые способы, которыми эти правила нарушаются на практике.
Что-то непонятно?
Задай вопрос по этому уроку. Вопросы анонимны и попадают напрямую автору — урок станет лучше.