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

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

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

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

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

0

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

0

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

0

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

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

0

AndreyDyakonov,

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

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

0

Сообщение от nubo Причем тут прошлый век?

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

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

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

0

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

Зачем?

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

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

1

0

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1

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

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

Вы про себя?

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

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

0

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

1

0

Всем большое спасибо, коллеги!
Буду тестировать предложенные методы.

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

0

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

0

Я про это

0

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

1

Сообщение от 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 означает рендерить или не рендерить хтмл.

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

1