Если ваш сайт, мини-программа или App предоставляет внешние сервисы, его обязательно будут сканировать, проверять и атаковать — вопрос лишь в том, обнаружат ли это вовремя. Многие команды сосредоточены на разработке функциональности и скорости запуска, а тестирование безопасности откладывают, и в результате один интерфейс с нарушением авторизации или одна точка загрузки может привести к компрометации всей системы. MIC Studio в ходе长期ных услуг по тестированию безопасности и реверс-тестированию снова и снова наблюдает одну и ту же закономерность: систему обычно пробивают не самые изощрённые технологии, а несколько типов старых, игнорируемых проблем. В этой статье подробно разобраны наиболее распространённые уязвимости при тестировании безопасности веб-сайтов и даны рекомендации по укреплению, которые можно применять напрямую.
一、Сначала разберитесь с целями и границами тестирования безопасности
Тестирование безопасности — это не покупка сканера и один прогон для отчётности. Оно должно ответить на три вопроса: через какую точку входа может проникнуть атакующий? Что он сможет получить после проникновения? Какой ущерб он сможет нанести после получения доступа?
По способу тестирования обычно выделяют три категории:
- Чёрный ящик: полностью имитирует внешнего атакующего, без исходного кода и учётных данных, наиболее близок к реальному сценарию атаки;
- Белый ящик: сочетается с аудитом исходного кода, позволяет выявить глубокие логические проблемы, которые не обнаруживаются чёрным ящиком;
- Серый ящик: имеются часть учётных данных или документация по API, самый эффективный вариант, подходит для проектов с частыми итерациями.
Для большинства малых и средних проектов в первую очередь стоит тестировать уровень API и уровень прав доступа — это наиболее выгодно по соотношению затрат и результата. Потому что именно здесь проблемы возникают чаще всего, и последствия самые серьёзные — утечка данных, несанкционированные операции, захват админ-панели — всё это начинается отсюда.
二、SQL-инъекции: старая проблема, но по-прежнему главный убийца
SQL-инъекции существуют более двадцати лет, но до сих пор остаются постоянным гостем в различных рейтингах уязвимостей. Причина проста: если хотя бы в одном месте SQL собирается конкатенацией, это может быть использовано.
Типичные сценарии:
- Интерфейс входа использует конкатенацию строк для запроса пользователя, ввод `' or '1'='1` напрямую обходит пароль;
- Поля сортировки и условия поиска в списках напрямую подставляются в SQL, что приводит к error-based инъекции или time-based blind инъекции;
- Некоторые старые системы используют ORM, но с конкатенацией нативного SQL — риск сохраняется.
Рекомендации по укреплению:
- Повсеместно использовать параметризованные запросы (prepared statements), на уровне стандартов кода запретить конкатенацию строк в SQL;
- Для полей сортировки, имён таблиц и других мест, где параметризация невозможна, применять проверку по белому списку, разрешая только предустановленные значения;
- Учётная запись базы данных должна следовать принципу минимальных привилегий; бизнес-аккаунту не выдавать опасные права, такие как DROP, FILE, GRANT;
- В production отключить вывод подробных ошибок, чтобы не раскрывать структуру таблиц и версию базы данных;
- Внедрить WAF как дополнительный рубеж защиты, но не рассматривать его как единственную защиту.
三、XSS межсайтовый скриптинг: самая долгоживущая инъекция
Суть XSS в том, что пользовательский ввод выполняется как код. Хранимая XSS наиболее опасна, потому что она长期но остаётся на странице и влияет на каждого посетителя.
Типичные сценарии:
- Комментарии, никнеймы, личные подписи напрямую выводятся на страницу;
- Rich-text редактор допускает тег `