проектирование
4 статей с этим тегом
4 частые ошибки в безопасности: настройки по умолчанию, забытые сервисы, отсутствие мониторинга и излишнее доверие к проверке ввода
Инциденты возникают из небольшого набора повторяющихся схем, и их проще увидеть, если сортировать не по технологиям, а по убеждениям. Их четыре: настройки по умолчанию безопасны (ничего не настроили), неиспользуемое безвредно (ничего не закрыли), мы бы заметили (ничего не видно) и проверенный ввод безопасен (вводу доверили слишком многое). Чтобы это исправить, не нужны глубокие технические знания — нужна привычка проверять. Ниже — на что смотреть в каждом случае.
Небезопасная десериализация: чем опасно, когда внешние данные выбирают тип объекта, и как это предотвратить
Опасность десериализации не в том, что приходят плохие значения, а в том, что некоторые форматы позволяют внешним данным решать, объект какого типа создать. Поэтому ущерб не ограничивается испорченными данными: OWASP называет отказ в обслуживании, обход контроля доступа и удалённое выполнение кода. Две защиты: перейти на чистый формат данных, где ничто не выбирает типы за вас, и подписывать сериализованные сообщения, чтобы неподписанные никогда не восстанавливались. А некоторые механизмы вообще нельзя сделать безопасными настройкой — единственное решение не использовать их.
Ошибки в сбросе пароля: 5 способов захватить аккаунт при надёжном входе и как их исправить
Сброс пароля позволяет человеку, который не знает пароль, задать новый, — значит, это самостоятельный путь аутентификации. Сколько ни усиливайте вход, если сброс слабый, реальная сила аутентификации равна силе сброса. Пять типичных ошибок: угадываемые токены, токены без срока действия, ссылки, которые остаются в почтовом ящике, ссылки, адрес которых можно задать извне (заголовок Host), и ответы, раскрывающие, существует ли аккаунт. Главное при реализации — отделить то, что руководство требует, от чисел, которые оно оставляет вам.
Ограничение частоты запросов и защита от злоупотреблений: лимиты против перебора паролей и неконтролируемых расходов
Ограничение частоты обычно не срабатывает не потому, что лимит слишком мягкий, а потому, что задан не тот вопрос. Три вопроса: кого считать (IP можно подделать, и его делят настоящие пользователи, поэтому главное — идентичность), что считать (одно число запросов пропускает дорогие одиночные операции — стоимость, размер, число записей) и что происходит у предела (грубая блокировка — это отказ в обслуживании для законных пользователей). NIST ограничивает неудачные попытки подряд сотней и просит задержки и CAPTCHA вместо блокировки; OWASP включает лимиты расходов у сторонних сервисов — последний рубеж против финансового ущерба.