Предотвращение неправильного ввода данных

Question

Является ли хорошей практикой полностью делегировать проверку данных ограничениям ядра базы данных?

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

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

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

Answer 1

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

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

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

Answer 2

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

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

Параноик?Мне?Нет, просто испытал.

Answer 3

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

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

Answer 4

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

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

Это хороший ресурс для базовой проверки уязвимостей:

http://ha.ckers.org/xss.html

Answer 5

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

Answer 6

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

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

Answer 7

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

Answer 8

Еще одним недостатком проверки данных из базы данных является то, что часто вы не выполняете проверку одинаково в каждом случае.Фактически, это часто зависит от логики приложения (ролей пользователей), а иногда вам может потребоваться вообще обойти проверку (задания cron и сценарии обслуживания).

Answer 9

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

Answer 10

Я не думаю, что есть один правильный ответ, это зависит от вашего использования.

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

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

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

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