Кодер ошибается один раз, программист постоянно. (о безопасности скриптов)

Ошибаетесь вы. Шаблонизатор не отделяет код от шаблона, он разделяет логику. (принимает на вход данные и выводит их в соответствующем виде)

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

<?php
$content = "Hello, World";
?>
<p><?php echo htmlspecialchars($content);?></p>

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

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

Вот я тоже так думал раньше :)

А оказывается теперь он должен быть еще и специалистом в информационной безопасности. :)

На сегодняшний день в большинстве случаев именно верстальщик делает шаблон, а не тупо верстку. Многие шаблонизаторы (Smarty не единственный) позволяют сделать шаблон небезопасным и без участия программиста.

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

Ну а часть действительно считают, что безопасность это глупости, и на само деле достаточно сделать форму логина, и все - скрипт безопасен :)

<?php

$content = "Hello, World";

?>

<p><?php echo htmlspecialchars($content);?></p>

Ну это уже вопрос формулировок. Спор тут не конструктивен. А вот если ближе к теме, то тогда надо так:

<?php

$content = htmlspecialchars("Hello, World");

?>

<p><?php echo $content;?></p>

Чисто к контексте обсуждения видны сразу два важных момента:

1 - эскейпинг данных идет за пределами шаблона. Это не задача шаблона обеспечивать безопасность.

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

Опыт сравнения подходов "все что не запрещено разрешено" и "все что не разрешено - запрещено" исчисляется десятилетиями, и плюсы и минусы обоих подходов бесспорны :)

Вообще строго говоря должно быть что-то типа:

<?php

$out[content] = "Hello, World";

// ************* конец прикладного кода *****

foreach ($out as $k => $v) $out[$k] = htmlspecialchars($v);

?>

<p><?php echo $out[content];?></p>

Так отпадает необходимость помнить о ескейпинге постоянно. И это уже позволяет писать прикладной код кодеру а не программисту :)

Ну а вообще как по мне, так простейший шаблонизатор это что-то вроде:

<?php

$templ=file_get_contents(баблабла);

while (list($var, $param) = each($templ_var)) 

	{ 

	$templ=str_replace('{'.$var.'}', htmlspecialchars($param), $templ);

	}

echo $templ;

?>

*кто не понял - не стоит путать сферических коней с реальными :)

поздравляю! вы изобрели пассивный шаблонизатор с автоэскейпом 🤣

вопрос подходов и правда разный, гдето хорошо автоэскейп, гдето без него. это как холивар windows vs linux, ни к чему не приведет, ничего не стоит в общем :)

Безопасность должна быть заложена на уровне инструмента, которым вы пользуетесь.

Нужно отделять все запросы к бд на уровне инструмента и все критичные поля обезопасить, т.е. не давать их редактировать из формы если они придут.

Разделять права админа и менеджеров, хотя многие ленятся это делать, и аккаунт к админке один на 10 отсталых единиц офисного планктона.

Отделять логику записи с выводом формы. Обычно это делается в одном файле и на один и тот же запрос/линк.

Пассивная защита

Не использовать популярные движки/скрипты, по возможности. От верстальщиков забирать только html, вставить пару переменных в дизайн не займет много времени. Если у вас больше нескольких переменных в шаблоне, значит у вас не верная структура/логика, смотрите в сторону переноса логики из шаблонов в отдельные файлы.

Не использовать стандартные функции для вывода print и echo, замените их на самописные, чтобы по дефолту отдавали все данные в html escape.

По ту сторону экрана враги, и все, что они вводят в форму потенциально опасно.

Сравнение ОС действительно неразумно. Зависит от задачи. А вот сравнение подходов к безопасности - очень даже... не даром мелкомягкие с каждой итерацией все ближе и близе к парадигме "все что не разрешено - запрещено". Понятно что на рабочих станциях в чистом виде это неприменимо, но тем не менее - если наблюдать развитие окон с 3.11 (лично я более древних не использовал) то это довольно очевидно.

:) собственно к этому я плавно и клоню... инструмент параноика должен быть надежным.

Часто это излишество - это полезно для логирования изменений, поиска ответственности и т.п.

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

не совсем понятен смысл такого подхода в контексте безопасности. Раскройте свою мысль плиз.

Не ну это паранойя. Таки да имея исходники скрипта или как минимум его "скелета" проще найти уязвимость, но с другой стороны у самописов этих уязвимостей больше чем у старых проверенных временем КАЧЕСТВЕННЫХ движков. (естественно есть движки которые принципиально уязвимы, и их невозможно вылечить на 100%, но это отдельный разговор, никак не связанный с их возрастом и популярностью.)

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

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

Это да, это факт. :)

Вот тут вы ошибаетесь.

Это касается не безопасности, это касается просто самой логики скрипта. (без эскейпинга скрипт не просто "дырявый" а просто напросто "неправильный" ибо вместо HTML мы подаём в шаблон text/plain что неправильно)

- $content это данные

- эскейпнутые данные это вывод

- эскейпинг должен делать шаблонизатор а не ядро и не шаблон

Т.е конкретнее

<?php
// ядро скрипта
$content = "Hello, World";

// шаблонизатор
$template_data = htmlspecialchars($content);
// шаблон
?>
<p><?php echo $template_data;?></p>

wano-moroz добавил 31.01.2011 в 09:42

Именно по этому надо разделять данные и "эскейпить" их зависимо не от того откуда они пришли, а от того куда они уйдут.

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

Это уже из области сферического коня. Я например вывод не эскейплю, только ввод и базу.

А вывод по ситуации.

Собственно это я и сказал

полный ужас подход

seodude добавил 01.02.2011 в 12:13

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

seodude добавил 01.02.2011 в 12:13

одним словом - костыли ради костылей

Говоря короче "тоже". Для разметки, используются обычно несколько вещей, например разрешается HTML (НО НЕ ВЕСЬ !!!) или используется BBCode и это должно реализовываться на уровне шаблонизатора. (т.е вместо htmlspecialchars надо будет использовать какую нибудь IIIyXeP_HaXeP_TpAxEp_bbcode_convert функцию, которая должна быть в шаблонизаторАХ)

Подробнее.

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

Допускаем что у нас есть CMS (для простоты берём гостевую книгу) что мы имеем ? Мы имеем текст введённый пользователем (в формате text/plain с например использованием BBCode)

Нам надо вывести его в браузер, и допустим ещё отправить на мыло подписчикам, и закинуть в RSS и ещё через 20 лет появится какой нибудь "мега-шухер-мухер-хтмл" и нам надо будет отправить его ещё и туда...

Что делает "идеальная" CMS...

Кидает текст в базу (прямо так, не "эскейпнутую" версию, т.е "исходник") причём кидает его не в SQL-запрос, а в базу (т.е данные "эскейпаются" для SQL, но не меняются с точки зрения исходных данных, т.е как бы отдаются SQL-шаблонизатору !!! НО это не для безопасности, а просто потому что "так положено", и если так не сделать, то в скрипте будет дыра, но не потому что "программер не думал о безопасности" а потому что "вообще не думал ни о чём, и сделал неправильно") потом опять же исходные данные (а не эскейпнутые для SQL) мы прогоняем через "mail-шаблонизатор" (вёрстка для него отличается от браузерной) и отправляем подписчикам

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

Тут все просто, логика вывода и записи должна быть разделена, это упрощает выделение уязвимостей. Когда код это не понятный ассемблер написанный на php, то тут не до выявления уязвимостей. Допустим для отсылки мыла это еще допустима, но для более серьезных вещей..

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