Это очень скоропалительный комментарий, не проходит проверку практикой.
Как раз в PHP, как языке общего назначения, так делать ни в коем случае нельзя.
Ведь проблема касается только одной ипостаси, РНР-как-шаблонизатора.
правда, для <?=?> оно с одной стороны, идеально подходит, но с другой — настолько ломать обратную совместимость — я думаю, невозможно.
Беда в том, что как раз в приведённом выше примере мы имеем объект $order, и это очень показательно.
А объекты — штука тонкая. К моменту попытки автоискейпинга объект может ещё не знать, что у него такое свойство есть.
Или вообще его не иметь.
Ну то есть да — если заставить разработчика передавать в шаблон только скаляры и массивы — это работает.
Но, увы, я еще не встречал ни одного, который бы не хотел передать в шаблон объект $user и уже в шаблоне обращаться к его свойствам/методам. Хотя сам считаю это порочной практикой.
Ну вот это «очень легко решается» и проблема.
Кто-то стал решать, но не зная технологии, насовал в _e() кучу бесполензного мусора.
Кто-то вообще не знал, что что-то решать надо.
Кто-то знал, да забыл.
В общем — типичный «пхп-стайл», и типичный же результат, ЕВПОЧЯ.
Я не зря привел аналогию с SQL — там эти баталии на тему «легко решается» уже (надеюсь) отгремели, и все согласились наконец-то, что ручное экранирование должно быть забыто как страшный сон.
Ну вот кстати это тоже неправильно. Автоэкранирование должно быть в дефолтном операторе, а всё остальное — опция.
то есть, всё должно быть наоборот — в Laravel пишем {{{ }}} по дефолту, а можно написать {{ }}, если надо вывести данные как есть. А вообще определять вывод количеством скобочек — это мина замедленного действия
Эта ерунда с подсчетом скобочек еще аукнется многочисленными XSS-ами.
Ну, учитывая, что большинство пользователей похапешечки не вышли из ясельного возраста, то им такая реклама как раз.
Те же, которые вышли, или сами понимают сильные и слабые стороны движка безо всякой рекламы, либо вообще пилят большой портал на собственном софте, и им поп-фреймворки перпендикулярны.
А так-то да — ORM и роутенг преподносятся прям как исключительные заслуги Лярвы, и чуть фанфары из каждого абзаца не играют.
У нейтив ПХП есть один очень серёьзный недостаток — невозможно сделать нормальный авто-искейпинг.
А это, пожалуй, в шаблонизаторе главное.
«приятный синтаксис», «экономия целых двух символов на оператор» — это всё ерунда. А вот собственный оператор вывода, которым можно управлять — это очень, очень важно.
Ведь на самом деле в нейтив должно быть что-то вроде
<li><?=_e($order->title) ?></li>
— а с таким довеском идея как-то уже меркнет.
В какой-то мере можно рассматривать {{ $order->title }} как аналог плейсхолдера в SQL. А <?=$order->title ?>, соответственно — как прямую интерполяцию, со всеми вытекающими.
Ладно, так и быть, я попробую один раз.
Хотя заранее уверен, что не получится — уж больно случай запущенный.
Любая проверка входящих данных не имеет ни малейшего отношения к работе с БД.
Ну, то есть, в типичном похапе-стайл говнокоде, где «роутер» — это if (isset($_POST['submit'])), после которого данные сразу же пихаются в mysql_query — тут вполне возможно визуально проконтролировать, что попадающие в запрос данные были проверены некой кривой регуляркой. Но так, вообще-то, никто давно не пишет.
Ты и сам упомянул роутер — за язык тебя никто не тянул. Наличие же роутера предполагает наличие мало-мальски структурированного приложения. В котором слой работы с БД отделен от роутера многими другими слоями. И к моменту, когда надо исполнять запрос, код не имеет ни малейшего представления о том, откуда взялись данные — из роутера, из POST-а, из БД, из файла, из веб-сервиса стороннего. Больше того — ему это знать и НЕ НАДО. А вот программисту желательно понимать принцип разделения полномочий. Хотя, о чем это я? Программистов среди пользователей похапе — раз-два, и обчёлся.
Получается, чтобы учесть результаты проверки роутером, надо прицеплять к данным какую-то специальную бирочку, мол, «мы тут в роутере проверили, всё чисто — можно в запрос писать напрямую». Разумеется, это будет глупость несусветная. Это заберет ресурсов в сто раз больше, чем сэкономит, и на пустом месте усложнит систему.
Плюс, учитывая, что роутер — не единственный источник данных, получается, что там таких бирочек надо миллион. Учитывая очевидную глупость такого подхода, так никто и не делает. И идея про «всемирно принятую практику разработки» — это исключительно твои эротические фантазии.
Мировая же практика — для любых данных, независимо от их источника, использовать подготовленные выражения. Где вместо самих данных в запросе ставятся метки — плейсхолдеры. Если тебе не хватает ума понять принцип типизованных плейсхолдеров (повсеместно уже пол-века применяемый в функциях семейства printf()) — ничего страшного, пусть будут обычные. Типизация — это всего лишь возможность унифицировать работу с данными различных типов, не раздувая код, давая малограмотному разработчику единый инструмент для любых типов данных. Но внутри у там все равно лежит тот же самый принцип подготовленных выражений (впрочем, судя по твоему последнему каменту, ты даже не понимаешь, что плейсхолдер — это обязательный, ключевой элемент подготовленного выражения, без которого оно бесполезно).
И в итоге, написав «Зачем городить огород из [типизированных] плейсхолдеров?» — и тут же предложив взамен проверку входящих данных! — ты поставил всё с ног на голову — отрицая действительно общепринятую практику, и продвигая левый бессмысленный самопал.
В общем, я надеюсь что ты поумнеешь всё-таки (лет, где-нибудь, через 10), и когда-нибудь поймешь, какую глупость ты тут написал.
Да дело-то ведь не в авторе. А в том что каша в голове. Всё буквально с ног на голову.
Ерунда с входной валидацией у него — это «всемирно принятая практика».
А на самом деле всемирно принятая практика (использование подготовленных выражений) — для него это «зачем городить огород».
Роутинг не имеет отношения к защите от инъекций. Никакого. Больше того — и не должен иметь. Просто исходя из формальной логики. 100%-ю защиту не обеспечит, значит, надо защищать другими средствами. А если мы их используем, то защита роутингом оказывается бессмысленной. Не говоря уже о том что сам роутинг может использовать БД. Это совершенно разные и непересекающиеся области. Тот, кто защищается от инъекций роутингом, будет сидеть в инъекциях по уши.
Защиту от инъекций путем фильтрации входных параметров мы уже проходили — это magic quotes. Не помогло.
Больше того — на первом же слайде в докладе написано, что защищаться вообще не надо. принимать какие-то специальные меры по защите не нужно. Надо просто работать с БД. Средствами для работы с БД, а не парсером УРЛов.
Про типизованные плейсхолдеры в интернете нет практически ничего. Получается, что заявление про «мусолилось то, что на страницах интернета и так полным полно» не соответствует действительности.
Реальный SQL — это в первую очередь тот, который не входит в стандартные методы ORM («фильтры эктиврекорда»). Во вторую — тот, который невозможно воспроизвести билдерами, да.
Вы слушали какой-то другой доклад, а собирались на ещё какой-то, отличный от этих двух :)
Во-первых, это был доклад про SQL-инъекции, поэтому было бы глупо ожидать услышать там про csrf.
Во-вторых, про кастинг там не было ничего. Я не представляю, как можно перепутать приведение типов и форматирование SQL литералов. Это разные вещи.
В-третьих, важно не только само форматирование, но и где и когда оно происходит. magic_quotes тоже «кастовали», но это был эпик фейл.
В-четвертых, если вы считаете, что «роутинг» имеет хоть какое-то отношение к защите от инъекций, то доклад однозначно был провальный, но не потому что в нем не говорилось правильных вещей, а потому что их не получилось донести. Но вина докладчика в этом только частичная — как я говорил выше, пробить скепсис всезнайства и предубеждения очень трудно.
В-пятых, «фильтры эктиврекорда» там вполне упоминались. Когда РСУБД использвется в качестве примитивного key-value storage, эти фильтры прекрасно работают. Но как только нам начинает требоваться реальный SQL, а не примитивный его субсет, фильтры оказываются бесполезны. Об о всех таких случаях, когда «информация, которой полно в интернете» не помогает, и говорилось в докладе.
При этом, увы, сама по себе подача была так себе, без огонька. И у «многоопытных коллег» вполне могли быть обоснованные претензии как к самой информации, так и к её подаче. Но чтобы их понять и пересказать, надо хоть немного разбираться в теме.
При этом никто из «многоопытных коллег» не предлложил до сих пор всеобъемлющего решения, которое бы работало и с «фильтрами эктиврекорда», и с SQL, и с методами квери-билдеров, обеспечивая защиту на всех уровнях.
Странная ситуация складывается — «все всё знают», но единого решения нет. Есть только надерганные из разных источников и зачастую противоречащие друг другу «рекомендации из интернета».
Ну, проблема в том, что с этой позицией действительно трудно спорить.
Меня ты, по сути, еще в том топике на пхпклубе убедил.
Разве что именно что в две итерации сделать — почему собачки очень-очень плохо, а потом почему иногда все-таки можно.
Но у меня нету четкой картинки как это делать.
И плюс непонятно, насколько это вообще востребовано. Судя по настроению масс — не слишком.
Ну, я имел в виду — чью сторону представлять.
Вообще, сдается мне, представление Григория насчет этого диспута может отличаться от представлений других заявленных участников :)
Вообще, в заявках может оказаться любая тема, чисто by design — форма подачи открыта для всех.
А вот дальше уже идет голосование и отбор. Сказать по правде, я только вчера эту заявку обнаружил, и тоже несколько удивился.
Это заблуждение, на самом деле.
Предубеждение вообще мешает воспринимать информацию адекватно, а в данном вопросе, где каждый школьник мнит себя экспертом — и подавно. Когда же доходит до дела — при написании чуть более сложных запросов, чем выборка по первичному ключу, или даже просто при обсуждении связанных вопросов — на свет вываливается фантастическая дремучесть таких «всезнаек». Что, в частности, неоднократно случалось при обсуждении темы здесь, на Хабре.
Как раз в PHP, как языке общего назначения, так делать ни в коем случае нельзя.
Ведь проблема касается только одной ипостаси, РНР-как-шаблонизатора.
правда, для <?=?> оно с одной стороны, идеально подходит, но с другой — настолько ломать обратную совместимость — я думаю, невозможно.
А объекты — штука тонкая. К моменту попытки автоискейпинга объект может ещё не знать, что у него такое свойство есть.
Или вообще его не иметь.
Ну то есть да — если заставить разработчика передавать в шаблон только скаляры и массивы — это работает.
Но, увы, я еще не встречал ни одного, который бы не хотел передать в шаблон объект $user и уже в шаблоне обращаться к его свойствам/методам. Хотя сам считаю это порочной практикой.
Кто-то стал решать, но не зная технологии, насовал в _e() кучу бесполензного мусора.
Кто-то вообще не знал, что что-то решать надо.
Кто-то знал, да забыл.
В общем — типичный «пхп-стайл», и типичный же результат, ЕВПОЧЯ.
Я не зря привел аналогию с SQL — там эти баталии на тему «легко решается» уже (надеюсь) отгремели, и все согласились наконец-то, что ручное экранирование должно быть забыто как страшный сон.
то есть, всё должно быть наоборот — в Laravel пишем {{{ }}} по дефолту, а можно написать {{ }}, если надо вывести данные как есть. А вообще определять вывод количеством скобочек — это мина замедленного действия
Эта ерунда с подсчетом скобочек еще аукнется многочисленными XSS-ами.
Те же, которые вышли, или сами понимают сильные и слабые стороны движка безо всякой рекламы, либо вообще пилят большой портал на собственном софте, и им поп-фреймворки перпендикулярны.
А так-то да — ORM и роутенг преподносятся прям как исключительные заслуги Лярвы, и чуть фанфары из каждого абзаца не играют.
А это, пожалуй, в шаблонизаторе главное.
«приятный синтаксис», «экономия целых двух символов на оператор» — это всё ерунда. А вот собственный оператор вывода, которым можно управлять — это очень, очень важно.
Ведь на самом деле в нейтив должно быть что-то вроде
— а с таким довеском идея как-то уже меркнет.
В какой-то мере можно рассматривать {{ $order->title }} как аналог плейсхолдера в SQL. А <?=$order->title ?>, соответственно — как прямую интерполяцию, со всеми вытекающими.
Хотя заранее уверен, что не получится — уж больно случай запущенный.
Любая проверка входящих данных не имеет ни малейшего отношения к работе с БД.
Ну, то есть, в типичном похапе-стайл говнокоде, где «роутер» — это if (isset($_POST['submit'])), после которого данные сразу же пихаются в mysql_query — тут вполне возможно визуально проконтролировать, что попадающие в запрос данные были проверены некой кривой регуляркой. Но так, вообще-то, никто давно не пишет.
Ты и сам упомянул роутер — за язык тебя никто не тянул. Наличие же роутера предполагает наличие мало-мальски структурированного приложения. В котором слой работы с БД отделен от роутера многими другими слоями. И к моменту, когда надо исполнять запрос, код не имеет ни малейшего представления о том, откуда взялись данные — из роутера, из POST-а, из БД, из файла, из веб-сервиса стороннего. Больше того — ему это знать и НЕ НАДО. А вот программисту желательно понимать принцип разделения полномочий. Хотя, о чем это я? Программистов среди пользователей похапе — раз-два, и обчёлся.
Получается, чтобы учесть результаты проверки роутером, надо прицеплять к данным какую-то специальную бирочку, мол, «мы тут в роутере проверили, всё чисто — можно в запрос писать напрямую». Разумеется, это будет глупость несусветная. Это заберет ресурсов в сто раз больше, чем сэкономит, и на пустом месте усложнит систему.
Плюс, учитывая, что роутер — не единственный источник данных, получается, что там таких бирочек надо миллион. Учитывая очевидную глупость такого подхода, так никто и не делает. И идея про «всемирно принятую практику разработки» — это исключительно твои эротические фантазии.
Мировая же практика — для любых данных, независимо от их источника, использовать подготовленные выражения. Где вместо самих данных в запросе ставятся метки — плейсхолдеры. Если тебе не хватает ума понять принцип типизованных плейсхолдеров (повсеместно уже пол-века применяемый в функциях семейства printf()) — ничего страшного, пусть будут обычные. Типизация — это всего лишь возможность унифицировать работу с данными различных типов, не раздувая код, давая малограмотному разработчику единый инструмент для любых типов данных. Но внутри у там все равно лежит тот же самый принцип подготовленных выражений (впрочем, судя по твоему последнему каменту, ты даже не понимаешь, что плейсхолдер — это обязательный, ключевой элемент подготовленного выражения, без которого оно бесполезно).
И в итоге, написав «Зачем городить огород из [типизированных] плейсхолдеров?» — и тут же предложив взамен проверку входящих данных! — ты поставил всё с ног на голову — отрицая действительно общепринятую практику, и продвигая левый бессмысленный самопал.
В общем, я надеюсь что ты поумнеешь всё-таки (лет, где-нибудь, через 10), и когда-нибудь поймешь, какую глупость ты тут написал.
Ерунда с входной валидацией у него — это «всемирно принятая практика».
А на самом деле всемирно принятая практика (использование подготовленных выражений) — для него это «зачем городить огород».
Вам логику надо учить, молодой человек. Формальную.
Ну, и читать ещё желательно научиться.
А доклад и вправду провальный. Если после него такая разруха в голове осталась — то действительно, это эпик фейл.
Защиту от инъекций путем фильтрации входных параметров мы уже проходили — это magic quotes. Не помогло.
Больше того — на первом же слайде в докладе написано, что защищаться вообще не надо. принимать какие-то специальные меры по защите не нужно. Надо просто работать с БД. Средствами для работы с БД, а не парсером УРЛов.
Про типизованные плейсхолдеры в интернете нет практически ничего. Получается, что заявление про «мусолилось то, что на страницах интернета и так полным полно» не соответствует действительности.
Реальный SQL — это в первую очередь тот, который не входит в стандартные методы ORM («фильтры эктиврекорда»). Во вторую — тот, который невозможно воспроизвести билдерами, да.
Во-первых, это был доклад про SQL-инъекции, поэтому было бы глупо ожидать услышать там про csrf.
Во-вторых, про кастинг там не было ничего. Я не представляю, как можно перепутать приведение типов и форматирование SQL литералов. Это разные вещи.
В-третьих, важно не только само форматирование, но и где и когда оно происходит. magic_quotes тоже «кастовали», но это был эпик фейл.
В-четвертых, если вы считаете, что «роутинг» имеет хоть какое-то отношение к защите от инъекций, то доклад однозначно был провальный, но не потому что в нем не говорилось правильных вещей, а потому что их не получилось донести. Но вина докладчика в этом только частичная — как я говорил выше, пробить скепсис всезнайства и предубеждения очень трудно.
В-пятых, «фильтры эктиврекорда» там вполне упоминались. Когда РСУБД использвется в качестве примитивного key-value storage, эти фильтры прекрасно работают. Но как только нам начинает требоваться реальный SQL, а не примитивный его субсет, фильтры оказываются бесполезны. Об о всех таких случаях, когда «информация, которой полно в интернете» не помогает, и говорилось в докладе.
При этом, увы, сама по себе подача была так себе, без огонька. И у «многоопытных коллег» вполне могли быть обоснованные претензии как к самой информации, так и к её подаче. Но чтобы их понять и пересказать, надо хоть немного разбираться в теме.
При этом никто из «многоопытных коллег» не предлложил до сих пор всеобъемлющего решения, которое бы работало и с «фильтрами эктиврекорда», и с SQL, и с методами квери-билдеров, обеспечивая защиту на всех уровнях.
Странная ситуация складывается — «все всё знают», но единого решения нет. Есть только надерганные из разных источников и зачастую противоречащие друг другу «рекомендации из интернета».
Меня ты, по сути, еще в том топике на пхпклубе убедил.
Разве что именно что в две итерации сделать — почему собачки очень-очень плохо, а потом почему иногда все-таки можно.
Но у меня нету четкой картинки как это делать.
И плюс непонятно, насколько это вообще востребовано. Судя по настроению масс — не слишком.
Вообще, сдается мне, представление Григория насчет этого диспута может отличаться от представлений других заявленных участников :)
А вот дальше уже идет голосование и отбор. Сказать по правде, я только вчера эту заявку обнаружил, и тоже несколько удивился.
Я, правда, не уверен в общей реализуемости затеи.
Предубеждение вообще мешает воспринимать информацию адекватно, а в данном вопросе, где каждый школьник мнит себя экспертом — и подавно. Когда же доходит до дела — при написании чуть более сложных запросов, чем выборка по первичному ключу, или даже просто при обсуждении связанных вопросов — на свет вываливается фантастическая дремучесть таких «всезнаек». Что, в частности, неоднократно случалось при обсуждении темы здесь, на Хабре.