Когда разработчик программного обеспечения впервые знакомится с веб-безопасностью, он неизбежно запоминает свою первую аббревиатуру: XSS! Это означает межсайтовый скриптинг и является одной из старейших уязвимостей. Его истоки восходят к 90-м годам, когда Javascript был новичком в мире. XSS (тогда это был CSS) был его злым младшим братом, и он до сих пор процветает благодаря успеху своего брата. Может возникнуть вопрос: Почему это называется межсайтовый скриптинг?. Ну, изначально он действительно был межсайтовым: страница имела возможность загружать другую и иметь доступ на чтение/запись к своей DOM (Вау, вы можете в это поверить? Подробнее об этом здесь) Эти дни давно прошли, теперь мы вооружены различными браузерными безопасными функциями для борьбы с этой атакой. Тем не менее, XSS по-прежнему является доминирующей уязвимостью, и она не исчезнет в ближайшее время…
Анатомия
Межсайтовый скриптинг — это выполнение вредоносного кода в браузере. Я также включил несколько браузеров и мобильных устройств, чтобы показать, что эта атака не ограничена каким-либо браузером или устройством. Это влияет на все, что способно запускать Javascript. Важно отметить, что хотя фактическая эксплуатация происходит на стороне клиента, сервер также может играть роль в создании уязвимости! Как вы увидите позже, большинство механизмов защиты должны быть развернуты на сервере. Не будем забегать вперед, для начала нужно четко понимать, от чего мы защищаемся.
Типы XSS
Мы, люди, любим классифицировать и называть вещи. В данном случае мы придумали три категории. Я буду придерживаться исходной классификации, поскольку она широко принята (подробнее об этом позже). Давайте рассмотрим каждый из них подробно.
Отраженный XSS
Первый, самый безопасный, называется «отраженный межсайтовый скриптинг». Это происходит, когда злонамеренный ввод отражается обратно в содержимом страницы без правильной кодировки (обратите внимание, что кодировка здесь не относится к символам). кодировка). В качестве примера подумайте о веб-сайте с простой формой поиска. Вы вводите свой поисковый запрос и отправляете его. Сервер получит ваш запрос и отправит результаты с заголовком, указывающим, что вы искали. Следующее изображение иллюстрирует этот момент.
Процесс начинается с того, что клиент отправляет на сервер специально созданный запрос. В нашем случае это простой GET-запрос с вредоносной строкой запроса. Когда уязвимый сервер обрабатывает это, он отправляет часть вредоносного запроса в исходный код страницы в незакодированном виде. Теперь подумайте о том, что происходит дальше: браузер клиента получает испорченный ответ и анализирует его, чтобы отобразить сайт для пользователя. Во время этой процедуры введенный незакодированный ввод будет обработан, и браузер интерпретирует его как тег скрипта и выполнит его содержимое, вызвав всплывающее предупреждение. Бум, тебя взломали!
Есть пара ключевых понятий, которые мы должны рассмотреть.
Во-первых, атака состоит из двух фаз: внедрение и эксплуатация. В этом случае оба происходят в одном цикле запрос-ответ. Фаза внедрения отправляет вредоносный ввод на сервер, а этап эксплуатации происходит, когда браузер обрабатывает зараженный ответ. >. С точки зрения хакера это очень сильное ограничение. Обратите внимание, что внедрение должно быть выполнено жертвой. сильный>. Это затрудняет масштабирование атаки, поскольку она будет успешной только в том случае, если каждая жертва пройдет фазу внедрения и посетит созданный со злым умыслом URL. Если это обычный запрос, не содержащий вредоносного кода, ничего не произойдет. Итак, зачем кому-то в здравом уме посещать такой URL? В идеале никто бы так не делал! Хотя на самом деле это гораздо более сложный вопрос. Пользователей манипулируют, заставляя переходить по таким ссылкам или, что еще лучше, они автоматически запрашиваются браузером без ведома пользователя, не говоря уже о его согласии. Это подводит нас к следующему пункту.
Злоумышленник должен будет найти способ выполнить фазу внедрения, главным образом, чтобы заставить жертву запросить специально созданный URL-адрес. Пользователи не будут просто взламывать себя или будут они? Я оставлю читателю возможность подумать о возможных методах распространения (подсказка: https://genuine-looking-site.com/index?parameter=‹payload›).
В-третьих, вредоносный запрос может содержать полезную нагрузку где угодно (на самом деле это зависит от того, как сервер обрабатывает запрос). Для злоумышленника лучше всего, если полезная нагрузка находится в строке запроса, так как ее легко передать по URL-адресу.
Однако это может быть и тело или даже заголовки. Излишне говорить, что атака не ограничивается командой GET.
В этом посте мы изложили основы, но, конечно же, XSS — не единственный тип! Оставайтесь с нами, чтобы прочитать о других!
