Комментарии 37
Хотеть!
+2
Иду, на этот раз — уже не один. :) В прошлый раз местами «зажгли» только так, понравилось. Главное — боевого настроя потом хватило надолго, вспыхнул интерес к изучению чего-то нового. Жаль только, что Фабьен Потенсьер отказался заехать.
+3
За 5000 рублей можно было и что-то более серьёзное подготовить, имхо. На девконфе 2013 года практически ничего нового не узнал, хотя Laravel и архитектура игровых движков подкупают…
0
Это еще не все — пока подано 33-50% заявок. Многие докладчики еще думают, знают что уровень серьезный — и с халтурой заявка не пройдет :-)
0
Я помню как в прошлом году было выступление в PHP секции про sql инъекции, где 70% были советы откровенно для совсем начинающих, а остальные 30% — скорее как не надо делать. Скрещу пальцы, что бы в этом году подобного халатства не было =)
0
Это заблуждение, на самом деле.
Предубеждение вообще мешает воспринимать информацию адекватно, а в данном вопросе, где каждый школьник мнит себя экспертом — и подавно. Когда же доходит до дела — при написании чуть более сложных запросов, чем выборка по первичному ключу, или даже просто при обсуждении связанных вопросов — на свет вываливается фантастическая дремучесть таких «всезнаек». Что, в частности, неоднократно случалось при обсуждении темы здесь, на Хабре.
Предубеждение вообще мешает воспринимать информацию адекватно, а в данном вопросе, где каждый школьник мнит себя экспертом — и подавно. Когда же доходит до дела — при написании чуть более сложных запросов, чем выборка по первичному ключу, или даже просто при обсуждении связанных вопросов — на свет вываливается фантастическая дремучесть таких «всезнаек». Что, в частности, неоднократно случалось при обсуждении темы здесь, на Хабре.
+2
Заблуждение по поводу чего?
Весь час доклада мусолилось то, что на страницах интернета и так полным полно, а весь доклад можно сократить до одного предложения: «кастуйте данные к определённому типу». Что нового я узнал (и многоопытные коллеги с конференции) из этого? Главное то, что не было ни одного упоминания фильтров эктиврекорда и простого роутинга.
Я бы ещё мог понять, если бы рассказывали о безопасности в целом, о csrf токенах, о блокировки открытия сайта в айфреймах и прочем.
Для того, что бы не быть голословным, вот его доклад: 2013.devconf.ru/data/2013/presentation/24.pdf
Весь час доклада мусолилось то, что на страницах интернета и так полным полно, а весь доклад можно сократить до одного предложения: «кастуйте данные к определённому типу». Что нового я узнал (и многоопытные коллеги с конференции) из этого? Главное то, что не было ни одного упоминания фильтров эктиврекорда и простого роутинга.
Я бы ещё мог понять, если бы рассказывали о безопасности в целом, о csrf токенах, о блокировки открытия сайта в айфреймах и прочем.
Для того, что бы не быть голословным, вот его доклад: 2013.devconf.ru/data/2013/presentation/24.pdf
0
Вы слушали какой-то другой доклад, а собирались на ещё какой-то, отличный от этих двух :)
Во-первых, это был доклад про SQL-инъекции, поэтому было бы глупо ожидать услышать там про csrf.
Во-вторых, про кастинг там не было ничего. Я не представляю, как можно перепутать приведение типов и форматирование SQL литералов. Это разные вещи.
В-третьих, важно не только само форматирование, но и где и когда оно происходит. magic_quotes тоже «кастовали», но это был эпик фейл.
В-четвертых, если вы считаете, что «роутинг» имеет хоть какое-то отношение к защите от инъекций, то доклад однозначно был провальный, но не потому что в нем не говорилось правильных вещей, а потому что их не получилось донести. Но вина докладчика в этом только частичная — как я говорил выше, пробить скепсис всезнайства и предубеждения очень трудно.
В-пятых, «фильтры эктиврекорда» там вполне упоминались. Когда РСУБД использвется в качестве примитивного key-value storage, эти фильтры прекрасно работают. Но как только нам начинает требоваться реальный SQL, а не примитивный его субсет, фильтры оказываются бесполезны. Об о всех таких случаях, когда «информация, которой полно в интернете» не помогает, и говорилось в докладе.
При этом, увы, сама по себе подача была так себе, без огонька. И у «многоопытных коллег» вполне могли быть обоснованные претензии как к самой информации, так и к её подаче. Но чтобы их понять и пересказать, надо хоть немного разбираться в теме.
При этом никто из «многоопытных коллег» не предлложил до сих пор всеобъемлющего решения, которое бы работало и с «фильтрами эктиврекорда», и с SQL, и с методами квери-билдеров, обеспечивая защиту на всех уровнях.
Странная ситуация складывается — «все всё знают», но единого решения нет. Есть только надерганные из разных источников и зачастую противоречащие друг другу «рекомендации из интернета».
Во-первых, это был доклад про SQL-инъекции, поэтому было бы глупо ожидать услышать там про csrf.
Во-вторых, про кастинг там не было ничего. Я не представляю, как можно перепутать приведение типов и форматирование SQL литералов. Это разные вещи.
В-третьих, важно не только само форматирование, но и где и когда оно происходит. magic_quotes тоже «кастовали», но это был эпик фейл.
В-четвертых, если вы считаете, что «роутинг» имеет хоть какое-то отношение к защите от инъекций, то доклад однозначно был провальный, но не потому что в нем не говорилось правильных вещей, а потому что их не получилось донести. Но вина докладчика в этом только частичная — как я говорил выше, пробить скепсис всезнайства и предубеждения очень трудно.
В-пятых, «фильтры эктиврекорда» там вполне упоминались. Когда РСУБД использвется в качестве примитивного key-value storage, эти фильтры прекрасно работают. Но как только нам начинает требоваться реальный SQL, а не примитивный его субсет, фильтры оказываются бесполезны. Об о всех таких случаях, когда «информация, которой полно в интернете» не помогает, и говорилось в докладе.
При этом, увы, сама по себе подача была так себе, без огонька. И у «многоопытных коллег» вполне могли быть обоснованные претензии как к самой информации, так и к её подаче. Но чтобы их понять и пересказать, надо хоть немного разбираться в теме.
При этом никто из «многоопытных коллег» не предлложил до сих пор всеобъемлющего решения, которое бы работало и с «фильтрами эктиврекорда», и с SQL, и с методами квери-билдеров, обеспечивая защиту на всех уровнях.
Странная ситуация складывается — «все всё знают», но единого решения нет. Есть только надерганные из разных источников и зачастую противоречащие друг другу «рекомендации из интернета».
+1
Возможно вы правы, возможно нет. В любом случае спорить не буду, т.к. это моё личное и от этого субъективное мнение.
Пример с csrf\фреймами — это пример того, о чём действительно не задумываются зачастую, проектируя ресурс, и что было бы действительно интереснее в плане получения опыта.
И да, я считаю что грамотный роутинг — это как-минимум 50% защиты от любых инъекций, т.к. он и типы проверяет и валидность строки по регулярке (или псевдо-регулярке), а при ошибке просто отредиректит на 404.
Не понимаю что значит реальный SQL? Это SQL, где больше 255 символов? Или SQL, который невозможно воспроизвести билдерами?
З.Ы. Под кастингом я имел ввиду типизированные плейсхолдеры, не верно выразился.
Пример с csrf\фреймами — это пример того, о чём действительно не задумываются зачастую, проектируя ресурс, и что было бы действительно интереснее в плане получения опыта.
И да, я считаю что грамотный роутинг — это как-минимум 50% защиты от любых инъекций, т.к. он и типы проверяет и валидность строки по регулярке (или псевдо-регулярке), а при ошибке просто отредиректит на 404.
Не понимаю что значит реальный SQL? Это SQL, где больше 255 символов? Или SQL, который невозможно воспроизвести билдерами?
З.Ы. Под кастингом я имел ввиду типизированные плейсхолдеры, не верно выразился.
+1
Роутинг не имеет отношения к защите от инъекций. Никакого. Больше того — и не должен иметь. Просто исходя из формальной логики. 100%-ю защиту не обеспечит, значит, надо защищать другими средствами. А если мы их используем, то защита роутингом оказывается бессмысленной. Не говоря уже о том что сам роутинг может использовать БД. Это совершенно разные и непересекающиеся области. Тот, кто защищается от инъекций роутингом, будет сидеть в инъекциях по уши.
Защиту от инъекций путем фильтрации входных параметров мы уже проходили — это magic quotes. Не помогло.
Больше того — на первом же слайде в докладе написано, что защищаться вообще не надо. принимать какие-то специальные меры по защите не нужно. Надо просто работать с БД. Средствами для работы с БД, а не парсером УРЛов.
Про типизованные плейсхолдеры в интернете нет практически ничего. Получается, что заявление про «мусолилось то, что на страницах интернета и так полным полно» не соответствует действительности.
Реальный SQL — это в первую очередь тот, который не входит в стандартные методы ORM («фильтры эктиврекорда»). Во вторую — тот, который невозможно воспроизвести билдерами, да.
Защиту от инъекций путем фильтрации входных параметров мы уже проходили — это magic quotes. Не помогло.
Больше того — на первом же слайде в докладе написано, что защищаться вообще не надо. принимать какие-то специальные меры по защите не нужно. Надо просто работать с БД. Средствами для работы с БД, а не парсером УРЛов.
Про типизованные плейсхолдеры в интернете нет практически ничего. Получается, что заявление про «мусолилось то, что на страницах интернета и так полным полно» не соответствует действительности.
Реальный SQL — это в первую очередь тот, который не входит в стандартные методы ORM («фильтры эктиврекорда»). Во вторую — тот, который невозможно воспроизвести билдерами, да.
0
<irоny>Конечно роутинг не имеет никакого отношения к защите от sql инъекций… А то, что мы указали в адресе /books/:id, где id только числовой ([0-9]+) и потом получаем в контроллере модель с этим id — это так, баловство. Оно не защитит от того, что пользователь вместо числа введёт строку, да ведь?
А то, что на этапе проверки какой-нибудь почты мы добавляем к ней фильтр почты и при ошибке возвращаем сообщение об ошибке не гарантирует того, что почта это именно почта и сквозь фильтр у нас вполне может просочится DROP TABLE students;, это ведь так похоже на email адрес.
И главное, что ничего работать не будет, т.к. sql у нас невозможно сгенерировать билдером!</irоny>
Извините, но пока что не убедительно, т.к. приходилось работать и не с таким и пока никаких проблем не бывало.
А то, что на этапе проверки какой-нибудь почты мы добавляем к ней фильтр почты и при ошибке возвращаем сообщение об ошибке не гарантирует того, что почта это именно почта и сквозь фильтр у нас вполне может просочится DROP TABLE students;, это ведь так похоже на email адрес.
И главное, что ничего работать не будет, т.к. sql у нас невозможно сгенерировать билдером!</irоny>
Извините, но пока что не убедительно, т.к. приходилось работать и не с таким и пока никаких проблем не бывало.
0
У, как всё запущено. Вам с инъекциями ещё рано.
Вам логику надо учить, молодой человек. Формальную.
Ну, и читать ещё желательно научиться.
А доклад и вправду провальный. Если после него такая разруха в голове осталась — то действительно, это эпик фейл.
Вам логику надо учить, молодой человек. Формальную.
Ну, и читать ещё желательно научиться.
А доклад и вправду провальный. Если после него такая разруха в голове осталась — то действительно, это эпик фейл.
0
Мы говорим о конечном продукте, а не о прямом доступе к базе данных из консоли браузера — тут уж никакой роутинг не спасёт.
И не стоит хамить пожалуйста, даже столь завуалированно. Лучше доходчиво объясните почему следования двум правилам — отсечение внешних данных роутингом и проверка значений фильтрами не убережёт от sql-инъекций. Зачем городить огород из типизированных плейсхолдеров?
И не стоит хамить пожалуйста, даже столь завуалированно. Лучше доходчиво объясните почему следования двум правилам — отсечение внешних данных роутингом и проверка значений фильтрами не убережёт от sql-инъекций. Зачем городить огород из типизированных плейсхолдеров?
0
Вы ведь уже поняли, что спорите с автором того доклада?
+2
Спорю потому, что мог упустить какую-то тонкость, например какие-либо невидимые юникод-последовательности, которые могут пройти сквозь регулярку вида [a-z]+@[a-z_\.]+\.[a-z] (это только пример) и натворить гадостей, а волшебные плейсхолдеры спасут от этого. Вроде я уже раз 10 это написал, но как таковых примеров ошибочной уверенности во всемирно принятой практике разработки (не включающей магические типизированные плейсхолдеры) — не увидел =(
0
Да дело-то ведь не в авторе. А в том что каша в голове. Всё буквально с ног на голову.
Ерунда с входной валидацией у него — это «всемирно принятая практика».
А на самом деле всемирно принятая практика (использование подготовленных выражений) — для него это «зачем городить огород».
Ерунда с входной валидацией у него — это «всемирно принятая практика».
А на самом деле всемирно принятая практика (использование подготовленных выражений) — для него это «зачем городить огород».
0
Пожалуйста не надо приплетать ваши домыслы к моим словам, я написал то, что написал, а не то, что вы пытаетесь пропихнуть за моё мнение.
Написано то, что кастинг в плейсхолдерах — это идиотизм, не больше — ни меньше и про prepared statments ни одного слова. Учитывая то, что не было ни одного примера того, что кастинг спасает лучше, нежели приведённые мною трижды примеры — смею высказать мнение о том, что вы намеренно уклоняетесь от прямого ответа и просто решили потрепать языком.
За сим заканчиваю диалог, т.к. не вижу смысла далее выслушивать ваш сарказм и троллинг.
Написано то, что кастинг в плейсхолдерах — это идиотизм, не больше — ни меньше и про prepared statments ни одного слова. Учитывая то, что не было ни одного примера того, что кастинг спасает лучше, нежели приведённые мною трижды примеры — смею высказать мнение о том, что вы намеренно уклоняетесь от прямого ответа и просто решили потрепать языком.
За сим заканчиваю диалог, т.к. не вижу смысла далее выслушивать ваш сарказм и троллинг.
0
Ладно, так и быть, я попробую один раз.
Хотя заранее уверен, что не получится — уж больно случай запущенный.
Любая проверка входящих данных не имеет ни малейшего отношения к работе с БД.
Ну, то есть, в типичном похапе-стайл говнокоде, где «роутер» — это if (isset($_POST['submit'])), после которого данные сразу же пихаются в mysql_query — тут вполне возможно визуально проконтролировать, что попадающие в запрос данные были проверены некой кривой регуляркой. Но так, вообще-то, никто давно не пишет.
Ты и сам упомянул роутер — за язык тебя никто не тянул. Наличие же роутера предполагает наличие мало-мальски структурированного приложения. В котором слой работы с БД отделен от роутера многими другими слоями. И к моменту, когда надо исполнять запрос, код не имеет ни малейшего представления о том, откуда взялись данные — из роутера, из POST-а, из БД, из файла, из веб-сервиса стороннего. Больше того — ему это знать и НЕ НАДО. А вот программисту желательно понимать принцип разделения полномочий. Хотя, о чем это я? Программистов среди пользователей похапе — раз-два, и обчёлся.
Получается, чтобы учесть результаты проверки роутером, надо прицеплять к данным какую-то специальную бирочку, мол, «мы тут в роутере проверили, всё чисто — можно в запрос писать напрямую». Разумеется, это будет глупость несусветная. Это заберет ресурсов в сто раз больше, чем сэкономит, и на пустом месте усложнит систему.
Плюс, учитывая, что роутер — не единственный источник данных, получается, что там таких бирочек надо миллион. Учитывая очевидную глупость такого подхода, так никто и не делает. И идея про «всемирно принятую практику разработки» — это исключительно твои эротические фантазии.
Мировая же практика — для любых данных, независимо от их источника, использовать подготовленные выражения. Где вместо самих данных в запросе ставятся метки — плейсхолдеры. Если тебе не хватает ума понять принцип типизованных плейсхолдеров (повсеместно уже пол-века применяемый в функциях семейства printf()) — ничего страшного, пусть будут обычные. Типизация — это всего лишь возможность унифицировать работу с данными различных типов, не раздувая код, давая малограмотному разработчику единый инструмент для любых типов данных. Но внутри у там все равно лежит тот же самый принцип подготовленных выражений (впрочем, судя по твоему последнему каменту, ты даже не понимаешь, что плейсхолдер — это обязательный, ключевой элемент подготовленного выражения, без которого оно бесполезно).
И в итоге, написав «Зачем городить огород из [типизированных] плейсхолдеров?» — и тут же предложив взамен проверку входящих данных! — ты поставил всё с ног на голову — отрицая действительно общепринятую практику, и продвигая левый бессмысленный самопал.
В общем, я надеюсь что ты поумнеешь всё-таки (лет, где-нибудь, через 10), и когда-нибудь поймешь, какую глупость ты тут написал.
Хотя заранее уверен, что не получится — уж больно случай запущенный.
Любая проверка входящих данных не имеет ни малейшего отношения к работе с БД.
Ну, то есть, в типичном похапе-стайл говнокоде, где «роутер» — это if (isset($_POST['submit'])), после которого данные сразу же пихаются в mysql_query — тут вполне возможно визуально проконтролировать, что попадающие в запрос данные были проверены некой кривой регуляркой. Но так, вообще-то, никто давно не пишет.
Ты и сам упомянул роутер — за язык тебя никто не тянул. Наличие же роутера предполагает наличие мало-мальски структурированного приложения. В котором слой работы с БД отделен от роутера многими другими слоями. И к моменту, когда надо исполнять запрос, код не имеет ни малейшего представления о том, откуда взялись данные — из роутера, из POST-а, из БД, из файла, из веб-сервиса стороннего. Больше того — ему это знать и НЕ НАДО. А вот программисту желательно понимать принцип разделения полномочий. Хотя, о чем это я? Программистов среди пользователей похапе — раз-два, и обчёлся.
Получается, чтобы учесть результаты проверки роутером, надо прицеплять к данным какую-то специальную бирочку, мол, «мы тут в роутере проверили, всё чисто — можно в запрос писать напрямую». Разумеется, это будет глупость несусветная. Это заберет ресурсов в сто раз больше, чем сэкономит, и на пустом месте усложнит систему.
Плюс, учитывая, что роутер — не единственный источник данных, получается, что там таких бирочек надо миллион. Учитывая очевидную глупость такого подхода, так никто и не делает. И идея про «всемирно принятую практику разработки» — это исключительно твои эротические фантазии.
Мировая же практика — для любых данных, независимо от их источника, использовать подготовленные выражения. Где вместо самих данных в запросе ставятся метки — плейсхолдеры. Если тебе не хватает ума понять принцип типизованных плейсхолдеров (повсеместно уже пол-века применяемый в функциях семейства printf()) — ничего страшного, пусть будут обычные. Типизация — это всего лишь возможность унифицировать работу с данными различных типов, не раздувая код, давая малограмотному разработчику единый инструмент для любых типов данных. Но внутри у там все равно лежит тот же самый принцип подготовленных выражений (впрочем, судя по твоему последнему каменту, ты даже не понимаешь, что плейсхолдер — это обязательный, ключевой элемент подготовленного выражения, без которого оно бесполезно).
И в итоге, написав «Зачем городить огород из [типизированных] плейсхолдеров?» — и тут же предложив взамен проверку входящих данных! — ты поставил всё с ног на голову — отрицая действительно общепринятую практику, и продвигая левый бессмысленный самопал.
В общем, я надеюсь что ты поумнеешь всё-таки (лет, где-нибудь, через 10), и когда-нибудь поймешь, какую глупость ты тут написал.
0
Темой одной из заявок на конференцию является конфликт вокруг оператора @. Кто-нибудь в курсе, кто какую точку зрения отстаивает?
+2
Я не за собак, я за гармонию и баланс :)
+2
Если вы в целом против собак, но считаете целесообразным использование их в исключительных случаях, например в процессе записи лога в файл, как это сделано в Yii, то с такой точкой зрения очень сложно спорить. В таком случае странно, что тема вообще оказалась в заявках на devconf.
0
Ну, я имел в виду — чью сторону представлять.
Вообще, сдается мне, представление Григория насчет этого диспута может отличаться от представлений других заявленных участников :)
Вообще, сдается мне, представление Григория насчет этого диспута может отличаться от представлений других заявленных участников :)
+1
Григорий спросил, смогу ли я выразить публично свою точку зрения на собачек и хорошо её аргументировать, я согласился.
0
Ну, проблема в том, что с этой позицией действительно трудно спорить.
Меня ты, по сути, еще в том топике на пхпклубе убедил.
Разве что именно что в две итерации сделать — почему собачки очень-очень плохо, а потом почему иногда все-таки можно.
Но у меня нету четкой картинки как это делать.
И плюс непонятно, насколько это вообще востребовано. Судя по настроению масс — не слишком.
Меня ты, по сути, еще в том топике на пхпклубе убедил.
Разве что именно что в две итерации сделать — почему собачки очень-очень плохо, а потом почему иногда все-таки можно.
Но у меня нету четкой картинки как это делать.
И плюс непонятно, насколько это вообще востребовано. Судя по настроению масс — не слишком.
0
Кто хочет пойти проставьте тут — интересно сколько из 1000 участников читает хабр
habrahabr.ru/company/devconf/events/4921/
habrahabr.ru/company/devconf/events/4921/
+3
А розыгрыши билетов будут как в прошом году от Badoo со слонами? А то для провинции накладно 5к + билеты до Москвы.
0
Конечно будут — подпишитесь на
twitter.com/devconf_ru
vk.com/devconf
www.facebook.com/groups/devconf/
для полного информирования…
+ конкурс значков и футболок сделаем :-)
twitter.com/devconf_ru
vk.com/devconf
www.facebook.com/groups/devconf/
для полного информирования…
+ конкурс значков и футболок сделаем :-)
+3
Интересует программа второго дня, ибо fisher в 2013м втором год подряд одно и тоже рассказывал. Ожидаю от баду прям такого ухх, как в 2012.
0
SonkoDmitry,
По второму дню — подтвержденные мастер-классы можно увидеть здесь
devconf.ru/mk
P.S. Fisher — не подавал заявку в этом году. Учитывая тренд в развитии секции Storage — будет что-то по нему.
Будет интересный мк по управлению командой (ведем переговоры) — хороший МК требует хорошей подготовки…
По второму дню — подтвержденные мастер-классы можно увидеть здесь
devconf.ru/mk
P.S. Fisher — не подавал заявку в этом году. Учитывая тренд в развитии секции Storage — будет что-то по нему.
Будет интересный мк по управлению командой (ведем переговоры) — хороший МК требует хорошей подготовки…
0
Не рекламы ради, а просто мнение!
В этом году будет снова Дмитрий Бородин мастер-класс давать. Скорее всего это будет то же самое что и в прошлом году, но если не были, то думаю посетив не пожалеете! Сам лично пересмотрел после его мастер-класса взгляды на то как проектировать приложения. Много для себя почерпнул.
IMHO.
На прошлом DevConf больше всего мне запомнились доклады Александра Календарева, Сергея Мартыненко и мастер-класс Дмитрия Бородина.
В этом году будет снова Дмитрий Бородин мастер-класс давать. Скорее всего это будет то же самое что и в прошлом году, но если не были, то думаю посетив не пожалеете! Сам лично пересмотрел после его мастер-класса взгляды на то как проектировать приложения. Много для себя почерпнул.
IMHO.
На прошлом DevConf больше всего мне запомнились доклады Александра Календарева, Сергея Мартыненко и мастер-класс Дмитрия Бородина.
0
А есть тезисы доклада про асинхронный php?
+1
Асинхронный PHP — миф? Реальность!
devconf.ru/offers/14
devconf.ru/offers/14
0
Был в 2012 – супер! В этом году похоже намечается отличное событие.
+1
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
DevConf 2014 пройдет 14 июня в Москве — соберутся более 1000 разработчиков из сообществ