Роутинг не имеет отношения к защите от инъекций. Никакого. Больше того — и не должен иметь. Просто исходя из формальной логики. 100%-ю защиту не обеспечит, значит, надо защищать другими средствами. А если мы их используем, то защита роутингом оказывается бессмысленной. Не говоря уже о том что сам роутинг может использовать БД. Это совершенно разные и непересекающиеся области. Тот, кто защищается от инъекций роутингом, будет сидеть в инъекциях по уши.
Защиту от инъекций путем фильтрации входных параметров мы уже проходили — это magic quotes. Не помогло.
Больше того — на первом же слайде в докладе написано, что защищаться вообще не надо. принимать какие-то специальные меры по защите не нужно. Надо просто работать с БД. Средствами для работы с БД, а не парсером УРЛов.
Про типизованные плейсхолдеры в интернете нет практически ничего. Получается, что заявление про «мусолилось то, что на страницах интернета и так полным полно» не соответствует действительности.
Реальный SQL — это в первую очередь тот, который не входит в стандартные методы ORM («фильтры эктиврекорда»). Во вторую — тот, который невозможно воспроизвести билдерами, да.
Вы слушали какой-то другой доклад, а собирались на ещё какой-то, отличный от этих двух :)
Во-первых, это был доклад про SQL-инъекции, поэтому было бы глупо ожидать услышать там про csrf.
Во-вторых, про кастинг там не было ничего. Я не представляю, как можно перепутать приведение типов и форматирование SQL литералов. Это разные вещи.
В-третьих, важно не только само форматирование, но и где и когда оно происходит. magic_quotes тоже «кастовали», но это был эпик фейл.
В-четвертых, если вы считаете, что «роутинг» имеет хоть какое-то отношение к защите от инъекций, то доклад однозначно был провальный, но не потому что в нем не говорилось правильных вещей, а потому что их не получилось донести. Но вина докладчика в этом только частичная — как я говорил выше, пробить скепсис всезнайства и предубеждения очень трудно.
В-пятых, «фильтры эктиврекорда» там вполне упоминались. Когда РСУБД использвется в качестве примитивного key-value storage, эти фильтры прекрасно работают. Но как только нам начинает требоваться реальный SQL, а не примитивный его субсет, фильтры оказываются бесполезны. Об о всех таких случаях, когда «информация, которой полно в интернете» не помогает, и говорилось в докладе.
При этом, увы, сама по себе подача была так себе, без огонька. И у «многоопытных коллег» вполне могли быть обоснованные претензии как к самой информации, так и к её подаче. Но чтобы их понять и пересказать, надо хоть немного разбираться в теме.
При этом никто из «многоопытных коллег» не предлложил до сих пор всеобъемлющего решения, которое бы работало и с «фильтрами эктиврекорда», и с SQL, и с методами квери-билдеров, обеспечивая защиту на всех уровнях.
Странная ситуация складывается — «все всё знают», но единого решения нет. Есть только надерганные из разных источников и зачастую противоречащие друг другу «рекомендации из интернета».
Ну, проблема в том, что с этой позицией действительно трудно спорить.
Меня ты, по сути, еще в том топике на пхпклубе убедил.
Разве что именно что в две итерации сделать — почему собачки очень-очень плохо, а потом почему иногда все-таки можно.
Но у меня нету четкой картинки как это делать.
И плюс непонятно, насколько это вообще востребовано. Судя по настроению масс — не слишком.
Ну, я имел в виду — чью сторону представлять.
Вообще, сдается мне, представление Григория насчет этого диспута может отличаться от представлений других заявленных участников :)
Вообще, в заявках может оказаться любая тема, чисто by design — форма подачи открыта для всех.
А вот дальше уже идет голосование и отбор. Сказать по правде, я только вчера эту заявку обнаружил, и тоже несколько удивился.
Это заблуждение, на самом деле.
Предубеждение вообще мешает воспринимать информацию адекватно, а в данном вопросе, где каждый школьник мнит себя экспертом — и подавно. Когда же доходит до дела — при написании чуть более сложных запросов, чем выборка по первичному ключу, или даже просто при обсуждении связанных вопросов — на свет вываливается фантастическая дремучесть таких «всезнаек». Что, в частности, неоднократно случалось при обсуждении темы здесь, на Хабре.
С чисто практической точки зрения я скорее согласен с этим утверждением.
Но с методологической, или, даже — философской…
— Уже есть один отличный, проверенный временем тип орудий. Им разделывают шкуры мамонтов, рубят деревья, убивают зверей на охоте. Ну зачем ещё увеличивать энтропию и делать из блестящего, но бесполезного металла, который задумывался исключительно для украшений, вот такого франкенштейна?
На самом деле пути эволюции неисповедимы. В мире разработаки она, собственно, только и держится на энтузиазме. И это прекрасно. Без проб и ошибок нет и развития. При этом никто не может предсказать, что получится в итоге. Никто. В этом-то и прелесть. Поэтому обязательно надо пробовать новое. Разумеется, некоторые ростки обязательно окажутся тупиковыми. Ничего страшного — это так и задумано. Важно понимать, что без тупиковых ветвей не бывает прорывов. Так что безумству храбрых стоит петь песню, а не держать их за штаны и не пущать.
PS. Ну зачем ещё увеличивать энтропию и делать из Perl, который задумывался для совсем других целей, вот такого франкенштейна — набор утилит Pretty Home Page / Form Interpreter? ;)
Я не большой спец в серверах, но куда там дуют вентиляторы?
Судя по фото — в глухую крышку, закрывающую процессорный отсек. Это так и задумано или я чего-то очевидного не понимаю в конструкции?
Запрос в любом случае будет один.
Если речь об обращении к функциям API, то никак — обращений будет два.
Первый оператор выполнит запрос, а второй получит id
Противоречий тут очень много.
Начиная с того, что комментаторы при упоминании сложного пароля тут же начинают воображать себе злой сайт с дубинкой. И начинают спорить с этим воображаемым сайтом. При этом минусуя комментарий, в котором не было ни слова ни про сайт, ни про дубинку.
«Сайтами, которые вымогают регистрацию» интернет не ограничивается. Рассказывать про одни сайты и умалчивать в своем комментарии о других — это или шулерство или глупость.
Это уже вторая статья, которая претендует на роль всеобъемлющего руководства по хэшированию. И в ней тоже не упоминается такой важный элемент, как стойкость пароля.
«Сайт не должен обеспечивать безопасность тем пользователям, кому она нафиг не сдалась» — это тоже очень смешное высказывание. Для аудитории хабра вполне годится, но для дискуссии о безопасности, увы — нет.
Удивительно. Почему-то у среднего хабраюзера прямо-таки аллергия на упоминание стойкости паролей.
Это тем более странно, что если авторы предыдущей статьи хотя бы предлагали альтернативу — тот самый перец — то здесь-то и вовсе крыть нечем. То есть, пароли вида 12345 и vasya — это неизбежный фейл.
Фейл, который сведет на нет любые ухищрения с хешированием. Это в буквальном смысле навешивание бронированной двери на картонный сарай.
10 000 самых распространённых паролей будут перепробованы за считанные секунды. А это много. Все ваши любимые имена-отчества включая ласкательно-уменьшительные, наряду с датами рождения плюс весь ваш словарный запас в английском языке.
Пароль длиной в 6 символов, состоящий из одних латинских букв, будет взломан за считанные часы. И никакая соль, никакой алгоритм не помогут.
Заявления «у меня нестойкий пароль потому что воровать нечего» совершенно смехотворны в контексте обсуждаемого вопроса. Если вас не волнует безопасность пароля, то уж тем более проблема перцев и хэшей не должна волновать и подавно. Но почему-то обе статьи на эту тему вызвали довольно большой ажиотаж. Неувязочка получается.
Здесь да — виноват. Формулировка подкачала.
Имелось в виду то же, что и выше — «Проектируя систему так, чтобы её безопасность зависела от „локального параметра“, вы вносите в неё заведомо слабое звено».
В рамках парадигмы «пароли находятся в безопасности для случая сферической базы в вакууме» система получается безопасной. Проблема в том, что взломщик не будет связывать себя такими смехотворными рамками — «ломать только базу, и больше ничего» :)
Нигде я не писал, что введением своего параметра вы ослабляете систему. Я говорю, что она остаётся изначально дырявой, даже при наличии костыля.
Про сложность пароля не стоило спрашивать, если у вас нет своих цифр.
Пока у нас есть только те, что приведены в статье. Если они вас не устраивают — предъявляйте претензии автору, а не мне.
Вам логику надо учить, молодой человек. Формальную.
Ну, и читать ещё желательно научиться.
А доклад и вправду провальный. Если после него такая разруха в голове осталась — то действительно, это эпик фейл.
Защиту от инъекций путем фильтрации входных параметров мы уже проходили — это magic quotes. Не помогло.
Больше того — на первом же слайде в докладе написано, что защищаться вообще не надо. принимать какие-то специальные меры по защите не нужно. Надо просто работать с БД. Средствами для работы с БД, а не парсером УРЛов.
Про типизованные плейсхолдеры в интернете нет практически ничего. Получается, что заявление про «мусолилось то, что на страницах интернета и так полным полно» не соответствует действительности.
Реальный SQL — это в первую очередь тот, который не входит в стандартные методы ORM («фильтры эктиврекорда»). Во вторую — тот, который невозможно воспроизвести билдерами, да.
Во-первых, это был доклад про SQL-инъекции, поэтому было бы глупо ожидать услышать там про csrf.
Во-вторых, про кастинг там не было ничего. Я не представляю, как можно перепутать приведение типов и форматирование SQL литералов. Это разные вещи.
В-третьих, важно не только само форматирование, но и где и когда оно происходит. magic_quotes тоже «кастовали», но это был эпик фейл.
В-четвертых, если вы считаете, что «роутинг» имеет хоть какое-то отношение к защите от инъекций, то доклад однозначно был провальный, но не потому что в нем не говорилось правильных вещей, а потому что их не получилось донести. Но вина докладчика в этом только частичная — как я говорил выше, пробить скепсис всезнайства и предубеждения очень трудно.
В-пятых, «фильтры эктиврекорда» там вполне упоминались. Когда РСУБД использвется в качестве примитивного key-value storage, эти фильтры прекрасно работают. Но как только нам начинает требоваться реальный SQL, а не примитивный его субсет, фильтры оказываются бесполезны. Об о всех таких случаях, когда «информация, которой полно в интернете» не помогает, и говорилось в докладе.
При этом, увы, сама по себе подача была так себе, без огонька. И у «многоопытных коллег» вполне могли быть обоснованные претензии как к самой информации, так и к её подаче. Но чтобы их понять и пересказать, надо хоть немного разбираться в теме.
При этом никто из «многоопытных коллег» не предлложил до сих пор всеобъемлющего решения, которое бы работало и с «фильтрами эктиврекорда», и с SQL, и с методами квери-билдеров, обеспечивая защиту на всех уровнях.
Странная ситуация складывается — «все всё знают», но единого решения нет. Есть только надерганные из разных источников и зачастую противоречащие друг другу «рекомендации из интернета».
Меня ты, по сути, еще в том топике на пхпклубе убедил.
Разве что именно что в две итерации сделать — почему собачки очень-очень плохо, а потом почему иногда все-таки можно.
Но у меня нету четкой картинки как это делать.
И плюс непонятно, насколько это вообще востребовано. Судя по настроению масс — не слишком.
Вообще, сдается мне, представление Григория насчет этого диспута может отличаться от представлений других заявленных участников :)
А вот дальше уже идет голосование и отбор. Сказать по правде, я только вчера эту заявку обнаружил, и тоже несколько удивился.
Я, правда, не уверен в общей реализуемости затеи.
Предубеждение вообще мешает воспринимать информацию адекватно, а в данном вопросе, где каждый школьник мнит себя экспертом — и подавно. Когда же доходит до дела — при написании чуть более сложных запросов, чем выборка по первичному ключу, или даже просто при обсуждении связанных вопросов — на свет вываливается фантастическая дремучесть таких «всезнаек». Что, в частности, неоднократно случалось при обсуждении темы здесь, на Хабре.
Но с методологической, или, даже — философской…
На самом деле пути эволюции неисповедимы. В мире разработаки она, собственно, только и держится на энтузиазме. И это прекрасно. Без проб и ошибок нет и развития. При этом никто не может предсказать, что получится в итоге. Никто. В этом-то и прелесть. Поэтому обязательно надо пробовать новое. Разумеется, некоторые ростки обязательно окажутся тупиковыми. Ничего страшного — это так и задумано. Важно понимать, что без тупиковых ветвей не бывает прорывов. Так что безумству храбрых стоит петь песню, а не держать их за штаны и не пущать.
PS. Ну зачем ещё увеличивать энтропию и делать из Perl, который задумывался для совсем других целей, вот такого франкенштейна — набор утилит Pretty Home Page / Form Interpreter? ;)
Либо там эти вентиляторы попросту не нужны, либо процессоры не охлаждаются.
Судя по фото — в глухую крышку, закрывающую процессорный отсек. Это так и задумано или я чего-то очевидного не понимаю в конструкции?
Если речь об обращении к функциям API, то никак — обращений будет два.
Первый оператор выполнит запрос, а второй получит id
Начиная с того, что комментаторы при упоминании сложного пароля тут же начинают воображать себе злой сайт с дубинкой. И начинают спорить с этим воображаемым сайтом. При этом минусуя комментарий, в котором не было ни слова ни про сайт, ни про дубинку.
«Сайтами, которые вымогают регистрацию» интернет не ограничивается. Рассказывать про одни сайты и умалчивать в своем комментарии о других — это или шулерство или глупость.
Это уже вторая статья, которая претендует на роль всеобъемлющего руководства по хэшированию. И в ней тоже не упоминается такой важный элемент, как стойкость пароля.
«Сайт не должен обеспечивать безопасность тем пользователям, кому она нафиг не сдалась» — это тоже очень смешное высказывание. Для аудитории хабра вполне годится, но для дискуссии о безопасности, увы — нет.
Это тем более странно, что если авторы предыдущей статьи хотя бы предлагали альтернативу — тот самый перец — то здесь-то и вовсе крыть нечем. То есть, пароли вида 12345 и vasya — это неизбежный фейл.
Фейл, который сведет на нет любые ухищрения с хешированием. Это в буквальном смысле навешивание бронированной двери на картонный сарай.
10 000 самых распространённых паролей будут перепробованы за считанные секунды. А это много. Все ваши любимые имена-отчества включая ласкательно-уменьшительные, наряду с датами рождения плюс весь ваш словарный запас в английском языке.
Пароль длиной в 6 символов, состоящий из одних латинских букв, будет взломан за считанные часы. И никакая соль, никакой алгоритм не помогут.
Заявления «у меня нестойкий пароль потому что воровать нечего» совершенно смехотворны в контексте обсуждаемого вопроса. Если вас не волнует безопасность пароля, то уж тем более проблема перцев и хэшей не должна волновать и подавно. Но почему-то обе статьи на эту тему вызвали довольно большой ажиотаж. Неувязочка получается.
Имелось в виду то же, что и выше — «Проектируя систему так, чтобы её безопасность зависела от „локального параметра“, вы вносите в неё заведомо слабое звено».
В рамках парадигмы «пароли находятся в безопасности для случая сферической базы в вакууме» система получается безопасной. Проблема в том, что взломщик не будет связывать себя такими смехотворными рамками — «ломать только базу, и больше ничего» :)
Про сложность пароля не стоило спрашивать, если у вас нет своих цифр.
Пока у нас есть только те, что приведены в статье. Если они вас не устраивают — предъявляйте претензии автору, а не мне.