Я вас умоляю.
Если такие вещи надо объяснять, то это заранее бесполезно.
Предназначение этого текста — вызывать восхищение у детей младшей школы, и с этой задачей он справляется прекрасно. Это всё.
Такого рода опусы все пишутся под одну копирку:
— про поиск уязвимости — ничего
— про защиту — хочется плакать кровавыми слезами
— про эксплуатацию — аффтар щеголяет знанием пары банальных 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, которое само объект, который не инициализирован изначально, а тянется только когда вызван. В общем, я пока бросил эту затею.
Но по умолчанию-то 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, которое само объект, который не инициализирован изначально, а тянется только когда вызван. В общем, я пока бросил эту затею.
Но работать не будет.
Разработчики будут по умолчанию лепить контекст «HTML» и пропускать JS-инъекции.