Безопасность веб-приложений

Все темы Python Developer

Как безопасно хранить пароли?

Пароль хранят как результат медленной password-hashing функции, например Argon2id, scrypt или bcrypt, с уникальной случайной salt и параметрами стоимости. При входе библиотека повторяет вычисление и сравнивает результат; исходный пароль восстановить нельзя. Параметры со временем повышают и rehash выполняют после успешной проверки. Обратимое шифрование и быстрые SHA-хеши не подходят; pepper можно хранить отдельно как дополнительную защиту. Защиту проверяют на границе доверия и отказе, не полагаясь на секретность формата или добросовестность клиента.

Какие меры нужны HTTP API помимо HTTPS?

HTTPS защищает канал, но API еще нужны аутентификация и проверка права на конкретный объект, строгая валидация, лимиты размера и частоты, таймауты и безопасные CORS-настройки. Ошибки не должны раскрывать внутренности, а логи содержать токены и пароли. Для cookie-аутентификации учитывают CSRF, для bearer-токенов защищают их хранение. Зависимости обновляют, а чувствительные операции журналируют. Защиту проверяют на границе доверия и отказе, не полагаясь на секретность формата или добросовестность клиента.

Чем серверная сессия отличается от cookie?

Cookie является данными, которые браузер хранит и отправляет серверу. При серверной сессии cookie обычно содержит только непредсказуемый идентификатор, а состояние и возможность отзыва находятся на сервере. После входа ID ротируют, задают Secure, HttpOnly, подходящий SameSite и срок жизни, чтобы снизить риск session fixation и кражи. Подписанный cookie может хранить состояние на клиенте, но подпись не скрывает содержимое. Защиту проверяют на границе доверия и отказе, не полагаясь на секретность формата или добросовестность клиента.

Как устроен multipart/form-data для загрузки файла?

multipart/form-data делит тело boundary-маркерами на именованные части. У файловой части есть Content-Disposition с именем поля и filename, иногда Content-Type, затем идут байты. Сервер должен потоково ограничивать общий размер и число частей, не доверять filename и заявленному MIME, проверять содержимое и сохранять под собственным именем вне исполняемого каталога. Boundary берут из заголовка, а не угадывают. Защиту проверяют на границе доверия и отказе, не полагаясь на секретность формата или добросовестность клиента.

Почему десериализацию внешних данных нужно отделять от валидации?

Десериализация отвечает за синтаксис и преобразование формата в базовые значения. Валидация отдельно проверяет схему, типы, диапазоны и бизнес-правила. Такое разделение позволяет отличить битый JSON от корректного, но недопустимого заказа, и не наделяет parser лишним доверием. Небезопасные форматы, способные создавать произвольные объекты, например недоверенный pickle, нельзя использовать даже с последующей валидацией. Защиту проверяют на границе доверия и отказе, не полагаясь на секретность формата или добросовестность клиента.

Как устроен OAuth 2.0 authorization code flow?

Клиент отправляет пользователя на authorization endpoint с redirect_uri, state и PKCE challenge. После согласия authorization server возвращает короткоживущий code; клиент меняет его на токены по защищенному каналу, предъявляя verifier. state связывает ответ с запросом и защищает от подмены потока, PKCE от перехвата code. OAuth 2.0 делегирует авторизацию; идентификацию пользователя поверх него обычно задает OpenID Connect. Защиту проверяют на границе доверия и отказе, не полагаясь на секретность формата или добросовестность клиента.

Как устроена аутентификация Django?

Django аутентифицирует credentials через настроенные authentication backends и связывает результат с User model. После login идентификатор пользователя хранится в серверной сессии, а AuthenticationMiddleware выставляет request.user. Permissions проверяют право выполнить действие, но объектные права зависят от backend или приложения. При cookie-сессии изменяющие запросы защищает CSRF-механизм; он решает другую задачу, чем вход пользователя. Защиту проверяют на границе доверия и отказе, не полагаясь на секретность формата или добросовестность клиента.

Когда выбрать серверную сессию вместо JWT?

Серверная сессия удобна, когда нужен немедленный отзыв, централизованный контроль устройств и небольшое состояние входа. Cookie хранит opaque ID, а серверное хранилище требует доступности, очистки и масштабирования. JWT удобен для автономной проверки между сервисами, но отзыв и обновление прав сложнее до истечения срока. Подписанный JWT не зашифрован по умолчанию, поэтому секреты в payload не кладут. Защиту проверяют на границе доверия и отказе, не полагаясь на секретность формата или добросовестность клиента.