Решил рассказать о более продвинутых уязвимостях, которые можно встретить на практике в рамках #edu контента, чтобы вы не засиживались в классических рамках. Пусть отныне такое будет #advanced_edu
Server-Side XSS - разновидность XSS, которая срабатывает на стороне сервера. Один из редких кейсов, когда уязвимость можно считать одновременно и клиентской и серверной. Забавно, что к текущему моменту не помню, чтобы хоть один кандидат называл данную разновидность на собеседованиях, которые я проводил, хотя разновидность интересная и импакт от нее сильный. Впервые я встретил ее на одном из CTF и с тех пор начал находить на реальных проектах (CTF - это круто, играйте в CTF, чтобы развиваться).
🔤Тип:
- Web
- Client-Side
- Server-Side.
Возникает логичный вопрос - а это вообще как? Схема тут такая: атакующий строит нагрузку (обычно хранимую), затем при помощи серверных механизмов приложения заставляет приложение ее отобразить. Чтобы это работало, на стороне сервера должен быть функционал, запускающий браузер для отработки страницы или ее компонентов. Тут снова может возникнуть вопрос - а кому вообще нужно такое писать? Действительно, в таком базовом сценарии вы вряд ли встретите данную уязвимость, однако такой функционал часто скрывается в используемых компонентах или библиотеках. Чаще всего таким грешат генераторы pdf-документов/изображений, которые для отрисовки красивого документа сначала обрабатывают HTML-страницу (даже если вы изначально создавали не HTML-страницу, а просто ввели, например, свои данные). Плюс, замечал, что некоторое современное ПО зачем-то бесшовно использует браузер для красивой отрисовки чего-либо, что тоже создает возможности для исполнения данной уязвимости.
По итогу мы можем использовать XSS-пейлоады, которые отрабатывают даже без наличия жертвы-пользователя. Более того, из-за того, что исполняет это сервер, с точки зрения атакующего у нас появляются новые возможности по сравнению с классической XSS.
🔤Влияние:
Почти всегда будет высокий или критичный импакт. По умолчанию мы можем делать SSRF нагрузки вида <script>window.location='some.internal.site'</script>, при этом он будет видимый с картинкой! Доступы будут аналогичны серверу, с которого это все запускается. В некоторых случаях мы можем добавлять в документ файлы с системы, получая LFR. Более интересным может получиться случай с исполнением кода (RCE). Если такой функционал используется как компонент какого-то ПО, разработчики могут не следить за версией браузера, который используется внутри (который мы, как атакующие можем получать из User-Agent отстуком на себя). В результате мы можем иметь браузер старой версии, к которому можно написать эксплоит (тут, правда, для обычного вебера будет целое испытание, потому что нужен бинарный сплоит и под каждую версию браузера он будет свой), но такое возможно и не является редким кейсом.
🔤Как сплоитить?
- 🔤 Самым сложным этапом будет найти функционал, где под капотом используется браузер, обрабатывающий пользовательский ввод. Как говорил раньше, это часто неочевидные механизмы
- 🔤 По мотивам стандартных XSS стоит определить Origin, окружение и версию браузера
- 🔤 Далее исходить из возможного импакта: двигаться в сторону SSRF (проще всего), LFR (если есть возможность), RCE (если вы крутой или дружите с бинарщиками)
🔤Как защититься?
- 🔤 Посмотреть, что за ПО вы используете (особенно для генерации PDF-документов) и есть ли там браузер внутри
- 🔤 По возможности избегать такого поведения или убедиться, что на этапе обработки предприняты меры защиты от стандартных XSS
- 🔤 При неообходимости создать issue в репозиторий библиотеки, чтобы они обновили браузер)
Вдогонку закину хороший недавний ресерч по PDF-генераторам. Единственное, тема серверных XSS там не освещена, хотя считаю что при изучении pdf-генераторов это очень важный момент
#advanced_edu #vuln #web #xss #server_side_xss
