Экранирование лишь некоторых символов

@sqlnooby · Регистрация: 22.02.2013

Студворк — интернет-сервис помощи студентам

Здравствуйте!
Есть веб форма. Она экранируется функцией addslashes.
Вся загвоздка в том, что иногда для вводимых данных строго необходимо, чтобы присутствовали знаки типа \ / | ' "
К примеру R'n'B.

В базу данные попадают нормально. При выгрузке в мою форму просмотра содержимого они снова экранируются с помощью addslashes. И выводится только R (это я про пример с R'n'B).

В чём вопрос? Как мне избежать SQL инъекций и прочих напастей (т.е. обеспечить должную безопасность) и в то же время получать при выгрузке эти символы (' " \ | /) без вредя для себя.

Я в этом пока нуб) Помогите, коллеги)

@dapol · 12.09.2013, 13:38

А почему бы, если они нужны, не заменять их на html сущности?

@sqlnooby · 12.09.2013, 15:08 **[ТС]**

htmlspecialchars?
Идея интересная.

@AndreyDyakonov · 12.09.2013, 15:46

Сообщение от sqlnooby

Как мне избежать SQL инъекций

не читать учебники из прошлого века, а использовать PDO, накрайняк MySqli и подготовленные запросы

@nubo · 12.09.2013, 16:24

AndreyDyakonov,

не читать учебники из прошлого века, а использовать PDO, накрайняк MySqli и подготовленные запросы

Причем тут прошлый век? И сегодня есть две разные точки зрения на подготовленные запросы. У них есть и плюсы и минусы.
Если вам они так нравятся, ставьте ИМХО. Про "накрайняк" тоже. Лично мне PDO нравится куда как меньше mysqli, я же не говорю, что PDO накрайняк.

@AndreyDyakonov · 12.09.2013, 17:53

Сообщение от nubo

Причем тут прошлый век?

Не хотел никого обижать.. Пусть будет прошлое десятилетие. Старпёрам ставлю ИМХО, как просили...

Сообщение от nubo

Лично мне PDO нравится куда как меньше mysqli, я же не говорю, что PDO накрайняк.

...
... действительно, ну что я на человека напал... меньше знаешь - крепче спишь!

KOPOJI · 12.09.2013, 19:09

Сообщение от sqlnooby

При выгрузке в мою форму просмотра содержимого они снова экранируются с помощью addslashes

Зачем?

P.S. к SQL-инъекциям это уже не относится, а относится к XSS-инъекциям, и addslashes не нужен, а нужно, как говорили выше, использовать htmlspecialchars.

P.P.S. в некоторых кодировках (не в UTF-8) есть уязвимость при использовании addslashes, используйте лучше библиотечную функцию экранирования данных

@AndreyDyakonov · 12.09.2013, 20:21

Не по теме:

не собираюсь никого обижать.. все эти инъекции, если все делать правильно, это лажа... опасны инъекции второго порядка...

@nubo · 12.09.2013, 21:30

Сообщение от AndreyDyakonov

не собираюсь никого обижать.. все эти инъекции, если все делать правильно, это лажа

Так объяснили бы, что не лажа и как делать правильно. Только без этих смешных выкрутасов про старперов и прошлый век. Нахватаетесь верхушек и сами не понимаете, что советуете.

Собственно нет разницы, где запросы "подготавливаются". В недрах драйвера из плэйсхолдеров или сразу при формирования строки. Важен механизм. А вы советуете ничего не знать, крепко спать, слепо пользоваться готовыми решениями.

Так вот, для транспортировки данных в СУБД используется экранирование. Используется оно непосредственно при формировании запроса, а не на входе данных в скрипт. Именно это и является проблемой ТС. Он обработал данные сразу, а потом столкнулся с задачей возврата их в форму.

Это разные способы обработки. Для базы нужно экранировать спецсимволы обратным слэшем, для вывода в поток заменять их на эквиваленты. Но делать это нужно там, где данные не могут быть использованы иначе.

