Три кита веб-уязвимостей
Каждое веб-приложение — это сложный механизм, и в нём есть слабые места. Ошибки в коде, невнимательность разработчиков и устаревшие практики открывают дверь для атак. Если вы строите или поддерживаете сайт, три типа уязвимостей стоит знать особенно хорошо. Они встречаются чаще всего, и последствия могут быть фатальными: от утечки данных до полного захвата управления.
SQL-инъекции: дверь в базу данных
SQL-инъекция — это когда злоумышленник вставляет вредоносный SQL-код в поле ввода (например, в форму логина или поиска). Если приложение напрямую подставляет пользовательский ввод в запрос, база данных может выполнить команды, которые ей не предназначены. Представьте: вместо имени пользователя атакующий пишет ' OR '1'='1 — и вот он уже получает доступ ко всем учётным записям. Последствия — кража паролей, личных данных, удаление таблиц.
Защита проста: никогда не доверяйте пользовательскому вводу. Используйте параметризованные запросы (prepared statements) — современные ORM и библиотеки делают это за вас. Валидация и экранирование — тоже полезны, но главное — разделение кода и данных.
XSS (межсайтовый скриптинг): атака через браузер
XSS позволяет внедрить скрипты в страницу, которую просматривает другой пользователь. Это может быть комментарий, имя профиля или даже URL. Если приложение не фильтрует вывод, браузер выполнит JavaScript атакующего. Через такой скрипт можно украсть куки, перенаправить на фишинговый сайт, записать нажатия клавиш.
Различают отражённый XSS (вредоносный код передаётся в URL), сохранённый (записывается в базу и показывается всем) и DOM-based (манипуляция через клиентские скрипты). Защита — экранирование вывода (контекстное: для HTML, атрибутов, JavaScript отдельно), Content Security Policy (CSP) и санитизация ввода. Не полагайтесь только на frontend — проверка нужна на сервере.
CSRF (межсайтовая подделка запроса): атака от имени пользователя
CSRF заставляет браузер жертвы отправить запрос на сайт, где она авторизована, без её ведома. Например, пользователь заходит на форум, а там вставлена картинка с URL перевода денег: <img src="bank.com/transfer?to=attacker&amount=1000">. Если у пользователя активная сессия и банк не проверяет происхождение запроса — деньги уходят.
Эта уязвимость работает потому, что браузер автоматически прикрепляет куки к запросам. Защита — использование уникальных токенов (CSRF-токенов) в каждой форме, проверка заголовка Referer, а также требование подтверждения чувствительных действий (например, ввод пароля заново). Современные фреймворки включают защиту по умолчанию — не отключайте её.
Эти три уязвимости — не новость, но они продолжают ломать даже крупные сервисы. Внимание к вводу и выводу данных, регулярные аудиты и следование лучшим практикам сведут риск к минимуму. Начните с малого: проверьте свои формы на SQL-инъекции, убедитесь в экранировании вывода и включите CSRF-защиту. Это займёт час, а спасёт годы репутации.
