Подождите-подождите.
Во-первых, что значит «чищеные»? От чего чищеные?
Во-вторых, не святым же духом они станут «чищеными»? То есть, какой-то код понадобится?
Вас не затруднит привести полный код составления запроса, вместе с «очисткой» переменных? А то заявление про «усложнение кода» выглядит несколько голословно, уж извините.
По поводу же ресурсов, я приведу аналогию. При выводе HTML мы используем примерно такой же принцип — «парсеры, массивы, пересчеты туда-сюда». Но, вроде бы, необходимость использования шаблонизаторов никем не оспаривается, а накладные расходы считаются приемлемой платой за удобство и безопасность.
В качестве единственного средства защиты — это так и есть. Подробное объяснение, мне кажется, есть в статье, причём в нескольких местах. Но если коротко, то основная проблема состоит в том, что mysql_real_escape_string — это лишь часть необходимого форматирования, применимая только к строкам, при этом абсолютно бесполезная для любых других элементов запроса. Не говоря уже о том, что сама по себе эта функция к защите от инъекций не имеет никакого отношения. Она служит для форматирования строк.
Признайтесь, вы написали комментарий, не читая статью? :)
На самом деле, всё наоборот — код (прикладной) значительно упрощается.
Правила форматирования SQL кода, увы, совсем не единообразны. К примеру, строковые литералы надо форматировать одним способом, а числовые — совсем другим.
В то время как плейсхолдеры, как раз, являются именно таким единообразным способом формирования динамических запросов.
Вот пример кода с плейсхолдерами
$data = $db->getAll(«SELECT * FROM news WHERE id IN(a:) AND theme=s:»,$ids,$theme);
Я думаю, что проблема тут скорее в терминологии, и elve имел в виду то же самое. Особенно, если учесть, что термин «экранировать» тоже не очень удачный.
Но на самом деле его ошибка совсем в другом:
Форматирование данных должно определяться не источником, а получателем данных. С точки зрения защиты от инъекций корректно обрабатывать надо не «переданные из формы» данные, а «передаваемые в запрос».
Не стоит так ругаться. Стилистика тут не при чём. Оператор if работает с булевыми выражениями, а is_file возвращает именно его, и поэтому дополнительное сравнение является избыточным.
Если тебе указали на ошибку, то лучше попросить объяснить, чем отругиваться.
У вас все в кучу перемешалось.
Я не предлагаю делать эту тупую проверку на "<?".
Эта проверка сама по себе дурацкая и не имеет смысла.
Однако, если сайт вообще делает какую-то проверку, и отвергает какие-то пользовательские данные, то это только его, сайта, дело, и никакого «поступания с чужими данными» здесь нет.
Скажем, есть ограничение на минимальный размер заливаемых картинок. Если я не принимаю картинку размером 32х32, то никакого надругательства над пользовательскими данными я не совершаю.
А чтобы заказчики не звонили, надо просто выдавать внятные сообщения об ошибках и собирать их в отчет, выдаваемый по запросу.
А чтобы на кофейной гуще не гадать — нужно обязательно логировать весь процесс.
Не понял, как именно поступать?
Он же никак эти данные не портит, а просто предлагает не принимать.
Сайт и не обязан принимать всё подряд.
Смысла я в такой проверке не вижу, но и никаких проблем с пользовательскими данными — тоже
Вот проблема ( ваша и OnYourLips ) как раз в том, что вы отказываетесь действовать по принципу белого списка (запрещено всё, что не разрешено) и предпочитаете действовать по принципу списка чёрного — разрешено всё, что не запрешено.
Но чёрный список заведомо дырявее белого. Всё предусмотреть невозможно. И, скажем, добраться до какого-нибудь файла с паролями можно будет и безо всяких точек.
Два правила начинающему комментатору:
1. Если эта идея прямо сейчас пришла вам в голову, то надо сначала проверить — насколько она применима в реальной жизни.
2. Если вы к этой идее не имеете вообще никакого отношения, а просто повторяете за кем-то — тем более надо сначала проверить — насколько она применима в реальной жизни. Чтобы не быть одним из миллионов разносчиков мусора.
В качестве домашнего задания попробуйте поискать эти сочетания в любой мало-мальски объемной коллекции заведомо безопасных картинок.
Я же пример привел, работающий. В самом первом комментарии к топику.
Собственно, практически любой фреймфорк запускает PHP файлы в зависимости от пользовательского ввода. Очень часто части запрошенного урла совпадают с названиями файлов/методов имеющихся классов.
А фильтрация всего этого дела остаётся на совести программиста.
Ну, как минимум следует учитывать возможность инклюда с локального диска.
Понятно, что инклюды надо защищать отдельно, но программисты обычно не слишком заботятся о безопасности внутренних инклюдов. А проверку на open_basedir картинка пройдёт спокойно.
Опять же, sun.php.jpg оказывается куда более разрушительным. Так что не все рекомендации в статье одинаково бесполезны.
Обработка с помощью GD убьёт любые посторонние данные по умолчанию, а Imagemagick-у надо при конвертации об этом специально сказать. Впрочем, я не возьмусь назвать конкретные ключи, которые в этом случае надо применить — кроме EXIF-а наверняка есть ещё лазейки.
Во-первых, что значит «чищеные»? От чего чищеные?
Во-вторых, не святым же духом они станут «чищеными»? То есть, какой-то код понадобится?
Вас не затруднит привести полный код составления запроса, вместе с «очисткой» переменных? А то заявление про «усложнение кода» выглядит несколько голословно, уж извините.
По поводу же ресурсов, я приведу аналогию. При выводе HTML мы используем примерно такой же принцип — «парсеры, массивы, пересчеты туда-сюда». Но, вроде бы, необходимость использования шаблонизаторов никем не оспаривается, а накладные расходы считаются приемлемой платой за удобство и безопасность.
На самом деле, всё наоборот — код (прикладной) значительно упрощается.
Правила форматирования SQL кода, увы, совсем не единообразны. К примеру, строковые литералы надо форматировать одним способом, а числовые — совсем другим.
В то время как плейсхолдеры, как раз, являются именно таким единообразным способом формирования динамических запросов.
Вот пример кода с плейсхолдерами
$data = $db->getAll(«SELECT * FROM news WHERE id IN(a:) AND theme=s:»,$ids,$theme);
Покажите, пожалуйста, как сделать его проще?
Но на самом деле его ошибка совсем в другом:
Форматирование данных должно определяться не источником, а получателем данных. С точки зрения защиты от инъекций корректно обрабатывать надо не «переданные из формы» данные, а «передаваемые в запрос».
Если тебе указали на ошибку, то лучше попросить объяснить, чем отругиваться.
Я не предлагаю делать эту тупую проверку на "<?".
Эта проверка сама по себе дурацкая и не имеет смысла.
Однако, если сайт вообще делает какую-то проверку, и отвергает какие-то пользовательские данные, то это только его, сайта, дело, и никакого «поступания с чужими данными» здесь нет.
Скажем, есть ограничение на минимальный размер заливаемых картинок. Если я не принимаю картинку размером 32х32, то никакого надругательства над пользовательскими данными я не совершаю.
А чтобы заказчики не звонили, надо просто выдавать внятные сообщения об ошибках и собирать их в отчет, выдаваемый по запросу.
А чтобы на кофейной гуще не гадать — нужно обязательно логировать весь процесс.
Он же никак эти данные не портит, а просто предлагает не принимать.
Сайт и не обязан принимать всё подряд.
Смысла я в такой проверке не вижу, но и никаких проблем с пользовательскими данными — тоже
Но чёрный список заведомо дырявее белого. Всё предусмотреть невозможно. И, скажем, добраться до какого-нибудь файла с паролями можно будет и безо всяких точек.
Многие современные методы обработки картинок бережно сохраняют имеющиеся в файле метаданные.
1. Если эта идея прямо сейчас пришла вам в голову, то надо сначала проверить — насколько она применима в реальной жизни.
2. Если вы к этой идее не имеете вообще никакого отношения, а просто повторяете за кем-то — тем более надо сначала проверить — насколько она применима в реальной жизни. Чтобы не быть одним из миллионов разносчиков мусора.
В качестве домашнего задания попробуйте поискать эти сочетания в любой мало-мальски объемной коллекции заведомо безопасных картинок.
Тем более, что в статье есть более простое решение — запретить исполнение скриптов в этой папке.
Собственно, практически любой фреймфорк запускает PHP файлы в зависимости от пользовательского ввода. Очень часто части запрошенного урла совпадают с названиями файлов/методов имеющихся классов.
А фильтрация всего этого дела остаётся на совести программиста.
habrahabr.ru/post/148999/#comment_5034779
Понятно, что инклюды надо защищать отдельно, но программисты обычно не слишком заботятся о безопасности внутренних инклюдов. А проверку на open_basedir картинка пройдёт спокойно.
Опять же, sun.php.jpg оказывается куда более разрушительным. Так что не все рекомендации в статье одинаково бесполезны.