Мне надо, чтобы пользователь мог ввести имя пользователя, после чего я создаю его в БД.
Вопрос в том, как это имя правильно заэскейпить, то есть помешать ввести 'xx; drop table'?

Вызов в базу делается через клиентскую библиотеку (а точнее, через питоновскую обёртку над ней). В этих библиотеках есть функция типа exectute(stmt, params), которая умеет подставлять параметры в запрос, но эта подстановка не работает с DDL выражениями.

> Мне надо, чтобы пользователь мог ввести имя пользователя, после чего я
> создаю его в БД.
> Вопрос в том, как это имя правильно заэскейпить, то есть помешать ввести
> 'xx; drop table'?

Analyze This! (с)

Здравствуйте, tdiff, Вы писали:

T>Мне надо, чтобы пользователь мог ввести имя пользователя, после чего я создаю его в БД.
T>Вопрос в том, как это имя правильно заэскейпить, то есть помешать ввести 'xx; drop table'?

Ну, например, если речь идёт об Oracle — пусть вводит Вообще — в данном случае, очевидно, следует наложить на параметр ровно те ограничения, которые действуют в СУБД для имён пользователей, их можно посмотреть в документации. Кроме этого, есть ещё один хороший метод — давать вводить любой бред, а в качестве внутреннего (настоящего) имени использовать хэш от этого бреда. Пусть вводит 'xx; drop table' — Вы создадите ему такого пользователя и он даже сможет под ним работать

Здравствуйте, tdiff, Вы писали:

T>Мне надо, чтобы пользователь мог ввести имя пользователя, после чего я создаю его в БД.
T>Вопрос в том, как это имя правильно заэскейпить, то есть помешать ввести 'xx; drop table'?

Бинди имя пользователя как параметр для запроса.
Ещё лучше -- оберни создание пользователя процедурой, бинди пользователя как параметр процедуры.
Ещё лучше -- не создавай пользователей СУБД вообще, создавай своих собственных пользователей приложения.
Пользователь СУБД вообще-то нужен для одного приложения только один -- владелец объектов БД для приложения.


Если говорить только о экранировании с техн. точки зрения -- тут надо глядеть на СУБД, потому что в
каждой СУБД всё разное, и по разному надо экранировать.

Например, в большинстве СУБД этот запрос

'xx; drop table'

вообще тупо не пройдёт -- будет ошибка синтаксиса, ';' -- недо пустимый символ,
drop table должен быть отдельным батчем.

Применяемые эскейп-последовательности также специфичны для каждой СУБД.

Здравствуйте, MasterZiv, Вы писали:

MZ>Бинди имя пользователя как параметр для запроса.

Это как раз не работает с DDL-выражениями у меня, ни в оракле, ни в постгресе.

MZ>Ещё лучше -- оберни создание пользователя процедурой, бинди пользователя как параметр процедуры.

Это, я полагаю, то же самое.

MZ>Ещё лучше -- не создавай пользователей СУБД вообще, создавай своих собственных пользователей приложения.
MZ>Пользователь СУБД вообще-то нужен для одного приложения только один -- владелец объектов БД для приложения.

У меня как раз задача создать пользователя в БД.

MZ>Применяемые эскейп-последовательности также специфичны для каждой СУБД.

Я надеялся, что в интерфейсе к бд должна быть функция типа "заэскейпить строку", но что-то не нахожу пока.

Здравствуйте, Softwarer, Вы писали:

S>Ну, например, если речь идёт об Oracle — пусть вводит Вообще — в данном случае, очевидно, следует наложить на параметр ровно те ограничения, которые действуют в СУБД для имён пользователей, их можно посмотреть в документации. Кроме этого, есть ещё один хороший метод — давать вводить любой бред, а в качестве внутреннего (настоящего) имени использовать хэш от этого бреда. Пусть вводит 'xx; drop table' — Вы создадите ему такого пользователя и он даже сможет под ним работать

Идея хорошая, но не подходит к моей задаче.

Здравствуйте, tdiff, Вы писали:

T>Мне надо, чтобы пользователь мог ввести имя пользователя, после чего я создаю его в БД.
T>Вопрос в том, как это имя правильно заэскейпить, то есть помешать ввести 'xx; drop table'?

Если нельзя использовать параметры:

* Простой неправильный способ: запретить всё, кроме alphanumeric + более-менее разумное ограничение по длине. Проверять, разумеется, в доверенном коде, а не на стороне пользователя.

* Сложный: ищем в документации на БД аналог вот этого, пишем что-то такое + тесты на всё, включая data truncation attack, надеемся, что ничего не забыли. Тесты неплохо бы и для предыдущего варианта написать, но там они не настолько критичны.

В идеале: использовать оба способа.