Почему безопасность важна в веб-разработке

Худший инцидент безопасности, который мне пришлось помогать разгребать, был не хитрым эксплойтом. Это был пароль базы данных в закоммиченном .env-файле в репозитории, который кто-то считал приватным. Никакого zero-day, никакого умелого атакующего — просто учётные данные, которых никогда не должно было быть в git, найдены и использованы. Так выглядит большинство реальных взломов: не киношный хакинг, а скучный, предотвратимый пробел, за который никто не отвечал.

«Безопасность важна» — это не совет. Вот версия, которую я бы реально дал PHP-, Laravel- или WordPress-разработчику: короткая модель угроз и конкретные пробелы, через которые компрометируют сайты, примерно в том порядке, в каком они и случаются.

Думайте в терминах поверхности и радиуса поражения

Идеальная безопасность — не цель, потому что её не существует. Два вопроса дают вам бóльшую часть пользы. Первый: какова эксплуатируемая поверхность — каждое место, где недоверенный ввод достигает вашего кода, каждые учётные данные, каждая зависимость, которую вы не писали? Второй: когда одно из этого падает, как далеко расходится ущерб? Утёкший read-only API-ключ — плохой день; утёкший root-пароль базы — катастрофа. Большинство хороших решений по безопасности приходят из сжатия первого и сдерживания второго, а не из погони за идеальной оценкой.

Сломанный контроль доступа: тихий номер один

Самый частый серьёзный изъян — он же наименее драматичный: код, который проверяет, залогинены ли вы, но не то, к чему вам разрешено прикасаться. Классическая форма — эндпоинт, доверяющий ID из запроса:

// Anyone logged in can read anyone's invoice
public function show($id)
{
    return Invoice::findOrFail($id);
}

Поменяйте ID в URL — и вы читаете чужие данные. Спрятать ссылку в UI не меняет ничего, потому что атакующий зовёт эндпоинт напрямую. Авторизация должна происходить на сервере, для каждого действия, относительно текущего пользователя:

public function show(Invoice $invoice)
{
    $this->authorize('view', $invoice); // policy checks ownership
    return $invoice;
}

Инъекции: фреймворки защищают, пока вы не откажетесь

SQL-инъекции и межсайтовый скриптинг стары, и современные фреймворки блокируют их по умолчанию — именно поэтому оставшиеся случаи приходят из кода, сходящего с безопасного пути. Eloquent и биндинги параметризуют SQL за вас; уязвимость появляется, когда кто-то конкатенирует ввод в сырой запрос:

// Vulnerable: input concatenated into SQL
DB::select("SELECT * FROM users WHERE email = '$email'");

// Safe: parameter binding
DB::select('SELECT * FROM users WHERE email = ?', [$email]);

XSS — та же история на выводе. {{ }} в Blade экранирует автоматически; опасность — {!! !!}, который печатает сырой HTML. В WordPress это вывод пользовательских данных без esc_html() или esc_attr(). Правило, предотвращающее бóльшую часть: никогда не доверяйте вводу на входе, всегда экранируйте на выходе и относитесь к каждому {!! !!} или неэкранированному echo как к месту, требующему обоснования.

Секреты и зависимости: скучные взломы

Два пробела, стоящие за большой долей реальных компрометаций, не имеют ничего общего с логикой приложения. Первый — утёкшие секреты: учётные данные в закоммиченном .env, API-ключ, вставленный в репозиторий или чат. Держите секреты вне контроля версий, а если один утёк — ротируйте немедленно и считайте его полностью скомпрометированным; приватный репозиторий — небезопасное место для живых учётных данных. Я писал ровно про этот сценарий отказа в статье про случайно запушенные секреты в git.

Второй — устаревшие зависимости, а для WordPress в частности плагины — крупнейший единичный вектор взлома. Известная уязвимость в непропатченном плагине — это опубликованный, скриптуемый эксплойт. Относитесь к обновлениям как к работе по безопасности, а не рутине: запускайте composer audit, держите плагины актуальными и удаляйте те, что не используете. На Bedrock-подобной установке блокировка изменений файлов из браузера в продакшене (DISALLOW_FILE_MODS) держит набор плагинов под контролем версий, где его можно аудировать.

Не доверяйте никакому payload извне

Любой запрос от внешней системы недоверен, пока не доказано обратное, включая вебхуки. Платёжный или интеграционный вебхук, на который вы реагируете без проверки подписи, — это открытый эндпоинт, куда кто угодно может слать поддельные события. Проверяйте подпись до того, как что-либо делать с телом — ту же мысль я провожу про Stripe в гайде по Laravel Cashier. Это становится драматически проще, когда внешние интеграции живут за одной границей, которую можно аудировать, а не разбросаны по контроллерам — структурный аргумент в статье про внедрение и инверсию зависимостей.

Заголовки и транспорт: реально, но эшелонированная защита

HTTPS везде, HSTS и content security policy стоит иметь — это значимый слой, и CSP в частности ограничивает ущерб от XSS, который проскользнул. Но это эшелонированная защита, а не главное событие. Строгий CSP не спасёт эндпоинт со сломанным контролем доступа. Поставьте заголовки, а потом тратьте внимание на авторизацию, инъекции, секреты и зависимости — там, где взломы и происходят.

Ошибки, ведущие к реальным взломам

Безопасность — это ещё и процесс

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

FAQ

Какая самая частая уязвимость веб-приложений?

Сломанный контроль доступа — эндпоинты, которые подтверждают, что пользователь аутентифицирован, но не то, что ему авторизовано действовать с конкретным ресурсом. Смена ID в запросе для чтения чужих данных — классический случай. Авторизацию надо обеспечивать на стороне сервера на каждом действии.

Делает ли использование Laravel или WordPress сайт безопасным по умолчанию?

Они предотвращают многое — Eloquent параметризует SQL, Blade экранирует вывод — но только пока вы на безопасном пути. Сырые запросы с интерполированным вводом, неэкранированный {!! !!}, утёкшие секреты и устаревшие плагины обходят эти защиты. Фреймворк снижает риск; он не снимает вашу ответственность.

Что делать, если я случайно закоммитил секрет в git?

Считайте его полностью скомпрометированным и ротируйте немедленно — смените пароль или отзовите ключ, даже если репозиторий приватный. Удаление файла в более позднем коммите не помогает, потому что значение остаётся в истории git и могло быть уже скопировано.

Достаточно ли заголовков безопасности вроде CSP, чтобы защитить сайт?

Нет. Заголовки вроде HSTS и content security policy — ценная эшелонированная защита и ограничивают ущерб от некоторых атак, но они не чинят сломанный контроль доступа, инъекции или утёкшие учётные данные. Используйте их в дополнение к серверной авторизации и безопасной обработке ввода, а не вместо них.

Похожие статьи

• Случайно запушили секреты в git — разбирает сценарий утечки учётных данных и как из него восстановиться.
• Laravel Cashier и Stripe — про проверку подписей вебхуков, чтобы внешние payload нельзя было подделать.