Но, в общем, смысл понятен.
Слово «экранирование» просьба употреблять в узком смысле — «экранирование специсмволов в строковых литералах SQL», а не «форматирование произвольных частей SQL запроса, согласно правилам форматирования для них»
Слово «строки» просьба употреблять в узком смысле — «строковые литералы SQL», а не абстрактные строки на стороне клиента и не произвольные части SQL запроса.
И умоляю не писать ужасающих вещей типа «правила форматирования элементов запроса зависят от источника получения данных».
Вместо безусловного соблюдения чётких правил составления запросов (при этом инкапсулированных в библиотеку, а не разбросанных по коду) вводить человеческий фактор — отдавать на откуп программисту решение, форматировать ли переменную — это мина замедленного действия. Один написал переменную и не отформатировал. Другой взял, да и поменял, на такую, которую надо форматировать. Но он же не знал, что у первого в голове. И не отформатировал. Вылезла ошибка.
Вы, по-моему, так и не понимаете, что правила форматирования элементов запроса в ПЕРВУЮ очередь нужны для обеспечения синтаксической корректности SQL, а безопасность — это всего лишь побочный эффект.
И именно ваш подход (пусть девелопер решает, что форматировать, а что — нет) вместо жёсткого следования простому набору правил и приводит в конечном счёте к тому, что инъекции вообще до сих пор существуют.
В общем, спасибо Свете, она мне показала точки зрения, с которых ваши слова не выглядят, как совсем ужасающий бред.
Но умоляю впредь быть точнее в формулировках.
Слово «экранирование» употреблять в узком смысле — «экранирование специсмволов в строковых литералах SQL», а не «форматирование произвольных частей SQL запроса, согласно правилам форматирования для „
Слово “строки» употреблять в узком смысле — «строковые литералы SQL»
по вопросу, форматировать ли элементы запроса, прописанные вручную в скрипте, придерживаться не варианта «всё разрешено, но есть исключения », а наоборот всё форматируем, могут быть исключения "? причём исключения эти ОЧЕНЬ нежелательны. поскольку, во-первых, прямая связь инициализации переменной с форматирвоанием её для помещения в запрос говорит о плохом коде, а во-вторых, вы вносите человеческий фактор в защиту от инхекций. В итоге один программист переменную создал, посчитал ненужной,
Нет-нет. Ты опять всё путаешь :)
Нет никаких «строк, которые экранировать не нужно». По определению строка — это то, что нужно экранировать. Всё остальное — не строка.
Кавычка в вашем примере — это ограничитель строки, а не сама строка.
Константа с названием поля — это не строка. Это идентификатор.
Понимаешь?
Задача у нас одна — составление безопасных SQL запросов.
Без разницы — в админке или в ПО.
И подходы везде одинаковые.
В частности, правила форматирования строк в Mysql такие:
— строка должна быть заключена в кавычки
— в ней должны быть экранированы спецсимволы
Эти правила, увы, никак не зависят от прикладной задачи :)
Я только не понял про «экономию на escape немногих проверенных строк». Ты точно поняла, о чём говорим мы с zerkms? Мы ничего экономить не предлагаем.
Мы предлагаем
1. Всегда соблюдать правила форматирования строк.
2. Любые данные всегда подставлять в запрос только через плейсхолдер.
Что из этого, по-твоему, неприменимо в каких-то частных случаях?
С этим твоим (псевдо)кодом я согласен.
С тем, который был приведён выше — нет. Там нет никакой сборки плейсхолдера, там сборка запроса. Это разные вещи.
Свет.
Я не очень понимаю контекст твоего замечания.
Если ты хочешь вступиться за коллегу, то его основная проблема — заявление
>«Не потому, что строки, а потому что из внешнего источника.»
И ты окажешь ему куда большую услугу, если объяснишь, что всё на самом деле РОВНО наоборот — «Не потому, что из внешнего источника, а потому что строки.»
Писать реализацию плейсхолдеров и других «автоматических правил». Руками. Разве это не очевидно? (я, кстати, как раз сейчас именно об этом пишу в соседнем окне :)
Но разговор-то был не о них совсем.
Если вы отвечали на мой комментарий, а не на пост в целом, то я писал несколько о другом.
Мой богатый опыт общения с начинающими программистами говорит о том, что они попросту не подозревают о существовании такого понятия, как отладка.
И в случае, если их программа не работает, варианта они видят два — либо поискать новый, совсем другой код, либо спросить у кого-нибудь — в чём проблема с имеющимся.
В то время как мой богатый опыт программирования говорит о том, что умение отлаживать код — это один из самых важных навыков программиста, без которого создать и поддерживать что-то осмысленное попросту невозможно.
Когда я прочёл, что работа «несложная» — я насторожился.
Когда в списке даваемых навыков не обнаружил отладки, подрзрение переросло в уверенность — с программистами, увы, полученные в результате клепальщики кода не имеют ничего общего.
И в итоге компания, нанявшая «молодых, перспективных сотрудников» попадёт в ситуацию, подобную описанной в oldmann.livejournal.com/225657.html
С другой стороны, создавать отечественную конкуренцию вездесущим индусам — дело, всё-таки, полезное. Государственной, можно сказать, важности.
Просто в качестве совета на будущее
Даже при ручной сборке запросов также можно пользоваться плейсхолдерами, не колупаясь с форматированием вручную.
И, в любом случае, сборка синтаксически корректного SQL запроса никакого отношения не имеет к валидации данных. Это разные задачи. Рекомендую их не путать.
Драйвер БД у тебя занимается валидацией данных, а форматирование их для помещения в запрос ты делаешь где-то в коде.
Так вот — всё должно быть наоборот! :)
чего-чего?
каких-таких «внутренних данных»?
Ну поймите же уже — нет никакого «экранирования»
Нет никаких «внешних» или «внутренних» данных. Есть только данные, которые идут в SQL запрос. Самому запросу абсолютно всё равно, откуда данные поступали — правила форматирования одинаковы для всех!
Разбрасывать подготовку данных по коду — вот это действительно может послужить причиной серьезных логических ошибок. именно поэтому данные должны форматироваться перед самым попаданием в запрос, и нигде больше.
Именно поэтому мы не можем знать содержимое строки — и, следовательно, обязаны обрабатывать её так, как будто в ней есть спецсимволы
Я только сейчас заметил ещё один классический косяк, от которого отвертеться будет посложнее.
И он, как раз, является прямым следствием представления об искейпинге, как о средстве защиты, в то время как это не более чем скромный форматтер строк:
> «Экранировать надо все внешние данные.»
В этом утверждении, на самом деле, сразу два заблуждения. Одно из них, про «внешние» отметил zerkms
Второе — «все».
Простой пример, который нам показывает, что искейпить «все внешние данные, а не только строки» в некоторых случаях чуть более, чем бессмысленно:
Не стоит упорствовать в глупости.
Любой может затупить или оказаться во власти старинного заблуждения. Это не позор.
Но настаивать на своём, когда тебе указывают на ошибку, да при том такую детскую — вот это уже стыдно.
Вы, как и автор статьи, не понимаете, для чего нужно экранирование. Вы полагаете, что для «безопасности». Хотя на самом деле это всего лишь элемент синтаксиса. Именно требованиями синтаксиса продиктована необходимость искейпинга строк. А безопасность (в данном случае) является всего лишь побочным продуктом.
И строки, которые вы хотите поместить в запрос, выбрав их только что из БД (а так же получив из любого другого источника, включая свой собственный код) необходимо форматировать не потому, что они какие-то «внешние», а потому что таков синтаксис строк в SQL: по краям должны стоять кавычки, а внутри проискейплены спецсимволы. Хочешь добавить в запрос — отформатируй по правилам.
И такая процедура должна быть единообразной.
Программист НЕ ДОЛЖЕН думать о том, какая у него строка или откуда она получена.
Если безопасность зависит внимательности от программиста, то это не безопасность.
Только автоматическое соблюдение правил гарантирует безопасность.
А автоматическое соблюдение правил в свою очередь гарантирует только использование плейсхолдеров. При котором форматирование данных производится скриптом, а не программистом.
Поэтому ваш пример ручной сборки запроса — чудовищен.
Вам должно быть стыдно демонстрировать такой код.
Чувак. Даже после моих подробных ответов на вопросы, которые ты задавал мне в личку, у тебя не получилось :)
Ещё раз повторю одну очень важную вещь: писать статьи надо только на основании ПРАКТИЧЕСКОГО ОПЫТА, а не нахватавшись по-быстрому информации из статей и комментариев.
В контейнер FilesMatch
<FilesMatch \.php$>
AddType application/x-httpd-php .php
</FilesMatch>
Это отобьёт Апачу охоту умничать при определении MIME-типа:
phpfaq.ru/good/blah.php.jpg
phpfaq.ru/good/blah.php
phpfaq.ru/apache/blah.php.jpg — дефолтные настройки.
Поэтому рекомендуется заключать подключение PHP в контейнер
Но, в общем, смысл понятен.
Слово «экранирование» просьба употреблять в узком смысле — «экранирование специсмволов в строковых литералах SQL», а не «форматирование произвольных частей SQL запроса, согласно правилам форматирования для них»
Слово «строки» просьба употреблять в узком смысле — «строковые литералы SQL», а не абстрактные строки на стороне клиента и не произвольные части SQL запроса.
И умоляю не писать ужасающих вещей типа «правила форматирования элементов запроса зависят от источника получения данных».
Вместо безусловного соблюдения чётких правил составления запросов (при этом инкапсулированных в библиотеку, а не разбросанных по коду) вводить человеческий фактор — отдавать на откуп программисту решение, форматировать ли переменную — это мина замедленного действия. Один написал переменную и не отформатировал. Другой взял, да и поменял, на такую, которую надо форматировать. Но он же не знал, что у первого в голове. И не отформатировал. Вылезла ошибка.
Вы, по-моему, так и не понимаете, что правила форматирования элементов запроса в ПЕРВУЮ очередь нужны для обеспечения синтаксической корректности SQL, а безопасность — это всего лишь побочный эффект.
И именно ваш подход (пусть девелопер решает, что форматировать, а что — нет) вместо жёсткого следования простому набору правил и приводит в конечном счёте к тому, что инъекции вообще до сих пор существуют.
Но умоляю впредь быть точнее в формулировках.
Слово «экранирование» употреблять в узком смысле — «экранирование специсмволов в строковых литералах SQL», а не «форматирование произвольных частей SQL запроса, согласно правилам форматирования для „
Слово “строки» употреблять в узком смысле — «строковые литералы SQL»
по вопросу, форматировать ли элементы запроса, прописанные вручную в скрипте, придерживаться не варианта «всё разрешено, но есть исключения », а наоборот всё форматируем, могут быть исключения "? причём исключения эти ОЧЕНЬ нежелательны. поскольку, во-первых, прямая связь инициализации переменной с форматирвоанием её для помещения в запрос говорит о плохом коде, а во-вторых, вы вносите человеческий фактор в защиту от инхекций. В итоге один программист переменную создал, посчитал ненужной,
Нет никаких «строк, которые экранировать не нужно». По определению строка — это то, что нужно экранировать. Всё остальное — не строка.
Кавычка в вашем примере — это ограничитель строки, а не сама строка.
Константа с названием поля — это не строка. Это идентификатор.
Понимаешь?
Задача у нас одна — составление безопасных SQL запросов.
Без разницы — в админке или в ПО.
И подходы везде одинаковые.
В частности, правила форматирования строк в Mysql такие:
— строка должна быть заключена в кавычки
— в ней должны быть экранированы спецсимволы
Эти правила, увы, никак не зависят от прикладной задачи :)
Я только не понял про «экономию на escape немногих проверенных строк». Ты точно поняла, о чём говорим мы с zerkms? Мы ничего экономить не предлагаем.
Мы предлагаем
1. Всегда соблюдать правила форматирования строк.
2. Любые данные всегда подставлять в запрос только через плейсхолдер.
Что из этого, по-твоему, неприменимо в каких-то частных случаях?
С тем, который был приведён выше — нет. Там нет никакой сборки плейсхолдера, там сборка запроса. Это разные вещи.
Свет.
Я не очень понимаю контекст твоего замечания.
Если ты хочешь вступиться за коллегу, то его основная проблема — заявление
>«Не потому, что строки, а потому что из внешнего источника.»
И ты окажешь ему куда большую услугу, если объяснишь, что всё на самом деле РОВНО наоборот — «Не потому, что из внешнего источника, а потому что строки.»
Но разговор-то был не о них совсем.
Мой богатый опыт общения с начинающими программистами говорит о том, что они попросту не подозревают о существовании такого понятия, как отладка.
И в случае, если их программа не работает, варианта они видят два — либо поискать новый, совсем другой код, либо спросить у кого-нибудь — в чём проблема с имеющимся.
В то время как мой богатый опыт программирования говорит о том, что умение отлаживать код — это один из самых важных навыков программиста, без которого создать и поддерживать что-то осмысленное попросту невозможно.
Когда в списке даваемых навыков не обнаружил отладки, подрзрение переросло в уверенность — с программистами, увы, полученные в результате клепальщики кода не имеют ничего общего.
И в итоге компания, нанявшая «молодых, перспективных сотрудников» попадёт в ситуацию, подобную описанной в oldmann.livejournal.com/225657.html
С другой стороны, создавать отечественную конкуренцию вездесущим индусам — дело, всё-таки, полезное. Государственной, можно сказать, важности.
«За всё время существования человечества мотиватор был изобретён только один: морковка. Либо спереди, либо сзади...»
Даже при ручной сборке запросов также можно пользоваться плейсхолдерами, не колупаясь с форматированием вручную.
И, в любом случае, сборка синтаксически корректного SQL запроса никакого отношения не имеет к валидации данных. Это разные задачи. Рекомендую их не путать.
Конкретных аргументов по теме обсуждения нет, есть только невнятные пассы руками.
Спасибо за ваше участие.
Драйвер БД у тебя занимается валидацией данных, а форматирование их для помещения в запрос ты делаешь где-то в коде.
Так вот — всё должно быть наоборот! :)
каких-таких «внутренних данных»?
Ну поймите же уже — нет никакого «экранирования»
Нет никаких «внешних» или «внутренних» данных. Есть только данные, которые идут в SQL запрос. Самому запросу абсолютно всё равно, откуда данные поступали — правила форматирования одинаковы для всех!
Разбрасывать подготовку данных по коду — вот это действительно может послужить причиной серьезных логических ошибок. именно поэтому данные должны форматироваться перед самым попаданием в запрос, и нигде больше.
Именно поэтому мы не можем знать содержимое строки — и, следовательно, обязаны обрабатывать её так, как будто в ней есть спецсимволы
И он, как раз, является прямым следствием представления об искейпинге, как о средстве защиты, в то время как это не более чем скромный форматтер строк:
> «Экранировать надо все внешние данные.»
В этом утверждении, на самом деле, сразу два заблуждения. Одно из них, про «внешние» отметил zerkms
Второе — «все».
Простой пример, который нам показывает, что искейпить «все внешние данные, а не только строки» в некоторых случаях чуть более, чем бессмысленно:
$limit = my_favorite_escaping_function($_GET);
$query = «SELECT * FROM table LIMIT $limit»;
Любой может затупить или оказаться во власти старинного заблуждения. Это не позор.
Но настаивать на своём, когда тебе указывают на ошибку, да при том такую детскую — вот это уже стыдно.
Вы, как и автор статьи, не понимаете, для чего нужно экранирование. Вы полагаете, что для «безопасности». Хотя на самом деле это всего лишь элемент синтаксиса. Именно требованиями синтаксиса продиктована необходимость искейпинга строк. А безопасность (в данном случае) является всего лишь побочным продуктом.
И строки, которые вы хотите поместить в запрос, выбрав их только что из БД (а так же получив из любого другого источника, включая свой собственный код) необходимо форматировать не потому, что они какие-то «внешние», а потому что таков синтаксис строк в SQL: по краям должны стоять кавычки, а внутри проискейплены спецсимволы. Хочешь добавить в запрос — отформатируй по правилам.
И такая процедура должна быть единообразной.
Программист НЕ ДОЛЖЕН думать о том, какая у него строка или откуда она получена.
Если безопасность зависит внимательности от программиста, то это не безопасность.
Только автоматическое соблюдение правил гарантирует безопасность.
А автоматическое соблюдение правил в свою очередь гарантирует только использование плейсхолдеров. При котором форматирование данных производится скриптом, а не программистом.
Поэтому ваш пример ручной сборки запроса — чудовищен.
Вам должно быть стыдно демонстрировать такой код.
Ещё раз повторю одну очень важную вещь: писать статьи надо только на основании ПРАКТИЧЕСКОГО ОПЫТА, а не нахватавшись по-быстрому информации из статей и комментариев.