Дискуссия, которая возникла в комментариях к посту про -555 тазиков , свидетельствует о том, что не для всех очевидно как реагировать на некорректные данные, полученные от пользователя.
Между тем, пример с отрицательным количеством товара, также как и различные XSS, SQL-injections — все это частные случаи, требующие подхода, известного как «Защитное (безопасное) программирование» (Secure programming).
Данная тема довольно часто и подробно рассматривается в специализированной литературе, например, см. «Совершенный код» С. Макконнелла (Steve McConnell, Code Complete), Глава 8 «Защитное программирование».
Приведу небольшую цитату из этой книги (если кто не читал — рекомендую):
Механизм проверки может быть различным и зависит от типа данных/языка/библиотек/фреймворка и т.д. Это могут быть утверждения (assertions), перечислимые типы данных (enum), свойства и так далее. Главное, чтобы в архитектуре приложения проверки были обязательным элементом, логически отделенным от процесса обработки данных.
Касательно реакции на некорректные данные, полученными через пользовательский интерфейс, то, на мой взгляд — нужно быть честным с юзером. Попытка предугадать, что хотел получить пользователь, указав несуществующий почтовый индекс, отрицательное количество товара или некорректный текст вместо свого e-mail — будет самообманом. Мы никогда не узнаем, о чем действительно думал посетитель во время заполнения формы. А значит, не сможем выяснить — какое значение подразумевалось на самом деле.
Вероятно, он опечатался, возможно, какой-то кулхацкер проверял — как тут все работает, а быть может это просто ошибка в интерфейсе.
В любом случае, если происходит ошибка при вводе данных — логично приостановить выполнение программы и сообщить пользователю о том, что введенные данные неверны. (Естественно, речь идет о понятных для пользователя сообщениях, например, «населенного пункта с таким индексом не существует», вместо «http/500, UE throw… incorrect zip… at class N»).
Бытует мнение, что это снизит «дружественность» интерфейса. Это не так. Напротив, ПО станет более понятным, предсказуемым и безопасным — как для пользователя, так и для разработчика. Это легко проверить на практике: достаточно писать такие ошибки в лог, и в последствии проанализировать его содержание.
Стремление добиться того, чтобы программа продолжала выполняться любой ценой, сбрасывая некорректные значения к дефолтным – опасно, и, скорее всего, говорит о том, разработчик не вполне понимает — какой в итоге может оказаться эта цена.
Между тем, пример с отрицательным количеством товара, также как и различные XSS, SQL-injections — все это частные случаи, требующие подхода, известного как «Защитное (безопасное) программирование» (Secure programming).
Данная тема довольно часто и подробно рассматривается в специализированной литературе, например, см. «Совершенный код» С. Макконнелла (Steve McConnell, Code Complete), Глава 8 «Защитное программирование».
Приведу небольшую цитату из этой книги (если кто не читал — рекомендую):
Защитное программирование не означает защиту своего кода словами: «Это так работает!» Его идея совпадает с идеей внимательного вождения, при котором вы готовы к любым выходкам других водителей: вы не пострадаете, даже если они совершат что-то опасное. Вы берете на себя ответственность за собственную защиту и в тех случаях, когда виноват другой водитель.
В защитном программировании главная идея в том, что если методу передаются некорректные данные, то его работа не нарушится, даже если эти данные испорчены по вине другой программы. Обобщая можно сказать, что в программах всегда будут проблемы, программы всегда будут модифицироваться и разумный программист всегда будет учитывать это при разработке кода.
Эта глава рассказывает, как защититься от беспощадного мира неверных данных, событий, которые «никогда» не могут случиться, и других программистских ошибок. Если вы опытный программист, то можете пропустить следующий раздел про обработку входных данных и перейти к разделу 8.2, который расскажет об утверждениях.
8.1. Защита программы от неправильных входных данных.
Вы, возможно, слышали в школе выражение: «Мусор на входе – мусор на выходе» («Garbage in, garbage out»). Это вариант предостережения потребителю от разработчиков ПО: пусть пользователь остерегается.
Для промышленного ПО принцип «мусор на входе – мусор на выходе» не слишком подходит. Хорошая программа никогда не выдаст мусор независимо от того, что было у нее на входе. Вместо этого она использует принципы: «мусор на входе – ничего на выходе», «мусор на входе – сообщение об ошибке на выходе» или «мусор на входе не допускается». По сегодняшним стандартам «мусор на входе – мусор на выходе» — признак небрежного, небезопасного кода.
Существует три основных способа обработки входных мусорных данных, перечисленных далее.
Проверяйте все данные из внешних источников
Получив данные из файла, от пользователя, из сети или любого другого внешнего интерфейса, удостоверьтесь, что все значения попадают в допустимый интервал. Проверьте, что числовые данные имеют разрешенные значения, а строки достаточно коротки чтобы их можно было обработать. Если строка должна содержать определенный набор значений (скажем, идентификатор финансовой транзакции или что-то подобное), проконтролируйте, что это значение допустимо в данном случае, если же нет – отклоните его. Если вы работаете над приложением, требующим соблюдения безопасности, будьте особенно осмотрительны с данными, которые могут атаковать вашу систему: попыткам переполнения буфера, внедренным SQL-командам, внедренному HTML- или XML-коду, переполнения целых чисел, данным передаваемым системным вызовам и т.п.
Проверяйте значение всех входных параметров метода
Проверка значений входных параметров метода практически тоже самое, что и проверка данных из внешнего источника, за исключением того, что все данные поступают из другого метода, а не из внешнего интерфейса. В разделе 8.5 вы узнаете, как определить, какие методы должны проверять свои входные данные.
Решите, как обрабатывать неправильные входные данные
Что делать, если вы обнаружили неверный параметр? В зависимости от ситуации вы можете выбрать один из дюжины подходов, подробно описанных в разделе 8.3
Защитное программирование – это полезное дополнение к другим способам улучшения качества программ, описанным в этой книге. Лучший способ защитного кодирования – изначально не плодить ошибок. Итеративное проектирование, написание псевдокода и тестов до начала кодирования и низкоуровневая проверка соответствия проекту – это все, что помогает избежать добавления дефектов.…
Механизм проверки может быть различным и зависит от типа данных/языка/библиотек/фреймворка и т.д. Это могут быть утверждения (assertions), перечислимые типы данных (enum), свойства и так далее. Главное, чтобы в архитектуре приложения проверки были обязательным элементом, логически отделенным от процесса обработки данных.
Касательно реакции на некорректные данные, полученными через пользовательский интерфейс, то, на мой взгляд — нужно быть честным с юзером. Попытка предугадать, что хотел получить пользователь, указав несуществующий почтовый индекс, отрицательное количество товара или некорректный текст вместо свого e-mail — будет самообманом. Мы никогда не узнаем, о чем действительно думал посетитель во время заполнения формы. А значит, не сможем выяснить — какое значение подразумевалось на самом деле.
Вероятно, он опечатался, возможно, какой-то кулхацкер проверял — как тут все работает, а быть может это просто ошибка в интерфейсе.
В любом случае, если происходит ошибка при вводе данных — логично приостановить выполнение программы и сообщить пользователю о том, что введенные данные неверны. (Естественно, речь идет о понятных для пользователя сообщениях, например, «населенного пункта с таким индексом не существует», вместо «http/500, UE throw… incorrect zip… at class N»).
Бытует мнение, что это снизит «дружественность» интерфейса. Это не так. Напротив, ПО станет более понятным, предсказуемым и безопасным — как для пользователя, так и для разработчика. Это легко проверить на практике: достаточно писать такие ошибки в лог, и в последствии проанализировать его содержание.
Стремление добиться того, чтобы программа продолжала выполняться любой ценой, сбрасывая некорректные значения к дефолтным – опасно, и, скорее всего, говорит о том, разработчик не вполне понимает — какой в итоге может оказаться эта цена.