Другими словами,

Сообщение от sqlnooby

Есть веб форма. Она экранируется функцией addslashes.

это нужно убрать.

Запрос сформировать по правилам безопасности (смотря что применяется в проекте для работы с СУБД). Можно использовать штатные средства библиотеки, можно подготовленные запросы, кому что ближе.

Возвращаемые данные обработать htmlspecialchars().

Не нужно бояться, что что-то может навредить скрипту. Именно это заблуждение (что кто-то что-то введет и все взорвется) и заставляет новичков эранировать все на входе. Магические кавычки давно отменили, зачем повторять ошибки. Спасать нужно СУБД и юзеров.

Что касается подготовленных запросов. Как я и говорил, у них есть не только плюсы, но и минусы.
1. Проигрыш в скорости
2. Потеря читабельности больших запросов (особенно у неименованых плэйсхолдеров)
3. Невозможность получить текст запроса для анализа или дебаггинга без костылей (ну или в логи лезть)
4. "Кросплатформенность" страдает, хотя это конечно довольно редко.

Плюсы тоже есть конечно.
1. (Его же можно рассмотреть как минус, если сделать акцент на первой части фразы.)
Не нужно думать о безопасности.
Это несколько расслабляет.
2. Возможность многократного исполнения (что требуется исключительно редко)
3. Ну и есть еще один небольшой - понты. Что мы и наблюдаем в распираемом ЧСВ

Сообщение от AndreyDyakonov

Пусть будет прошлое десятилетие. Старпёрам ставлю ИМХО, как просили

Так что каждый выбирает свой путь, говорить о том, что простые запросы - прошлый век несколько самонадеянно. Нужно сначала изучить предмет более досконально, потом уже бравировать такими фразами.

@AndreyDyakonov · 12.09.2013, 21:48

Молодца. Объяснили.

Сообщение от nubo

Нахватаетесь верхушек и сами не понимаете, что советуете.

Вы про себя?

Сообщение от nubo

простые запросы - прошлый век несколько самонадеянно

вы не правы.вам никто ничего подобного не говорил.

KOPOJI · 12.09.2013, 23:36

sqlnooby, по теме уже все ответили, будут вопросы - спрашивайте..

Не по теме:

Кликните здесь для просмотра всего текста

Сообщение от nubo

Проигрыш в скорости

всегда, конечно же, и не раз проверенное? Или это тоже "имхо без имхо"? :)

Сообщение от nubo

Потеря читабельности больших запросов

Чем падает читабельность при использовании именованных параметров (а ведь начали говорить именно про PDO?) Чем "читабельнее" строка вида

SQL
1
WHERE foo = '$foo'

строки вида

SQL
1
WHERE foo = :foo

? Или это еще одно имхо без имхо?

Сообщение от nubo

Невозможность получить текст запроса для анализа или дебаггинга без костылей (ну или в логи лезть)

Ну-ка, ну-ка.. А где возможно? В mysql ? В mysqli ? Это вы про это "mysqli_report" ? То же самое, что уже вшито в PDO. И там, и там без "костылей" не получить текст запроса. Ну или не ловить исключение, да, как вариант. Опять же, и там, и там.

Сообщение от nubo

"Кросплатформенность" страдает, хотя это конечно довольно редко

О да..

Не по теме:

Сообщение от nubo

Ну и есть еще один небольшой - понты. Что мы и наблюдаем в распираемом ЧСВ

да, я это часто у вас замечаю :)

P.S. Не имею ни малейшего желания продолжать оффтопить в этой теме насчет чьих-то "ЧСВ", "имхо", и/или еще чего-то. Если кто-то хочет продолжить беседу - создавайте отдельную тему, чтобы не было потом жалоб на "я не хочу быть ТС-ом".

@nubo · 13.09.2013, 08:21

Не по теме:

Сообщение от KOPOJI

Не имею ни малейшего желания продолжать оффтопить

Я верю, верю :) Написать такой язвительный талмуд и заявить об отсутствии желания оффтопить. :D

