Шаблонизатор Smarty - нужно ли автоэкранирование?

[Фанат]

Я думаю, мне тоже надо более ясно выразиться.
Существует две проблемы, связанных с корректным форматированием данных. Обсуждая тему, люди их часто путают, и в итоге получается совсем ерунда и невозможность договориться.
Это:
- безопасность
- порча данных

При всем уважении ко второму пункту, первый, все-таки, важнее.
Поэтому любое автоформатирование должно обеспечивать стопроцентную безопасность. Пример:
Если мы ВСЕ помещаемые в SQL запрос данные будем форматировать, как строки, то в худшем случае мы получим ошибку запроса, НО инъекция все равно не пройдёт. Это принципиально важный вопрос. На котором, в частности, строится и механизм работы пресловутого ПДО.
Это очень важный момент. Автоформатирование вполне имеет право на жизнь. Но если оно действует так, как описано выше - пусть будет ошибка, но не будет инъекции.
Только разобравшись с первым, мы можем переходить ко второму (который, в общем-то, проблемы никакой и не представляет - ответ на него я сформулировал в предыдущем сообщении). Но первый меня беспокоит.

Что-что?

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

document.write ("Hello"+<?=htmlspecialchars($name)?>)

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

 

[Вурдалак]

Фанат
Я, кстати, заметил, что по инерции тебя троллю, хотя вроде ты в этой теме и не занимаешь прямо противоположную позицию. Извини за резкость.

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

Принципиальных отличия два:

• автоэкранирование работает с конкретными значениями при выводе, не трогая переменные, в то время как magic_quotes перезатирает переменные;
• область действия автоэкранирования очень конкретна: HTML-шаблон, либо его часть (между двумя тегами). Поэтому удивляться, что в HTML-шаблоне данные встраиваются по умолчанию с примением HTML-экранирования, по меньшей мере странно.

с ходу десяток примеров приведу

Пустой звук.

 

[Фанат]

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

Фанат
Принципиальных отличия два:

• автоэкранирование работает с конкретными значениями при выводе, не трогая переменные, в то время как magic_quotes перезатирает переменные;
• область действия автоэкранирования очень конкретна: HTML-шаблон, либо его часть (между двумя тегами). Поэтому удивляться, что в HTML-шаблоне данные встраиваются по умолчанию с примением HTML-экранирования, по меньшей мере странно.

Ну это, имхо, ерунда.
Эти два пункта друг другу противоречат.
Если нигде больше, кроме этого шаблона, данные не используются, то в чем бенефит первого пункта?
Со вторым хуже - как я уже выше писал, шаблон (как и SQL запрос) принимает данные РАЗНЫХ типов. Нет такой сущности, "данные для HTML", как нет сущности "данные для SQL". Есть определенные элементы шаблона (и запроса), которые должны форматироваться соответственно своей роли.

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

 

[флоппик]

Отсюда у меня и вопрос. Обеспечивает ли htmlspecialchars() стопроцентную защиту данных в любом контексте шаблона? В джейсоне, внутри JS кода, и пр?

При условии правильно выбранной кодировки и режима ENT_QUOTES, и вставки контента в тег, а не атрибут тега, да, ты получишь 100%-но нормальный plain text, который не будет распознан как разметка.
Проблема начинается там, что тебе как правило, не особо нужен plain text.

 

[Фанат]

При условии...

Мне бы хотелось без условий.
Основная (если не единственная) цель применения автоформатирования - безопасность.
Если оно обеспечивает безопасность безусловно - оно имеет смысл.
Если не обеспечивает - ну... имеет, но оооооочень мало. По принципу "авось не грянет, мужик не перекрестится". Это не наш метод

 

[AnrDaemon]

Если это была попытка оскорбления - на меня это не действует.
Если это была попытка указания на несоответствие реальности - тут ваше восприятие реальности дало сбой.
Впрочем, хорошо, забудем про десяток. Вернёмся к одному примеру, что у нас уже есть.
Переменная $url содержит строку с русскими символами в кодировке UTF-8.
Поведение автоэскейпинга в этом случае?

 

[AnrDaemon]

При условии

Каком ещё условии? Условия тут были оглашены выше - ВСЕ переменные АВТОМАТИЧЕСКИ обрабатываются через htmlentities().
Либо они обрабатываются (все, да), либо это уже какое-то "тут играем, тут не играем, тут рыбу заворачивали".

 

[AnrDaemon]

Я думаю, мне тоже более ясно выразиться.
Существует две проблемы, связанных с корректным форматированием данных. Обсуждая тему, люди их часто путают, и в итоге получается совсем ерунда и невозможность договориться.
Это:
- безопасность
- порча данных

При всем уважении ко второму пункту, первый, все-таки, важнее.

По вашей логике, безопасность важнее работоспособности? Я правильно вас понимаю? По мне, тут некорректно расставлять приоритеты. Если приложение НЕ РАБОТАЕТ, оно может быть сколь угодно безопасным - цена этой безопасности ноль без палочки.

 

[флоппик]

Основная (если не единственная) цель применения автоформатирования - безопасность.
Если оно обеспечивает безопасность безусловно - оно имеет смысл.

Если результат не соотвествует ожидаемому, но «безопасен», то я не считаю это решением. Для тебя это возможно, приемлемо.

 

[Вурдалак]

