Если приложение уязвимо для сохраненной уязвимости XSS, но только администратор может поместить в приложение полезные нагрузки XSS.Это действительная ошибка безопасности? - PullRequest
0 голосов
/ 11 октября 2018

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

Так это действительная ошибка безопасности?И я должен это исправить?

Заранее спасибо!

Ответы [ 3 ]

0 голосов
/ 11 октября 2018

Я думаю, что это допустимая ошибка безопасности, хотя она снижает фактор риска, потому что только авторизованный пользователь может установить полезную нагрузку xss.Многие из веб-приложений (например, wp и т. Д.) Позволяют привилегированной учетной записи размещать нефильтрованный HTML-контент, но при наличии нескольких администраторов это может привести к горизонтальной привилегированной эскалации или перехвату, если один администратор может использовать xss для захвата другого администратора.

0 голосов
/ 12 октября 2018

Для более авторитетного источника рассмотрим CVSS (Общая система оценки уязвимостей).Без всех деталей мне сложно оценить эту уязвимость, но я думаю, что это будет что-то вроде этого:

https://www.first.org/cvss/calculator/3.0#CVSS:3.0/AV:N/AC:L/PR:H/UI:N/S:C/C:N/I:L/A:N

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

Таким образом, это определенно допустимая ошибка безопасности, но похоже, что она имеет оценку 4,1 (средней серьезности).

У вас ошибка безопасности средней серьезности, и она доВы и ваша организация решаете эту проблему.Возможно, учитывая существующие смягчающие обстоятельства, вы решите принять риск.Возможно, вы просто сначала расставите приоритеты для других вещей, или, возможно, добавите дополнительные меры, такие как 2FA или расширенный мониторинг, чтобы обеспечить меньшую вероятность взлома учетной записи администратора.

Как специалист по безопасности, я бы сказал,всегда рекомендую исправить это.Кроме того, XSS может быть индикатором того, что в коде есть и другие более серьезные уязвимости.Возможно, тестирование на проникновение или проверка кода безопасности будет уместным в следующих шагах.

0 голосов
/ 11 октября 2018

Нет однозначного ответа, это зависит.Вы можете принять связанный с этим риск или нет.

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

Также могут быть вещи, которые даже администраторы не могут сделать в приложении.В качестве очень произвольного примера рассмотрим администратора, у которого есть веб-сайт, на котором он хочет генерировать просмотры страниц (или попросить других использовать материалы).Использование XSS в вашем приложении для генерации просмотра страницы на его веб-сайте из браузера жертвы может оказаться полезным в определенных сценариях.В примере, который, вероятно, ближе к реальной жизни, администратор может атаковать сеансы TLS других администраторов (например, подслушивать их пароли, которые, вероятно, также используются в других местах).Для определенных атак TLS необходим некоторый уровень контроля клиента (т. Е. XSS).Или в приложениях с очень высокой конфиденциальностью (используемых в сетевых сетях, т. Е. «Темной сети»), XSS может использоваться для выявления реального IP-адреса клиента.

Таким образом, в общем случае XSS влияет не только насамо приложение.Это влияет на клиента, который запускает полезную нагрузку, способами, иногда весьма неожиданными.Если есть только один администратор, который может выполнять XSS только для себя, вы могли бы поспорить, что это не такой большой риск.Но все же, что если кто-то еще получит доступ к базе данных, например, и вставит полезную нагрузку XSS для запуска администратором?Конечно, это может быть нелегко, но в соответствии с принципом глубокоэшелонированной защиты исправление всех известных уязвимостей также является хорошим уровнем защиты от этого.Это также может произойти, если злоумышленник получит доступ к авторизованному клиенту администратора (администратор на некоторое время оставит свой компьютер без присмотра).

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

...