Не, я на провокацию не поддамся. Про все это можно почитать в официальных источниках, повторять не вижу смысла. Особенно когда это на корм троллям.

@sqlnooby · 13.09.2013, 10:36 **[ТС]**

Всем большое спасибо, коллеги!

Буду тестировать предложенные методы.

Также недавно наткнулся на статью на хабре.
Есть смысл брать готовое решение оттуда?

KOPOJI · 13.09.2013, 10:40

А где вы там увидели готовое решение?

Я вижу только перечень нелепых ошибок и таких же нелепых решений, по большей части..

@sqlnooby · 13.09.2013, 10:46 **[ТС]**

Я про это

PHP
1
2
3
$input_text = strip_tags($_GET['input_text']);
$input_text = htmlspecialchars($input_text);
$input_text = mysql_escape_string($input_text);

KOPOJI · 13.09.2013, 11:21

htmlspecialchars лучше использовать при выводе, а не при записи. strip_tags - по желанию. mysql_escape_string - устарела, используйте вместо нее mysql_real_escape_string, а лучше подготовленные запросы mysqli или PDO

@sqlnub · 13.09.2013, 22:13

Сообщение от sqlnooby

При выгрузке в мою форму просмотра содержимого они снова экранируются с помощью addslashes.

Ваша БД может хакнуть сама себя, или по какой причине вы фильтруете вывод, который все равно когда-то пойдет на вход. Вопрос риторический. Вы не понимаете что делаете отсюда и проблемы.

Было: I'm an R'n'B star. real_escape_string() сделает I\'m an R\'n\'B star. Правильно? В таком виде кавычки не помешают другим кавычкам сообщить запросу что это значение поля, а не идентификатор, не оператор, не ключевое слово и тп. Вы спокойно вставляете значение переменной в запрос внутрь тех самых кавычек и если запрос отпечатать то увидите: ... 'I\'m an R\'n\'B' В таблицу же запишется I'm an R'n'B star. И вы можете получить этот текст как значение поля и записать его куда угодно, в том числе в value input а. Откуда он если снова пойдет в БД - все повторится как будто его ввел пользователь.

Теперь вы, надеюсь, понимаете что к чему.

Единственная закавыка это с хтмлем который лежит, если лежит в БД. Если выводить как есть - можно напороться. Поэтому в случае с хтмл принято поступать наоборот. Записывать как есть, без фильтрации, а выводить через htmlentities(); тем более что там есть опции всякие.

Добавлено через 7 минут
То есть в целом на входе в БД вам надо лишь сделать сам запрос правильным во избежании появления ошибок запроса, а на выводе уже фильтруйте предполагаемый хтмл как угодно. Вот кусочек кода на вывод данных в таблицу. Параметр v означает рендерить или не рендерить хтмл.

PHP
1
2
3
4
if(!$get->v) 
    $td .= htmlentities($row[$cnt], ENT_QUOTES, "UTF-8", false); 
else 
    $td .= strip_tags($row[$cnt], $allowed_tags);

$allowed_tags - тут перечислено несколько тегов, типа p img a из списка в бд. Все просто и понятно.

