У меня есть стол test(id,name)
.
Мне нужно вставить значения , как: user's log
, 'my user'
, customer's
.
insert into test values (1,'user's log');
insert into test values (2,''my users'');
insert into test values (3,'customer's');
Я получаю сообщение об ошибке, если я запускаю любое из приведенных выше утверждений.
Если есть какой-либо способ сделать это правильно, пожалуйста, поделитесь. Я не хочу никаких готовых заявлений.
Возможно ли использовать sql escape-механизм?
Ответы:
Строковые литералы
Избавление от одинарных кавычек
'
путем их удвоения ->''
это стандартный способ, который работает, конечно:В старых версиях или если вы все еще работаете с
standard_conforming_strings = off
или, как правило, если вы добавляете строкуE
к объявлению синтаксиса escape-строки Posix , вы также можете использовать обратную косую черту\
:Сама обратная косая черта экранируется другой обратной косой чертой. Но это вообще не желательно.
Если вам приходится иметь дело со множеством одинарных кавычек или несколькими уровнями экранирования, вы можете избежать использования кавычек в PostgreSQL с помощью строк в кавычках :
Чтобы избежать путаницы в кавычках, добавьте уникальный токен к каждой паре:
Который может быть вложен в любое количество уровней:
Обратите внимание, должен ли
$
персонаж иметь особое значение в вашей клиентской программе. Возможно, вам придется избежать этого в дополнение. Это не относится к стандартным клиентам PostgreSQL, таким как psql или pgAdmin.Это все очень полезно для написания функций plpgsql или специальных команд SQL. Тем не менее, это не может облегчить необходимость использования подготовленных операторов или какого-либо другого метода для защиты от внедрения SQL в ваше приложение, когда возможен ввод данных пользователем. Ответ @ Крейга имеет больше об этом. Больше деталей:
Значения внутри Postgres
При работе со значениями в базе данных есть пара полезных функций для правильного цитирования строк:
quote_literal()
илиquote_nullable()
- последний выводит строкуNULL
для нулевого ввода. (Также естьquote_ident()
возможность заключить строки в двойные кавычки, где необходимо получить действительные идентификаторы SQL .)format()
с указателем формата%L
эквивалентноquote_nullable()
.Подобно:
format('%L', string_var)
или,concat()
как правило, бесполезны, так как те не избегают вложенных одинарных кавычек и обратной косой черты.concat_ws()
источник
SELECT $outer$OUT$inner$INNER$inner$ER$outer$;
доказывает, что вложение 2-го уровня здесь не работает.Это очень много плохих миров, потому что ваш вопрос подразумевает, что у вас, вероятно, есть пробелы в SQL-инъекциях в вашем приложении.
Вы должны использовать параметризованные операторы. Для Java используйте
PreparedStatement
с заполнителями . Вы говорите, что не хотите использовать параметризованные операторы, но не объясняете почему , и, честно говоря, это должно быть очень веской причиной, чтобы не использовать их, потому что это самый простой и безопасный способ решения проблемы, которую вы пытаетесь решить. решать.См. Предотвращение внедрения SQL в Java . Не будь следующей жертвой Бобби .
В PgJDBC нет публичной функции для цитирования строк и экранирования. Это отчасти потому, что это может показаться хорошей идеей.
Есть и встроенные функции цитирования
quote_literal
иquote_ident
в PostgreSQL, но они предназначены дляPL/PgSQL
функций, которые используютEXECUTE
. Эти дниquote_literal
в основном устарелиEXECUTE ... USING
, что является параметризованной версией , потому что это безопаснее и проще . Вы не можете использовать их для целей, которые вы здесь объясняете, потому что они являются функциями на стороне сервера.Представьте, что произойдет, если вы получите значение
');DROP SCHEMA public;--
от злонамеренного пользователя. Вы бы произвели:который разбивается на два утверждения и комментарий, который игнорируется:
Упс, там идет ваша база данных.
источник
= ANY(?)
и параметр массива.database is accessed by java
что это напрямую решает вопрос. Для людей, приезжающих сюда, также очень важно знать о потенциальных опасностях, особенно учитывая, что SQL-инъекция является # 1 причиной уязвимости программного обеспечения. Узнав о проблеме, люди могут принимать обоснованные решения относительно того, когда это не имеет значения, например, ваш вариант начальной загрузки.Согласно документации PostgreSQL (4.1.2.1. Строковые константы) :
См. Также параметр standard_conforming_strings , который определяет, работает ли экранирование с обратной косой чертой.
источник
В postgresql, если вы хотите вставить
'
в него значения, то для этого вы должны дать дополнительные'
источник
Вы можете использовать функцию postrgesql chr (int):
источник
Если вам нужно выполнить работу внутри Pg:
to_json(value)
https://www.postgresql.org/docs/9.3/static/functions-json.html#FUNCTIONS-JSON-TABLE
источник
format()
,quote_literal()
илиquote_nullable()
для экранирования кавычек. См .: stackoverflow.com/a/25143945/939860источник
user's log
вместоabc
правильно для начала. Поймай 22