В чем опасность небезопасного ввода пользователем текста в Django?

Question

Недавно один из моих сотрудников опубликовал уязвимость на странице разработки. Это позволяет пользователю вставить 30 символов неэкранированного кода, который будет выполнен с фильтром |safe. Таким образом, html небезопасные символы (<, >, ', " или &) могут быть свободно вставлены в шаблон страницы.

Уязвимость существует в сообщении об ошибке в форме, поэтому он не позволяет хакеру редактировать то, что показано другим пользователям, только сам. Я хочу показать моему сотруднику опасность уязвимости с ужасающим примером. Кроме того, я лично заинтригован на профессиональном уровне в отношении того, что было бы самым худшим случаем с такой уязвимостью, как это было бы. Я знаю, что в PHP (возможно, в более старых версиях) это позволит пользователю отображать содержимое файлов сервера. Будет ли эта уязвимость позволять мне также показывать содержимое в файле настроек? Django Devs (благословить их) мудро выбрали, что { не будет экранирован даже с фильтром |safe. Поэтому он не может использоваться для отображения контекстных переменных.

Худшее, что я смог придумать самостоятельно, - это вставка (и исполнение) любого JS-файла, расположенного в любом месте в Интернете, что было бы ужасно, если это могло повлиять на других пользователей, но это не кажется, что плохо, если js-файл будет выполнен только для самого хакера.

Answer 1

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

т.е. http://example.com?email=<script>alert(1)</script>

В противном случае, единственный другой способ (что я могу думать), чтобы использовать это было бы использовать форму на другой странице (предполагается, что этот запрос разрешен).

<form name="xssForm" action="http://example.com" method="POST"> 
    <input type="hidden" name="email" value="<script>alert(1)</script>" /> 
</form> 
<script> 
    document.xssForm.submit(); 
</script> 

Второй вариант - уязвимость CSRF, которая может быть или не существовать на вашем сайте.

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