Новые блоги и статьи Все статьи Все блоги /
Валидация и контроль данных табличной части документа перед записью Maks 22.04.2026 Алгоритм из решения ниже реализован на примере нетипового документа, разработанного в КА2. Задача: контроль и валидация данных табличной части документа перед записью с учетом регламента компании. . .	Отчёт о затраченных материалах за определенный период с макетом печатной формы Maks 21.04.2026 Отчёт из решения ниже размещён в конфигурации КА2. Задача: разработка отчёта по затраченным материалам за определённый период, с возможностью вывода печатной формы отчёта с шапкой и подвалом. В. . .	Отчёт о спецтехнике находящейся в ремонте Maks 20.04.2026 Отчёт из решения ниже размещен в конфигурации КА2. Задача: отобразить спецтехнику, которая на данный момент находится в ремонте. Есть нетиповой документ "Заявка на ремонт спецтехники" который. . .	Памятка для бота и "визитка" для читателей "Semantic Universe Layer (Слой семантической вселенной)" Hrethgir 19.04.2026 Сгенерировано для краткого описания по случаю сборки и компиляции скелета серверного приложения. И пусть после этого скажут, что статьи сгенерированные AI - туфта и не интересно. И это не реклама -. . .
Запрет удаления строк ТЧ документа при определённом условии Maks 19.04.2026 Алгоритм из решения ниже реализован на примере нетипового документа "Аккумуляторы", разработанного в конфигурации КА2. У данного документа есть ТЧ, в которой в зависимости от прав доступа. . .	Модель заражения группы наркоманов alhaos 17.04.2026 Условия задачи сформулированы тут Суть: - Группа наркоманов из 10 человек. - Только один инфицирован ВИЧ. - Колются одной иглой. - Колются раз в день. - Колются последовательно через. . .	Мысли в слух. Про "навсегда". kumehtar 16.04.2026 Подумалось тут, что наверное очень глупо использовать во всяких своих установках понятие "навсегда". Это очень сильное понятие, и я только начинаю понимать край его смысла, не смотря на то что давно. . .	My Business CRM MaGz GoLd 16.04.2026 Всем привет, недавно возникла потребность создать CRM, для личных нужд. Собственно программа предоставляет из себя базу данных клиентов, в которой можно фиксировать звонки, стадии сделки, а также. . .

@sqlnooby 0 / 0 / 0 Регистрация: 22.02.2013 Сообщений: 12

	Экранирование лишь некоторых символов 12.09.2013, 13:35. Показов 2589. Ответов 16 Метки нет (Все метки) Здравствуйте! Есть веб форма. Она экранируется функцией addslashes. Вся загвоздка в том, что иногда для вводимых данных строго необходимо, чтобы присутствовали знаки типа \ / \| ' " К примеру R'n'B. В базу данные попадают нормально. При выгрузке в мою форму просмотра содержимого они снова экранируются с помощью addslashes. И выводится только R (это я про пример с R'n'B). В чём вопрос? Как мне избежать SQL инъекций и прочих напастей (т.е. обеспечить должную безопасность) и в то же время получать при выгрузке эти символы (' " \ \| /) без вредя для себя. Я в этом пока нуб) Помогите, коллеги) 0

@dapol 4 / 4 / 2 Регистрация: 12.09.2013 Сообщений: 73
	12.09.2013, 13:38
	А почему бы, если они нужны, не заменять их на html сущности? 0

@sqlnooby 0 / 0 / 0 Регистрация: 22.02.2013 Сообщений: 12
	12.09.2013, 15:08 [ТС]
	htmlspecialchars? Идея интересная. 0

@AndreyDyakonov
	12.09.2013, 20:21
	Не по теме: не собираюсь никого обижать.. все эти инъекции, если все делать правильно, это лажа... опасны инъекции второго порядка... 0

@sqlnooby 0 / 0 / 0 Регистрация: 22.02.2013 Сообщений: 12
	13.09.2013, 10:36 [ТС]
	Всем большое спасибо, коллеги! Буду тестировать предложенные методы. Также недавно наткнулся на статью на хабре. Есть смысл брать готовое решение оттуда? 0

KOPOJI Почетный модератор 16844 / 6724 / 880 Регистрация: 12.06.2012 Сообщений: 19,967
	13.09.2013, 10:40
	А где вы там увидели готовое решение? Я вижу только перечень нелепых ошибок и таких же нелепых решений, по большей части.. 0

KOPOJI Почетный модератор 16844 / 6724 / 880 Регистрация: 12.06.2012 Сообщений: 19,967
	13.09.2013, 11:21
	htmlspecialchars лучше использовать при выводе, а не при записи. strip_tags - по желанию. mysql_escape_string - устарела, используйте вместо нее mysql_real_escape_string, а лучше подготовленные запросы mysqli или PDO 1