Удаленное включение файлов путем изменения полезных нагрузок POST. Это действительно возможно через HTTPS?

Question

Вот как мое приложение загружает необходимые JS-файлы:

Страница (на HTTPS) отправит запрос POST, описывающий, какие JS-файлы должны быть загружены с различных серверов. Полезная нагрузка будет выглядеть примерно так:

{
   "1": "https://somehost.com/path/first.js",
   "2": "https://someotherhost.com/path/second.js"
}

Сервер соберет все эти файлы JS, объединит их и отправит обратно клиенту. Клиент поместит полученное содержимое в динамически созданный <script> тег.

На этом мы запустили IBM Appscan, и, к моему удивлению, Appscan сообщил об уязвимости удаленного включения файлов, и инструмент смог добавить третий параметр в JSON, существенно изменив полезную нагрузку. Так это выглядело примерно так:

{
   "1": "https://somehost.com/path/first.js",
   "2": "https://someotherhost.com/path/second.js"
   "3": "https://appscan-host/malicious-test.js"
}

Мои вопросы:

1. Это действительно правдоподобный сценарий? Что злоумышленник может изменить полезную нагрузку POST, отправленную браузером жертвы, чтобы включить удаленный вредоносный скрипт? Я просто не могу обернуть голову вокруг этого - я уверен, что что-то здесь упускаю.
2. Учитывая, что у нас есть архитектура, которая динамически отправляет URL-адреса файлов JS в полезной нагрузке JSON, чтобы сервер загружал их и отправлял обратно клиенту, какие возможные решения у меня есть для исправления этой уязвимости?
3. Я читал об использовании HMAC для подписи запросов, но если злоумышленник выяснит алгоритм, использованный для генерации HMAC на стороне клиента, он может просто пересчитать HMAC и заменить HMAC, отправленный клиентом, после изменения полезной нагрузки после право?

Кроме того, если это в любом случае помогает, мы используем проверку подлинности на основе файлов cookie (сервер Tomcat устанавливает cookie-файл JSESSIONID HttpOnly после проверки подлинности на основе форм для последующих запросов).

Answer 1

Я полностью согласен с ответом @duskwuff, просто добавив сюда еще несколько пунктов (это дополнение, а не замена тому, что уже упоминалось в предыдущем ответе):

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

Хотя злоумышленник не может изменить (или даже перехватить в виде простого текста) запрос https в полете, он может изменить запрос во время создания, возможно, с помощью какой-либо уязвимости межсайтового скриптинга. Таким образом, жертва - это не только ваш сервер (см. Предыдущий ответ), но и ваш клиент.

3. Я читал об использовании HMAC для подписи запросов, но если злоумышленник выяснит алгоритм, использованный для генерации HMAC на стороне клиента, он может просто пересчитать HMAC и заменить HMAC, отправленный клиентом, после изменения полезной нагрузки после право?

Хотя подписи HMAC защищены (пока ваш ключ в безопасности), я не думаю, что включение подпрограммы генерации HMAC в ваш код на стороне клиента принесет вам пользу, так как злоумышленник может легко увидеть алгоритм hmac и ваши ключи и может подделать ваши подписи. HMAC хорош только в том случае, если он выполняется в безопасной и заслуживающей доверия среде (например, на вашем собственном сервере).

В вашем случае лучше всего занести в белый список допустимые URL-адреса и загружать только файлы js из доверенных доменов.

Answer 2

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

Вам не хватает того, что злонамеренный пользователь может преднамеренно отправить неверный запрос на ваш сервер. Жертва - это ваш сервер, а не другой пользователь сайта.

2. Учитывая, что у нас есть архитектура, которая динамически отправляет URL-адреса файлов JS в полезной нагрузке JSON, чтобы сервер загружал их и отправлял обратно клиенту, какие возможные решения у меня есть, чтобы исправить эту уязвимость?

Зависит от ваших конкретных потребностей. Одним из подходов может быть внесение в белый список набора URL-адресов JS, которые могут быть загружены таким образом.

3. Я читал об использовании HMAC для подписи запросов, но если злоумышленник выяснит алгоритм, используемый для генерации HMAC на стороне клиента, он может просто пересчитать HMAC и заменить HMAC, отправленный клиентом, после фальсификации сообщения полезная нагрузка, верно?

Этот метод будет работать только в том случае, если HMAC будет вычисляться на стороне сервера. Это не применимо на стороне клиента.