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

wano-moroz, вы закапываетесь в детали.

Я например вообще не эскейплю вывод.

В смысле централизованно не эскейплю.

и метод bbcode2html у меня не в шаблонизаторе заложен.

на уровне ядра я навязываю прикладнику только безопасность.

Хотя если честно рассматриваю вариант сделать два метода передачи данных шаблонизатору - с эскейпом и без.

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

sun, ну именно читабельность кода можно по разному организовывать :)

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

К примеру у меня (как и у многих фреймворков) ссылки по умолчанию обрабатываются как /имя_класса/имя_метода/параметр1/параметрN

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

Ну а на счет:

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

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

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

если так, то все ок. Просто речь шла о выводе в хтмл везде, и у подумал уже что вы используете htmlspecialchars перед загоном в базу :)

Вот и вы делаете ту самую ошибку которая приводит к краху многие продукты.

Цитируя одну статейку

format c:

wano-moroz, в чем ошибка собственно? :)

В том, что нельзя доверять инфе от пользователя?

от эскейпа "для профилактики" краха не будет.

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

Не вижу противоречий.

mendel добавил 04.02.2011 в 14:44

Да еще к статейке интересный момент.

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

В том числе и в этом.

Нет конечно правда что ввод надо проверять, например если мы ждём ввод положительного числа то мы должны проверить (и опять же не фильтровать) пришло число или нет (аналогично и с мылом/адресом/итд)

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

Будет и не малый.

И какой будет? Что вместо хтмл выведется исходный код?

Ну и фиг с ним... зато уязвимости на ровном месте не заработаем.

wano-moroz, мне кажется у нас с вами недопонимание именно в постановке вопроса.

Я говорю о фреймворке, а вы похоже о прикладном скрипте.

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

Вот в этом ваша главная ошибка, ядро оперирует данными а не их представлением (представление это уже забота модулей) т.е за HTML отвечает шаблонизатор, за SQL отвечает либа для работы с БД итд

Именно, по этому все они должны оперировать абстрактными данными, а за вывод их в браузер/базу/файлы/итд должен отвечать не каждый модуль (ибо писатель модуля может не знать какие там вообще модули есть) а непосредственно тот что работает с выводом.

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

wano-moroz добавил 04.02.2011 в 20:44

Если при надевании двух презервативов вреда будет не заметно, то при заливании в бензобак воды вместо опасного бензина, вред будет намного больше.

Ну а Ваша главная ошибка в том, что ищете у меня ошибки. :)

Приведите пример где от такого подхода может быть вред, а не теоретизируйте.

mendel добавил 05.02.2011 в 12:55

И да, это:

не пример если что :)