Основы безопасности для новичка

Зачем это новичку

Не для того, чтобы стать специалистом по безопасности. Для того, чтобы не написать дыру по незнанию — и чтобы ответить на вопрос собеседования, который задают почти всегда.

Пять типов проблем ниже покрывают подавляющее большинство того, что встречается в учебных и небольших боевых проектах.

1. Подстановка в запрос к базе

Самая известная. Возникает, когда данные от пользователя вклеиваются в текст запроса:

query = "SELECT * FROM users WHERE name = '" + name + "'"

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

Как не надо: склеивать строки, «экранировать самому», проверять на плохие слова.

Как надо: параметризованные запросы, где данные передаются отдельно от текста запроса:

cursor.execute("SELECT * FROM users WHERE name = %s", (name,))

Все нормальные библиотеки работы с базой это поддерживают. Если вы пользуетесь механизмом отображения объектов на таблицы, он делает это за вас.

2. Выполнение чужого кода в браузере

Возникает, когда текст, введённый одним пользователем, показывается другому без обработки. Внутри текста может быть код, который выполнится в браузере жертвы.

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

Если вставить разметку правда нужно (например, разрешаете форматирование), пропускайте её через проверенный очиститель.

3. Отсутствие проверки прав

Самая частая в реальных проектах и самая недооценённая.

Классика: адрес вида «/orders/42» показывает заказ, и никто не проверяет, ваш ли он. Меняете номер и смотрите чужие заказы.

Как надо: проверять права на каждом обращении к данным, а не только прятать кнопки в интерфейсе. Скрытая кнопка не защищает: обратиться к адресу можно напрямую.

Правило: если пользователь может подставить идентификатор, проверьте, что этот объект его.

4. Слабое хранение паролей

Пароли в открытом виде или зашифрованные обратимо. Разбирается в отдельной статье, но коротко: только специальные функции хеширования паролей, только готовая библиотека.

5. Секреты в коде

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

Ещё несколько вещей на минимум

Ограничение частоты обращений. Форма входа без ограничений — приглашение перебирать пароли. Простое ограничение по количеству попыток закрывает большую часть проблемы.

Защита форм от подделки запроса. Механизм, не дающий чужому сайту отправить запрос от имени вашего пользователя. Фреймворки дают это из коробки — не отключайте.

Обновление зависимостей. Значительная часть уязвимостей приходит из старых версий библиотек. Проверяйте хотя бы иногда.

Не показывайте подробности ошибок пользователю. Цепочка вызовов и пути на сервере — подарок тому, кто ищет уязвимости. Подробности в журнал, пользователю — общее сообщение.

Что отвечать на собеседовании

Вопрос про безопасность новичку задают в мягкой форме: «какие уязвимости знаете». Достаточно назвать три-четыре из списка выше и объяснить, как от них защищаются.

Гораздо лучше звучит, если вы можете добавить: «в своём проекте использовал параметризованные запросы и проверку прав на каждом обращении, ключи вынесены в переменные окружения». Это уже не теория, а практика.