Для любых. Если можешь назвать хоть один, то он подойдет. Напиши на бумажке SQL запрос, и выбери любую его часть, которая не строковый литерал. Вот для ее защиты real_escape_string и будет бесполезна на 146%
По той причине, что она, в качестве побочного эффекта, защищает от инъекций только строковые литералы. Для всех остальных элементов запроса она бесполезна, и ее использование приведет к инъекции. Именно по этой причине её категорически нельзя использовать для защиты.
И снова я вынужден повторять в который раз, real_escape_string не имеет никакого отношения к инъекциям и никогда не должен использоваться для защиты от них.
Я не предлагаю принять на веру. Я предлагаю принять на логику. Я вам привел железобетонный логический аргумент: нигде не написано, кроме устарвешей страницы документации по несуществующей версии пхп, что эта функция должна использоваться для защиты от инъекций. Этого уже должно быть достаточно.
Если в каком-то отдельно взятом случае эта функция случайно помогла, это не значит, что ее предназначение именно в защите от инъекций.
Я ничего такого не писал. Не надо перевирать мои слова.
Давайте я вам еще раз попробую объяснить. Не бывает никаких абстрактных "данных", которые можно волшебным образом "обезопасить". Этот бред действительно был когда-то написан в документации, но люди делятся на тех, кто умеет извлекать уроки из ошибок прошлого, и тех кто предпочитает не считать их ошибками.
Волшебной функции для защиты от инъекций вообще в природе не существует. Не существует волшебной палочки, которая защитит любые абстрактные данные от любой абстрактной инъекции. Как только вы избавитесь от этой иллюзии дело сразу пойдет легче.
Дружище, это уже совсем за гранью добра и зла и формальной логики. В описании функций strlen, htmlspecialchars, empty, intval, urlencode, sort, header тоже не написано, что их нельзя применять для защиты от инъекций. Cогласно вашей логике получается что можно?
Просто написано, что данные можно вставлять в запрос,
Там нету слова "данные".
Почему нельзя использовать mysqli_real_escape_string в качестве защиты от sql-инъекций?
Потому что эта функция для этого никаким боком не предназначена. По своему прямому назначению ее применять можно. Для защиты от инъекций — нельзя.
Не уходим от темы. Вопрос ко мне был, "можно ли использовать эту функцию для защиты от инъекций". По ссылке выше не написано, что можно. Вообще ни одного слова про инъекцию. Еще вопросы будут?
Потому что эскейпинг не предназначен для защиты от инъекций. Точка.
Для защиты от инъекций надо применять те инструменты, которые для этого предназначены, а не случайно взятую с потолка функцию, которая может случайно 1 раз сработать.
Самая большая проблема здесь в том, что средний пользователь похапе воображает, будто SQL инъекция — это когда некий злодей Волдеморт водит волшебной палочкой и говорит заклинания. И чтобы от нее защититься, надо тоже поводить своей палочкой туда-сюда. А эскейпинг как раз и является такой палочкой. А если хоть раз в жизни дать себе труд задуматься, что такое инъекция и что делает эскейпинг, то сразу станет понятно что его тупо в одних случаях недостаточно, а в других он неприменим вовсе.
А "эскейпить все входные данные от пользователя" это уже совсем дно. Когда-то в ПХП была такая функция, "волшебные кавычки" называлась. Но уже 10 лет назад её с ужасом и стыдом из языка выпилили. Опять же, надо дать себе труд задуматься — что с ней было не так. Помимо того, что эскейпинг сам по себе не имеет отношения к инъекциям, тут у нас еще одна черная дыра глупости — "входные данные от пользователя". Если спросить среднего похапешника, какие данные входят от пользователя, аакие нет, волосы встанут дыбом. Во всех местах. Так что если доверить этому похапешнику решать, какие данные надо защищать и когда, то проще пароль от базы данных сразу написать на главной странице сайта.
Вот, кстати, про ваш личный опыт было бы интереснее почитать, чем перевод этой наполовину недописанной книги.
Хотя я осознаю, что в этом случае объем работы несопоставим.
К сожалению, это никакая не книга. Этак и я буду песатель, плодовитый автор бестселлеров.
Отличие книги от этой самодеятельности состоит в том, что у книги всегда есть редактор. И даже не один. Задача которого не пропустить в печать откровенную лажу.
В данном же случае мы имеем по сути стену лифта. Кто хочет — тот и самовыражается. О достоверности сведений можно лишь догадываться.
Обычно такого рода опусы можно разделить условно на две части:
начинают все с абстрактных рассуждений, состоящих из общих мест, с которыми спорить трудно, но и практической пользы никакой извлечь нельзя;
когда же автор переходит к практическим рекомендациям, пытаясь реализовать в коде многочисленные и зачастую противоречашие друг другу рекомендации из теоретической части, чтение становится чревато появлением синяков на лбу и ладони.
С нетерпением жду перевод раздела про инъекции, который с большим удовольствием прокомментирую.
Сам же этот код — для исключений — фатальных ошибок.
Но, как было сказано в статье, исключения — это не только ошибки.
К тому же, даже ошибки бывают не фатальными, и их вполне можно обрабатывать по месту.
К примеру, идет обработка картинок.
Из ста картинок одна — битая.
Все что нам надо — это запомнить имя этой картинки, если было брошено invalidImageFormat исключение.
Писать и регистрировать хендлер из одной строчки будет избыточным.
А вот если мы во время обработки картинок улетели по памяти — то да, здесь как раз пригодится стандартный обработчик.
Ты забавный мальчик :)
Если назовешь хоть одну причину, по которой я должен это сделать, то так и быть, я разжую тебе даже это.
Зададим тебе это в качестве домашнего задания :)
Мда.
если нам требуется сортировка по выбираемому пользователем полю, то real_escape_string не защитит его от слова "никак".
Для любых. Если можешь назвать хоть один, то он подойдет. Напиши на бумажке SQL запрос, и выбери любую его часть, которая не строковый литерал. Вот для ее защиты real_escape_string и будет бесполезна на 146%
По той причине, что она, в качестве побочного эффекта, защищает от инъекций только строковые литералы. Для всех остальных элементов запроса она бесполезна, и ее использование приведет к инъекции. Именно по этой причине её категорически нельзя использовать для защиты.
И снова я вынужден повторять в который раз, real_escape_string не имеет никакого отношения к инъекциям и никогда не должен использоваться для защиты от них.
Я не предлагаю принять на веру. Я предлагаю принять на логику. Я вам привел железобетонный логический аргумент: нигде не написано, кроме устарвешей страницы документации по несуществующей версии пхп, что эта функция должна использоваться для защиты от инъекций. Этого уже должно быть достаточно.
Если в каком-то отдельно взятом случае эта функция случайно помогла, это не значит, что ее предназначение именно в защите от инъекций.
Не только строки
Я ничего такого не писал. Не надо перевирать мои слова.
Давайте я вам еще раз попробую объяснить. Не бывает никаких абстрактных "данных", которые можно волшебным образом "обезопасить". Этот бред действительно был когда-то написан в документации, но люди делятся на тех, кто умеет извлекать уроки из ошибок прошлого, и тех кто предпочитает не считать их ошибками.
Волшебной функции для защиты от инъекций вообще в природе не существует. Не существует волшебной палочки, которая защитит любые абстрактные данные от любой абстрактной инъекции. Как только вы избавитесь от этой иллюзии дело сразу пойдет легче.
Дружище, это уже совсем за гранью добра и зла и формальной логики. В описании функций strlen, htmlspecialchars, empty, intval, urlencode, sort, header тоже не написано, что их нельзя применять для защиты от инъекций. Cогласно вашей логике получается что можно?
Там нету слова "данные".
Потому что эта функция для этого никаким боком не предназначена. По своему прямому назначению ее применять можно. Для защиты от инъекций — нельзя.
Не уходим от темы. Вопрос ко мне был, "можно ли использовать эту функцию для защиты от инъекций". По ссылке выше не написано, что можно. Вообще ни одного слова про инъекцию. Еще вопросы будут?
Что "есть"? По этой ссылке можно увидеть корректные формулировки, бреда про "обезопасить данные" там нет.
По этой ссылке написано, что Данное расширение устарело, начиная с версии PHP 5.5.0, и удалено в PHP 7.0.0.
В актуальной документации этой ереси нет.
Потому что эскейпинг не предназначен для защиты от инъекций. Точка.
Для защиты от инъекций надо применять те инструменты, которые для этого предназначены, а не случайно взятую с потолка функцию, которая может случайно 1 раз сработать.
Самая большая проблема здесь в том, что средний пользователь похапе воображает, будто SQL инъекция — это когда некий злодей Волдеморт водит волшебной палочкой и говорит заклинания. И чтобы от нее защититься, надо тоже поводить своей палочкой туда-сюда. А эскейпинг как раз и является такой палочкой. А если хоть раз в жизни дать себе труд задуматься, что такое инъекция и что делает эскейпинг, то сразу станет понятно что его тупо в одних случаях недостаточно, а в других он неприменим вовсе.
А "эскейпить все входные данные от пользователя" это уже совсем дно. Когда-то в ПХП была такая функция, "волшебные кавычки" называлась. Но уже 10 лет назад её с ужасом и стыдом из языка выпилили. Опять же, надо дать себе труд задуматься — что с ней было не так. Помимо того, что эскейпинг сам по себе не имеет отношения к инъекциям, тут у нас еще одна черная дыра глупости — "входные данные от пользователя". Если спросить среднего похапешника, какие данные входят от пользователя, аакие нет, волосы встанут дыбом. Во всех местах. Так что если доверить этому похапешнику решать, какие данные надо защищать и когда, то проще пароль от базы данных сразу написать на главной странице сайта.
в 2017 warning-и являются исключениями
Боты в стиле жж теперь и на хабре?
Вот, кстати, про ваш личный опыт было бы интереснее почитать, чем перевод этой наполовину недописанной книги.
Хотя я осознаю, что в этом случае объем работы несопоставим.
Про "никто не заставляет читать" реплика явно лишняя.
К сожалению, это никакая не книга. Этак и я буду песатель, плодовитый автор бестселлеров.
Отличие книги от этой самодеятельности состоит в том, что у книги всегда есть редактор. И даже не один. Задача которого не пропустить в печать откровенную лажу.
В данном же случае мы имеем по сути стену лифта. Кто хочет — тот и самовыражается. О достоверности сведений можно лишь догадываться.
Обычно такого рода опусы можно разделить условно на две части:
С нетерпением жду перевод раздела про инъекции, который с большим удовольствием прокомментирую.
Но, как было сказано в статье, исключения — это не только ошибки.
К тому же, даже ошибки бывают не фатальными, и их вполне можно обрабатывать по месту.
К примеру, идет обработка картинок.
Из ста картинок одна — битая.
Все что нам надо — это запомнить имя этой картинки, если было брошено invalidImageFormat исключение.
Писать и регистрировать хендлер из одной строчки будет избыточным.
А вот если мы во время обработки картинок улетели по памяти — то да, здесь как раз пригодится стандартный обработчик.