CompTIA SY0-701: Безопасность приложений и веб-ресурсов — Руководство по подготовке
Часть CompTIA Security+ SY0-701 — Руководство по подготовке. Практикуйтесь с проверенными ответами в центре экзаменов CompTIA, или пройдите тесты на время на ExamRoll.io.
Современные приложения находятся на стыке бизнес-логики, конфиденциальных данных и ненадёжного пользовательского ввода. Поскольку веб- и мобильные фронтенды доступны всему интернету, они представляют собой одну из самых больших и постоянно эксплуатируемых поверхностей атаки в любой организации. Их защита требует многоуровневых средств контроля, которые начинаются со способа написания кода и распространяются на защиту во время выполнения, проверку целостности и непрерывное тестирование.
Атаки внедрения (Injection)
Внедрение кода остается архетипичной веб-уязвимостью. Она возникает всякий раз, когда приложение объединяет (конкатенирует) ненадёжный ввод с инструкцией для интерпретатора — SQL-запросом, командой оболочки, LDAP-фильтром, XML-парсером или шаблонизатором — без должного разделения кода и данных. При SQL-инъекции (SQLi) злоумышленник модифицирует запрос таким образом, чтобы база данных выполнила логику, контролируемую злоумышленником. Классический уязвимый паттерн на PHP выглядит так:
$query = "SELECT * FROM users WHERE username = '" . $_GET['user'] . "'";
Отправка admin' OR '1'='1 превращает запрос в тавтологию, которая возвращает все строки. Более продвинутые варианты включают извлечение данных через UNION (' UNION SELECT credit_card FROM payments--), слепое булево или временное умозаключение (' AND SLEEP(5)--) и внеполосную эксфильтрацию данных через DNS-обращения. Надежное решение — это параметризованные запросы или подготовленные выражения, которые отправляют шаблон запроса и его параметры в базу данных как раздельные структуры:
cursor.execute("SELECT * FROM users WHERE username = %s", (user_input,))
Внедрение команд следует тому же принципу, но нацелено на оболочку операционной системы. Код вроде os.system("ping " + host) позволяет злоумышленнику отправить 8.8.8.8; cat /etc/passwd и выполнить произвольные команды. Исправление требует полного отказа от вызова оболочки, использования API, которые принимают массивы аргументов (subprocess.run(["ping", host], shell=False)), и применения строгой валидации по списку разрешенных (allow-list) для любого значения, которое должно попасть в оболочку.
Межсайтовый скриптинг (XSS) и CSRF
Межсайтовый скриптинг (XSS) — это внедрение вредоносного скрипта на страницы, отображаемые доверенным приложением, в результате чего браузер жертвы выполняет код злоумышленника в контексте источника (origin) сайта. Отраженный XSS (Reflected XSS) отправляет полезную нагрузку через уязвимый параметр; хранимый XSS (Stored XSS) сохраняет полезную нагрузку в базе данных и доставляет ее каждому посетителю; DOM-based XSS полностью происходит в клиентском JavaScript, который записывает ненадёжные данные в innerHTML, document.write или аналогичные приемники (sinks). Последствия варьируются от перехвата сессии и кейлоггинга до полного захвата аккаунта через принудительное выполнение действий.
Межсайтовая подделка запроса (CSRF) — это отдельная, но дополняющая атака. Она злоупотребляет автоматическим добавлением cookie браузером, чтобы обманом заставить аутентифицированного пользователя отправить нежелательный запрос — например, скрытая форма на вредоносном сайте, отправляющая POST-запрос на bank.com/transfer. Меры защиты включают токены-синхронизаторы (случайные значения для каждой сессии, встраиваемые в формы и проверяемые на стороне сервера), атрибут cookie SameSite=Lax или SameSite=Strict, а также требование повторной аутентификации для выполнения чувствительных действий. XSS и CSRF часто путают, но XSS выполняет код в браузере жертвы, в то время как CSRF просто заставляет браузер отправить запрос; примечательно, что успешная атака XSS может обойти большинство защит от CSRF.
Безопасное программирование: валидация входных данных и кодирование выходных
Эти два механизма контроля часто путают, хотя они решают разные задачи. Валидация входных данных гарантирует, что данные соответствуют ожидаемой структуре — длина, тип, набор символов, диапазон, формат — прежде чем приложение начнет с ними работать. Она должна происходить на сервере, по возможности с использованием списков разрешенных (allow-lists) (^[A-Za-z0-9_]{3,20}$ для имени пользователя). Валидация на стороне клиента с помощью JavaScript — это лишь элемент удобства использования; ее можно обойти с помощью любого HTTP-прокси, и она никогда не должна служить границей безопасности.
Кодирование выходных данных гарантирует, что данные будут безопасно отображены в любом контексте, в который они попадают. Одна и та же строка, являющаяся абсолютно валидными входными данными, может требовать разной обработки в зависимости от того, где она окажется: контекст тела HTML требует кодирования HTML-сущностей (< → <), контекст атрибута требует кодирования для атрибутов в кавычках, контекст JavaScript требует экранирования \xHH, а URL-адреса требуют процентного кодирования. Имя пользователя, такое как O'Brien, является легитимными входными данными, но при вставке в HTML должно быть закодировано как O'Brien. Валидация входных данных не может заменить кодирование выходных, а кодирование не может заменить валидацию — они решают разные проблемы на разных этапах жизненного цикла данных.
Дополнительные меры по усилению безопасности включают заголовки Content Security Policy (CSP) для ограничения источников скриптов, флаги HttpOnly и Secure для сессионных cookie, а также параметризованные API на каждой границе доверия.
WAF и защита при загрузке файлов
Межсетевой экран для веб-приложений (WAF) инспектирует HTTP-трафик и блокирует запросы, соответствующие известным вредоносным шаблонам — сигнатурам SQLi, полезным нагрузкам XSS, последовательностям обхода каталога, аномалиям протокола. Развернутый как обратный прокси-сервер (ModSecurity с OWASP Core Rule Set, AWS WAF, Cloudflare, F5), он обеспечивает ценный «виртуальный патчинг», когда уязвимость обнаружена, но код еще не исправлен. Однако WAF является компенсирующим контролем, а не заменой безопасной разработке кода. Опытные злоумышленники регулярно обходят WAF с помощью трюков с кодированием, загрязнения параметров HTTP (HTTP parameter pollution) и фрагментации полезной нагрузки.
Загрузка файлов заслуживает особого внимания, поскольку она сочетает в себе ненадёжный контент, хранение на стороне сервера и, зачастую, выполнение. Меры защиты включают валидацию типа файла путем проверки «магических байтов» вместо того, чтобы доверять расширению или заголовку Content-Type, хранение загруженных файлов за пределами корневого каталога веб-сервера, переименование файлов в сгенерированные сервером идентификаторы (для предотвращения обхода каталога через специально созданные имена файлов), сканирование антивирусом перед сохранением и раздачу загруженного пользователями контента с отдельного домена для предотвращения выполнения скриптов в том же источнике (same-origin).
Практический сценарий: SQL-инъекция, приведшая к полной компрометации базы данных
Конечная точка поиска товаров в розничной компании принимала параметр category, который напрямую конкатенировался с SQL-запросом без какой-либо санитарной обработки. Исследователь безопасности обнаружил, что отправка строки ' UNION SELECT table_name,null,null FROM information_schema.tables-- приводила к возврату списка всех таблиц базы данных в ответе. Последующие запросы позволили извлечь таблицу customers, что привело к утечке 1,2 миллиона записей, включая имена, адреса электронной почты и пароли, хешированные с помощью bcrypt. Злоумышленник также обнаружил хранимую процедуру, которую можно было вызвать через SQL-инъекцию для записи файлов в корневой каталог веб-сервера, что позволило развернуть веб-шелл и полностью скомпрометировать сервер. Уязвимость существовала три года и была пропущена в двух предыдущих тестах на проникновение, потому что тестировщики проверяли только форму входа, а не конечную точку поиска. Урок: тестирование на инъекции должно охватывать каждый параметр в каждой конечной точке, а не только очевидные пути аутентификации.
← Реагирование на инциденты · Все домены · Безопасность облаков →
Отработать эти вопросы → · Тесты на время на ExamRoll.io →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
Сдайте экзамен →