Проверка ввода данных всегда была для меня довольно внутренней борьбой.
На грани добавления реальной инфраструктуры безопасности и кода в наш проект переписывания старых приложений (который до сих пор в значительной степени сохраняет унаследованный код защиты карты и проверки данных), я снова задаюсь вопросом о том, сколько я должен проверять, где и т. д.
За 5 лет работы в качестве профессионального Java-разработчика я создал и усовершенствовал свои персональные правила для проверки правильности ввода данных и мер безопасности. Поскольку я хотел бы улучшить свои методы, я хотел бы услышать некоторые идеи от вас, ребята. Общие правила и процедуры хороши, а также специфичны для Java.
Подводя итог, это мои рекомендации (представлены в трехуровневом стиле веб-приложения) с краткими пояснениями:
Клиентская часть 1-го уровня (браузер): минимальная проверка, только неизменные правила (обязательное поле электронной почты, необходимо выбрать один элемент и т. П.); реже используется дополнительная проверка, например, «от 6 до 20 символов», так как это увеличивает объем работ по обслуживанию изменений (может быть добавлено после стабилизации бизнес-кода);
Серверная часть 1-го уровня (обработка веб-коммуникации, «контроллеры»): у меня нет правила для этого, но я считаю, что здесь должны обрабатываться только ошибки манипулирования данными и сборки / синтаксического анализа (поле дня рождения недопустимо); добавление дополнительной проверки здесь легко делает этот процесс действительно скучным;
2-й уровень (бизнес-уровень): надежная проверка, не менее; формат входных данных, диапазоны, значения, внутренняя проверка состояния, нельзя ли вызывать метод в любое время, пользовательские роли / разрешения и т. д .; используйте как можно меньше пользовательских вводимых данных, при необходимости извлеките их снова из базы данных; если мы также рассматриваем полученные данные базы данных как входные данные, я проверю их только в том случае, если известно, что некоторые конкретные данные ненадежны или достаточно повреждены в БД - строгая типизация выполняет большую часть работы здесь, IMHO;
3-й уровень (уровень данных / DAL / DAO): никогда не считалось, что здесь требуется много проверки, так как только бизнес-уровень должен получить доступ к данным (возможно, в некоторых случаях может быть проверка, например, «param2 не должен быть нулевым, если param1 истинно»); заметьте, однако, что когда я имею в виду «здесь», я имею в виду «код, который обращается к базе данных» или «методы выполнения SQL», сама база данных полностью противоположна;
база данных (модель данных): должна быть продуманной, сильной и самодостаточной, чтобы максимально избежать некорректных и поврежденных данных в БД, с хорошими первичными ключами, внешними ключами, ограничениями, типом данных / длиной / размером / точность и т. д. - я оставляю триггеры из-за этого, так как у них есть свое личное обсуждение.
Я знаю, что ранняя проверка данных хороша и влияет на производительность, но повторная проверка данных - это скучный процесс, и я признаю, что сама проверка данных довольно раздражает. Вот почему так много кодеров пропускают это или делают это наполовину. Кроме того, каждая дублированная проверка является возможной ошибкой, если они не синхронизируются все время. Это основные причины, по которым я в настоящее время предпочитаю, чтобы большинство проверок доходило до бизнес-уровня за счет времени, пропускной способности и ЦП, а исключения обрабатывались в каждом конкретном случае.
так что ты думаешь об этом? Противоположные мнения? У вас есть другие процедуры? Ссылка на такую тему? Любой вклад действителен.
Примечание: если вы думаете о способе работы Java, наше приложение основано на Spring с Spring MVC и MyBatis (производительность и плохая модель базы данных исключают решения ORM); Я планирую добавить Spring Security в качестве нашего поставщика безопасности плюс JSR 303 (Hibernate Validator?)
Благодарность!
Изменить: некоторые дополнительные разъяснения на 3-м слое.
Ответы:
Ваша проверка должна быть последовательной. Поэтому, если пользователь вводит в веб-форму некоторые данные, которые определены как действительные, их не следует отклонять уровнем базы данных из-за некоторых критериев, которые вы не внедрили на стороне клиента.
Как пользователь, ничто не могло бы быть более раздражающим, чем ввод правильной страницы с данными, по-видимому, правильно только после того, как после значительного обращения к базе данных было сказано, что что-то не так. Это было бы особенно верно, если бы я включил некоторую проверку клиента в процессе.
Вы должны проходить валидацию на разных уровнях, поскольку вы их выставляете и потенциально не можете контролировать, кто их вызывает. Таким образом, вы должны организовать (насколько это возможно), чтобы ваша валидация была определена в одном месте и вызвана из любого места, где это необходимо. Как это устроено, будет зависеть от вашего языка и структуры. В Silverlight (например) вы можете определить его на стороне сервера и с подходящими атрибутами он будет скопирован на сторону клиента для использования там.
источник
В реляционной системе я рассматриваю это как трехслойный подход. Каждый слой ограничен следующими:
Идеальным ответом на это будет система , которая позволяет определить ограничения на всех трех слоев в одном месте. Это потребует некоторой генерации кода для SQL и, по крайней мере, некоторой управляемой данными проверки для клиента и сервера.
Я не знаю, есть ли здесь какая-то серебряная пуля ... но поскольку вы работаете в JVM, я бы посоветовал взглянуть на Rhino, чтобы хотя бы разделить код проверки JavaScript между клиентом и сервером. Не пишите свое подтверждение ввода дважды.
источник
Это так неправильно. Самое важное место для проверки - в самой базе данных. На данные почти всегда влияет больше, чем приложение (даже если вы думаете, что это не так), и в лучшем случае безответственно не помещать надлежащие элементы управления в базу данных. Принимая решение не делать этого, теряется целостность данных, чем любой другой фактор. Целостность данных имеет решающее значение для долгосрочного использования базы данных. Я никогда не видел ни одной базы данных, которая не смогла бы обеспечить соблюдение правил целостности на уровне базы данных, которая содержала бы хорошие данные (и я видел данные буквально в тысячах баз данных).
Он говорит это лучше, чем я: http://softarch.97things.oreilly.com/wiki/index.php/Database_as_a_Fortress
источник
Все вышесказанное делает предположение, что разработчики и сопровождающие являются идеальными и пишут идеальный код, который всегда работает идеально. Будущие выпуски программного обеспечения знают обо всех сделанных вами предположениях, которые никогда не документировались, а также о пользователях и хакерах, которые вводят данные в систему так, как вы никогда не представляли.
Конечно, слишком много проверок - это плохо, но при условии, что программы, сети и ОС идеальны, хакеры не пройдут через ваш брандмауэр, администраторы БД не будут вручную «подправлять» базу данных, что, вероятно, хуже.
Нарисуйте граничные круги вокруг объектов, определите режимы отказов, от которых он защищает, и установите соответствующий уровень проверки для этой границы. Например, ваша база данных никогда не должна видеть недействительные данные, но как это могло произойти и что, если это произойдет? Кто ваш пользователь, сколько стоит сбой?
Изучите физические модели безопасности мира, безопасность должна быть в слоях, как лук. Одна толстая стена считается плохой безопасностью. Проверка данных должна рассматриваться так же.
источник
Два коротких общих правила проверки:
Если вы собираетесь вызывать что-либо, что не гарантирует, что оно вернет что-то (ошибка, исключение), чтобы сообщить вам о недопустимом вводе способом, который вы можете передать обратно вызывающей стороне, проверьте его.
Если вы собираетесь делать с данными что-то еще (принимать решения, делать математические операции, сохранять их и т. Д.), Проверяйте их.
источник