Разрешить немного SQL в публичном API?

Question

Я предоставляю более или менее публичный API, который позволяет пользователю запрашивать наборы данных из базы данных.Поскольку пользователю необходимо отфильтровать определенные наборы данных, у меня возникает соблазн принять WHERE-часть инструкции SELECT в качестве параметра API.Таким образом, пользователь может выполнять запросы так сложно, как ему хотелось бы, не беспокоясь об загроможденном интерфейсе API.

Мне известно о том, что мне придется отлавливать попытки SQL-внедрения.

Считаете ли вы, что это обойдёт цель слишком оборачивать API-интерфейс в базу данных, или вы считаете это разумным подходом?

Answer 1

В общем, я бы рекомендовал не позволять им вставлять фактические sql в свои запросы

Вы можете позволить им легко отправлять where условия в своем запросе:

<where>
    <condition "field"="name" "operator"="equal" "value"="Fred"/>
</where>

или что-то подобное.

Значение для этого многократное:

1. Вы анализируете каждое условие и проверяете его на правильность перед запуском
2. Вы можете создавать «поддельные» поля, такие как «полное_имя», которые могут не существовать.
3. Вы можете ограничить столбцы, на которые они могут поставить условия
4. Вы можете изолировать пользователей от реальных изменений в вашей базовой базе данных.

Я думаю, что последний пункт на самом деле самый важный. Настанет день, когда вам нужно будет внести изменения в базовую схему базы данных. В конце концов, это произойдет. В этот момент вы по достоинству оцените наличие некоторого уровня «перевода» между тем, что отправляют пользователи, и запросами. Это позволит вам изолировать пользователей от реальных изменений в базовой базе данных.

API должен представлять «абстрагированную» версию самих реальных таблиц, которая отвечает потребностям пользователей, и изолировать их от изменений в реальной базовой базе данных.

Answer 2

Я бы порекомендовал ограничить учетную запись пользователя, изменив разрешения, чтобы разрешить пользователю только SELECT из таблиц.Не разрешайте обновление, вставку или удаление наборов записей.Максимально заблокируйте пользователя, возможно, на уровне таблицы.

Answer 3

Лично я бы не хотел, чтобы пользователи могли передавать SQL напрямую в мою базу данных, риски слишком велики.

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

Answer 4

Если предложение WHERE ограничено только несколькими столбцами, а компаратор ограничен >, = или <, тогда, возможно, вы могли бы просто передать пользователю некоторые дополнительные параметры для представления столбцов и компараторов.Затем вы безопасно создаете WHERE на стороне вашего сервера.

Если это слишком грязно, тогда непременно дайте им пройти полное предложение WHERE - его не так уж сложно очистить, и если вы объедините это свыполнение запроса под заблокированной учетной записью (только SELECT), тогда любой потенциальный ущерб ограничен.