Хранение частей пользовательских данных в файлах для предотвращения внедрения SQL

Question

Я новичок в веб-программировании и изучаю проблемы, связанные с веб-безопасностью.

У меня есть форма, где пользователь может публиковать данные двух типов - давайте назовем их «безопасными» и «небезопасными» (с точки зрения sql).

В большинстве мест рекомендуется хранить обе части данных в базе данных после очистки «небезопасной» части (чтобы сделать ее «безопасной»).

Меня интересует другой подход - хранить «безопасные» данные в базе данных и «небезопасные» данные в файлах (вне базы данных). Конечно, этот подход создает свой собственный набор проблем, связанных с поддержанием связи между файлами и записями в БД. Но есть ли другие серьезные проблемы с этим подходом, особенно связанные с безопасностью?

ОБНОВЛЕНИЕ: Спасибо за ответы! Извиняюсь за то, что не ясно, что я учитывая "безопасно", поэтому некоторые уточнения в порядке. Я использую Django, и форма данные, которые я считаю "безопасными", доступны через "cleaned_data" формы словарь, который делает все необходимое, убегая.

Для целей этого вопроса давайте рассмотрим вики-страницу. Название к вики-странице не нужно прикреплять стили. Таким образом, это может быть доступно через словарь "cleaned_data" формы, который преобразует вводимые пользователем данные в «безопасный» формат. Но так как я хочу предоставить пользователям возможность произвольного стиля я не могу получить доступ к части контента, используя словарь "cleaned_data".

Решает ли файловый подход аспекты безопасности этой проблемы? Или есть другие вопросы безопасности, которые я пропускаю?

Answer 1

Вы знаете "безопасные" данные, о которых говорите? Это не так. Это все небезопасно, и вы должны относиться к нему как к такому. Не храня его в файлах, а создавая правильные операторы SQL.

Как уже упоминали другие, использование подготовленных утверждений или библиотеки, которая имитирует их, - это путь, например,

$db->Execute("insert into foo(x,y,z) values (?,?,?)", array($one, $two, $three));

Answer 2

Разделение ваших данных не защитит вас от внедрения SQL-кода, оно просто ограничит данные, которые могут быть открыты через него, но это не единственный риск атаки. Они также могут удалять данные, добавлять фиктивные данные и т. Д.

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

Что, даже не войдя в кошмар, ваш подход закончится.

В конце концов, зачем вам использовать базу данных, если вы ей не доверяете? Просто используйте простые файлы, если хотите, микс - нет-нет.

Answer 3

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

Answer 4

Что вы считаете «безопасным» и «небезопасным»? Считаете ли вы, что данные с экранированными косыми чертами «безопасны»? Если это так, пожалуйста, не надо.

Использование связанных переменных с заполнителями SQL. Это единственный разумный способ защиты от SQL-инъекций.