Если нигде больше, кроме этого шаблона, данные не используются, то в чем бенефит первого пункта?

Одна и та же переменная может использоваться в двух разных контекстах:

<html>
<head>
    <script>
        {% autoescape 'js' %}
        document.write ("Hello, {{ name }}");
        {% endautoescape %}
    </script>
</head>
<body>
    Hi, {{ name }}
</body>
</html>

echo $twig->render('index.twig.html', array('name' => '<Д\'артаньян>'));

<html>
<head>
    <script>
                document.write ("Hello, \x3C\u0414\x27\u0430\u0440\u0442\u0430\u043D\u044C\u044F\u043D\x3E");
            </script>
</head>
<body>
    Hi, &lt;Д&#039;артаньян&gt;
</body>
</html>

 

[флоппик]

Каком ещё условии? Условия тут были оглашены выше - ВСЕ переменные АВТОМАТИЧЕСКИ обрабатываются через htmlentities().

Не переменнные. Операции вывода. Как можно обработать переданную модель в шаблон целиком?

 

[AnrDaemon]

А, вспомнил... Сейчас все дружно смеяться будем.

{capture name="myblock"}{$url}{/capture}
{$smarty.capture.myblock}

Сколько раз будет применён автоэскейпинг?... Один? Два? Кто больше?

 

[AnrDaemon]

Не переменнные. Операции вывода. Как можно обработать переданную модель в шаблон целиком?

Да, прошу прощения, некорректно выразился. Разница действтельно есть, и я её понимаю, но вот принципиально я против любой подобной "помощи". Гораздо чаще это выливается в медвежью услугу. И почти всегда - в неоправданное замедление обработки запроса.

 

[Вурдалак]

Видимо ты не добавил к raw-данным ($smarty.capture.myblock) nofilter и жалуешься. Я правильно понимаю?

 

[Фанат]

Если результат не соотвествует ожидаемому, но «безопасен», то я не считаю это решением. Для тебя это возможно, приемлемо.

Да, для меня это приемлемо. Но я не продвигаю здесь лозунги "испортим ВСЕ данные ради безопасности".

Я нигде не пишу, что я предлагаю всё так и оставить.
Наоборот - я несколько раз написал, что если у разработчика хватило ума поставить правильный фильтр - то ради бога, пусть выводит хоть в двоичном коде на альфу центавра.
Речь идет - если кто-то совсем не въезжает, о чем топик - об АВТОформатировании. То есть, о форматировании, СПЕЦИАЛЬНО предназначенном для случая, когда разработчик не поставил вообще никакой фильтр. Это единственный смысл автоформатирования. И говорить о нем имеет смысл только в этом контексте. В контексте безопасности.

Поэтому - да, я предлагаю портить данные. Если не было указано обратное. Белый список, гарантированная безопасность.
Но нигде я не писал, что все надо так и оставить, и применять автоформатирование для всех данных подряд.
У авторов ПДО, кстати, сказать - точно такой же подход.

В том же самом ПДО цикл разработки именно такой:
- попытался забиндить идентификатор
- получил ошибку
- сел думать.
И-ДЕ-АЛЬ-НЫЙ цикл.

[Мне стало стыдно, всю беллетристику потёр]

 

[AnrDaemon]

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

 

[Вурдалак]

Переменная $url содержит строку с русскими символами в кодировке UTF-8.
Поведение автоэскейпинга в этом случае?

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

У меня стойкое ощущение, что ты не слышал про rawurlencode/urlencode, и ищешь виновного в мистическом автоэкранировании, которое и знать не знает о других уровнях экранирования.

 

[Фанат]

Я бы даже называл это не автоформатированием, а дефолтным форматированием. Во избежание недоразумений.

Но проблема в том, что, в отличие от SQL, дефолтное (HTML) форматирование НЕ обеспечивает безопасности. И по этой причине не годится на роль автоформаттера.

 

[флоппик]

о форматировании, СПЕЦИАЛЬНО предназначенном для случая, когда разработчик не поставил вообще никакой фильтр. Это единственный смысл автоформатирования. И говорить о нем имеет смысл только в этом контексте. В контексте безопасности.
Поэтому - да, я предлагаю портить данные. Если не было указано обратное. Белый список, гарантированная безопасность.

Извини. Да, я совершенно согласен с тобой в такой формулировке.
Да, переход на именно такую политику у меня сократил список уязвимостей на этапе тестирования безопасности с трех-четырех страниц до двух-трех строчек. Перешли где-то полгода назад, когда штат вырос, и контролировать все коммиты стало нереальным.

 

[AnrDaemon]

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

У меня стойкое ощущение, что ты не слышал про rawurlencode/urlencode, и ищешь виновного в мистическом автоэкранировании, которое и знать не знает о других уровнях экранирования.

Я не ищу виновных - я провожу натурную демонстрацию в ответ на ваше(?) заявление о "уранокенецтопоявившемся" автоэкранировании в Smarty. Любая автоматика, не запрошенная напрямую пользователем и работающая без его ведома и согласия - зло. Ничего, кроме недоумения, в процесс разработки это не привносит.

Фанат, говорить о безопасности в контексте языка разметки документов вообще несколько... как бы это сказать... в общем, да, конечно, нужное дело и всё такое... но у меня есть стойкой ощущение притянутости за уши. Сложно объяснить.