Проблемы безопасности с HTML-шаблонами Mustache

У меня есть вариант использования, в котором содержимое HTML-шаблона с усами потенциально может исходить от приложения/конечного пользователя (т.е. содержимое тега script в приведенном ниже фрагменте кода).

<script id="template" type="x-tmpl-mustache">
  Hello {{ name }}!
</script>

Поскольку это потенциально может привести к выполнению вредоносного кода, я делаю

  1. Разрешено добавлять в шаблон только подмножество HTML-тегов и атрибутов (внутри тега script)
  2. Разрешены только экранированные переменные HTML, т. е. разрешены только {{name}}, а не {{{name}}}.

Есть ли что-то еще, что необходимо учитывать для обеспечения безопасности приложения?


person Arjun    schedule 22.10.2015    source источник
comment
Это интересный вопрос, но на него сложно ответить: не может быть окончательного списка потенциальных проблем с безопасностью, потому что некоторые реальные проблемы будут упущены из виду, а простое изменение в библиотеке усов или коде вашего приложения может открыть совершенно новый набор возможностей для атаки. Почему бы не открыть вопрос в репозитории усов на github, где авторы могли бы рассмотреть ваш вопрос более внимательно?   -  person Gwendal Roué    schedule 25.10.2015
comment
нет риска, нет, ноль, молния. тег script просто скрытый тег, если тип не является текстовым/javascript, а mustache.js больше не выполняет какой-либо динамический код, поэтому это не может быть проблемой. теперь, если вы разрешите ввод onmouseover и прочую хрень, у вас, конечно, будут проблемы, но они не имеют ничего общего с несуществующим тегом script. используйте ‹шаблон›, если сомневаетесь...   -  person dandavis    schedule 28.10.2015
comment
Спасибо. Что произойдет после оценки шаблона для заданных данных. Обратите внимание, что и содержимое шаблона, и данные поступают из приложения. Что касается onmouseover, я разрешаю только белый список HTML-элементов и атрибутов, так что это не проблема.   -  person Arjun    schedule 28.10.2015


Ответы (2)


Я думаю, что это не проблема «усов», если мы будем следовать философии «маленькие острые инструменты». Затем, прежде чем сопоставлять незащищенные данные (сторонний JSON) с шаблоном, вы должны проверить данные с помощью других инструментов.

Самый простой способ начать с замены строковых полей, содержащих незащищенные данные.

function clearJson(userStringData){

  return JSON.parse(userStringData, function(k,v) { 
        // string values containg something like
        // html tags or js block braces will not pass
        return String(v).match('[<>{}]') ? 'UNSAFE' : v;
  });
}

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

person diziaq    schedule 27.10.2015

Вы должны выполнить user inputs на сервере, а не "только" на клиенте. Если какой-то "плохой код" будет выполняться на клиенте, то уже слишком поздно ;)

person webdeb    schedule 31.10.2015
comment
Да, очистка входных данных приложения, которые станут частью шаблона, будет происходить на сервере. - person Arjun; 01.11.2015