чтобы пройти своего рода испытание – сообщество само решит, стоит ли наделить пользователя возможностью влиять на других.
Не работает. Любая халтура, которая сляпана с помощью копипасты и хорошо подвешенного языка, легко проходит фильтр. При этом минусы, которые получила статья — они не за качество. А за банальность темы. Есть такая фишка на Хабре, минусовать статьи на тему, которая кажется всем избитой, про которую «все всё знают». Ага, знают. Тема, казалось бы, всем известна, но принципиальные ошибки видит всего пара человек.
Увы, отрицательная селекция, которой занимался Хабр все эти годы, дала свои плоды.
И дело совсем не в циферках кармы. Проблема в людях. У которых политика ресурса выработала два очень устойчивых рефлекса:
1. Заявленный, как технологическая площадка, Хабр, пор сути, превратился в этакий глянец, для чтения за завтраком. Про красивые гаджеты, модные аксессуары и космические новости. И у пользователей выработался рефлекс ставить плюсик статье, которая выглядит, как хорошая. В суть же вчитываются единицы: это же новостной ресурс о всяких диковинках. Прочитал-заплюсовал-пролистал дальше.
2. Шакалья политика затаптывать несогласных с мнением большинства вывела специальную породу юзера-конформиста, очень тщательно взвешивающего свои слова и никогда не идущего на конфликт, даже при 100% сознании собственной правоты. Обладающие же собственным мнением все давно ушли в минуса.
Так что надеяться на сообщество не стоит. Оно будет продолжать поощрять любую халтуру и графоманию — лишь бы выглядело красиво и не напрягало мозги.
Новые правила, конечно, будут получше в этом плане. Но селекция, увы, всё равно направлена на креативщиков, а не специалистов. Пересказать своими словами чужую новость и описать собственное исследование — это несоразмерные сущности. Новости можно постить хоть каждый день. Людей же, готовых потратить пару недель своего времени, чтобы написать что-то оригинальное, основанное на личном опыте — очень мало. В итоге, программа, призванная наделять правом голоса специалистов, на самом деле оставляет их за бортом, выдвигая новостников и PR-отделы корпораций.
В общем, эта публикация как бы говорит нам, что получения вожделенных гражданских прав не нужно обладать ни знаниями, ни опытом, ни совестью.
Нужно всего лишь немного наглости и воображения:
1. Найти в интернете копипасту от очередного незнайки с кучей ляпов в стиле «слышал звон, да не знаю где он».
2. Перевести её (снова без малейшего понимания, оставив все ляпы на месте).
3. Нафантазировать пару красивых деталей от себя.
4. На критические замечания отвечать в стиле «божья роса».
5. PROFIT!!!
Я вас умоляю.
Если такие вещи надо объяснять, то это заранее бесполезно.
Предназначение этого текста — вызывать восхищение у детей младшей школы, и с этой задачей он справляется прекрасно. Это всё.
Такого рода опусы все пишутся под одну копирку:
— про поиск уязвимости — ничего
— про защиту — хочется плакать кровавыми слезами
— про эксплуатацию — аффтар щеголяет знанием пары банальных SQL операторов, дотоле неизвестных незадачливому читателю, выдавая их за сакральные хакирские техники (при этом в подавляющем большинстве случаев никогда сам их не применял, а тупо скопипастил у такого-же горе-писаки, и не в состоянии объяснить, как и почему работает или не работает тот или иной запрос)
Для того, чтобы осуществить инъекцию, не нужно быть хакиром и читать макулатурные статьи.
Надо просто знать SQL. Если не знаешь — то набор наизусть выученных «приемчиков» тебе не поможет. А если знаешь — то не понадобится.
В этом комментарии содержится несколько заблуждений
1. С подавляющим большинством кодировок addslashes() абсолютно безопасна, если используется по назначению.
2. Сами по себе pdo & prepared statement в случае воображаемой автором атаки — не панацея, и при установках по умолчанию пропустит инъекцию за здорово живешь. Чтобы в кодировках, подверженных данному типу инъекции, атака становилась невозможной, ПДО надо настраивать специально.
3. Дарагая похапешечка, вместе со всеми своими функциями и расширениями, тут как бы вообще не при чем.
Что-то я не совсем понял про волшебный символ 0xbf5c27
«Волшебный» он только в кодировке GBK. Сайт с ругательствами — китайский?
И почему сайт выдал ошибку на кавычку, если, по мнению автора, addslashes таки исользуется?
Пост больше напоминает «реальные» истории с башорга, при ближайшем рассмотрении оказывающиеся целиком высосанными из пальца. Дополненную, в данном случае, унылой копипастой.
Ещё раз, медленно и по буквам читаем вышеприведённую цитату.
Там ничего нет про съёмку видео.
Там написано «если вы хотите скрыть что-то ото всех, может быть лучше просто не заниматься подобными вещами».
Проблема не в том, что кто-то что-то снял на видео, а оно утекло в сеть. Проблема в том, что условную «съемку на видео» гугль сделает сам, без вашей помощи (и желания). И единственный предложенный способ сделать так, чтобы гугль чего-то не знал про вас — это не делать ничего такого — не ходить в туалет, не заниматься сексом, не лечить всякие болячки — и пр.
Заявление Шмидта на самом деле — верх наглости, ханжества и цинизма. «Да, мы будем за вами следить, хотите вы этого или нет. Да, мы будем рыться в вашем грязном белье, без разницы, законно это или нет. Если вы не хотите, чтобы мы знали о чем-то — просто не делайте этого».
Но проблема в том, что эту планету населяют не ангелы. И у каждого есть свой скелет в шкафу, причем у большинства вполне законные — но такие, которые все равно не хочется показывать окружающим. Так уж человек устроен. Подвержен слабостям и порокам. Не существует человека, у которого не было бы какой-то стыдной тайны. Поэтому заявление Шмидта — ханжество: он знает прекрасно, что последовать его совету невозможно, он знает прекрасно, что и сам не следует ему — но другим советует.
Плюс это ещё и запредельная наглость — какой-то поисковишка взялся диктовать людям, что им делать, а что не делать. И это — в ответ на законное требование перестать рыться в чужих письмах.
Я бы сказал так.
Для «классического похапе» это действительно прекрасный шаблонизатор. Сделать автоискейпинг на этапе задания переменных шаблона совсем несложно, если в шаблон не передаются объекты.
Если же это современный код, где в шаблон передаются объекты с виртуальными свойствами, то чтобы сделать хороший автоискейпинг, надо наворотить кода не меньше, чем понадобится для небольшого шаблонизатора. При этом автоискейпинг — это стопроцентный маст-хэв, вещь, без которой в принципе нельзя.
Плюс такие вещи, как наследование в нативном пхп делаются не так чтобы просто.
И что с того?
Если прям так хочется на вершину — программирование далеко не лучший выбор профессии. Надо идти в финансисты, управленцы, юристы, политики.
Но лично я не понимаю, что там (на вершине) делать.
Программирование — это скорее для человека, который хочет получать деньги за занятие своим хобби, заниматься творчеством. А не скакать по лестницам.
Да и в целом эта проблема не слишком релевантна географии. Если у человека главная проблема в жизни — сколько зарабатывает его сосед, то ему везде будет некомфортно. Ну разве что в Африку уехать.
И всё же, «Силиконовая долина» — неправильно. Силиконовые бывают сиськи. А долина — Кремниевая.
Silicon и Silicone — это два разных слова. Если по-английски они звучат одинаково, это не повод коверкать название в русском. Надо уважать свой язык. В нём кремний и силикон — это разные слова. Точно так же как барак и казарма, милиция и ополчение, амуниция и боеприпасы. Переводя какой-либо термин, надо руководствоваться его значением, а не произношением.
Пожалуйста, не надо путать правильный вариант с привычным. Пусть «Вам сыр послайсать или писом брать будете?» и звучит привычно для эмигрантского уха, но это суржик, а не русский язык. Никто не называет этот вариант правильным.
Более корректной формулировкой было бы «Я знаю, что „силиконовая“ — неправильно, но калька проще и привычней».
Я ничего удивительного в этом не вижу. Write-only языки и подходы шагают по планете.
Ширпотреб вытесняет вещь. Машина делается со сроком службы три года, гаджет — полгода. Почему программа должна работать дольше? Написал шустренько — и в продакшен. А если что-то сломалось, то проще новую написать, чем со старой разбираться.
NikiC совсем заигрался. Всякий раз, когда я буду видеть вызов вида foo()() — я буду от всей души желать написавшему это гореть в аду.
Прелесть РНР всегда была в читабельности кода — читать код было почти так же легко, как и писать. То есть, поклонники стиля «фигак-фигак — и на продакшен» не могли сильно поднагадить тем, кто будет после них отлаживать код. Но в последние годы сообщество серьёзно работает над тем, чтобы окончательно похоронить читабельность.
а этого Andrea Faulds я затопчут свои же, я надеюсь
Ага, сам нашел. Сейчас только мускуль и лайт.
То есть, в данным момент единый интерфейс для доступа к любым БД — скорее желательное, чем действительное.
Но, вообще, при наличии достаточного количества драйверов, идея сделать ПДО единственным интерфейсом для работы с любыми БД, просто бай дезигн, не лишена смысла. Что-то в этом есть.
Во-первых, не плеера, а деки. Я понимаю, что несколько старомоден в своих аналогиях, но уж что первое в голову пришло :)
Во-вторых, как раз магнитола, представляющая собой комбайн из нескольких устройств, и является аналогом PDO. При этом каждое из устройств у комбайне справляется со своей задачей чуть хуже, чем специализированное.
В-третьих, аналогии вообще зло. Главное, что по остальным пунктам возражений нет :)
Кстати, про общую систему доступа к бд через кучу драйверов. Интересно, как у HHVM с драйверами?
Вы оба не совсем понимаете, что такое mysqli. Отвечу сразу обоим.
Ничего «старого» в технологии mysqli нет. Как и «нового» в PDO. И объективностью тут даже не пахнет.
Нельзя сравнивать профессиональную кассетную деку с портативной магнитолой, и заявлять о превосходстве последней только потому что ее можно взять с собой на шашлыки.
mysqli — это просто тончайшая обертка над C API. Из этого следуют ее плюсы и минусы.
Плюсы в том, что она реализует весь функционал API. А это несколько более широкий диапазон задач, чем «послать запрос-получить ответ». mysqli позволяет такие вещи, про которые в ПДО и слыхом не слыхивали: пинг, асинхронные запросы, низкоуровневый дебаг на уровне соединения и много других фич, о существовании которых пользователи «старой технологии» (шарашить функциями API прямо в коде приложения) даже не догадываются. И реализуется это всё без оглядки на необходимость соблюдения совместимости с остальными 100500 драйверами в колхозе.
Минусы тоже очевидны — обращение к низкоуровневым API всегда получается более трудоемким. Ну так для этого и существуют врапперы. Я конечно понимаю, что средний пользователь похапешечки способен пользоваться только тем, что дают, причем только в стандартной поставке языка. В этом случае PDO рулит безальтернативно, поскольку представляет из себя как раз недо-DAL, реализуя некоторые функции враппера. При наличии же рук, растущих из нужного места, и потребностей, чуть выходящих за рамки «SELECT * FROM users WHERE id=$id», сделать из mysqli инструмент столь же удобный, как PDO, не составляет проблемы.
Просто надо отказаться от этой дурацкой идеи, что низкоуровневое API предназначено для использования в коде приложения. Из той же «устаревшей технологии mysql API» Дима Бородин ещё в прошлом веке делал конфетку в виде одной-единственной функции для выполнения запросов к базе, с коннектом по требованию, экранированием и возвращением готового результата. Было бы желание.
С этой точки зрения, кстати, «голый» PDO — такой же анахронизм. В коде должны быть обращения к методам модели. В крайнем случае — враппера DB. Какой там драйвер лежит под ними — дело десятое.
Скажем прямо, для этого текста никакой лички не хватит.
«Переписанный» вариант оказался чуть ли не хуже изначального.
Тут, правда, не в грамматике дело — переводчик попросту не знает языка, на который взялся переводить.
Это-то и ужасно.
Ага, оно работает, и даже с методами (надо поправить опечатку в вызове call_user_func_array()).
Но беда в том, что принцип рекурсии, который распространяется на остальные типы, не распространяется на объекты. И если со свойством ещё можно как-то извернуться, то с методом, который возвращает массив — уже, кажется, никак… :(
А у меня, в моей практической задаче, есть, к примеру, у юзера свойство $geo, которое само объект, который не инициализирован изначально, а тянется только когда вызван. В общем, я пока бросил эту затею.
Не работает. Любая халтура, которая сляпана с помощью копипасты и хорошо подвешенного языка, легко проходит фильтр. При этом минусы, которые получила статья — они не за качество. А за банальность темы. Есть такая фишка на Хабре, минусовать статьи на тему, которая кажется всем избитой, про которую «все всё знают». Ага, знают. Тема, казалось бы, всем известна, но принципиальные ошибки видит всего пара человек.
Увы, отрицательная селекция, которой занимался Хабр все эти годы, дала свои плоды.
И дело совсем не в циферках кармы. Проблема в людях. У которых политика ресурса выработала два очень устойчивых рефлекса:
1. Заявленный, как технологическая площадка, Хабр, пор сути, превратился в этакий глянец, для чтения за завтраком. Про красивые гаджеты, модные аксессуары и космические новости. И у пользователей выработался рефлекс ставить плюсик статье, которая выглядит, как хорошая. В суть же вчитываются единицы: это же новостной ресурс о всяких диковинках. Прочитал-заплюсовал-пролистал дальше.
2. Шакалья политика затаптывать несогласных с мнением большинства вывела специальную породу юзера-конформиста, очень тщательно взвешивающего свои слова и никогда не идущего на конфликт, даже при 100% сознании собственной правоты. Обладающие же собственным мнением все давно ушли в минуса.
Так что надеяться на сообщество не стоит. Оно будет продолжать поощрять любую халтуру и графоманию — лишь бы выглядело красиво и не напрягало мозги.
Новые правила, конечно, будут получше в этом плане. Но селекция, увы, всё равно направлена на креативщиков, а не специалистов. Пересказать своими словами чужую новость и описать собственное исследование — это несоразмерные сущности. Новости можно постить хоть каждый день. Людей же, готовых потратить пару недель своего времени, чтобы написать что-то оригинальное, основанное на личном опыте — очень мало. В итоге, программа, призванная наделять правом голоса специалистов, на самом деле оставляет их за бортом, выдвигая новостников и PR-отделы корпораций.
Нужно всего лишь немного наглости и воображения:
1. Найти в интернете копипасту от очередного незнайки с кучей ляпов в стиле «слышал звон, да не знаю где он».
2. Перевести её (снова без малейшего понимания, оставив все ляпы на месте).
3. Нафантазировать пару красивых деталей от себя.
4. На критические замечания отвечать в стиле «божья роса».
5. PROFIT!!!
Но по умолчанию-то EMULATE_PREPARES включена. И для «знака 0xbf5c27» вышеприведенный код при дефолтных настройках угрозы не представляет.
Если такие вещи надо объяснять, то это заранее бесполезно.
Предназначение этого текста — вызывать восхищение у детей младшей школы, и с этой задачей он справляется прекрасно. Это всё.
Такого рода опусы все пишутся под одну копирку:
— про поиск уязвимости — ничего
— про защиту — хочется плакать кровавыми слезами
— про эксплуатацию — аффтар щеголяет знанием пары банальных SQL операторов, дотоле неизвестных незадачливому читателю, выдавая их за сакральные хакирские техники (при этом в подавляющем большинстве случаев никогда сам их не применял, а тупо скопипастил у такого-же горе-писаки, и не в состоянии объяснить, как и почему работает или не работает тот или иной запрос)
Для того, чтобы осуществить инъекцию, не нужно быть хакиром и читать макулатурные статьи.
Надо просто знать SQL. Если не знаешь — то набор наизусть выученных «приемчиков» тебе не поможет. А если знаешь — то не понадобится.
Я надеялся на честный ответ.
Сюда это постить не стоило.
1. С подавляющим большинством кодировок addslashes() абсолютно безопасна, если используется по назначению.
2. Сами по себе pdo & prepared statement в случае воображаемой автором атаки — не панацея, и при установках по умолчанию пропустит инъекцию за здорово живешь. Чтобы в кодировках, подверженных данному типу инъекции, атака становилась невозможной, ПДО надо настраивать специально.
3. Дарагая похапешечка, вместе со всеми своими функциями и расширениями, тут как бы вообще не при чем.
«Волшебный» он только в кодировке GBK. Сайт с ругательствами — китайский?
И почему сайт выдал ошибку на кавычку, если, по мнению автора, addslashes таки исользуется?
Пост больше напоминает «реальные» истории с башорга, при ближайшем рассмотрении оказывающиеся целиком высосанными из пальца. Дополненную, в данном случае, унылой копипастой.
Там ничего нет про съёмку видео.
Там написано «если вы хотите скрыть что-то ото всех, может быть лучше просто не заниматься подобными вещами».
Проблема не в том, что кто-то что-то снял на видео, а оно утекло в сеть. Проблема в том, что условную «съемку на видео» гугль сделает сам, без вашей помощи (и желания). И единственный предложенный способ сделать так, чтобы гугль чего-то не знал про вас — это не делать ничего такого — не ходить в туалет, не заниматься сексом, не лечить всякие болячки — и пр.
Заявление Шмидта на самом деле — верх наглости, ханжества и цинизма. «Да, мы будем за вами следить, хотите вы этого или нет. Да, мы будем рыться в вашем грязном белье, без разницы, законно это или нет. Если вы не хотите, чтобы мы знали о чем-то — просто не делайте этого».
Но проблема в том, что эту планету населяют не ангелы. И у каждого есть свой скелет в шкафу, причем у большинства вполне законные — но такие, которые все равно не хочется показывать окружающим. Так уж человек устроен. Подвержен слабостям и порокам. Не существует человека, у которого не было бы какой-то стыдной тайны. Поэтому заявление Шмидта — ханжество: он знает прекрасно, что последовать его совету невозможно, он знает прекрасно, что и сам не следует ему — но другим советует.
Плюс это ещё и запредельная наглость — какой-то поисковишка взялся диктовать людям, что им делать, а что не делать. И это — в ответ на законное требование перестать рыться в чужих письмах.
Для «классического похапе» это действительно прекрасный шаблонизатор. Сделать автоискейпинг на этапе задания переменных шаблона совсем несложно, если в шаблон не передаются объекты.
Если же это современный код, где в шаблон передаются объекты с виртуальными свойствами, то чтобы сделать хороший автоискейпинг, надо наворотить кода не меньше, чем понадобится для небольшого шаблонизатора. При этом автоискейпинг — это стопроцентный маст-хэв, вещь, без которой в принципе нельзя.
Плюс такие вещи, как наследование в нативном пхп делаются не так чтобы просто.
Если прям так хочется на вершину — программирование далеко не лучший выбор профессии. Надо идти в финансисты, управленцы, юристы, политики.
Но лично я не понимаю, что там (на вершине) делать.
Программирование — это скорее для человека, который хочет получать деньги за занятие своим хобби, заниматься творчеством. А не скакать по лестницам.
Да и в целом эта проблема не слишком релевантна географии. Если у человека главная проблема в жизни — сколько зарабатывает его сосед, то ему везде будет некомфортно. Ну разве что в Африку уехать.
И всё же, «Силиконовая долина» — неправильно. Силиконовые бывают сиськи. А долина — Кремниевая.
Silicon и Silicone — это два разных слова. Если по-английски они звучат одинаково, это не повод коверкать название в русском. Надо уважать свой язык. В нём кремний и силикон — это разные слова. Точно так же как барак и казарма, милиция и ополчение, амуниция и боеприпасы. Переводя какой-либо термин, надо руководствоваться его значением, а не произношением.
Пожалуйста, не надо путать правильный вариант с привычным. Пусть «Вам сыр послайсать или писом брать будете?» и звучит привычно для эмигрантского уха, но это суржик, а не русский язык. Никто не называет этот вариант правильным.
Более корректной формулировкой было бы «Я знаю, что „силиконовая“ — неправильно, но калька проще и привычней».
Ширпотреб вытесняет вещь. Машина делается со сроком службы три года, гаджет — полгода. Почему программа должна работать дольше? Написал шустренько — и в продакшен. А если что-то сломалось, то проще новую написать, чем со старой разбираться.
Прелесть РНР всегда была в читабельности кода — читать код было почти так же легко, как и писать. То есть, поклонники стиля «фигак-фигак — и на продакшен» не могли сильно поднагадить тем, кто будет после них отлаживать код. Но в последние годы сообщество серьёзно работает над тем, чтобы окончательно похоронить читабельность.
а этого Andrea Faulds я затопчут свои же, я надеюсь
То есть, в данным момент единый интерфейс для доступа к любым БД — скорее желательное, чем действительное.
Но, вообще, при наличии достаточного количества драйверов, идея сделать ПДО единственным интерфейсом для работы с любыми БД, просто бай дезигн, не лишена смысла. Что-то в этом есть.
Во-вторых, как раз магнитола, представляющая собой комбайн из нескольких устройств, и является аналогом PDO. При этом каждое из устройств у комбайне справляется со своей задачей чуть хуже, чем специализированное.
В-третьих, аналогии вообще зло. Главное, что по остальным пунктам возражений нет :)
Кстати, про общую систему доступа к бд через кучу драйверов. Интересно, как у HHVM с драйверами?
Ничего «старого» в технологии mysqli нет. Как и «нового» в PDO. И объективностью тут даже не пахнет.
Нельзя сравнивать профессиональную кассетную деку с портативной магнитолой, и заявлять о превосходстве последней только потому что ее можно взять с собой на шашлыки.
mysqli — это просто тончайшая обертка над C API. Из этого следуют ее плюсы и минусы.
Плюсы в том, что она реализует весь функционал API. А это несколько более широкий диапазон задач, чем «послать запрос-получить ответ». mysqli позволяет такие вещи, про которые в ПДО и слыхом не слыхивали: пинг, асинхронные запросы, низкоуровневый дебаг на уровне соединения и много других фич, о существовании которых пользователи «старой технологии» (шарашить функциями API прямо в коде приложения) даже не догадываются. И реализуется это всё без оглядки на необходимость соблюдения совместимости с остальными 100500 драйверами в колхозе.
Минусы тоже очевидны — обращение к низкоуровневым API всегда получается более трудоемким. Ну так для этого и существуют врапперы. Я конечно понимаю, что средний пользователь похапешечки способен пользоваться только тем, что дают, причем только в стандартной поставке языка. В этом случае PDO рулит безальтернативно, поскольку представляет из себя как раз недо-DAL, реализуя некоторые функции враппера. При наличии же рук, растущих из нужного места, и потребностей, чуть выходящих за рамки «SELECT * FROM users WHERE id=$id», сделать из mysqli инструмент столь же удобный, как PDO, не составляет проблемы.
Просто надо отказаться от этой дурацкой идеи, что низкоуровневое API предназначено для использования в коде приложения. Из той же «устаревшей технологии mysql API» Дима Бородин ещё в прошлом веке делал конфетку в виде одной-единственной функции для выполнения запросов к базе, с коннектом по требованию, экранированием и возвращением готового результата. Было бы желание.
С этой точки зрения, кстати, «голый» PDO — такой же анахронизм. В коде должны быть обращения к методам модели. В крайнем случае — враппера DB. Какой там драйвер лежит под ними — дело десятое.
«Переписанный» вариант оказался чуть ли не хуже изначального.
Тут, правда, не в грамматике дело — переводчик попросту не знает языка, на который взялся переводить.
Это-то и ужасно.
Но беда в том, что принцип рекурсии, который распространяется на остальные типы, не распространяется на объекты. И если со свойством ещё можно как-то извернуться, то с методом, который возвращает массив — уже, кажется, никак… :(
А у меня, в моей практической задаче, есть, к примеру, у юзера свойство $geo, которое само объект, который не инициализирован изначально, а тянется только когда вызван. В общем, я пока бросил эту затею.